W3C home > Mailing lists > Public > www-svg@w3.org > December 2013

The (new, enhanced) viewbox property

From: Brian Birtles <bbirtles@mozilla.com>
Date: Tue, 17 Dec 2013 10:17:52 +0900
Message-ID: <52AFA640.9010908@mozilla.com>
To: 'www-svg' <www-svg@w3.org>
Hi all,

For SVG2 there are two proposed changes to viewBox.

a) Make it a CSS property so you can, for example, tweak it with media 
queries to make responsive SVG images.

b) Add an 'auto' value that allows it to be calculated automatically 
from the bounding box of the content.

This was originally discussed in July 2012.[1]

I ended up with the action (ACTION-3326) to draft both since I proposed (a).

To that end, here are the issues I can think of so far with some 
tentative proposals:

Issue 1: The property name.
Proposal: 'viewbox'
Rationale: Otherwise we end up with 'viewBox', 'viewbox' (for 
SVG-in-HTML) and 'view-box'. It feels like one word to me, or could be 
anyway.

Issue 2: Does this apply to HTML iframe too?
Tab has an action (ACTION-3325) to look into this.

Issue 3: What bounding box to use for (b)?
Proposal: The stroke bounding box as defined in SVG2[2] (which, by the 
way, includes markers).
Rationale: It's nearly always more desirable than the geometric bounding 
box, at least for simple use cases which is what (b) is aimed at.

Issue 4: Does the viewbox keep changing if the content moves around or 
its bbox changes?
Proposal: Yes.
Rationale: The idea of snapshotting the geometry at some initial time is 
far too fragile. Do you wait until all styles have loaded? (Remember 
that we plan to promote geometrical attributes like x/y/width/height to 
properties) And what if animation starts in the meantime?
Making the viewbox 'live' means that if you change the stroke width of 
an object at the edge of the graphic the whole thing will move but 
that's just how it works. Perhaps we need viewbox: fill-bbox as well for 
those sort of cases?

Issue 5: The syntax.
Proposal: viewbox: none | auto | <length>{4}
- Units are allowed on lengths (including when used as an attribute value)
- Units may also be omitted as per usual SVG parsing

Issue 6: Can we make 'auto' the initial value?
If we introduce a new top-level graphics element, perhaps. We could, for 
example, rename 'auto' to 'bounds' and make the initial value of the 
property 'auto' and treat that as 'bounds' on <graphics> and 'none' on 
existing elements that establish viewports.

Issue 7: Can <calc> be used?
Proposal: Yes, in place of each of the individual <length> arguments.
Rationale: Why not?

Issue 8: The rest of the property definition
Proposal:
   Initial: none
   Applies to: elements that establish a viewport
   Inherited: no
   Animatable: as simple list of length
   Percentages: ??? Relative to the stroke bbox of the content ??
   Media: visual
   Computed value: as specified
   Canonical order: per grammar

I'm not really sure what to do about percentages

These are just some rough thoughts. Any feedback is welcome!

Best regards,

Brian

[1] http://www.w3.org/2012/07/24-svg-minutes.html#item04
[2] 
https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getStrokeBBox
Received on Tuesday, 17 December 2013 01:18:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:34 UTC