Re: [css-houdini-drafts] TypedOM returning an array of strings isn't a helpful behavior

> For instance, if I am reacting to the user touching the screen to 
progress the animation (swipe to dismiss, page curl animation, etc). I
 think this is one of the general use cases that the Typed OM spec 
targets.

Okay, so you want to be targeting the property at a level where 
variables aren't an issue. You don't want to have to go digging around
 inside an unparsed or partially-parsed value-with-holes-for-variables
 data structure just to do this.  Either read from the computed value,
 or add an additional variable, give it typing information, and 
manipulate *that* in your JS. Then you get good, fully-parsed Typed OM
 objects.

> That being said, it looks more like a work-around than a solution. 
TypedOM is supposed to give me access to object representation of 
values, not force me to decompose my css into a bunch of variables to 
make editing possible at all.

What we keep repeating to you is that prior to computed value, *we 
can't do any significant Typed OM stuff because we don't know what the
 types are*.  You're trying to bring up examples where you just need 
to poke at a dimension or something, but in many cases it is 
*literally impossible* (without full information about how the page 
uses the variable) to tell what a given token represents in a 
pre-substitution value.  

For example, `box-shadow: red 2px 2px var(--foo) 0px;` *looks* like 
the `--foo` var is just setting the blur radius, and so the last 
length is the spread distance. But it *could* be `--foo: , blue 3px;`,
 so that last length is actually the vertical offset on a second 
shadow.  Is this silly? Of course! But it's not something we can 
ignore, and you shouldn't either.

So no, using a separate var is not a workaround, it's *exactly how 
this is supposed to be done*.

(If we have typing information for all the variables in a property, we
 *should* be able to go ahead and do a full grammar 
match/decomposition, and then present you with the full normal Typed 
OM value you'd get without variables; some of the leaf values would 
just be vars rather than the expected type, is all. That's something 
I'm happy to expand this to in level 2, as it's fairly complex for 
implementations.)

> This is something the minimalist structure would do for you.

Again, I explicitly said that having a "generic parse" exposed is a 
Good Idea - it's part of the hand-wavey Parsing API we want to do.  As
 the example you provide points out, there's nothing about this 
request that is var-specific - you're not using a single var in 
`scale(2) * matrix(...) + matrix(...)`, but you still want it broken 
down for you into reasonable chunks.

So this use-case has *nothing* to do with vars, and doesn't belong in 
this thread. Move it to a collection of Parser API use-cases. ^_^

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

Received on Tuesday, 24 May 2016 22:10:28 UTC