Re: [css21][css3][svg] SVG and unit-less length values

Hi, Tab-

Tab Atkins Jr. wrote (on 8/14/10 1:27 PM):
> On Sat, Aug 14, 2010 at 9:56 AM, Doug Schepers<>  wrote:
>>  I was under the impression that it was not possible to render real-world
>>  units to uncalibrated monitors, and that most monitors are uncalibrated; am
>>  I mistaken or confused (maybe thinking of color calibration), or has that
>>  changed?
> That is also true, more or less.  I'm not an expert at the arcane
> details of the information exposed by various system APIs, but yeah, I
> believe that at least a significant amount of the time you can't get
> "true" information about the physical dimensions of the monitor, so
> rendering a "true inch" is logically impossible for *any* program that
> doesn't self-calibrate with a "hold a ruler up to the screen"-type
> message.

Yet there are times and circumstances where that is useful, and where 
it's worth the effort for the user to calibrate their monitor with a 
real-world reference (like holding up a ruler to their screen).  For 
example, in architectural drawings, or with widgets that let you measure 
things onscreen, like calipers.  SVG is more graphical than CSS+HTML, so 
these sorts of things do arise more often, perhaps, in SVG.

We are trying to move SVG and CSS closer together, so we need to 
consider use cases from both.  That said, the most common case (outside 
of printing, which is too often ignored) does seem to weigh heavily in 
favor of the abstracted units.

>>  Wouldn't it be possible to meet both use-cases by adding a property,
>>  something like 'unit-space':'realteive*|absolute', where the default is to
>>  use these abstracted units (for necessary bugwards compatibility), and the
>>  'absolute' option would do its best to render the physical size as
>>  indicated?  This would be something like dealing with transforms or
>>  viewboxes.
> That's been proposed, as has a parallel set of "true" physical units
> that aren't tied to the definition of a pixel.
> The basic issue is simply a question of how much anyone *cares*.
> There doesn't seem to be much evidence that the current state of
> affairs is bad enough to fix.  After all, the "bugwards compatibility"
> that we're adding is simply a reflection of what every browser has
> done for years; it's correcting the spec to match reality, not coming
> up with something new.  If it was really a problem, we'd see authors
> complaining about it.

I really don't like this line of reasoning, for a few reasons:

1) It seems shortsighted to focus on the set of use cases that have been 
common up until now, when the future of the Web is clearly going to be 
much more complex and increasingly pervasive.  As devices improve their 
sensors, and augmented reality becomes more common, interactions between 
Web content and the real world (including real-world measurements) seem 
like they will be more relevant, not less.

2) When I hear one author express a reasonable concern (and Dr. Olaf is 
a prolific author of SVG content), I assume there are a fair number of 
others out there who aren't speaking up, but who have the same needs.

3) Many people don't *know* they want functionality until suddenly it is 
given to them.  Nobody was asking for CSS transitions, animation, or 
transforms, but once WebKit delivered it, it's all anyone can talk 
about; very few people, at the time, asked for CSS, or DTP, or the Web; 
10 years ago, most people thought the idea of webapps was laughable. 
Certainly real-world units are not nearly so sexy, but for some people 
they may be indispensable.

> So, since this is an issue that (a) only affects a limited class of
> devices right now, and will disappear *completely* in the relatively
> near future, and (b) authors don't seem to care about in the first
> place, it doesn't seem like it's worthwhile to care about it.  As far
> as I've been able to tell, the only concern that anyone has expressed
> over it has been aesthetic, not practical.

At the very least, I think it's worthwhile not to be dismissive of 
people's feedback; it discourages them and others from participating, 
and we want more varied participation.  From a purely tactical stance, 
acknowledging the value of a commentor's feedback, even when the 
ultimate decision can't meet their criteria, fosters a more productive 
tone and helps decrease frustrating and lengthy "no-but-yeah-but-no-but" 

The CSS WG is almost certainly going to decide upon the solution you're 
advocating, with the abstracted 1px==1/96in, and there are good reasons 
for it.  Please don't be a sore winner. :)

(I like both you and Dr. Olaf, and I cry when you fight. ;_;)

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 14 August 2010 19:57:15 UTC