On Mar 14, 2010, at 1:10 AM, MEM wrote:

> However, if I recall correctly, this very nice property/value par, is not
> well supported cross-browser, that's why I try to avoid it.

As long as you apply it to inline element, ti should be reasonably well 
supported, including IE 6 and 7. Applied to block level elements won't work in 
IE 6 & 7.

> Still, and since I have a float applied, we can rely on display:block; only
> right?

Yes.

> Question, assuming that all my previous assumptions were correct:
> Is it ok to change the nature of a inline element to block ? Silly question
> perhaps, it depends on our/user/layout requirements, but, I mean, should we
> use it with caution (ie. Using mostly with very specific selectors?) (I
> believe I have repeat the same silly question) :) Please reply if it makes
> any sense.

You can always change the display value of (and all) elements, there are no 
limitations beyond what the spec specifies and no particular reason otherwise 
that would prevent from doing so. 

> 
> Almost perfectly clear. Why the line-height doesn't affect the container? Or
> better (or worst) yet, what kind of rule, apply when the element affect the
> container or don't affect it?

The line-box generated by the inner element/line-height wont affect the 
line-box(es) generated on the parent elements generally. The inner (inline) 
element's line-box will overflow the line-box generated by/on the parent 
(block) element eventually, but it won't affect the layout of the block.

> ...
> 
> 
>> I rarely use overflow:hidden for these kind of constructs. If the
>> intent is to contain the floated blocks for 'good' browsers, there are
>> many ways. 
> 
> Now that bugs me. Until know, I thought that, for compliant browsers, the
> only condition that should apply for floats to be contained was that the
> container should be wide enough to contain the child floated elements. And,
> perhaps for consistency cross browser, explicitly declare a width on both,
> container an elements.(don't recall if this is for IE only).

I mean contain in the vertical dimension: floats are removed from the flow, and 
as such don't affect the height of the parent element, unless that parent 
element is set to contain those floats, by having a clearing element inside, or 
use a property that establishes a new block formatting context, per CSS2.1:9.4.1
http://www.w3.org/TR/CSS21/visuren.html#block-formatting

> Yes but, in order to use it, and as far as I know, to have it validate, we
> need to create a separate css file on a conditional comment for ie browsers
> only. Clearly, this will be done but, let's say that we have 140 elements to
> contain the floats.

Hmm. I personally don't care about validation in _that_ way (my stylesheets are 
mostly invalid anyway, by using vendor-prefixed properties); I mostly use the 
CSS validator as a spell checker :-).
If you're concerned about validation, other properties that trigger hasLayout 
can be used (width, height, min/max-width, min-max-height)
http://www.satzansatz.de/cssd/onhavinglayout.html

I always suggest 'zoom:1' because it screams 'hasLayout', and is very easy to 
find in a stylesheet. The other properties all have legitimate uses. When 
reading through / editing / managing a stylesheet, it takes just a little more 
attention to understand if the property is used as a 'hasLayout' trigger or for 
some other reason

>  Should we declare all those elements again on a separate
> css file (assuming this is the best approach), and apply zoom:1; to each of
> them?

You could have a class that does the job and apply it to those elements that 
need it.

I personally avoid having to use multiple stylesheets if possible (performance 
reasons mostly). There is nothing wrong in having a IE-only stylesheet.

Philippe
---
Philippe Wittenbergh
http://l-c-n.com/





______________________________________________________________________
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Reply via email to