Re: Selector for tags with a certain child.

On Wed, Oct 8, 2008 at 5:01 PM, Simetrical <simetrical@gmail.com> wrote:

>
> On Wed, Oct 8, 2008 at 3:52 PM, Keiji Ikari <kei@teamikaria.com> wrote:
> > What I would like to be able to do, though, is set a CSS rule which,
> > by some selector, would specify "all <a> tags containing an <img>
> > tag". It would have the effect of using the selector "a img" but then
> > applying the style to the parent of the <img> tag, not the <img> tag
> > itself. This would prevent me from having to modify the classes of
> > every image that was inside a link.
> >
> > On a perhaps somewhat related note, I'd also like to suggest a
> > ":child" generated content selector, similar to ":before" and
> > ":after", except this time behaving as if a <div>...</div> (or
> > <span>...</span> for inline elements) were inserted around all the
> > content of the tag following the rule. In a lot of situations I need
> > to always nest one tag inside another and apply the same style to this
> > nested tag, which leads to HTML being more complicated than it needs
> > to be.
>
> This has been discussed extensively: for a recent occasion, see
> <http://lists.w3.org/Archives/Public/www-style/2008Jul/0442.html> and
> the dozens of replies to that.  The conclusion is that such a selector
> would be much more expensive to implement than a parent selector,
> because it would require reflows during document layout.
>
> In your case, the browser would be forced to begin rendering the <a>
> element, then hit the image and have to erase what it already did and
> start over.  Or else to not even bother rendering the <a> element
> until it verified that it had no <img> children, which could mean that
> display is frozen for a relatively long time, until it finds the </a>
> (however long that is).
>
> These might seem worth it, but consider a rule matching "every body
> element containing a div with class 'abc'".  Consider *multiple* such
> rules.  Such a rule would require the entire document to be reflowed,
> maybe multiple times, as part of incremental layout.  This would be
> noticeably slow and confusing to users, and quite unpleasant.
>
> Therefore, CSS requires the document author to take responsibility for
> using classes, so that the rendering agent can know in advance what it
> has to render.  This allows documents to render faster and more
> smoothly.  UAs are evidently not willing to take the performance hit
> that arbitrary parent selectors could cause in a poorly-optimized
> document.


The discussion spawned off of that thread [1] between me and Boris, though,
came to the conclusion that a simple parent selector wouldn't be overly
burdensome (a previous-adjacent-sibling selector would be worse, a
previous-sibling selector worse still, and an ancestor selector worst of
all).  It can cause reflowing, but the damage is relatively limited (to only
the parent and any siblings+children), and the computational hit of
computing matches is minor in this simple case.

[1]:http://lists.w3.org/Archives/Public/www-style/2008Jul/0603.html

~TJ