[css-selectors] Standardize `:(‑moz‑)first‑node` and `:(‑moz‑)last‑node`

[ExE-Boss]

Right now, CSS Selectors 4 defines :first-child and :last-child, which works as such for the following:

span:last-child {
  background-color: lime;
}

<div>
  <span>This doesn’t match.</span>
  <span>This matches.</span>
</div>

<div>
  <span>This matches.</span>
  Some text after.
</div>

For :first-node and :last-node, this would work as follows:

span:last-node {
  background-color: lime;
}

<div>
  <span>This doesn’t match.</span>
  <span>This matches.</span>
  <!-- White-space and comments are ignored when
     - determining whether :last-node matches -->
</div>

<div>
  <span>This doesn’t match.</span>
  Some text after.
</div>

Mozilla Firefox already implements the previous in prefixed form and exposes it to the web.

[emilio]

FWIW, these selectors are somewhat slow, and I planned on trying to hide them from content when I had the chance...

[upsuper]

Selectors mainly work on element level, and extending them to node level may cause some confusing, and ignoring white-space and comments isn't really what "last node" should mean...

[emilio]

Selectors mainly work on element level, and extending them to node level may cause some confusing, and ignoring white-space and comments isn't really what "last node" should mean...

I agree, the only reason these selectors exist at all in Gecko is to implement quirks.

[SelenIT]

The demand to differentiate child elements that don't have any text before them from those that do seems to occur quite often (especially in styling user-generated content, in designing components that can be inserted into arbitrary environment, some more use cases are mentioned in #2208). So it would be great if there would be a standard tool for this, even if the current Gecko's experimental implementation is not perfect (though it's much better than nothing:).

[ExE-Boss]

The demand to differentiate child elements that don't have any text before them from those that do seems to occur quite often (especially in styling user-generated content)

For me it’s elements that don’t have any text after them (eg. the last paragraph in a comment shouldn’t have a bottom margin, but I can’t guarantee that there won’t be any text after it, because I’m dealing with making a custom post style for my posts on forum using a horrible frontend that still uses tables for layout in 2018).

[fantasai]

As the main use case for this is controlling margins, we've added a 'margin-trim' property, see discussion in https://lists.w3.org/Archives/Public/www-style/2018Nov/0005.html

Are there other major use cases for this?

[ExE-Boss]

There are the same use cases as for :first‑child and :last‑child, but I don’t know how major those are.

[simevidas]

I don’t know how important my use-case is, but on my website, I style <strong> elements differently (small caps, extra bold) if they appear before any other text in a paragraph.

Currently, I have to use JavaScript to add a CSS class to these elements, but I would use the :first-node selector instead if it was cross browser.

// add class to paragraphs that begin with a <strong> element
for (let p of article.querySelectorAll('p')) {
  let node = p.childNodes[0];
  if (node && node.nodeName === 'STRONG') {
    p.classList.add('Issue__note');
  }
}

[oriadam]

I have another use case: I style emojione images differently when they appear in the middle of text, than when they are solo.

[tabatkins]

@emilio Can you elaborate on why these are slow? Presumably they're slow in comparison to :first-child? Is it related to the "ignore text nodes that are just whitespace" bit?