Re: The (new, enhanced) viewbox property

Tab Atkins Jr.:

>No, CSS applies, the language as it stands, not any obsolete snapshots
>of the standard like 2.0.

No, SVG 1.1 clearly references the CSS 2.0 recommendation.
Some others for example EPUB 2 do this as well.
Currently one cannot use CSS 2.1 or CSS 3 modules for SVG 1.1
documents. That is the idea of standards and recommendations.
But indeed, the second edition of SVG 1.1 seems to have some
inconsistencies and backwards incompatible changes  beyond
simple bug fixes, this variant is not just a new edition, it should 
have its own version number to avoid such confusions.

If SVG 2 will reference CSS 2.1 or something else, the described
issues, if not fixed, will be clearly applicable for it.

>Once again, you misunderstand what was actually defined by CSS.  I'm
>far past the point of hoping to educate you on this matter, but for
>the edification of other readers, here's how CSS deals with units:

Well, as an experimental physicist I know what an absolute unit of 
length is - I even know people caring about such standards personally. 
There is no need for education for me from you on this issue -
maybe the CSS WG needs some more information here ;o)
Facts don't change, just because they are ignored intentionally ;o)
It would be helpful for other readers, if you do not try to 
'inform/educate' wrong facts, respectively only about things,
you are informed correctly about and not biased by some 
intentionally confusing 'philosophy' of the CSS WG ;o)

And it is obvious, that the related bugs in user-agent 
especially cause problem/nonsense in the presentation
of some specific use cases for SVG, what is different to
most use case of CSS for (X)HTML, where one typically
does not use any absolute length units, respectively if
they are used by desinformed authors, it does not matter
a lot, if they are completely ignored or interpreted wrong.
Because the interpreation of size of SVG documents and
fragments differs clearly from most other CSS applications,
SVG 2 should specify this independently from the confusing
CSS 2.1 section, to give viewers a better chance to present
such SVG use cases in a meaningful way without absolute
unit obfuscation.

>It turns out that authors commonly assume that there is a fixed ratio
>between the px unit and all the physical units, especially pt.  This
>sometimes results in page designs that work when a particular px:pt
>ratio is used, but breaks (lines break unexpectedly, floats move
>chaotically) when a different one is used.  This means that browsers,
>in practice, have to fix a particular ratio of px:pt in order to
>render the internet correctly.

If this happens for projects using (X)HTML+CSS, typically those
pages are already broken due to user-stylesheets with a required
minimal font size. Often one has to switch off CSS interpretation for
such projects at all to get some kind of interpretable presentation -
in several cases however it turns out, that the content is in a similar
way chaotic than the styling. This needs to be fixed by the authors,
CSS cannot fix nonsense of authors.

And our experience with stupid stylesheets for (X)HTML do not
necessarily apply for all use case of SVG documents or fragments.
Therefore CSS for (X)HTML is not necessarily what counts, if we
talk about SVG use cases for units.

>The most common ratio, and the one CSS mandates, is 4px = 3pt, due to
>most monitors using 96 dpi for many years.

I used many monitors in the past years, none of them had 96 decive pixels
per inch. Most older monitors have about 120 device pixels per inch (CRT),
for notebooks I have 72, 99, 120 in use.
Already with this few examples of monitors, produced from maybe 1995 to
2012 we can see, that the 96 is just a random number.
If someone relies on this, conclusions will be typically wrong. It is not 
about what people really get presented, neither in the past nor in the 
present. As you note as well, with tiny devices now you get even higher
device pixel densities. 
It is ok to say, that for example the SVG base unit '1' is not related to
device pixels and it is obviously pretty useful in most use cases to
forget about width and height attributes of the root svg element, rescaling
only the viewBox to the viewport, however for a few use cases, where
size matters, absolute units like mm are relevant.
A use case for device pixels may appear, if a pixel graphics is used in the
SVG document and the author does not want some interpolation (or only
an scaling factor like half size). Typically, if the SVG document does not
contain pixel graphics, there are no such restrictions on scaling, what is
an important point about SVG, we do not have with CSS+(X)HTML using
PNG or JFIF/JPEG or GIF in the past.
Restrictions on scaling could be covered by specific media queries or a
similar mechanism for SVG documents, respectively pixel based content 
or a similar mechanism.

There seems to be a need for authors to indicate, whether size matters
or not for presentation. I agree, that for most use cases size does not
matter, respectively, if it deviates by up to maybe 30%, most authors 
will not worry about it - for them it is ok to have some mechanism to
optimize the presentation to the device. For some other use cases 
related especially to absolute units like mm, this is obviously not the
case. And if it currently does not work with CSS units, there is a need
for another mechanism, especially for vector graphics, currently not 
present in stupid stylesheets, to cover such use cases.

>Devices have different pixel sizes,
>users zoom, etc., and nothing breaks as a result.

Well, if an author provides an SVG document, for example
a representation of a real object, where size might matter (mobile phones,
breast implants, vibrators, maps, art works, netbooks, shoes, clothes, fruits
following some EU-norm etc) and specifies width and height  in mm and notes 
in the text, that the graphics shows the original size, obviously the
presentation is broken, if a mm is not presented as a mm. 
The user-agent clearly fails, if this is presented with the wrong size.
If this happens in an online shop, the consequences
can result in a disaster or at least in a frustrating experience ;o)
The case is different, if the user intentionally and manually
decides, that there is a need for zooming in or out. By doing this
manually, it is obvious, that the zoomed presentation deviates
from the original size. This will be no problem, because it is 
the intention of the user, no mad magic by the device or user-agent.

Olaf

Received on Tuesday, 7 January 2014 12:15:10 UTC