20:31:21 <RRSAgent> RRSAgent has joined #svg
20:31:21 <RRSAgent> logging to http://www.w3.org/2014/01/09-svg-irc
20:31:23 <trackbot> RRSAgent, make logs public
20:31:23 <Zakim> Zakim has joined #svg
20:31:25 <trackbot> Zakim, this will be GA_SVGWG
20:31:25 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)3:30PM already started
20:31:26 <trackbot> Meeting: SVG Working Group Teleconference
20:31:26 <trackbot> Date: 09 January 2014
20:31:40 <birtles> Zakim, who is on the phone?
20:31:41 <Zakim> On the phone I see Doug_Schepers, Thomas_Smailus, krit, [IPcaller]
20:31:50 <birtles> Zakim, [ is me
20:31:50 <Zakim> +birtles; got it
20:32:35 <Zakim> +[IPcaller]
20:32:48 <ed> Zakim, [IP is me
20:32:48 <Zakim> +ed; got it
20:32:56 <Zakim> +[IPcaller]
20:32:58 <heycam> Zakim, [ is me
20:32:58 <Zakim> +heycam; got it
20:33:03 <Zakim> +??P5
20:33:03 <ed> Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Jan/0021.html
20:33:27 <ed> chair: ed
20:33:28 <stakagi> Zakim , ??P5 is me
20:33:59 <ed> Zakim, pick a scribe
20:33:59 <Zakim> Not knowing who is chairing or who scribed recently, I propose Thomas_Smailus
20:34:41 <stakagi> Zakim, who is on the phone?
20:34:41 <Zakim> On the phone I see Doug_Schepers, Thomas_Smailus, krit, birtles, ed, heycam, ??P5
20:35:18 <stakagi> Zakim, ??P5 is me
20:35:18 <Zakim> +stakagi; got it
20:35:34 <ed> Zakim, pick a scribe
20:35:34 <Zakim> Not knowing who is chairing or who scribed recently, I propose ed
20:35:49 <ed> Zakim, pick a scribe
20:35:49 <Zakim> Not knowing who is chairing or who scribed recently, I propose birtles
20:36:08 <heycam> Chair: Erik
20:36:13 <heycam> Scribe: Cameron
20:36:16 <heycam> ScribeNick: heycam
20:36:43 <heycam> Topic: Definition of rendered SVG elements
20:36:49 <ed> http://lists.w3.org/Archives/Public/www-svg/2013May/0000.html
20:37:51 <heycam> birtles: this is a mail that was sent to the list last May which we didn't follow up
20:38:02 <Zakim> +??P7
20:38:13 <nikos_> Zakim, ??P7 is me
20:38:13 <Zakim> +nikos_; got it
20:38:20 <birtles> https://svgwg.org/svg2-draft/struct.html#WAIARIAAttributes <-- "Rendered SVG attributes can have role attributes"
20:38:22 <heycam> ... to summarise, according to our descriptions of the aria attributes, is says rendered elements can have aria:role attributes
20:38:52 <heycam> ... the version of the spec that mail linked to said the same thing for aria attributes. but the recent version doesn't say that.
20:38:54 <heycam> s/aria:role/role/
20:39:08 <heycam> ... the other issue that's related is in the table of attributes, there are lots of inconsistencies
20:39:14 <birtles>  this table https://svgwg.org/svg2-draft/attindex.html#RegularAttributes has lots of inconsistencies
20:39:34 <heycam> ... it says animateColor can have the role attribute, hkern can but vkern can't
20:39:42 <heycam> ... in definitions.xml, we haven't added the aria attribute groups to a lot of elements
20:40:05 <heycam> ... the email suggests that we make anything that inherits from SVGGraphicsElement have aria attributes, with the possible exceptions of defs and view
20:40:23 <birtles> HTML: http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#wai-aria
20:40:25 <heycam> ... 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
20:40:29 <Zakim> +Tav
20:40:49 <heycam> ... I wanted to ask people familiar with accessibility whether there is any reason to restrict the attributes
20:40:53 <heycam> ... or if they should be allowed on all elements
20:41:23 <heycam> ed: SVGGraphicsElement doesn't include the <svg> element, right?
20:41:30 <heycam> heycam: I think it does
20:42:33 <shepazu> q+
20:42:54 <heycam> heycam: 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
20:42:57 <ed> to be clear, I wanted to make sure that you can use role on <svg>
20:43:01 <heycam> shepazu: we should ask rich when he's around
20:43:09 <heycam> ... I've heard people want to have aria attributes on animations
20:43:21 <heycam> ... if there are meaning animations, people would want to know what's going on
20:43:29 <heycam> ... what that actually means, not sure
20:43:40 <heycam> Thomas_Smailus: that sounds like a good goal
20:44:25 <heycam> shepazu: we do already allow aria attributes on SVG elements
20:44:26 <birtles> s/Rendered SVG attributes/Rendered SVG elements/
20:44:36 <heycam> ... let's say a <circle> is animated, moving from left to right
20:44:51 <heycam> ... there might be some aria way of describing the scene
20:45:12 <heycam> ... 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
20:45:42 <heycam> ... maybe we only allow it on rendered elements first, and extend it to animation elements later
20:45:49 <heycam> birtles: I just don't know if there's any benefit to restrict it
20:46:02 <heycam> ... maybe there are elements where it doesn't make much sense to put a role, but is there a need to restrict that?
20:46:33 <heycam> shepazu: if you have a group that is in a <defs>, it's not a rendered element, but it's a graphics element
20:46:39 <heycam> ... the <g> element should allow role too
20:47:07 <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
20:47:08 <heycam> heycam: it's not really clear what "rendered element" means
20:47:23 <heycam> birtles: next step would be to get Rich's feedback
20:48:02 <heycam> Topic: viewbox property
20:48:05 <ed> http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.html
20:48:13 <shepazu> q+
20:48:32 <birtles> I posted a summary: http://lists.w3.org/Archives/Public/www-svg/2014Jan/0023.html
20:48:48 <heycam> birtles: I posted a summary yesterday of the feedback, 24hrs ago, since then a number of other bits of feedback have come in
20:48:57 <heycam> ... I was going to go through each of these issues and see if there is further input
20:49:08 <heycam> ... Doug I'll want your input in particular, as there are a lot of questions about the auto sizing
20:49:12 <Zakim> -nikos_
20:49:14 <heycam> ... to summarise the feature, there are two things
20:49:25 <heycam> ... first, promoting viewBox to a property, and second adding an auto sizing keyword
20:49:37 <Zakim> +??P7
20:49:38 <heycam> ... first issue is the name
20:49:43 <nikos_> Zakim, ??P7 is me
20:49:43 <Zakim> +nikos_; got it
20:49:53 <heycam> ... I gave two options, "viewbox" or "view-box"; don't know if anyone here has any suggestions
20:50:12 <heycam> ... I lean towards no dash, but the tricky bit is if you have SVG in standalone documents you need to use the capital B
20:50:31 <heycam> heycam: have you asked CSS people about the name/
20:50:38 <heycam> birtles: had Tab's input, he didn't seem to mind without the dash
20:50:54 <jdaggett> jdaggett has joined #svg
20:50:55 <heycam> ... 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
20:51:04 <heycam> ... that's the only input from CSS people
20:51:06 <shepazu> http://www.w3.org/TR/2012/REC-media-frags-20120925/
20:51:21 <heycam> shepazu: I've been thinking recently that maybe we should be integrating things from media fragments
20:51:30 <heycam> ... wondering if we should consider using syntax from media fragments
20:51:48 <heycam> ... they don't use "viewbox", they use "xywh"
20:51:52 <shepazu> "xywh=160,120,320,240 "
20:52:08 <heycam> ... in that way, it's also passed as a parameter in a url
20:52:24 <heycam> ... I wonder if there's any value in consistency in syntax between the URL syntax and the property
20:52:57 <heycam> ... we could also consider the other media fragment syntaxes -- time for example, and relate them to our animations
20:53:09 <heycam> birtles: you're suggesting that is the name of the property?
20:53:17 <heycam> shepazu: which could then be overridding by the value in the URL fragment
20:53:39 <heycam> birtles: I'd like to see a bit more of the detail, can't quite see how it fits together
20:53:47 <heycam> shepazu: let's imagine the CSS property is called "xywh"
20:54:16 <heycam> ... it takes the same syntax as xywh in Media Fragments
20:54:23 <heycam> ... that would be your default
20:54:42 <heycam> ... if somebody gave a media fragment with xywh, we'd define it so that it overrides the value from the document
20:55:06 <heycam> ... the syntax of the value is the same, it's four numbers
20:55:32 <heycam> birtles: if you specify the viewBox attribute and xywh...
20:55:47 <heycam> shepazu: the idea that you could override the viewport with the Media Fragment, we could do that even if we did name it viewbox
20:56:08 <heycam> ... we don't have to have the same name. I just think the symmetry/consistency would be nice.
20:56:30 <heycam> Thomas_Smailus: is the intent that inside the document the Media Fragment would then take up the whole viewbox?
20:56:45 <heycam> shepazu: that section of the SVG takes up the whole viewbox, it's the same thing
20:57:03 <heycam> birtles: so it just sets the viewbox
20:57:28 <heycam> ... so do we name it to match the media fragment name or to match the viewBox attribute
20:58:20 <heycam> ed: you don't think it would be confusing with width and height attributes?
20:58:25 <heycam> ... and x and y?
20:58:47 <heycam> <svg x="10" y="10" widht="40" height="40" xywh="20 30 40 50">
20:59:09 <heycam> ... I would probably find that more confusing than viewbox
20:59:23 <heycam> shepazu: I don't think one is necessarily clearer, given a particular audience
21:00:50 <heycam> krit: there's not necessarily a win from the xywh name
21:01:32 <heycam> 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.
21:01:37 <heycam> ... doesn't mean we have to name it xywh
21:02:03 <heycam> krit: the thing I think is confusing is that SVG still do have media fragments on the outside
21:02:13 <heycam> ... but it wouldn't mean exactly the same thing as xywh on the <svg> element
21:02:19 <heycam> ... the media query one is like a clipping region
21:02:28 <heycam> ... the xywh/viewbox on the <svg> is some kind of a transform
21:02:33 <heycam> ... with translation and scaling
21:02:42 <heycam> s/query/fragment/
21:03:36 <heycam> shepazu: let me do some more research and I'll come back to you about that
21:04:06 <shepazu> http://www.w3.org/TR/2012/REC-media-frags-20120925/#naming-space
21:04:19 <heycam> shepazu: the interesting things in there is that you can pass in parameters and you can pass in units
21:04:21 <heycam> ... px, or %
21:04:26 <heycam> ... which is not something we can do with viewbox
21:04:32 <heycam> ... maybe we shouldn't, I don't know
21:04:47 <heycam> ... but I found it interesting that you can pass in different units
21:05:10 <heycam> ... maybe this is orthogonal, perhaps we allow both viewbox and xywh as properties
21:05:58 <heycam> birtles: I don't know if it's possible to have media fragments add viewbox as an alias....
21:06:09 <heycam> shepazu: media fragments is not widely deployed
21:06:50 <heycam> ... I want there to be some relationship between media fragments and what we do with viewbox
21:07:13 <heycam> birtles: I'm concerned about the syntax thing, so if we're defining a property we shouldn't use "percentage:..."
21:07:57 <heycam> birtles: so assuming we don't make an xywh property name, any other input we have about viewbox vs view-box?
21:08:06 <heycam> shepazu: without the dash
21:08:21 <heycam> birtles: I don't know anything about how this mapping works
21:08:25 <Zakim> +cabanier
21:08:35 <heycam> ... is it feasible about adding an exception to standalone SVG so that it can parse viewbox with a lowercase b?
21:09:04 <heycam> 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
21:09:37 <heycam> heycam: it's always possible to just add another "viewbox" lowercase-b attribute
21:09:49 <heycam> Thomas_Smailus: what's the motivation?
21:09:52 <heycam> shepazu: it's a super common typo
21:10:40 <heycam> Thomas_Smailus: is camel case common?
21:11:23 <heycam> shepazu: common but inconsistent
21:11:58 <heycam> Thomas_Smailus: if reinventing from the ground up, I'd make it all consistently camel case or lowercase
21:12:15 <heycam> krit: atm SVG is based on XML, but for something based on HTML it wouldn't matter
21:13:04 <heycam> shepazu: I think we should have both attributes
21:13:09 <heycam> Tav: I'm a bit worried about that
21:13:19 <heycam> ... if we allow it there we might need to allow it everywhere
21:13:23 <heycam> ... it's a bit of a floodgate
21:13:51 <heycam> ... there is code that assumes presentation attribute names match the property
21:13:57 <heycam> shepazu: you could change the code pretty easily
21:14:50 <heycam> Tav: I was in the opposite direction. the basic thing is to put the document through the validator.
21:15:26 <heycam> shepazu: SVG in HTML, when you encounter <svg viewbox> it treats it like <svg viewBox>
21:16:26 <heycam> shepazu: viewbox is the one attribute I've heard people have problems with
21:16:34 <heycam> Tav: so that attribute's the exception?
21:16:37 <heycam> shepazu: yes, for now
21:17:06 <heycam> ... in the future if we wanted to allow lowercase attribute names we'd solve that in a different way
21:17:42 <heycam> birtles: the other issues are less significant
21:17:51 <heycam> ... there's been a bit of feedback about the auto sizing behaviour
21:17:58 <heycam> ... and concern about using the stroked bounding box
21:18:06 <heycam> ... if you have an animated dash pattern, it's constantly changing
21:18:12 <heycam> ... I haven't gone through all the feedback yet
21:18:38 <heycam> ... I want to check that that property value is worthwhile having, given the issues surrounding it
21:18:48 <heycam> shepazu: I'd have to read the feedback
21:19:01 <heycam> ... if it's implementors whinging about a bit of extra code...
21:19:12 <heycam> birtles: some of that an author feedback
21:19:16 <heycam> s/an/and/
21:19:24 <heycam> ... let's leave that to the list then, follow up there
21:20:10 <heycam> Topic: Intrinsic sizing problems
21:20:30 <heycam> birtles: I don't know if we can get through this in 10 minutes
21:20:35 <heycam> ... I prepared a summary
21:20:46 <heycam> ... a lot of tools write out SVG with an absolute width/height
21:20:53 <heycam> ... then documents don't resize as authors often want
21:21:00 <heycam> ... this came up in the context of the viewbox property
21:21:24 <heycam> ... 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>
21:22:12 <heycam> ... 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
21:22:25 <heycam> ... otherwise the viewbox does
21:22:27 <birtles> here is the mail: http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.html
21:22:28 <heycam> ... that's the current behaviour
21:22:54 <birtles>   .my-hardcoded-svg {
21:22:54 <birtles>    width: auto !important;
21:22:54 <birtles>    height: auto !important;
21:22:54 <birtles>    viewbox: auto;
21:22:54 <birtles>   }
21:22:55 <heycam> ... Alex suggests a way to override it using an !important rule
21:23:02 <birtles> ^ That is the proposed syntax
21:23:36 <heycam> ... there is also the proposal to promote preserveAspectRatio to a property, so that you can override what the authoring tool output
21:23:45 <heycam> ... there's also object-fit
21:24:12 <birtles> my follow up mail: http://lists.w3.org/Archives/Public/www-svg/2014Jan/0024.html
21:24:13 <heycam> heycam: I thought we had decided to use object-fit as our preserveAspectRatio-like property
21:24:22 <heycam> birtles: it seems to work at a different level
21:24:30 <heycam> ... object-fit sets the aspect ratio, then it determines a concrete object size
21:24:34 <heycam> ... that's given to SVG as a viewport
21:24:42 <heycam> ... then we use pAR to fit in to that viewport
21:24:55 <heycam> ... I guess you could specify object-fit in two places?
21:25:01 <heycam> ... when you're sizing an SVG image into an HTML <img> element
21:25:26 <heycam> ... 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>
21:26:07 <heycam> birtles: I'll follow up on the list; the one thing to come out of it is that interop is still not very good
21:26:20 <heycam> ... Alex had suggested that we have a concrete algorithm for calcaulting the viewport
21:26:37 <heycam> ... not sure if that's the answer, or if we need new tests, but his point is right that interop isn't great
21:26:42 <heycam> ... especially with replaced content
21:27:10 <heycam> ... no action to come out of this, but I'll follow up with Alex
21:28:41 <heycam> ed: might be good to have the summary on the wiki somewhere?
21:28:52 <heycam> ... I'm finding it hard to follow the threads and get a clear view of what's going on
21:29:06 <Zakim> -Tav
21:29:08 <heycam> Tav: also a few demonstrations
21:29:17 <heycam> ACTION: Brian to summarise sizing issues on the wiki
21:29:18 <trackbot> Created ACTION-3556 - Summarise sizing issues on the wiki [on Brian Birtles - due 2014-01-16].
21:29:27 <Tav> My connection just timed out...
21:29:46 <heycam> 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
21:30:19 <ed> Zakim, end telcon
21:30:19 <Zakim> I don't understand 'end telcon', ed
21:30:34 <ed> trackbot, end telcon
21:30:34 <trackbot> Zakim, list attendees
21:30:34 <Zakim> As of this point the attendees have been Doug_Schepers, Thomas_Smailus, krit, [IPcaller], birtles, ed, heycam, stakagi, nikos_, Tav, cabanier
21:30:42 <trackbot> RRSAgent, please draft minutes
21:30:42 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/09-svg-minutes.html trackbot
21:30:43 <trackbot> RRSAgent, bye
21:30:43 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2014/01/09-svg-actions.rdf :
21:30:43 <RRSAgent> ACTION: Brian to summarise sizing issues on the wiki [1]
21:30:43 <RRSAgent>   recorded in http://www.w3.org/2014/01/09-svg-irc#T21-29-17