Sent by Ingo Chao on 17 June 2005 08:08
Paul Novitski schrieb:
> At 11:02 PM 6/14/2005, Ingo Chao wrote:
....
>> With your "Holly hack", you force the li to gain layout. But layout li
>> get their own counting context ("having layout means that an element
>> is responsible for drawing its own content"). So, every li counts for
>> itself (1. 1. 1. 1.)
>
>
> I'm interested in learning more about the IE 'has layout' phenomenon as
> it pertains to lists. Can you point me to any resources that address
> that issue specifically? I've found material on Microsoft's hasLayout
> property but nothing really on its effect on lists.
>
> I have seen that IE and Opera lose ordered list item numbering and
> unordered list item bullets when list items are floated left or right or
> given an explicit width. I'd like to learn more about the general
> phenomenon of which those are just two symptoms.
>
Paul, thanks for the reply.
I only have this link to offer: http://www.brunildo.org/test/IEWlispace.php
In the thread http://archivist.incutio.com/viewlist/css-discuss/55841
we discussed about the ordered list plus hasLayout phenomenon, but only
in a side note (and a lot of interesting aspects of hasLayout were
discussed by Bruno, Georg and Philippe).
I have thrown in this example:
>>
..layouted {zoom:1;}
<ol>
<li></li>
<li></li>
<li class="layouted"></li>
<li></li>
<li></li>
</ol>
[ 1. 2. 1. 4. 5. ]
<<
and off-list to Bruno:
>> ... with layout, the element draws only the things "inside" of it ...
the ol loses its list-type number when its outside:
ol {list-style: upper-roman outside; zoom:1; border:1px solid red;}
and gets it back when inside:
ol {list-style: upper-roman inside; zoom:1; border:1px solid red;}
<<
This leads into speculations how that can ever be interpreted. You are a
programmer. Can you imagine a mechanism to easily archive this
counting behavior? Why can 4. know of its number, and 3. not?
>>
Every element which has "layout" could be represented internally by an
single object with its own methods and properties.
<snipped>[some more OT pointless trolling about speculative methods and
properties]</snipped>
So, every element with has layout gets its own little rendering
"viewport", which is completely independent from other objects.
<<
In the end, we thought: what a mess.
All I know is that haslayout is poorly documented, but that little bit
what is documented in the MSDN is not cited very often:
1) "Having layout basically means an element is rectangular."
2) "Internally, having layout means that an element is responsible for
drawing its own content."
3) "If a layout element has contents, the layout of its contents is
determined by its bounding rectangle."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmshtml/html/mshtmleditplatf.asp
The different known bugs in IE6 related to this pseudo-CSS are due to
different combinations of 1), 2) and 3).
In this ol-counter case, it's 2), same to disappearing
backgrounds/elements 2), for the list whitespace bug fix, it's 2)+3),
for most float problems, its 1)+3).
Just ;) try to determine the negation of 2) and 3), the absence of
layout, and there might be a key to some, if not most IE rendering bugs
(or the key to loose mental health).
1)+2)+3) together: they speak of a little "window", and the hasLayout
property would be a flag to indicate that "quality" (my name for it) of
an element, which is internally represented by an object with methods
and properties for counting, clearing, stacking and so on.
haslayout seems to be part of another engine (as Dean Edwards once said
here
http://dean.edwards.name/weblog/2005/03/the-reason/
and here
http://dean.edwards.name/IE7/notes/
).
The other engine is, as I can think of, the contenteditable live editing
engine.
Only elements with that layout quality can be dragged. For example,
dragging a float within the CSS specifications must result in a mess, so
a rectangular entity is more handy. A little bit of hardwiring was
needed, and voila, a dragable float! (and as a result, we see some 3px
jog and other of IE's float model annoyances). Or a dragable list
entity? No problem! (as long as we don't want a working counter for ol).
regards,
Ingo
______________________________________________________________________
css-discuss [EMAIL-REMOVED]]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/