- 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