SVG Working Group Teleconference -- 09 Jan 2014

<trackbot> Date: 09 January 2014

<scribe> Chair: Erik

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Definition of rendered SVG elements

<ed> http://lists.w3.org/Archives/Public/www-svg/2013May/0000.html

birtles: this is a mail that was sent to the list last May which we didn't follow up

<birtles> https://svgwg.org/svg2-draft/struct.html#WAIARIAAttributes <-- "Rendered SVG elements can have role attributes"

birtles: to summarise, according to our descriptions of the aria attributes, is says rendered elements can have role attributes
... the version of the spec that mail linked to said the same thing for aria attributes. but the recent version doesn't say that.
... the other issue that's related is in the table of attributes, there are lots of inconsistencies

<birtles> this table https://svgwg.org/svg2-draft/attindex.html#RegularAttributes has lots of inconsistencies

birtles: it says animateColor can have the role attribute, hkern can but vkern can't
... in definitions.xml, we haven't added the aria attribute groups to a lot of elements
... the email suggests that we make anything that inherits from SVGGraphicsElement have aria attributes, with the possible exceptions of defs and view

<birtles> HTML: http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#wai-aria

birtles: I've had a look at HTML, and it says that you can use role and aria attributes on html elements, it doesn't restrict it
... I wanted to ask people familiar with accessibility whether there is any reason to restrict the attributes
... or if they should be allowed on all elements

ed: SVGGraphicsElement doesn't include the <svg> element, right?

heycam: I think it does
... my first thought is that if html allows it everywhere, and there is more accessibility focus in html, we should assume that it's ok for now

<ed> to be clear, I wanted to make sure that you can use role on <svg>

shepazu: we should ask rich when he's around
... I've heard people want to have aria attributes on animations
... if there are meaning animations, people would want to know what's going on
... what that actually means, not sure

Thomas_Smailus: that sounds like a good goal

shepazu: we do already allow aria attributes on SVG elements
... let's say a <circle> is animated, moving from left to right
... there might be some aria way of describing the scene
... it would be complex, it might be difficult to describe it in a meaningful way, but I have heard people say they'd like to see that
... maybe we only allow it on rendered elements first, and extend it to animation elements later

birtles: I just don't know if there's any benefit to restrict it
... maybe there are elements where it doesn't make much sense to put a role, but is there a need to restrict that?

shepazu: if you have a group that is in a <defs>, it's not a rendered element, but it's a graphics element
... the <g> element should allow role too

<birtles> btw, here is an example of an SVG with roles and it uses them on <g>s: https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg

heycam: it's not really clear what "rendered element" means

birtles: next step would be to get Rich's feedback

viewbox property

<ed> http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.html

<birtles> I posted a summary: http://lists.w3.org/Archives/Public/www-svg/2014Jan/0023.html

birtles: I posted a summary yesterday of the feedback, 24hrs ago, since then a number of other bits of feedback have come in
... I was going to go through each of these issues and see if there is further input
... Doug I'll want your input in particular, as there are a lot of questions about the auto sizing
... to summarise the feature, there are two things
... first, promoting viewBox to a property, and second adding an auto sizing keyword
... first issue is the name
... I gave two options, "viewbox" or "view-box"; don't know if anyone here has any suggestions
... I lean towards no dash, but the tricky bit is if you have SVG in standalone documents you need to use the capital B

heycam: have you asked CSS people about the name/

birtles: had Tab's input, he didn't seem to mind without the dash
... Daniel Holbert said one thing to be aware of is that if you don't have a dash, then the property in the CSSOM will have a lowercase b
... that's the only input from CSS people

<shepazu> http://www.w3.org/TR/2012/REC-media-frags-20120925/

shepazu: I've been thinking recently that maybe we should be integrating things from media fragments
... wondering if we should consider using syntax from media fragments
... they don't use "viewbox", they use "xywh"

<shepazu> "xywh=160,120,320,240 "

shepazu: in that way, it's also passed as a parameter in a url
... I wonder if there's any value in consistency in syntax between the URL syntax and the property
... we could also consider the other media fragment syntaxes -- time for example, and relate them to our animations

birtles: you're suggesting that is the name of the property?

shepazu: which could then be overridding by the value in the URL fragment

birtles: I'd like to see a bit more of the detail, can't quite see how it fits together

shepazu: let's imagine the CSS property is called "xywh"
... it takes the same syntax as xywh in Media Fragments
... that would be your default
... if somebody gave a media fragment with xywh, we'd define it so that it overrides the value from the document
... the syntax of the value is the same, it's four numbers

birtles: if you specify the viewBox attribute and xywh...

shepazu: the idea that you could override the viewport with the Media Fragment, we could do that even if we did name it viewbox
... we don't have to have the same name. I just think the symmetry/consistency would be nice.

Thomas_Smailus: is the intent that inside the document the Media Fragment would then take up the whole viewbox?

shepazu: that section of the SVG takes up the whole viewbox, it's the same thing

birtles: so it just sets the viewbox
... so do we name it to match the media fragment name or to match the viewBox attribute

ed: you don't think it would be confusing with width and height attributes?
... and x and y?

scribe: I would probably find that more confusing than viewbox

shepazu: I don't think one is necessarily clearer, given a particular audience

krit: there's not necessarily a win from the xywh name

shepazu: if I did xywh on a video, it would show me the viewbox of that video. I'd like there to be some consistency with other kinds of media and SVG.
... doesn't mean we have to name it xywh

