Re: [css-d] understading ul li as menus - A 5 question quest.
Philippe --- Sorry for this late reply. I couldn't wish better. All clear. :) (for now) :D Thanks for your time and css teachings on this. Márcio __ 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/
Re: [css-d] understading ul li as menus - A 5 question quest.
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/
Re: [css-d] understading ul li as menus - A 5 question quest.
well the a element is still inline (I was referring to that element in my answer above). Try setting to a to display: inline-block in that test case. I have change to display: inline-block; and, it worked as expected. The padding space on a elements was rendered on the viewport. 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. Still, and since I have a float applied, we can rely on display:block; only right? http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v5.html 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. property, I still can't see any effects on the vertical space augmentation: http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v4.html You apply the line-height to the a element. this won't affect the layout/height of the box which is governed by the line-box generated by the block element (LI in this case). 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? Apply to line-height to the parent block (like the UL or the LI). Ok, and if we do so, let me guess, we also need to change the border and background properties declarations from the A element to the LI, and some other necessary changes. :) Yes? http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v6.html So, I still have doubts here: but because it is an inline element, the excess padding will be clipped by the overflow:hidden. because it seems that, even if we remove the display:inline; property, the padding is still clipped,if we keep that overflow:hidden; declaration. As I explained above, your a element is an inline element. You had originally applied that display:inline to the parent li (iirc). In the testcases above, you float the li, but you apply the padding to the a. And since the A is a inline element by default, with or without overflow, I will get no margin or padding bottom/up here. So, actually, the relation I was assuming between inline and overflow, doesn't exist or, better saying, doesn't exist on the way I was describing? Correct? 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). Google 'containing floats'. if your use of 'overflow:hidden' is solely and only to trigger 'hasLayout' for IE 6 7, you could use 'zoom:1;' 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. 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? Philippe --- Philippe Wittenbergh http://l-c-n.com/ Thank you sooo much. K. Regards, Márcio __ 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/
Re: [css-d] understading ul li as menus - A 5 question quest.
On Mar 7, 2010, at 11:26 PM, MEM wrote: Ingo already gave you an explanation for what that space is (white-space nodes in the html mark-up) When you float the element or otherwise set to to display block, html parsing rules kicks in, and basically those nodes are suppressed for display purposes. A lot to discover here. What are those white-space nodes on html ? Not white-space nodes on html, but all kind of white-space nodes in the whole source code. That include line-feeds, etc. see 16.6.1 The 'white-space' processing model http://www.w3.org/TR/CSS21/text.html#white-space-model What other white-space nodes can we find? Why inline accepts those white spaces and block elements don't ? Is this something to do with box-model ? Does the box model apply to inline elements? Why has a markup language white spaces? No this has nothing to do with any box model, and yes, the box model applies to inline elements (although width and height don't apply to those). 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/
Re: [css-d] understading ul li as menus - A 5 question quest.
On Mar 7, 2010, at 11:26 PM, MEM wrote:
the parent UL DIV are set to 'overflow:hidden', the a elements are
set to display: inline. The padding (top and or bottom) is applied to the
elements, but because it is an inline element, the
excess padding will be clipped by the overflow:hidden.
Ok. But if I remove the display:inline; should the padding-top and bottom of
those elements (that are no longer inline), be rendered on the viewport,
despite the overflow:hidden; declaration ?
If I remove only the display:inline; and I keep the overflow:hidden; I still
can't see the padding effects:
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v3.html
well the a element is still inline (I was referring to that element in my
answer above). Try setting to a to display: inline-block in that test case.
Line-height should affect the layout though.
and if I remove the padding declarations and try to do it with line-height
property, I still can't see any effects on the vertical space augmentation:
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v4.html
You apply the line-height to the a element. this won't affect the
layout/height of the box which is governed by the line-box generated by the
block element (LI in this case). Apply to line-height to the parent block (like
the UL or the LI). or do the same as above: a {display: inline-block;} (or
block)
So, I still have doubts here:
but because it is an inline element, the
excess padding will be clipped by the overflow:hidden.
because it seems that, even if we remove the display:inline; property, the
padding is still clipped,if we keep that overflow:hidden; declaration.
As I explained above, your a element is an inline element. You had originally
applied that display:inline to the parent li (iirc). In the testcases above,
you float the li, but you apply the padding to the a.
Since to accomplish this,
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v2.html
we need to remove the overflow:hidden; declarations, may I presume that, on
this case, this is not the proper hasLayout trigger to sue?
In your opinion, what effective hasLayout trigger can be used here?
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. Google
'containing floats'. if your use of 'overflow:hidden' is solely and only to
trigger 'hasLayout' for IE 6 7, you could use 'zoom:1;'
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/
Re: [css-d] understading ul li as menus - A 5 question quest.
Thank you all for your replies, again.:) I needed some time to test and
think a little...
1)
If we apply overflow property here, will this property
be inherited to descendants even without being declared
on them as inherit ?
see
http://www.w3.org/TR/CSS21/visufx.html#propdef-overflowhttp://www.w3.org/TR/CSS21/visufx.html#propdef-overflow
see
Inherited: no
Clear. :)
2)
How do we call the properties that have this inheritance
capacities?
Having inheritance is something that some properties may
have by default, or the user agents are the responsible
for giving that to some properties?
2.
http://www.w3.org/TR/CSS21/cascade.html#inheritancehttp://www.w3.org/TR/CSS21/cascade.html#inheritance
Each property defines whether it is inherited or not.
see the Inherited? column here
http://www.w3.org/TR/CSS21/propidx.htmlhttp://www.w3.org/TR/CSS21/propidx.html
No doubts here as well, btw, this last link is a very useful table.
3.1)
I see that, to solve it, we can use the float property to
eliminate that extra space between inline elements.
Why is that? Is it because the float property tell us
by definition, that if we have, for example, 3 floated
elements they will/should place themselves on the outer
edge of the previous floated element or container?
Ingo already gave you an explanation for what that space is
(white-space nodes in the html mark-up)
When you float the element or otherwise set to to display block,
html parsing rules kicks in, and basically those nodes are
suppressed for display purposes.
A lot to discover here. What are those white-space nodes on html ? What
other white-space nodes can we find? Why inline accepts those white spaces
and block elements don't ? Is this something to do with box-model ? Does the
box model apply to inline elements? Why has a markup language white spaces?
I realize this is to many questions with two many uncovered holes. I will
try to clarify them with the list help, with time, if you all allow.
David Laakso and others, I was clearly unable to represent the intended
result, this works, either in navegacao class or on the ul related :
.navegacao
{
padding: 20px 0.5em; background: #eee;
float:right;
margin-top:2.5em;
margin-right:0.5em;
overflow:hidden;
}
But the intended result was something more like this:
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v2.html
to accomplish this, I have add padding to the a element.
4)
On the - .navegacao ul li a - declaration block,
we can't add padding-top and bottom, they will not be
rendered on the viewport. Why? Because we are treat them
as inline elements and not, block box elements.
Is this precise?
Why line-height doesn't work either?
the parent UL DIV are set to 'overflow:hidden', the a elements are
set to display: inline. The padding (top and or bottom) is applied to the
elements, but because it is an inline element, the
excess padding will be clipped by the overflow:hidden.
Ok. But if I remove the display:inline; should the padding-top and bottom of
those elements (that are no longer inline), be rendered on the viewport,
despite the overflow:hidden; declaration ?
If I remove only the display:inline; and I keep the overflow:hidden; I still
can't see the padding effects:
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v3.html
Line-height should affect the layout though.
and if I remove the padding declarations and try to do it with line-height
property, I still can't see any effects on the vertical space augmentation:
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v4.html
So, I still have doubts here:
but because it is an inline element, the
excess padding will be clipped by the overflow:hidden.
because it seems that, even if we remove the display:inline; property, the
padding is still clipped,if we keep that overflow:hidden; declaration.
Since to accomplish this,
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests_v2.html
we need to remove the overflow:hidden; declarations, may I presume that, on
this case, this is not the proper hasLayout trigger to sue?
In your opinion, what effective hasLayout trigger can be used here?
Thanks you all,
Márcio
__
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/
Re: [css-d] understading ul li as menus - A 5 question quest.
2010/3/7 Benoit Favreault b...@provokat.ca we need to remove the overflow:hidden; declarations, may I presume that, on this case, this is not the proper hasLayout trigger to sue? In your opinion, what effective hasLayout trigger can be used here? On floats, display : inline is a good hasLayout trigger. It won't be effectively applied because floats are always in block display mode (but the declaration triggers hasLayout anyway), so you can keep using your floats as blocks. Hope this help Benoit Favreault Provokat.ca __ 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/
Re: [css-d] understading ul li as menus - A 5 question quest.
2010/3/7 Benoit Favreault b...@provokat.ca we need to remove the overflow:hidden; declarations, may I presume that, on this case, this is not the proper hasLayout trigger to sue? In your opinion, what effective hasLayout trigger can be used here? On floats, display : inline is a good hasLayout trigger. It won't be effectively applied because floats are always in block display mode (but the declaration triggers hasLayout anyway), so you can keep using your floats as blocks. I didn't follow this thread, but the above is incorrect. floats always *have* a layout. afaik, display:inline is not used to trigger hasLayout, but to prevent the double margin bug. -- Regards, Thierry www.tjkdesign.com | articles and tutorials www.ez-css.org | ultra light CSS framework __ 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/
[css-d] understading ul li as menus - A 5 question quest.
Hello all, Sometimes we learn enough for doing it, and even customize it but, I actually would like to clear some points on the path to properly and precisely understand it. I will try to be as technical as I can at this moment, please correct any concepts that I may get wrong. Thanks a lot. Here is the source information: http://www.nuvemk.com/formacao_lx/outros/ul_li_tests.html - the css styles are inside. On the .navegacao class declaration block: We have a overflow:hidden; declaration. We know that this is for IE proposes only (trigger hasLayout property) we also know that we use it so that this element could contain the descended float elements. However, the immediate descended - ul - has no float property applied to it but the next descended element,- li - has. 1) If we apply overflow property here, will this property be inherited to descendants even without being declared on them as inherit ? 2) How do we call the properties that have this inheritance capacities? Having inheritance is something that some properties may have by default, or the user agents are the responsible for giving that to some properties? 3) The - display:inline; - declaration on - .navegacao ul li - selector, will place our list items inline. However, if we have no float declaration as well, we will have some left and/or(?) right space between inline elements. What space is that? Web developer toolbar show us no margin, neither padding. 3.1) I see that, to solve it, we can use the float property to eliminate that extra space between inline elements. Why is that? Is it because the float property tell us by definition, that if we have, for example, 3 floated elements they will/should place themselves on the outer edge of the previous floated element or container? 4) On the - .navegacao ul li a - declaration block, we can't add padding-top and bottom, they will not be rendered on the viewport. Why? Because we are treat them as inline elements and not, block box elements. Is this precise? Why line-height doesn't work either? 5) The question that make all those be here: how can I put a background on the navigation, that goes beyond the right border height? Since we can have no padding nor line-height, should we apply the background color to a parent element? Which one? Let's imagine that the background color should start on the top and end on the bottom : - - | item1 | | item2 | - - Please help me solve this maze, Márcio __ 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/
Re: [css-d] understading ul li as menus - A 5 question quest.
MEM wrote: Hello all, http://www.nuvemk.com/formacao_lx/outros/ul_li_tests.html - the css styles are inside. 5) The question that make all those be here: how can I put a background on the navigation, that goes beyond the right border height? Since we can have no padding nor line-height, should we apply the background color to a parent element? Which one? Let's imagine that the background color should start on the top and end on the bottom : - - | item1 | | item2 | - - Please help me solve this maze, Márcio Does this do what you after? padding: 20px 0.5em; background: #eee; aside -- beware the IE em font-scaling bug -- since helvetica is in the font-stack why are you feeding Macs arial? /aside Best, ~d -- desktop http://chelseacreekstudio.com/ mobile http://chelseacreekstudio.mobi/ __ 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/
Re: [css-d] understading ul li as menus - A 5 question quest.
David Laakso wrote:
MEM wrote:
Hello all,
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests.html - the css styles
are inside.
aside
-- beware the IE em font-scaling bug
-- since helvetica is in the font-stack why are you feeding Macs arial?
/aside
Best,
~d
Sorry. Should read:
.navegacao
{
padding: 20px 0.5em; background: #eee;
float:right;
margin-top:2.5em;
margin-right:0.5em;
overflow:hidden;
}
--
desktop
http://chelseacreekstudio.com/
mobile
http://chelseacreekstudio.mobi/
__
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/
Re: [css-d] understading ul li as menus - A 5 question quest.
2010/2/28 MEM tal...@gmail.com ... http://www.nuvemk.com/formacao_lx/outros/ul_li_tests.html - the css styles are inside. ... 1) If we apply overflow property here, will this property be inherited to descendants even without being declared on them as inherit ? see http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow see Inherited: no 2) How do we call the properties that have this inheritance capacities? Having inheritance is something that some properties may have by default, or the user agents are the responsible for giving that to some properties? 2. http://www.w3.org/TR/CSS21/cascade.html#inheritance Each property defines whether it is inherited or not. see the Inherited? column here http://www.w3.org/TR/CSS21/propidx.html 3) The - display:inline; - declaration on - .navegacao ul li - selector, will place our list items inline. However, if we have no float declaration as well, we will have some left and/or(?) right space between inline elements. What space is that? Web developer toolbar show us no margin, neither padding. 3. the space between inline elements is the whitespace between them, it's in the HMTL It's no margin and no padding. ... Ingo __ 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/
Re: [css-d] understading ul li as menus - A 5 question quest.
On Mar 1, 2010, at 12:17 AM, MEM wrote:
Here is the source information:
http://www.nuvemk.com/formacao_lx/outros/ul_li_tests.html - the css styles
are inside.
3.1)
I see that, to solve it, we can use the float property to
eliminate that extra space between inline elements.
Why is that? Is it because the float property tell us
by definition, that if we have, for example, 3 floated
elements they will/should place themselves on the outer
edge of the previous floated element or container?
Ingo already gave you an explanation for what that space is (white-space nodes
in the html mark-up)
When you float the element or otherwise set to to display block, html parsing
rules kicks in, and basically those nodes are suppressed for display purposes.
4)
On the - .navegacao ul li a - declaration block,
we can't add padding-top and bottom, they will not be
rendered on the viewport. Why? Because we are treat them
as inline elements and not, block box elements.
Is this precise?
Why line-height doesn't work either?
the parent UL DIV are set to 'overflow:hidden', the a elements are set to
display: inline. The padding (top and or bottom) is applied to the elements,
but because it is an inline element, the excess padding will be clipped by the
overflow:hidden.
Line-height should affect the layout though.
Please play a little with Firebug or Safari's webKit inspector; you can toggle
properties on elements on/off, or add properties as needed/wanted and see the
effect on your layout. It also helps adding background-colours/borders or the
outline property to various elements to see what affects what.
5)
The question that make all those be here: how can I
put a background on the navigation, that goes beyond
the right border height?
Since we can have no padding nor line-height, should
we apply the background color to a parent element?
Which one?
Let's imagine that the background color should start
on the top and end on the bottom :
- -
| item1 | | item2 |
- -
ul {background: lime; padding: 5em 0; } ?
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/
