- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 10 Jan 2014 10:33:16 +0900
- To: 'www-svg' <www-svg@w3.org>
- CC: Tavmjong Bah <tav.w3c@gmail.com>, Erik Dahlström <ed@opera.com>, Robert Longson <longsonr@gmail.com>, Dr.O.Hoffmann@gmx.de
Hi all, I'm following up all this discussion about viewbox with an updated list of issues where I'll try to summarise the outstanding points. a) Promoting viewBox to a property Issue 1: Do we actually need to do this? After some further investigation, I discovered that for the use case I had in mind, it *is* actually possible to achieve it declaratively without promoting viewBox to a property. The updated file with responsive aspect ratio is here: http://parapara-editor.mozlabs.jp/img/tool-picker.svg I'm really not sure why I didn't think of this earlier and hope I'm not missing something. I wonder, are there still other use cases for making viewBox a property particularly when it seems like it could cause a infinite looping when used together with object-fit:contain.[1] Issue 2: The name of the property (assuming we go ahead with this) We discussed this *at length* in the SVG WG and most people seem to prefer 'viewbox' (over 'view-box'). Some like the idea of adding special handling so that the attribute 'viewbox' is also allowed when parsing SVG in XML mode (standalong documents). This could be done by defining a second lowercase attribute (i.e. doesn't necessarily require parser changes). Further discussion is needed about whether we can do this for other attributes. But, again, I'm now less convinced we want to promote viewBox to a property. b) Adding an 'auto' property value to viewbox Issue 3: Which bounding box to use Robert Longson points out that current UA's implementation of stroke bounding boxes are not particularly accurate or consistent with each other since it is expensive to do it accurately in light of dash arrays, miter limits etc. and suggests the fill bounding box is better.[2] Dr. Olaf Hoffmann points out that if an massive rectangle is used to fill the background with a solid colour (as is commonly done) the auto property is not useful.[3] This could be worked-around by implementing background-color (viewport-fill). [Issues of legacy content/viewers remain but presumably they would not use/support the auto value anyway?] Erik prefers a bounding box that includes anti-aliasing, masking, filters etc., the rendered bounding box.[4] This could be somewhat addressed by allowing SVG to render outside the viewport. Tav agrees.[5] Tav suggests the geometric bounding box should be an option so that changes to the stroke dash offset etc. don't make the graphic jiggle [my word].[5] (In a related comment on a similar discussion, Cameron mentioned the idea of a "full stroke area" which would ignore the effect of dashes etc.[6] Is that worth speccing for this?) Issue 4: Making the viewbox live Dr. Olaf Hoffmann points out that making the viewbox live is sometimes counter-productive.[3] For example, for motion on a path it could actually cause the animated graphic to not appear to animate at all. Issue 5: The syntax Dr. Olaf Hoffmann questions whether we really need units (i.e. lengths) in the syntax or whether numbers are sufficient.[3] Also, concern about backwards compatibility. Doug agreed to look into these issues and see if the complexity involved in adding an 'auto' keyword is warranted.[7] c) Promoting preserveAspectRatio If we go ahead with promoting viewbox to a property, then we might want to consider promoting preserveAspectRatio as well (some rationale at [1]). My current thinking now though is not to bother. Thanks everyone for your input. Best regards, Brian [1] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0024.html, particularly observation 2. [2] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0025.html [3] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0026.html [4] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0027.html [5] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0029.html [6] http://tavmjong.free.fr/blog/?p=821#comment-525 [7] http://www.w3.org/2014/01/09-svg-irc#T21-18-48
Received on Friday, 10 January 2014 01:33:47 UTC