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

upsuper · 2018-01-01T12:46:22Z

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, 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>
<style>
div {
  width: 100px; height: 100px;
  background: red;
}
div::-webkit-something-invalid-12345, div {
  background: green;
}
</style>
<div></div>
<script>
  alert(document.styleSheets[0].cssRules[1].cssText);
</script>

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?

The text was updated successfully, but these errors were encountered:

upsuper · 2018-01-01T12:51:49Z

(If we want to spec this behavior, I guess this can happen in either the compat spec, or the selectors spec, but I want to hear from CSSWG for thoughts either way.)

Nadya678 · 2018-01-01T20:50:49Z

Please file a bug to Chromium project and other webkit browsers developers. Invalid a part of selector = invalid whole selector.

The -moz- and -ms- selectors are used to detect functionality and version of browser, In this case for fieldset correction in part of firefox/Chrome browsers we can write:

div::-moz-any-selector-appropriate-for-input, fieldset
{
   display:table-column; /* still existing known bug in Firefox and Chrome */
   /* filtered versions of Firefox from x to y... */
}

Hacks for IE
div::-ms-expand, main
{
   display:block;
   /* ms-expand is for input but here used as hack to change display mode of main to block in this browser */
}

The prefixed pseudoelements doesn't have to be used on appropriate elements for filtering functionality and detecting affected versions of browsers. The parsing proces is OK, then the styles will be applied.

Please read about hacks for EDGE, IE10+ and Firefox.

Here living example - the div is not styled. It is a hack. Also hack to filter the MSIE and EDGE.
This works:
https://jsfiddle.net/Lwfw2k9z/
This doesn't work (unknown pseudoelement):
https://jsfiddle.net/LLawnqzg/

upsuper · 2018-01-02T00:19:30Z

Yeah, it would definitely be a concern as well that other non-WebKit-based browsers may start getting WebKit-specific hacks if they accept webkit-prefixed pseudo-elements unconditionally, but it would also be a concern for WebKit and Blink-based browsers to drop that because that breaks some websites too.

FWIW, it was raised based on Firefox bug 1424106 which was filed for webcompat/web-bugs#14117.

Nadya678 · 2018-01-02T07:06:08Z

If any browser start to "support" (often bugly) foreign -prefixes- - the developers work it without thinking and without knowledge why it is written and... for their risk. Many people can drop their browser if many of webpages will be shown badly. Actually Moz (Thunderbird+Firefox+Gecko based browsers) supports only -moz- extended selectors. The -ms- selectors are supported only by MSIE and EDGE, The -webkit- is supported partially by.. EDGE. EDGE probably due to fact the M$ is ashamed of its own products and EDGE pretends to be a webkit browser even in UserAgent String. In reality the EDGE (12.0) is next version of IE (11.0).

There should not be any exception for -webkit- selectors.

Nadya678 · 2018-01-02T07:31:27Z

BTW. If Chromium / Safari starts support to :-moz-any-selector, the Moz and MS also shall start? The answer is NO. In case of broken layouts on webpages there shall be issued bug to owner of the webpage. Those -prefixed-selectors can be used maliciously against the browsers.

The

.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; }

looks like code from CSS minimizer/precompiler. Probably the minimizer has a bug. CSS Minimizers should not change prefixed selectors.

tabatkins · 2018-01-03T21:15:28Z

@Nadya678 Claiming that broken pages are solely the fault of the page owner is not helpful. Ordinary browser users don't like it when pages look broken; they usually blame the browser for that, especially when it looks fine in other browsers, and so there's often incentives to continue to support hacks if they're sufficiently widespread.

That said, I have no idea what sort of impact this would have in practice. I'm fine with trying to have it removed; if not, I'm fine with it going into the Compat spec.

upsuper · 2018-01-03T22:50:46Z

From Chrome's stats data, webkit unknown pseudo counts ~0.003% of page loads. Maybe it is something low enough for you to consider removing?

css-meeting-bot · 2018-01-04T00:15:12Z

The Working Group just discussed [selectors] webkit-prefixed pseudo-elements are always treated valid in WebKit and Blink.

The full IRC log of that discussion

<dael> Topic: [selectors] webkit-prefixed pseudo-elements are always treated valid in WebKit and Blink
<dael> github: https://github.com//issues/2156
<nainar> I've changed the wiki page to reflect this: https://wiki.csswg.org/planning/sydney-2018
<dael> ??: We don't have any useful statistics yet for webkit. I don't think we have enough information to know how often it happens.
<nainar> s/???/ericwilligers
<dael> florian: Presumably while gathering stats if we can tell the difference between webkit prefix that exists vs nonsense with a webkit prefix. So we can see if we need a short whitelist or a wildcard.
<dael> ericwilligers: I did distinguish but I don't have the data.
<ericwilligers> Chrome bug is crbug.com/547869 The use counter was added in December. We need to wait for this to reach stable before we have useful stats.
<dael> xidorn: It seems to be Chrome has some data for the unknown pseudo elements.
<dael> xidorn: I think it's 0.003% of pages.
<dael> ericwilligers: That's only people running like canary
<dael> Rossen_: Are you saying current data is only on canary which isn't very rep?
<dael> ericwilligers: Yes.
<dael> Rossen_: So fair to say we need to wait a little longer for actual data?
<dael> ericwilligers: Yes, before we can make a blink change.
<dael> Rossen_: Obj to moving on as the Chrome folks are collecting data?

Nadya678 · 2018-01-04T03:12:44Z

what is usage (stats) of it with -ms- and -moz- that are no effect today and will have effect after changes?

