- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Mon, 25 Oct 2010 17:59:51 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] > > Given the gradient issue, I am now a bit warier of making 0 values > unit-less since > > it could cause ambiguity in the future. > > Right; I don't think we should make anything unitless that isn't > already so. It's about making zero unitless across values that take units. > Gradients are the first place where there would have been > ambiguity, but I'd bet it wouldn't be the last. Using a unit makes it > clearer what the value is meant for, anyway, which I think is worth > the marginal cost of (typically) 2 extra characters per value. This request has nothing to do with typing whatsoever. (And given that we're talking about units I'm even surprised this even comes up). It's mostly about consistency for web authors as well as Values & Units overall. I'd very much prefer to be able to say that zero value do not need a unit anywhere as opposed to saying it's only true for lengths. Quite a few people know about the latter and may be surprised to find out it's an exception once they venture into the newer units. Especially if transforms already accept unitless zero angles. Never mind that it doesn't make a lot of sense to require a unit to be specified for a zero value. The only 'worth' this really has is that it *may* allow to resolve shorthand ambiguities. Now it's true that it's easier for JS code to parse property values correctly knowing that there always is a unit but that's only because the value needs to be parsed as a string in the first place, a legacy which I don't really want to optimize for given proposals to fix the CSSOM.
Received on Monday, 25 October 2010 18:00:34 UTC