Open Bug 1612602 Opened 4 years ago Updated 2 years ago

[css-pseudo] invalid or empty declaration block in ::selection pseudo-element incorrectly parsed

Categories

(Core :: CSS Parsing and Computation, defect, P3)

defect

Tracking

()

Tracking Status
firefox74 --- affected

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: testcase)

Tests:
div::selection {foo: bar;}
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-051.html

div::selection { }
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-052.html

div::selection {color: foo;}
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-053.html

div::selection {background-color: bar;}
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-054.html

Reference file:
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-051-ref.html

  • Firefox 74.0a1 buildID=20200131013147 fails all 4 tests
  • Chromium 79.0.3945.130 and Epiphany 3.32.1.2 (WebKitGTK+ 2.26.3; stable version release) pass all 4 tests
  • I expect these 4 tests to be part of/merged into the web platform test repository soon
  • I searched for a duplicate and did not find any
  • Linux Debian 10.2 here
Blocks: css-pseudo-4
Keywords: testcase

What's the spec that says that an empty declaration should behave the same as no declaration? Chromium / Epi behave like FF if I set ::selection { width: 10px } or such, which is equally useless. They don't hit this behavior because they optimize empty rules during selector matching (we don't so that devtools can access them).

You have no declaration to parse if the declaration block is empty..., no?
An empty declaration block has to be ineffective (or neutral, if you want) in the sense of rendering effet. Since neither color nor background-color has been specified, then OS-default highlight colors should be in effect.

Setting div::selection { width: 10px } should have no rendering effect of itself... but the UA should nevertheless highlight the content with OS-default highlight colors:
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-052-width10px.html

Chromium / Epi behave like FF if I set ::selection { width: 10px } (...)

If {Firefox, Chromium, Epiphany} do not highlight the "Selected Text" content with OS-default highlight colors, then I think they are wrong.

The priority flag is not set for this bug.
:nordzilla, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enordin)

There's ongoing discussion about the behavior here in https://github.com/w3c/csswg-drafts/issues/4720.

Flags: needinfo?(enordin)
Priority: -- → P3

Emilio,

There is a discussion over in issue 4720 involving presence of fill/stroke. Such discussion may (or may not) or will (or will not) impact the test in bug 1612028 for example. But I do not think that the discussion in issue 4720 may or should or will impact this bug 1612602 here.

Well, in that issue we've clarified what the current behavior is in browsers (which modulo the empty declaration bit, matches across browsers). It's unclear how to change our behavior here without that discussion IMHO.

"
The UA should use the OS-default highlight colors for ::selection when neither color nor background-color has been specified by the author.
"
https://www.w3.org/TR/css-pseudo-4/#highlight-cascade

I think bug 1650174 should be resolved as a DUPLICATE of bug 1612602

I just came across a website that uses:

::selection {
  background: default;
  color: default;
}

And this completely breaks selection on the page. It works fine in chromium. I don't think this should happen; parsing faults in ::selection should fallback to OS settings. It is kind of an anti-pattern to disable selection on websites and I don't think we should enable this anti-pattern by any technical shortcomings.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.