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

Tab Atkins Jr.:
>
> Now, authors don't distinguish between real physical units and
> sorta-physical units.  In particular, they relatively commonly specify
> fonts in pt (defined as 1/72 of an inch) while specifying everything
> else in px.
>

At least for CSS+(X)HTML we can consider these style sheets as broken
anyway. 
I have screens with resolutions above 100dpi for more than 10 years.
Because some authors want me to look at font-sizes of about 8px,
I always set the minimal font-size at a browser at something like 12-20px.
Either the style sheet scales with this or it is no useful styling for (X)HTML
- and if it causes problems for reading the content, such a styling is 
switched off completely, because it is useless nonsense.
Typically for well structured pages the default styling of a browser
is sufficient for such broken styling cases - therefore no problem at all, if
the author did not manage to povide a useful styling.
If the page is not structured well without author styling, it is broken
anyway, this cannot be changed with styling or scaling of lengths ;o)

> This causes a problem when screen DPI starts to rise, because the CSS
> px has to track the device pixel and shrink, while physical units have
> to stay the same size.  If we naively followed this, webpages would
> break - in the worst case (screens at about 140 dpi) fonts could be
> 50% larger than they were "supposed" to be (in relation to the rest of
> the page which is measured in px), which would break a lot of layouts.
>

It causes only problems for CSS for (X)HTML style sheets, if they are
not worth to be displayed anyway. The font-size is never under control
of the author due to minimal font-sizes. If the style sheets depend on
wrong assumptions or on a wrong/awkward choice of units, nothing
can save such a style sheet - it was already broken, when the author
created it.

> There's also a smaller subset of authors who use the other physical
> units (in, cm, mm, etc.) in conjunction with px, which would cause the
> same issues.
>
> So, we're stuck.  

I think, to choose useful units is mainly the problem of authors and
tutorials - as far as I have seen, there are some new interesting units
in a CSS3 draft avoiding some problems of cascading scaling of something
like em or ex. I think, this is really everything, CSS can do for authors
to avoid problems due to awkward unit mixing.
It is the task of authors to choose units properly for CSS+(X)HTML,
because for this combination this is essential to get something 
predictable with different font-sizes and viewport sizes.
SVG has another mechanism to manage this, therefore indeed 
within an SVG document or fragment authors typically have not
to mix units at all or to use units different from local units and 
percentage. These SVG mechanisms are pretty useful for graphics,
therefore this is no solution for CSS+(X)HTML either, unfortunately.
On the other hand, there are some mobile devices now with some similar
mechanisms to scale CSS+(X)HTML in a similar way more or less as
fixed graphics - not sure, if the readers of longer texts have some
benefits from this.


> We can either (1) just keep units as accurate as 
> possible, thus breaking sites, 

As discussed above, one can assume, that they were already
broken right from the beginning, nothing to worry about.
If the authors indicates an apple, do not even try to give him
a banana, even if the authors knows only fruit pulp.

> (2) maintain the px/in ratio by making 
> the CSS px map to a fractional number of device pixels, thus causing
> horrible performance regressions, or (3) maintain the px/in ratio by
> making the physical units equal something different than their "true"
> measurements.
>
> We can't break sites.  

It worked for a long time with Mozilla/Geckos with a correct inch size,
obviously this was no problem for authors and readers, because 
many people use these browsers ;o)

As long as the proper definitions of px, pt, pc do not change,
nothing happens. The relation between px and an absolute unit or em
is never predictable for authors. To create style sheets, that manage
this problem is their task. If they do not manage this, they break their
own styling, noone else does this. For the audience in useful browsers
it is always possible to switch off CSS styling, therefore the content
of a page cannot be broken by a stupid style sheet.

> We can't allow horrible performance 
> regressions.  So #3 is the only realistic choice.
>
> It's not nearly as weird as it sounds, though.
>
> First, it's the ratio that's important, not the actual value.  

Only for awkward choice of unit combinations.
For some maps and technical drawings (SVG) a proper size matters.
However, for most SVG documents, indeed the absolute size does
not matter so much, therefore it is a good approach to use no
unit identifiers at all to keep everthing scalable without surprises.
This is a simple consequence from the simple fact, that the relation
between px, cm and em are not always the same and not the
choice of the author.
Of course if some 'designers' try to style CSS+(X)HTML to behave
in the same way as an SVG document, they create graphics, no 
styled text and should use SVG instead of (X)HTML if they really 
need graphics or they have to use (X)HTML with an appropriate 
styling - both is not possible, but it is their decision.



Brad Kemper:
>And if I hook my computer up to a projector, how does the UA know how far 
>away the screen is, in order to determine what proportion of the video an 
>inch or a meter represents? There are many cases where the size of the 
>viewport in actual physical measurements is not known reliably.

There are mechanisms in CSS to provide device specific styling.
And for a clever projector it should be no problem to measure the
distance to the projection or to provide an interface to chose something.
If it has something like autofocus or a manual focus that can be monitored by
the projector CPU, it has the capabilities to provide information about the
resolution ;o)

Of course, if a device does not provide any information about resolution,
there is no method to calculate the relation between px and meter
automatically. The browser can provide of course an interface for the
audience to get this information manually, maybe with a default value
of 96dpi, if this is so important. But this should be only used, if further
information is missing. This is not the case for printers or conventional
monitors.

Olaf

Received on Friday, 13 August 2010 19:04:07 UTC