W3C home > Mailing lists > Public > www-style@w3.org > October 2010

RE: [css3-transitions][css3-values] transition-duration's inital value is '0' without a unit

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>
Message-ID: <045A765940533D4CA4933A4A7E32597E281440DB@TK5EX14MBXC120.redmond.corp.microsoft.com>
> 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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:33 GMT