Re: [csswg-drafts] [css-env] Consider value-level parsing like calc() rather than token-level like var()

Ideally it should be restricted to just the selector; I don't particularly want arbitrary substitution of stylesheet contents.

That said, imposing such a restriction would require more work than we probably want to mix into this particular feature.  I guess I should back off of `env()` doing arbitrary substitution thruout the stylesheet, and stick with it being able to substitute in values. (Maybe still want to sub in MQs, tho perhaps that's also best done by Custom MQs...)

So yeah, let's go ahead and make these assumptions:

1. env() is "value-level" - it produces a single terminal value, a la calc(), not a token stream like var()
2. env() will be typed to one of the "simple" terminal types length, number, etc.

Actually, I think we can just lean on the list of possible types for [the attr() function](https://drafts.csswg.org/css-values/#attr-notation); attr() is almost exactly the same feature as env(), just drawing from the element rather than from the document. That also suggests the API shape to handle custom env() - have a map of names to string/type pairs, and parse the string as the type (same as attr()) or else it's invalid and throws.

I'm not sure why I didn't see that parallel before. Hmm tho, that still doesn't let you type-check during parsing, like you can with built-in env() or with attr(); you'd have to wait until you got the custom value set. Hm. I guess we will still have to do something at the call site for this.

-----------

Okay, so we'll set aside custom env() for a moment; I'm confident we can engineer around any problems later. Let's just talk about built-in env().  A built-in env() is typed to one of the attr() types, according to the name given to it, so you can type-check at parse time. (Currently, all the names are lengths.)  I'll rewrite the spec accordingly.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3285#issuecomment-438058255 using your GitHub account

Received on Monday, 12 November 2018 22:55:18 UTC