184604 2018-04-13 14:57:36 -0700 Correct serialization of Selectors 2023-08-26 00:15:58 -0700 1 1 1 Unclassified WebKit CSS Safari 11 Unspecified Unspecified RESOLVED FIXED https://github.com/w3c/csswg-drafts/issues/8911 https://github.com/w3c/csswg-drafts/issues/8909 BrowserCompat, InRadar P2 Normal --- 257741 1 pascal annevk ahmad.saleem792 annevk bfulgham cdumez karlcow koivisto ntim simon.fraser vojacem webkit-bug-importer oldest_to_newest 1414517 0 337924 pascal 2018-04-13 14:57:36 -0700 Created attachment 337924 Simple reproduction Given a custom tag name with a colon in it (e.g. foo\:bar { font-weight; bold }), the cssText property should return a properly escaped string. Instead, the backslash gets dropped. Attached a simple example; in Chrome and Firefox pressing the button has no visible effect, in Safari the text changes color. This is potentially a regression: https://bugs.webkit.org/show_bug.cgi?id=33725 https://bugs.webkit.org/show_bug.cgi?id=34529 1414520 1 pascal 2018-04-13 15:08:29 -0700 Note, this also happens for other parts of the selector string, for example property names: [ng\:cloak] { display: none; } 1884190 2 bfulgham 2022-07-15 13:56:11 -0700 This continues to be an issue in Safari 15.5+. 1884191 3 webkit-bug-importer 2022-07-15 13:56:23 -0700 <rdar://problem/97092572> 1958530 4 ahmad.saleem792 2023-05-28 09:38:29 -0700 Still issue in Webkit ToT (264635@main). 1959553 5 annevk 2023-06-02 09:17:08 -0700 Pull request: https://github.com/WebKit/WebKit/pull/14629 1959579 6 annevk 2023-06-02 10:57:30 -0700 I filed https://github.com/w3c/csswg-drafts/issues/8909 against the specification. Looking at this more it seems this problem also applies to attributes. I'm somewhat surprised it was not discovered before. 1959675 7 annevk 2023-06-03 00:07:12 -0700 I think there's two bugs at issue here: 1. Selector serialization. We emit the raw identifier rather than the escaped identifier as required by https://drafts.csswg.org/cssom/#serialize-a-simple-selector. 2. Selector representation. For both the prefix and local name we don't represent the universal selector as its own thing internally. We therefore cannot distinguish between the inputs * and \*. Chromium has this problem as well, but only for the prefix. You can kinda fix 1 by serializing a lone * as * and not \*, but that still leaves \* { color:red } doing the wrong thing and also incorrectly getting serialized as * { color:red } The next step here is probably writing web-platform-tests as there appears to be no coverage for these scenarios in css/selectors or anywhere in WebKit's own tests based on my naive fix for 1. 1959695 8 annevk 2023-06-03 07:22:48 -0700 I convinced myself that 1 might not be so desirable after all given how the DOM works. Seems easier to just special case * in a couple of places. I opened https://github.com/w3c/csswg-drafts/issues/8911 to discuss this further and depending on the outcome of that our model will either be validated or we'll have to create some kind of internal representation for *, but I hope not. 1960524 9 ews-feeder 2023-06-08 03:45:25 -0700 Committed 264980@main (892935d504cf): <https://commits.webkit.org/264980@main> Reviewed commits have been landed. Closing PR #14629 and removing active labels. 1973753 10 annevk 2023-08-26 00:15:58 -0700 *** Bug 253041 has been marked as a duplicate of this bug. *** 337924 2018-04-13 14:57:36 -0700 2018-04-13 14:57:36 -0700 Simple reproduction test.html text/html 585 pascal PCFkb2N0eXBlIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+CiAgPG1ldGEgY2hhcnNldD0i VVRGLTgiPgogIDx0aXRsZT5UZXN0PC90aXRsZT4KPC9oZWFkPgo8c3R5bGUgaWQ9InRlc3QiPgog IHBcOmZvbyB7CiAgICBjb2xvcjogcmVkOwogIH0KPC9zdHlsZT4KPC9zdHlsZT4KPGJvZHk+CiAg PHA6Zm9vPlRoaXMgaXMgcmVkLjwvcDpmb28+CiAgPGJ1dHRvbiBpZD0icnVuIj5SZXBsYWNlIHdp dGggY3NzVGV4dDwvYnV0dG9uPgoKICA8c2NyaXB0PgogIGRvY3VtZW50LmdldEVsZW1lbnRCeUlk KCdydW4nKS5vbmNsaWNrID0gKCkgPT4gewogICAgY29uc3Qgbm9kZSA9IGRvY3VtZW50LmdldEVs ZW1lbnRCeUlkKCd0ZXN0Jyk7CgogICAgbGV0IGNvbnRlbnRzID0gJyc7CiAgICBmb3IgKGxldCBp ID0gMDsgaSA8IG5vZGUuc2hlZXQucnVsZXMubGVuZ3RoOyBpKyspIHsKICAgICAgY29udGVudHMg Kz0gbm9kZS5zaGVldC5ydWxlc1tpXS5jc3NUZXh0OwogICAgfQoKICAgIGNvbnNvbGUubG9nKGNv bnRlbnRzKTsKCiAgICBub2RlLmlubmVyVGV4dCA9IGNvbnRlbnRzOwogIH0KICA8L3NjcmlwdD4K PC9ib2R5Pgo8L2h0bWw+