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 PROTECTED]
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/

Reply via email to