Re: The (new, enhanced) viewbox property

Following this up with a summary of feedback so far in preparation for 
tomorrow's telcon.

(2013/12/17 10:17), Brian Birtles wrote:
> 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.

The above was unclear, it's not that you *have* to use 'viewbox' for 
SVG-in-HTML but that you *can*.

Daniel points out that when mapping to the CSSOM for getComputedStyle 
etc. 'view-box' would come out as viewBox.[1]

So the two options as I understand it:

Option A, property is 'viewbox',

  In SVG stand-alone documents you have to use viewBox for the 
presentation attribute.
  In SVG-in-HTML you can use viewBox or viewbox for the presentation 
attribute
  In CSS you can use viewBox or viewbox for the property.
  In CSSOM you use viewbox to access the property.

i.e. except for stand-alone SVG, you can use 'viewbox' everywhere. Is it 
possible/reasonable to add an exception for this?

Option B, property is 'view-box',

  In SVG stand-alone documents you have to use viewBox for the 
presentation attribute. (Is adding an exception here reasonable?)
  In SVG-in-HTML you can use viewBox or viewbox for the presentation 
attribute
  In CSS you can use view-box or view-Box for the property.
  In CSSOM you use viewBox to access the property.

i.e. you can use 'viewBox' everywhere except in CSS you need to use 
'view-box' (or view-Box).

I think I prefer option A but I've no idea how reasonable it is to allow 
'viewbox' in standalone SVG documents.

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

Tab?

> 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.

Alex Bell agrees to using stroke bounding box.[2] No other feedback yet.

> 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?

No feedback about this issue. Perhaps in a subsequent version we could 
extend the property with percentage values and make those percentages 
relative to either the stroke bbox or fill bbox. Or alternatively, add 
some notation that lets you easily specify, "the fill bbox plus a fixed 
number of pixels padding".

> 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

No feedback on this issue.

> 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.

Waiting to see what happens regarding <graphics>. Perhaps it is better 
to do this renaming anyway? i.e.

   viewbox: none | auto | stroke-bbox | <length>{4}

With 'auto' -> 'none' for <svg>?
'stroke-bbox' is a bit long and ugly.

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

No feedback here.

> 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

In the grammar above percentages aren't allowed so I don't know what I 
was thinking here.

I plan to run through these at the telcon tomorrow. In the meantime any 
further feedback is most welcome.

Best regards,

Brian

[1] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0088.html
[2] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0081.html

Received on Thursday, 9 January 2014 02:38:10 UTC