Emilio Cobos Álvarez
2018-10-16 22:17:28 UTC
Summary:
Fruit of procrastination, I plan to implement (but not ship) David's
proposal for a selector() function in @supports.
See https://github.com/w3c/csswg-drafts/issues/3207 for an explainer,
discussion and context.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1499386
No spec yet, thus I want to keep it behind a pref on nightly-only until
the spec is written and the WG resolves on the details to allow for
gathering feedback and experimentation, provided nobody objects.
Pending details (so far, at least) are whether to use <complex-selector>
or <selector-list> as the argument syntax, and what to do with
unregistered namespaces in selectors. The proposal over-all seems fairly
useful and uncontroversial.
Platform coverage: All
Estimated or target release: 64 / 65, depending on the WG's speed :)
Preference behind which this will be implemented:
layout.css.supports-selector.enabled
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
web-platform-tests: I've included some tentative web-platform-tests in
the patch. If the WG decides something that doesn't match the
implementation I'll update them as needed.
Is this feature restricted to secure contexts?
No, we (or other vendors as far as I know) don't currently restrict
@support feature queries, or the CSS.supports API, or any other CSS
property, to secure contexts.
We could restrict this feature without much trouble, but my feeling is
that there's not much value on doing it. If only it'd prevent usage from
frameworks and other secure-context-agnostic bits, which seems
unfortunate to me, specially since this feature aims to make writing
cross-browser / future-proof CSS easier.
-- Emilio
Fruit of procrastination, I plan to implement (but not ship) David's
proposal for a selector() function in @supports.
See https://github.com/w3c/csswg-drafts/issues/3207 for an explainer,
discussion and context.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1499386
No spec yet, thus I want to keep it behind a pref on nightly-only until
the spec is written and the WG resolves on the details to allow for
gathering feedback and experimentation, provided nobody objects.
Pending details (so far, at least) are whether to use <complex-selector>
or <selector-list> as the argument syntax, and what to do with
unregistered namespaces in selectors. The proposal over-all seems fairly
useful and uncontroversial.
Platform coverage: All
Estimated or target release: 64 / 65, depending on the WG's speed :)
Preference behind which this will be implemented:
layout.css.supports-selector.enabled
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
web-platform-tests: I've included some tentative web-platform-tests in
the patch. If the WG decides something that doesn't match the
implementation I'll update them as needed.
Is this feature restricted to secure contexts?
No, we (or other vendors as far as I know) don't currently restrict
@support feature queries, or the CSS.supports API, or any other CSS
property, to secure contexts.
We could restrict this feature without much trouble, but my feeling is
that there's not much value on doing it. If only it'd prevent usage from
frameworks and other secure-context-agnostic bits, which seems
unfortunate to me, specially since this feature aims to make writing
cross-browser / future-proof CSS easier.
-- Emilio