Re: Proposal for limited :matches pseudoclass

I don't like much the @allow-matches idea, because I think: either you do
things well, or you don't do them at all.
Explicitly: why only :matches? Why a CSS renderer should spawn an animation
thread when no animations are present? Why a CSS renderer should keep an
internal data model (maybe a memory consuming hash map) to optimize CSSOM
modification, if there is no JS (or it doesn't interact with CSS of the
current page)? Why the CSS renderer should compute a complicate inheritance
system when I only use one block per selector? Why the UA should check for
the presence of :hover/:active/etc. any time the mouse moves even if there
is no :hover/:active/etc in the page?
More generally, why not any possible time-consuming feature?

If you want to do things well, you may use something like:
@load-modules <string>*;
where every string is a short css module name
or something like
@profile <string>

But implementing rendering limitations on a per-feature basis is not
adviceable, IMHO.

Giovanni

2009/1/21 Eduard Pascual <herenvardo@gmail.com>

>
> 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?
>
>