W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2018

[csswg-drafts] [selectors] webkit-prefixed pseudo-elements are always treated valid in WebKit and Blink

From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
Date: Mon, 01 Jan 2018 12:46:23 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-285305507-1514810782-sysbot+gh@w3.org>
upsuper has just created a new issue for https://github.com/w3c/csswg-drafts:

== [selectors] webkit-prefixed pseudo-elements are always treated valid in WebKit and Blink ==
There is a webcompat issue raised against Firefox that Firefox treats rules like the following invalid which breaks some websites:
.promagnifier, .prosettings, .searchsettings, 
.search input[type=search]::-webkit-search-decoration,
.search input[type=search]::-webkit-search-cancel-button,
.search input[type=search]::-webkit-search-results-button,
.search input[type=search]::-webkit-search-results-decoration { 
      display: none !important; }

This is a reasonable behavior since Firefox doesn't support those webkit-prefixed pseudo-elements, and thus, according to [the spec](https://drafts.csswg.org/selectors-4/#invalid), it should treat the whole selector list invalid.

However, at least Blink only supports `-webkit-search-cancel-button`, and doesn't support any other pseudo-element here either, but it doesn't treat the rule invalid.

Then I did some test and I realized that in Blink and WebKit, all pseudo-element prefixed with `-webkit-` is treated valid, as can be shown with the following testcase:
<!DOCTYPE html>
div {
  width: 100px; height: 100px;
  background: red;
div::-webkit-something-invalid-12345, div {
  background: green;

I'm not sure what should we do, then.

Should we spec this behavior that any webkit-prefixed pseudo-element should be accepted even if it's unknown? Or should we push WebKit and Blink to change their behavior here?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2156 using your GitHub account
Received on Monday, 1 January 2018 12:46:28 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:22 UTC