krit: the thing I think is confusing is that SVG still do have media fragments on the outside
... but it wouldn't mean exactly the same thing as xywh on the <svg> element
... the media fragment one is like a clipping region
... the xywh/viewbox on the <svg> is some kind of a transform
... with translation and scaling

shepazu: let me do some more research and I'll come back to you about that

<shepazu> http://www.w3.org/TR/2012/REC-media-frags-20120925/#naming-space

shepazu: the interesting things in there is that you can pass in parameters and you can pass in units
... px, or %
... which is not something we can do with viewbox
... maybe we shouldn't, I don't know
... but I found it interesting that you can pass in different units
... maybe this is orthogonal, perhaps we allow both viewbox and xywh as properties

birtles: I don't know if it's possible to have media fragments add viewbox as an alias....

shepazu: media fragments is not widely deployed
... I want there to be some relationship between media fragments and what we do with viewbox

birtles: I'm concerned about the syntax thing, so if we're defining a property we shouldn't use "percentage:..."
... so assuming we don't make an xywh property name, any other input we have about viewbox vs view-box?

shepazu: without the dash

birtles: I don't know anything about how this mapping works
... is it feasible about adding an exception to standalone SVG so that it can parse viewbox with a lowercase b?

shepazu: I feel that we should define a "viewbox" attribute with a lowercase b, and just say it's an alias or whatever we need to say to allow that

heycam: it's always possible to just add another "viewbox" lowercase-b attribute

Thomas_Smailus: what's the motivation?

shepazu: it's a super common typo

Thomas_Smailus: is camel case common?

shepazu: common but inconsistent

Thomas_Smailus: if reinventing from the ground up, I'd make it all consistently camel case or lowercase

krit: atm SVG is based on XML, but for something based on HTML it wouldn't matter

shepazu: I think we should have both attributes

Tav: I'm a bit worried about that
... if we allow it there we might need to allow it everywhere
... it's a bit of a floodgate
... there is code that assumes presentation attribute names match the property

shepazu: you could change the code pretty easily

Tav: I was in the opposite direction. the basic thing is to put the document through the validator.

shepazu: SVG in HTML, when you encounter <svg viewbox> it treats it like <svg viewBox>
... viewbox is the one attribute I've heard people have problems with

Tav: so that attribute's the exception?

shepazu: yes, for now
... in the future if we wanted to allow lowercase attribute names we'd solve that in a different way

birtles: the other issues are less significant
... there's been a bit of feedback about the auto sizing behaviour
... and concern about using the stroked bounding box
... if you have an animated dash pattern, it's constantly changing
... I haven't gone through all the feedback yet
... I want to check that that property value is worthwhile having, given the issues surrounding it

shepazu: I'd have to read the feedback
... if it's implementors whinging about a bit of extra code...

birtles: some of that and author feedback
... let's leave that to the list then, follow up there

Intrinsic sizing problems

birtles: I don't know if we can get through this in 10 minutes
... I prepared a summary
... a lot of tools write out SVG with an absolute width/height
... then documents don't resize as authors often want
... this came up in the context of the viewbox property
... someone thought it would be confusing to say viewbox:auto and then you wouldn't have this responsive behaviour because the authoring tool set width/height on the root <svg>
... in terms of the sizing/aspect ratio of the SVG, as soon as you specify absolute values for width/height, that determines the intrinsic size/aspect ratio
... otherwise the viewbox does

<birtles> here is the mail: http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.html

birtles: that's the current behaviour

<birtles> .my-hardcoded-svg {

<birtles> width: auto !important;

<birtles> height: auto !important;

<birtles> viewbox: auto;

<birtles> }

birtles: Alex suggests a way to override it using an !important rule

<birtles> ^ That is the proposed syntax

birtles: there is also the proposal to promote preserveAspectRatio to a property, so that you can override what the authoring tool output
... there's also object-fit

<birtles> my follow up mail: http://lists.w3.org/Archives/Public/www-svg/2014Jan/0024.html

heycam: I thought we had decided to use object-fit as our preserveAspectRatio-like property

birtles: it seems to work at a different level
... object-fit sets the aspect ratio, then it determines a concrete object size
... that's given to SVG as a viewport
... then we use pAR to fit in to that viewport
... I guess you could specify object-fit in two places?
... when you're sizing an SVG image into an HTML <img> element
... if we were to make the property for pAR be object-fit, you'd need to specify it both on the <img> and on the root of the <svg>
... I'll follow up on the list; the one thing to come out of it is that interop is still not very good
... Alex had suggested that we have a concrete algorithm for calcaulting the viewport
... not sure if that's the answer, or if we need new tests, but his point is right that interop isn't great
... especially with replaced content
... no action to come out of this, but I'll follow up with Alex

ed: might be good to have the summary on the wiki somewhere?
... I'm finding it hard to follow the threads and get a clear view of what's going on

Tav: also a few demonstrations

<scribe> ACTION: Brian to summarise sizing issues on the wiki [recorded in http://www.w3.org/2014/01/09-svg-minutes.html#action01]

<trackbot> Created ACTION-3556 - Summarise sizing issues on the wiki [on Brian Birtles - due 2014-01-16].

<Tav> My connection just timed out...

birtles: I won't promise to add any examples there, don't have time to do that, but I'll at least summarise the discussion

<ed> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

09 Jan 2014

Attendees

Contents

Definition of rendered SVG elements

viewbox property

Intrinsic sizing problems

Summary of Action Items

Scribe.perl diagnostic output