- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 09 Jan 2014 11:37:41 +0900
- To: 'www-svg' <www-svg@w3.org>
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