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

Hi David,

Thanks for your detailed feedback.

On Sat, Aug 15, 2015 at 5:04 PM L. David Baron <dbaron@dbaron.org> wrote:

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

I think this is waiting on Tab adding the houdini group to bikeshed.


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

Issue added.


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

Issue added.


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

We can maybe start with simple types in level 1, and expand the grammar in
later levels.


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

I've added an issue tracking a similar problem with the 'syntax' string.


> Section 3: The apply hook
> =========================
>
> Please wrap the comment at a narrower width so it doesn't require
> horizontal scrolling.
>

Done.


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

Issue added.


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

I think that 'used value' in that comment was a mistake. I've adjusted it
to 'computed value' instead - our intention was that this was a processing
step before layout, etc.


> Section 4: Examples
> ===================
>
> The majority of the examples use type: where they intend to use
> syntax:.
>

I don't understand, sorry.


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

Issue added.


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

Example 4 can't work. We either need to rewrite it radically or remove it.
I've added an issue tracking this.


> Section 5: Notes
> ================
>
> I didn't follow the "Elephants in the room" subsection" -- or at
> least what it was trying to suggest.
>

When we drafted this, Greg, Ian and I were all worried about how multiple
independent libraries would interact with each other. There's a tension
between allowing multiple registrars on the one hand and causing weird
load-order-dependent behavior on the other. This topic is listed as a
discussion topic for our f2f.

Cheers,
    -Shane



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