W3C home > Mailing lists > Public > www-style@w3.org > July 2013

[cssom] Identifying types and shorthand and unsupported properties

From: Leif Arne Storset <lstorset@opera.com>
Date: Fri, 12 Jul 2013 17:30:41 +0200
Message-ID: <CAAi05dommzpk2CjFDcH45kX96YTQGnS7yc-sBxZReQLk66WpSA@mail.gmail.com>
To: www-style@w3.org
Cc: mail@rodneyrehm.de
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.

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)

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).

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.

[1] http://www.xanthir.com/b4Qi0#4Qi0-14
Received on Friday, 12 July 2013 15:31:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC