Re: Typed CSSOM

On Sun, Aug 9, 2015 at 9:05 PM, Shane Stephens <shans@google.com> wrote:
> Hi houdiños,
>
> Being able to describe the type of CSS values has been an important part of
> the custom properties proposals that we've talked about in this group.
>
> I'd like to explore whether we can extend this notion to JavaScript - i.e.
> provide typed JS objects rather than strings when accessing custom CSS
> values. I'd also like to see whether we can retrofit the existing CSSOM with
> this idea. These ideas were discussed in the January f2f but I don't think
> we've talked about it much on list since.
>
> My reasons are basically those provided in Sydney: converting CSS strings to
> values is tedious, error-prone, and a source of performance problems.
>
> So to get the ball rolling - here's a partial proposal that only covers
> numbers and lengths. Obviously we'll eventually want to expose the rest of
> the types too, but we need to start somewhere :) Bikeshed away!
>
> (1) Access to typed CSSOM
> A new OM can't just start to replace existing CSSOM functionality with typed
> versions because this will break lots of things. Instead we should create a
> new interface, StylePropertyMap, that is accessible alongside the old
> methods:
>
> interface StyleValue {
>   boolean isInitial();
>   boolean isInherit();
>   boolean isDefault();
>   boolean isUnset();
>   attribute DOMString cssString;
> }
>
> interface StylePropertyMap {
>   StyleValue get(DOMString property);
>   sequence<StyleValue> getAll(DOMString property);
>   void set(DOMString property, StyleValue or sequence<StyleValue> or
> DOMString value);
>   void append(DOMString property, StyleValue or sequence<StyleValue> or
> DOMString value);
>   iterable<DOMString, StyleValue or DOMString>;
>   stringifier;
> };
>
> interface ComputedStylePropertyMap : StylePropertyMap {
> };
>
> interface SpecifiedStylePropertyMap : StylePropertyMap {
>   boolean has(DOMString property);
>   sequence<DOMString> getProperties();
> }
>
> partial interface Element {
>   readonly attribute SpecifiedStylePropertyMap styleMap;
> };
>
> partial interface Document {
>   ComputedStylePropertyMap getComputedStyleMap(Element element);
> };
>
> partial interface CSSStyleRule {
>   readonly attribute SpecifiedStylePropertyMap styleMap;
> };
>
> (2) Numbers
>
> Number properties like z-index or opacity should have a very simple
> wrapping:
>
> interface NumberValue : StyleValue {
>   double value;
> }
>
> An open question: where and when does validation happen? What happens if I
> try to set an out-of-range number to opacity? Will this be consistent across
> all properties?
>
> (3) Lengths
>
> Usually, lengths are simple single-unit values (e.g. 50px or 30em). However,
> it is possible for calc values to be used instead. The following API tries
> to capture common use-cases without allowing web devs to accidentally write
> code that will break when calc values are fed in:
>
> enum LengthType {
>   "px", "percent", "em", // ...
> }
>
> interface Length : StyleValue {
>   Length add(Length value); // can throw
>   Length subtract(Length value); // can throw
>   Length multiply(double value); // can throw
>   Length divide(double value); // can throw
>   static Length parse(DOMString cssString);
>   static Length fromValue(double value, LengthType type);
>   static Length fromDictionary({...});
> }
>
> [Constructor(DOMString cssString),
>  Constructor(Length),
>  Constructor({
>   // … all the props.
> })]
> interface CalcLength : Length {
>   attribute double? px;
>   attribute double? percent;
>   attribute double? em;
>   attribute double? ex;
>   attribute double? ch;
>   attribute double? rem;
>   attribute double? vw;
>   attribute double? vh;
>   attribute double? vmin;
>   attribute double? vmax;
>   attribute double? cm;
>   attribute double? mm;
>   attribute double? q;
>   attribute double? in;
>   attribute double? pc;
>   attribute double? pt;
> }
>
> // lengths that are *just* keywords don't become SimpleLengths or
> CalcLengths.
> interface SimpleLength : Length {
>   attribute double value;
>   readonly attribute LengthType type;
> }
>
> In particular, lengths can be manipulated using the Length API without
> knowing whether they're simple or calc expressions. One downside is that
> developers need to check whether a Length is a SimpleLength before
> extracting the Length value - but then again, in practice they should be
> doing this anyway.
>
> (4) Everything else
>
> I realize that there are lots of details missing! Hopefully there's enough
> here to kick off a conversation, though - is this a direction we want to go
> in, and does the API sketched out above look like it could work?
>
> Ideally, I'd like to either start incorporating some of this stuff in the
> CSS Properties and Values specification, or alternatively begin a new ED
> (CSSOM Level 2?) WDYT?
>
> Cheers,
>     -Shane


I think this seems pretty interesting, we've said we need a way to let
developers deal with strings and this seems like a really good start
at it.  The one thing I'd like to propose though is that we build an
official prollyfill (experimental reference implementation) that real
developers can use in order to get real work done.  Having something
that developers can touch and use is way more likely to garner
feedback and I think we want that feedback as soon as possible so we
wind up with something that people actually will use.  Even for people
reading, I feel like you can only evaluate it so much on paper without
touching it.





-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Thursday, 8 October 2015 21:44:45 UTC