[svg2] Status of the viewbox property

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