Re: [css-props-vals] First iteration of L1 spec

On Friday 2015-06-12 00:39 +0000, Greg Whitworth wrote:
> Tab, Shane, Ian and I were able to get together on a video call today and hashed out some of the details regarding what the custom properties and values API can provide, its expected data structures, potential hurdles and some examples.
> 
> Please feel free to provide your feedback regarding the API design and any potential issues we didn't consider.
> 
> http://dev.w3.org/houdini/css-properties-values-api/

Here are some comments on
https://drafts.css-houdini.org/css-properties-values-api/ as of
revision https://hg.css-houdini.org/drafts/rev/94804d3e9678 :


The spec should give a preferred location for feedback (probably
public-houdini), as should all the other houdini specs.

Section 2:  Registering custom properties
=========================================

name:
"This must begin with a double dash" should say what happens if it
doesn't.  Is the registration ignored?  Does it throw an exception?
(Beyond saying that, it's probably not worth an authoring
conformance requirement at the "must" level.)

syntax:
This should actually give a list of the simple types that are
intended to be supported.  There are lots of simple types such as
<single-transition-property> that would add a good bit of
implementation burden for very little value.  (Section 5: Notes does
specifically say this.)

That said, I think the use of simple types here is probably too
constraining.  While providing default types seems useful, I think
allowing a function or functions (e.g., as I described in the last
option in
http://www.w3.org/mid/20150208105940.GA7982@pescadero.dbaron.org )
is probably needed to polyfill the range of CSS properties for which
developers will want to use this.

(However, in that last option, I neglected to handle the possibility
that the input string failed to parse; it would need a way to report
that.  I also neglected the need to provide an interpolation
function.)

Section 3: The apply hook
=========================

Please wrap the comment at a narrower width so it doesn't require
horizontal scrolling.

It's not clear to me that having inputProperties be nullable is a
good idea.  Otherwise this seems like a footgun.

I tend to think this concept requires that specifications define
used values in a much more formal way.  They're currently quite
vague, and not defined in syntactic form.  (Nor, I suspect, do
implementations have a consistent representation of them.)  I think
this may be enough of an obstacle that I would prefer to postpone
this feature to a later level of this specification.

Section 4: Examples
===================

The majority of the examples use type: where they intend to use
syntax:.

It seems better to merge example 1 and example 2 than to provide
example 1 as a broken but slightly simpler example and then fix it
in example 2.

Example 4 is missing its syntax: field due to failure to HTML-escape
"<ident>" with &lt; and &gt;.  It also seems bad form to use boolean
values, even though it's only an example.  The example also doesn't
check the --media-block property, which seems like a bug.  It also
relies on otherwise-undefined "child/width" syntax in
inputProperties.  (And it seems like it ought to use "child/width"
in outputProperties as well.)

Section 5: Notes
================

I didn't follow the "Elephants in the room" subsection" -- or at
least what it was trying to suggest.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)