Re: Proposal for limited :matches pseudoclass

First of all, I'd like to thank you Boris for your answers. While they
show up that the facts are quite less encouraging than what I expected
them to be, we (web content authors) need to be aware of the
implementation issues for any given proposal so we can try to figure
out some solution for our needs that doesn't crash into the same
issues.
Now, let's take each issue one by one, and see if we can come up with something:

On Tue, Jan 20, 2009 at 5:22 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> François REMY wrote:
>>
>> From: "Eduard Pascual" <herenvardo@gmail.com>
>>>
>>> It appears to me (please, someone correct me if I am wrong) that the
>>> main concern applies to page-loading, rather than arbitrary
>>> modifications from script
>
> The concerns apply to some of both, actually.  UAs currently make various
> attempts to optimize behavior in the face of post-load DOM modifications too
> (possibly with fallback to "just give up and recompute it all" in some
> cases).
This yields some (even if little) hope: maybe :matches could be
optimized enough so the "just give up and recompute it all" doesn't
trigger too often.

>
>>> so something like a full :matches wouldn't
>>>
>>> really hurt: scripts can anyway tweak the class or id of the root
>>> element.
>
> While true, right now toggling the class on some non-root node is a lot
> faster than toggling it on the root.  The simplest general :matches()
> implementation would make any DOM mutation (any attribute change, node
> insertion, node removal, etc) just as costly as changing the class of the
> root.  There are some obvious optimizations there (e.g. checking for
> attributes that are actually selected on), but DOM modification in general
> will get slower, or there will be a good bit of complexity, with a general
> :matches.
I'm confused now. Let's put some example: given a markup like this:
<ROOT>
<A><whatever>...</whatever></A>
<B><C>...</C></B>
</ROOT>
and a stylesheet with a single rule, whose selector is
B:matches( C) { ... }
would changes within <whatever> be impacted by the presence of such selector?
In a more general approach, given a SOMETHING:matches(anythinghere)
selector, would changes to the DOM *outside* of SOMETHING's subtree be
impacted by the presence of the selector?

Of course, I realize that something like :root:matches( whatever)
would be a "give up" case, but such a selector would be equivalent to
tweaking the root element from script, so authors should expect it to
have an equivalent cost (with the only, but significant, advantage
that this would work even when scripts are disabled).

> Now maybe the complexity is worth it, of course.
That's exactly what I'm trying to figure out; but I need to see the
implementor's side before I can reach any conclusion.

> But in practice complexity
> means you pay either performance or memory or both; that will be the real
> cost from the point of view of web pages.
Of course, everything has a cost. It's just a matter of *how much*
that cost is, and *how much* would we get for that cost.

>>> Actually, if authors try to rely on javascript emulation of
>>> the :matches capability, the impact is even greater
>
> While true, it only affects the authors who want to be affected.  Of course
> one could have optimizations based on whether anything on the page uses
> :matches...  But then adding a single CSS selector will inexplicably degrade
> your DOM performance.  You get that somewhat now with :nth-of-type and
> company, but only in the affected subtrees.
I still don't see how/why the :matches would cause any impact outside
of the "matched" subtree (see my question above), so if you could
clarify this that'd be quite useful.

Anyway, your "only affects the authors who want to be affected" has
given me an idea (not sure how doable would it be, it just popped up
from my brain's backgroundWorker): what about having some sort of
"@allow-matches" at-rule? If it's not present, then any selector using
":matches" is automatically invalid and ignored; and if it's present
authors know* what to expect (* on the part of the spec that defined
such a rule, some warning like "Enabling the :matches pseudo-class
with this rule may have a serious performance impact." would be
appropriate).

>>> - If the blocks containing ":matches" on their selectors were ignored
>>> during initial page loading, would the concerns still be there?
>
> Yes.
Some of your earlier comments already answered that ^^;

>>> - Would it be actually doable to skip such blocks during the initial
>>> loading, and "review" them once the page has been loaded?
>
> Possibly, but that doesn't seem very desirable (esp. given the number of
> pages out there that never finish loading).
Well, with the "yes" answer above, this question becomes pointless.
However, you got me intrigued: pages that never finish loading? Is
that even possible? If you are saying it, I guess it is possible, but
I'm still surprised.

I have some sort of idea related with this, floating in my head; but
it's quite abstract. As soon as I manage to express it in some
understandable form, I'll post it here.

>> Complaining about speed problems is a false argument since editing the
>> class of the root element also can change the whole DOM.
>
> But in this case the web page authors _expects_ it to.  The problem is
> slowness that the web page author doesn't want.  If he's just having a
> little ticker off in the corner, he doesn't expect each tick to cost the
> same as rebuilding the entire presentation.  Nor should it.
Again, please, see my questions above: how/why would changes outside
the ":matched" subtree be affected by the presence of :matches; and
what about the "@allow-matches" rule idea?

Received on Wednesday, 21 January 2009 16:53:43 UTC