- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Tue, 7 Jan 2014 13:14:34 +0100
- To: www-svg@w3.org
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