It is correct reaction of users if they blame the only-one browser. The hacks are used ONLY if browser has a bug in rendering engine. there in Chromium bugtracker there can be added info to contact webmaster of website first.

The 0.003% is a low figure. It is high time to clarify it before this figure goes up.

BTW. Owners of webpages will report the problem to their webmasters.

SelenIT · 2018-01-04T12:25:35Z

@Nadya678, there was even a petition to browser vendors not to implement -webkit-prefixed features back in 2012, but it was too late. The good thing is that since then browsers stopped to introduce experimental features via prefixes and started to hide them behind the flags instead, so prefixes are mostly a legacy compatibility issue now.

Nadya678 · 2018-01-05T21:06:50Z

Then we now can only drink a for this madness?

Please check Jigsaw validator. The -webkit- styles are treated AS WARNING but :-webkit-pseudoclasses and ::-webkit-pseudoelements are treated as ERRORS.

The shall be drunk by wenbmasters that wrote bugly code without validation of the site. Bon Appetit!!!

If WebKit starts to accept //comments and <!--comments in CSS, the other browsers also should? I can write 100 webpages with these constructions or with construction for EDGE to show the page correctly only in EDGE.

DHTMLX 2.0...

BTW. I think we can add:
@invalid-selectors "allow" | "deny" (default: deny)
but without specification "only -webkit-".

astearns · 2018-01-05T21:47:44Z

@Nadya678 please keep the discussion to the technical issue at hand. Most of your previous comment isn't adding anything useful.

Nadya678 · 2018-01-05T22:33:13Z

Is it possible to make informative campaign - If user opens a webpage with -webkit- selectors, then Mozilla, EDGE and other web-browsers will show information "The webpage uses unknown experimental features of other browser, please contact webmaster of [domain]. Check the 'contact section' to get an e-mail"?

the same feature for ::-moz- and ::-ms- if browser doesn't support. This due to big amount of e-mails shall "help" the webmaster to improve affected webpages.

Regarding -webkit- styles information show only if standard (not-prefixed) style is not included.

csnardi · 2018-04-19T13:16:46Z

The data is now showing ~40% of page loads have unknown -webkit pseudo elements from the Chrome use counter, which is a significant proportion.

tabatkins · 2018-04-19T18:21:40Z

Woah, wtf.

Well, that answers that then. It's almost certainly impossible for us to remove that behavior. We should document it in Compat, then.

ewilligers · 2018-12-07T05:15:00Z

I believe this issue can be closed. Similar issues #3051 and whatwg/compat#103 are already closed.

upsuper added the selectors-4 Current Work label Jan 1, 2018

fantasai added the Agenda+ label Jan 1, 2018

fantasai added Needs Data and removed Agenda+ labels Jan 4, 2018

miketaylr mentioned this issue Jul 11, 2018

webkit-prefixed pseudo-elements are always treated valid in WebKit and Blink whatwg/compat#103

Closed

myakura mentioned this issue Aug 26, 2018

[selectors] Specify the "all ::-webkit-* pseudos are valid" behavior #3051

Closed

ExE-Boss mentioned this issue Sep 5, 2018

[css-selectors] Reconsider removing selector list invalidation #3082

Open

tabatkins closed this as completed Dec 21, 2018

tabatkins added Closed Accepted by Editor Discretion and removed Needs Data labels Dec 21, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

upsuper commented Jan 1, 2018

upsuper commented Jan 1, 2018

Nadya678 commented Jan 1, 2018 •

edited

Loading

upsuper commented Jan 2, 2018 •

edited

Loading

Nadya678 commented Jan 2, 2018 •

edited

Loading

Nadya678 commented Jan 2, 2018 •

edited

Loading

tabatkins commented Jan 3, 2018

upsuper commented Jan 3, 2018

css-meeting-bot commented Jan 4, 2018

Nadya678 commented Jan 4, 2018 •

edited

Loading

SelenIT commented Jan 4, 2018

Nadya678 commented Jan 5, 2018 •

edited

Loading

astearns commented Jan 5, 2018

Nadya678 commented Jan 5, 2018 •

edited

Loading

csnardi commented Apr 19, 2018

tabatkins commented Apr 19, 2018

ewilligers commented Dec 7, 2018

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

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

Comments

upsuper commented Jan 1, 2018

upsuper commented Jan 1, 2018

Nadya678 commented Jan 1, 2018 • edited Loading

upsuper commented Jan 2, 2018 • edited Loading

Nadya678 commented Jan 2, 2018 • edited Loading

Nadya678 commented Jan 2, 2018 • edited Loading

tabatkins commented Jan 3, 2018

upsuper commented Jan 3, 2018

css-meeting-bot commented Jan 4, 2018

Nadya678 commented Jan 4, 2018 • edited Loading

SelenIT commented Jan 4, 2018

Nadya678 commented Jan 5, 2018 • edited Loading

astearns commented Jan 5, 2018

Nadya678 commented Jan 5, 2018 • edited Loading

csnardi commented Apr 19, 2018

tabatkins commented Apr 19, 2018

ewilligers commented Dec 7, 2018

Nadya678 commented Jan 1, 2018 •

edited

Loading

upsuper commented Jan 2, 2018 •

edited

Loading

Nadya678 commented Jan 2, 2018 •

edited

Loading

Nadya678 commented Jan 2, 2018 •

edited

Loading

Nadya678 commented Jan 4, 2018 •

edited

Loading

Nadya678 commented Jan 5, 2018 •

edited

Loading

Nadya678 commented Jan 5, 2018 •

edited

Loading