W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

Re: [whatwg] Better DOM hooks for polyfilling CSS properties?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 10 Jul 2014 18:15:45 -0700
Message-ID: <CAAWBYDDOkY_GrJ4pia7zxNiDgg0igCZM=erv8w7OpQ9o26UDVQ@mail.gmail.com>
To: Brian Blakely <anewpage.media@gmail.com>
Cc: WHATWG <whatwg@lists.whatwg.org>
[This discussion belongs on the www-style@w3.org list, not whatwg. I'll
give a perfunctory answer here, but will not follow up. Please start a
thread on www-style if you wish to discuss this further.]

On Jul 10, 2014 2:39 PM, "Brian Blakely" <anewpage.media@gmail.com> wrote:
>
> Problem
> ===
>
> It's difficult to know when an unsupported property was set for any
arbitrary
> element, and manually sifting through stylesheets isn't very easy.
>
> This makes polyfilling CSS harder than it needs to be.
>
> Strawman
> ===
>
> The endgoal is to easily get a NodeList containing elements that have a
> particular invalid/unsupported property applied.
>
> Suggestion 1: Dictionary
> ---
>
> Object populated with information about elements that have a rejected CSS
> property applied.  It updates continuously to reflect the app's most
> current state.
>
> document.rejectedCSSProperties = {
>   "<rejectedPropertyName>": <NodeList>,
>   ...
>   ...
> };
>
> This, combined with Object.observe, would allow authors an extensible way
to
> handle unsupported CSS.
>
> Suggestion 2: Query Method
> ---
>
> document.getElementsByRejectedProperty('foo-bar');
>
> This is the most direct solution.  Maybe more difficult to
implement/maintain
> vendorside.  Should return live NodeLists, a la getElementsByClassName.
>
> Suggestion 3: Event
> ---
>
> document.oncsspropertyrejected = function(event) {
>   element.property // "foo-bar"
>   event.elements // NodeList
> };
>
> Kind of similar semantically to the solution in Suggestion 1, but in a
> more traditional format.  I prefer Suggestion 1, as it offers a
> centralized "registrar" of rejected properties.

CSS very intentionally does not expose invalid properties, to protect our
ability to extend CSS in the future.

Instead, we are adding custom properties with a special syntax that
guarantees no future conflicts will occur: any property name that starts
with two dashes is a custom property, and will be preserved in the cssom
and not otherwise processed by CSS.

The first iteration of custom properties is defined in <
http://dev.w3.org/csswg/css-variables>. This is a simplistic variant,
exposing only the portion of vision properties that is needed for
variables, but the CSS Extensions spec <
http://dev.w3.org/csswg/css-extensions> will define a more complete variant
of the feature, including the ability to easily determine what elements
have a custom property applied to them, and when it changes.

~TJ
Received on Friday, 11 July 2014 01:16:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC