W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [cssom] Throwing on invalid pseudo-elements in getComputedStyle is not web-compatible (#6501)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Aug 2021 16:16:53 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-901247341-1629303411-sysbot+gh@w3.org>
The CSS Working Group just discussed `Throwing on invlaid pseudo-elements in getComputedStyle`, and agreed to the following:

* `RESOLVED: Return empty style if string begins with a colon, return element style otherwise`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Throwing on invlaid pseudo-elements in getComputedStyle<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6501<br>
&lt;fantasai> emilio: resolved to throw in these cases<br>
&lt;fantasai> emilio: I implemented it<br>
&lt;fantasai> emilio: but people do silly things<br>
&lt;fantasai> emilio: and it's not Web-compatible<br>
&lt;fantasai> emilio: One error is passing property names as pseudo-element names<br>
&lt;fantasai> emilio: and one is ???<br>
&lt;jfkthame> s/???/passing 'false'/<br>
&lt;fantasai> emilio: Question is, should we try to do something smarter? Should we return an empty style? Should we not throw and return the element's own style?<br>
&lt;fantasai> emilio: Blink and WebKit return the element's own style<br>
&lt;fantasai> emilio: Firefox does that, but not if pseudo-element starts with two colons<br>
&lt;fantasai> emilio: which is at least a bit more forwards-compatible<br>
&lt;fantasai> astearns: Not returning element style with two-colon strings means we're less likely to have problems when we introduce new pseudo-eements<br>
&lt;fantasai> emilio: Errors we're seeing seem to be mostly typos<br>
&lt;fantasai> emilio: ...<br>
&lt;fantasai> emilio: We could special-case in the IDL<br>
&lt;fantasai> dbaron[m]: Seems the Web-compat probems are strings without double-colon, so could throw on double-colon strings that are also errors<br>
&lt;fantasai> emilio: I'd be OK with that<br>
&lt;fantasai> TabAtkins: Don't have a strong opinion, whatever is both Web- and forwards-compatible<br>
&lt;fantasai> TabAtkins: document legacy weirdness<br>
&lt;fantasai> astearns: We'd resolved on throwing rather than empty style before, why did we decide that?<br>
&lt;fantasai> emilio: usually better, but optimistic that we could get away with it<br>
&lt;fantasai> emilio: anyone object to returning empty style if string begins with colon, otherwise return element style?<br>
&lt;dbaron[m]> the cases where we need to worry about fowards compat are (we think) the start-with-colon case<br>
&lt;dbaron[m]> s<br>
&lt;fantasai> iank_: Does this paint us into a corner for slot pseudos or anything like that?<br>
&lt;fantasai> emilio: I don't think so<br>
&lt;fantasai> emilio: If you do '::slotted' there's no style to return, multiple elements can match it<br>
&lt;fantasai> astearns: objections?<br>
&lt;fantasai> RESOLVED: Return empty style if string begins with a colon, return element style otherwise<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6501#issuecomment-901247341 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 August 2021 16:16:55 UTC

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