- From: Sebastian Zartner <sebastianzartner@gmx.de>
- Date: Thu, 26 Apr 2012 00:09:51 +0200
- To: www-style@w3.org
> > I heard that (from [1], for what it's worth) the subject marker is
> > going to be removed soon for performance reasons, so ... we
> > probably shouldn't assume that this still exists.
> >
> I assume part of the functionality will arrive in another form then,
> because it is one of the most requested features. The generic subject
> selector might be overkill, but something similar for just children
> and descendants would be more feasible.
So the same person refusing to implement :contains() with the argument
of performance issues also keeps the subject selector from being
implemented for the same reason.
Are there already measurements, which verify these concerns? From an
outsider view I see IDEs like Eclipse searching text in hundreds of
files within a second. So can somebody explain me what's the problem to
search for text in some text passages?
Of course a '*:contains("long text to check so that this selector
matches")' selector will generally perform worse than a
'#element:contains("a")' selector. But isn't that something, which
should in most cases be done within milliseconds?
Also I assume defining the subject of a selector doesn't cost any
additional performance because it's just marking, which element(s)
inside the selector should be styled.
So having 'OL! > LI:only-child' (as from the spec) would first find all
<li>s, which are the only child of a <ol> and mark the <ol> for styling
at the same time.
> If a subject selector is not introduced and :contains is implemented,
> then I wil predict seeing :contains abused to simulate the feature,
> anyway the problems with dynamic restyling are very similar for the
> two features.
Well, if it's just matching direct text node children, it can't be
abused that way.
> In any case I would argue for :contains matching only direct
> text-nodes, because it avoids the problems with deeper dependencies,
> issues that it would share with any generic subject-selector
> solution.
Anyway, before not implementing any solution for matching node text
contents, I'd also vote for implementing :contains() to match only
direct children.
But of course in combination with some kind of parent selector it would
be much more powerful.
Sebastian
Received on Wednesday, 25 April 2012 22:10:20 UTC