942315 - [CSS] Adjacent sibling selector applied despite in-between text nodes

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[BigBossSNK]

Attachment: AdjacentSibling.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1712.4 Safari/537.36

Steps to reproduce:

1. Open the attached HTML file
2. Right-click > Inspect element on the "W3C" link
3. Check if the adjacent sibling selector was applied to the parent <cite> element


Actual results:

The adjacent sibling selector is applied, even though there is a text node (not consisting of white-space) between the sibling candidates.


Expected results:

The text node between the first and second <cite> element should prevent the adjacent sibling selector from being applied.

According to the HTML5 spec (see the Note at http://www.w3.org/html/wg/drafts/html/CR/dom.html#content-models and http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#content-models), two elements are adjacent if
1) There are no other elements between them, and
2) There are no text nodes between them (excluding white-space text nodes).

When the adjacent sibling selector (http://www.w3.org/TR/css3-selectors/#adjacent-sibling-combinators) checks if two elements are adjacent, it checks between the sibling candidates only for other elements.
It should also check for text nodes (excluding white-space).

Comment 1

[mjh563]

According to your last link, text nodes are ignored when calculating adjacent siblings:

"There are two different sibling combinators: the adjacent sibling combinator and the general sibling combinator. In both cases, non-element nodes (e.g. text between elements) are ignored when considering adjacency of elements."

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yep.  HTML and CSS use different definitions of "adjacent".

Comment 3

[BigBossSNK]

True.
Part of the bug report's purpose is to open a discussion as to whether that rule needs to be re-examined.

A practical case for Text Nodes interrupting the adjacent sibling selector is shown in the attachment.

If speed considerations was the only reason the CSS spec chose to consider only elements and not Text Nodes, perhaps it's time to reconsider, and apply HTML's definition as well.
A similar bug report ~1999 was closed because there was no special provision for white-space Text Nodes.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Part of the bug report's purpose is to open a discussion as to whether that rule needs
> to be re-examined.

The right way to do that is by sending mail to [e-mail].

That said, given that the '+' combinator has been shipping in all browsers for years and following the current CSS spec, I would expect that pages depend on its current behavior.  What you're asking for is just a new combinator, which is a reasonable request to send to that list.

> If speed considerations was the only reason the CSS spec chose to consider only
> elements 

It wasn't; in fact it's _slower_ as defined in the CSS spec.  The reason was that all of selector matching only deals with the subtree of the DOM tree composed of elements (with the arguable exception of :empty).