- From: François REMY via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 May 2016 21:54:58 +0000
- To: public-houdini-archive@w3.org
Please accept my sincere excuses for my wording, I agree it is oversized to the problem at stake. I'm very much commenting on this particular issue and not on the general spec, which is very good and has my full support. My aim here is to make it even better by providing feedback as a potential user of the API, nothing else. I understand that browsers are not required to parse upfront (I don't think Edge does either), and of course I know that there is a second parse step once the value are being replaced in (this is the whole "invalid at computation time" concept). From the author standpoint, though, it doesn't mean this API has to bail out the way it currently does in this case. My problem here is that the current design does not meet the goals the spec sets upon itself. > Converting CSSOM value strings into meaningfully typed JavaScript representations and back can incur a significant performance overhead. This specification exposes CSS values as typed JavaScript objects to facilitate their performant manipulation. The goal of the Typed OM API is to make sure we can work with css values in a way that does not required to parse strings in javascript, because this is very inefficient. At least that is my understanding of it, please correct me if I'm wrong. If this is the goal of this API, then I do believe the answer to the case when the value is unparsed and contains variable is insufficient to guarantee this promise. I want to constructively build a better solution for this case, which I think is worth solving. -- GitHub Notification of comment by FremyCompany Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/193#issuecomment-221107931 using your GitHub account
Received on Monday, 23 May 2016 21:55:00 UTC