- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 May 2016 23:39:54 +0000
- To: public-houdini-archive@w3.org
> If me, author, knows that I will set the variable to a length, I can go ahead and update the next numeric component by setting its value to something else, then reassign the whole thing to the style. I will have to formally make that assumption, no "pre-parsing as a list of box-shadow" will be made for me, but I am still free to write code based on that assumption and modify the raw data. You, writing the entire page and never making mistakes in your code, are not the only audience we're optimizing towards. We should worry about multi-person teams, or you interacting with older code you wrote and no longer fully remember, etc. And in these situations, making assumptions about how an anonymous token will be used is dangerous and error-prone. And, as I *keep* pointing out, at *absolute best*, we can still only offer a useful representation for a handful of values (mostly just numbers and dimensions). For a lot of other values we can't do anything more useful than a string, and that's dumb - dealing with colors in arbitrary formats is just as annoying as having to parse CSS directly. Optimizing for this situation is throwing good money after bad. On the other hand, just adding another var for the spread value, giving it a type, and then manipulating that is (a) self-documenting, (b) way easier (property access, rather than diving deep into a data structure, and (c) actually gives you proper Typed OM value, regardless of type - we can tell for certain whether something is a length/color/etc and give you the right objects. > This would provide a solution to my first use case, but it looks more difficult to me than you seem to think it is. I might be wrong, though... Most grammars can decompose based purely on type information, without having to introspect on the actual values. (Check out your browser's parsing code sometime!) It's not *trivial* to implement, but it's not *hard* either; mostly it'll be slogging thru duplication, or else making our property parsers smarter in general so we don't have to duplicate things. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/208#issuecomment-221434087 using your GitHub account
Received on Tuesday, 24 May 2016 23:39:56 UTC