On 10/17/19 10:02 PM, ikilpatr...@chromium.org wrote:
On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote:
On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote:
On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren
As far as I know, we never constrain new CSS features to secure
contexts. At least not on the property/value level.

According to
you should be?

"Effective immediately, all new features that are web-exposed are to be
restricted to secure contexts. Web-exposed means that the feature is
observable from a web page or server, whether through JavaScript, CSS,
HTTP, media formats, etc."

True, but we have never applied that policy for CSS features
as far as I know.  Just recently we've added 'column-span',
the ::marker pseudo, new 'display' syntax with values like
'inline list-item', 'block ruby' etc, 'clip-path: path()',
and a long list of other CSS features since 2018.

These features (broadly speaking) are different however. According to the above 
"Exceptions to requiring secure contexts"
" - other browsers already ship the feature insecurely"

Most (all?) of the non-trivial features above have shipped in other browsers 
insecurely before shipping in Firefox, hence the above exception applies.

"subgrid" is different as Firefox is shipping this feature first.

As far as I know we don't even have a mechanism that I could
have used to restrict subgrid to secure contexts.  And to be
clear: I have no intention of blocking subgrid on waiting for
such a mechanism.

This should just involve passing a isSecureContext flag into the your CSS 

Kinda. For this case that'd probably be enough, since you are not introducing a new property... The general case (handle different properties being exposed differently in different contexts) is quite a bit more work, since stuff like serialization of shorthands in a declaration block could change depending on whether you're in a secure context or not, for example.

I'm not particularly convinced of the value of restricting subgrid to secure contexts (specially given no other CSS feature like that actually is, and that it makes the feature harder to use by stuff like frameworks or what not). But if people like Anne or Boris think it's valuable I'm ok making this change. As people have pointed out, the policy is a bit ambiguous as this could be seen as extending an existing feature or a new feature.

AFAICT, modulo paint() in Chrome, which has an associated [SecureContext] JS API, nobody has shipped such a restriction for any new CSS feature whatsoever. For new features we've implemented:

* @supports selector(): https://groups.google.com/d/msg/mozilla.dev.platform/JNLPcIZRd2w/r6Boq0h2BQAJ (I included my rationale for not doing this)

* The syntax changes to the display property: https://groups.google.com/d/msg/mozilla.dev.platform/0WFI1WvBbic/2yVDD9_UCwAJ

* clip-path: path(): https://groups.google.com/d/msg/mozilla.dev.platform/RM5O36MZ4x4/FV5Tp9y4EQAJ

* Various text-decoration bits: https://groups.google.com/d/msg/mozilla.dev.platform/Xsts-2ORpRY/j96vHsIRAAAJ

I guess the last two were implemented by safari at that point so we have that escape hatch.

Chromium hasn't been doing any better either, which I guess it's not necessarily an excuse... From a quick test, CSS.registerProperty and all of Typed OM is available in non-secure contexts.

If people decide that following that post to the letter for the specific case of subgrid is worth it I'm happy to do that, but in general (and based on the above data) I think the post you linked too aggressive, and having a hard mode switch between secure / non-secure contexts, specially for "regular" CSS features that don't have associated Javascript APIs, doesn't sound particularly appealing to me.

And finally, thanks for starting this discussion Ian, I think it's worth clarifying the situation here.

 -- Emilio
dev-platform mailing list

Reply via email to