Re: [cssom] Identifying types and shorthand and unsupported properties

On Fri, Jul 12, 2013 at 8:30 AM, Leif Arne Storset <lstorset@opera.com> wrote:
> Rodney Rehm tried unsuccessfully to post to this list, and put the
> following on Tab's blog [1] in response to the .specifiedStyle
> proposal.
>
> -Leif
>
> -- Original message --
>
> As a library author I want to identify longhand / shorthand
> properties. This is required so I can ignore margin in favor of
> margin-left et al. Right now this would be handy because we only have
> computedStyle, an returned values for shorthands vary across browsers.
> Even if there is a way to retrieve a proper value for a shorthand,
> this type information is still useful. I could use this in a rendering
> of the CSSOM (a la Dev Tools), ´prevent processing shorthands if there
> are (simpler to parse) longhands, etc.

Except in a few rare cases, this is actually simple to do today.  Do a
getComputedStyle and enumerate it with a for-in loop - every property
exists in it, so you can yank the names off and put them into an array
for further processing.  Then, just check each property to see if it's
a prefix for some other property - if so, it's a shorthand.

The few rare cases are things like border-color, which isn't *quite* a
prefix for border-left-color, so this method will detect 'border-left'
as a shorthand but report that 'border-color' is a longhand; and a few
weird legacy cases where we've made two things be related by a
shorthand well after the fact, and they don't have related names.

But it'll work for 95%+ of cases, and you can manually handle the last
couple of them.

However, I'm not against exposing this somehow, especially since Boris
is okay with it.  ^_^

> As a polyfill author I want to know about unsupported properties. Tab
> made the argument that you could use custom var- properties for that,
> but that would require the CSS author to provide (unnecessary)
> duplicate definition. I wouldn't want this exposed as a regular
> property, rather accessible through a separate list from
> CSSStyleDeclaration. (We will always be "fixing" stuff for older
> browsers)

This just isn't going to happen, sorry.  For one thing, it's
inefficient - browsers store properties in a tightly packed binary
format, where as much as possible they don't remember the exact text
you put in, but rather map the names and values into small integers or
even individual bits.

Variables are an (expensive) exception, where the exact property name
and value has to be preserved.  But they're intentional.  Forcing this
kind of cost on every page, every time you use a property the browser
doesn't understand, would be a bad thing.

More importantly, unknown properties have a lot of uses.  You may be
thinking of just using JS to fill in support for standardized
properties that older browsers don't understand, but a lot of people
will use them to implement entirely new properties in JS.  If we ever
add a property with the same name, we'll clobber their usage and break
their page. This is not good for either party - authors have to deal
with possible breakage at an undetermined time in the future, and we
have to eat compat risk every time we add a new property.

Sticking with the var- prefix for author-defined properties solves all
of the issues, at the cost of requiring one duplication if what you're
using it for is to polyfill support for a property in old browsers.
Given that we all muddled through the bad old days of 4 prefixed
versions of some properties (and some browsers still use prefixes...),
I think a single duplication for things like this is okay.

> As a library/polyfill author I want to know the type(s) a CSS property
> accepts. This is static data. It allows me to control different
> parsing / serialisation modes when processing property values. A map
> like this probably already exists within implementations (for pretty
> much the same reason).

This is potentially complicated to expose, as some properties have
rather complex grammars.  But in many cases, yeah, this should be
fairly simple.  If we only expose a single version of the grammar
(that is, ignore the fact that you can often reorder things), that
would likely simplify it a lot.

I can't speak for other browsers, but at least in Webkit/Blink, many
(most?) properties are parsed with custom code.  We don't just have a
grammar description of the property that we throw at the text.

> There are various serialized presentations of values. Colors (HSLa,
> RGBa, HEX, keywords) are a great example of how we have to parse
> strings in javascript-land simply so we can do some funky calculations
> on them. List-properties (such as animation-*, transition-*,
> box-shadow) require manual splitting. Way more "stupid string
> wrangling" than should really be necessary - considering engines
> already perform these tasks internally. I don't want to have to throw
> kilobytes of javascript at simple and repetitive problems like this.
> In a first step these complex value types should expose their
> components (RGBA: red, green, blue, alpha). In a second step these
> value objects could be enriched with utility functions such as
> lighten(<percentage>) for colors.

Strongly agreed.  There some old efforts to do this, under the name
"CSSOM Values API".  Before he left the group, Anne van Kesteren was
working on it.  Either me, fantasai, zcorpan, or a combination of us
will likely pick it up again soonish.

~TJ

Received on Friday, 12 July 2013 16:18:41 UTC