Re: [shadow-dom] Counters and list item counting

On Tue, Feb 19, 2013 at 11:49 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/19/13 2:43 PM, Tab Atkins Jr. wrote:
>> There's some layer-breaching intrinsic to this.  You do have to
>> examine your styles to see if you generate a box.
>
> Well, your styles and the styles of all your ancestors in the flattened
> tree, yes?

Yes.


>> I wouldn't want it to rely on the box tree, though, as that means
>> things like 'order' would affect list item numbering
>
> Mmm... Does 'order' affect z-ordering?

Yes: <http://dev.w3.org/csswg/css3-flexbox/#order-property> "This also
affects the painting order [CSS21], exactly as if the elements were
reordered in the document."


>> not to mention the effects that Elliot brings up.
>
> I'm not clear on what those effects are, actually.  What are they?

For example, if you intend for the component to contain a <ul>, but
pull the <li>s into your shadow tree without their <ul> wrapper,
they'll increment whatever element establishes a list-item counter
scope that's an ancestor of the component (or, if they're scoped to
the shadow tree, as it's a pseudo-document, they'll establish a new
counter on the shadow root).  If you pull out *some* of the <li>s but
not all, they'll be renumbered in the shadow tree from what you
expected them to have in the light tree - for example, if you pull all
the evens into one container and all the odds into another, they'll
both renumber into a dense numbering from 1 to n/2 instead (or, if the
containers didn't establish a counter scope for them, they'll number
consecutively, rather than alternating).  If the content in the light
DOM uses any custom counter rather than a well-known one like
"list-item" (for example, a "chapter" counter), you're completely
screwed, as you're pretty much guaranteed to not establish the counter
they expect, so the numbering will get messed up again.

Basically, any expectation made by counters in the light DOM is
probably bad to break due to shadow DOM reordering.

~TJ

Received on Tuesday, 19 February 2013 20:03:30 UTC