- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 25 Oct 2010 11:40:27 -0700
- To: Sylvain Galineau <sylvaing@microsoft.com>
- Cc: "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Mon, Oct 25, 2010 at 10:59 AM, Sylvain Galineau <sylvaing@microsoft.com> wrote: >> 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. Yeah, that's what I'm talking about too. Sorry if I'm unclear. >> 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). Sorry, it's slightly tangential. I'm just saying, the only practical effect of omitting a unit is that you save two characters (for typical units). The upside is your stylesheet is slightly terser. The downside is your stylesheet may be slightly more difficult to read, because you have to remember what units the given property normally takes. > 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. I'll admit that I was slightly surprised when I learned that only lengths can have their unit omitted. But it's a cost you pay once, when you see that your rule isn't working for some reason. Units other than lengths aren't used very commonly anyway, so it's a minority use-case in the first place. So, I don't see much utility in changing this; given that, I'd prefer to make it easier to resolve shorthands. > 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. Right; I'm not attempting to care about the CSSOM, just my own reading of stylesheets. I like reading the units on non-lengths, because it makes it clearer to me what I'm reading. ~TJ
Received on Monday, 25 October 2010 18:41:16 UTC