20:28:16 RRSAgent has joined #svg 20:28:16 logging to http://www.w3.org/2015/11/05-svg-irc 20:28:18 RRSAgent, make logs public 20:28:18 Zakim has joined #svg 20:28:20 Zakim, this will be GA_SVGWG 20:28:20 I do not see a conference matching that name scheduled within the next hour, trackbot 20:28:21 Meeting: SVG Working Group Teleconference 20:28:21 Date: 05 November 2015 20:29:51 FYI, the meeting access code has changed 20:29:57 644 384 016 20:30:03 heycam has changed the topic to: Meeting access code is: 644 384 016 20:31:50 Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Nov/0011.html 20:31:57 present+ ed 20:32:06 BogdanBrinza has joined #svg 20:32:09 Chair: Cameron 20:32:15 present+ heycam 20:34:01 present+ Tav 20:34:52 present+ stakagi 20:35:17 present+ BogdanBrinza 20:35:20 https://mit.webex.com/mit/j.php?MTID=mfbd328afdc7c85003ed6c87919f43c67 20:36:51 present+ AmeliaBR 20:37:32 present+ nikos 20:37:58 Scribe: Cameron 20:38:00 ScribeNick: heycam 20:38:06 Topic: https://lists.w3.org/Archives/Public/www-svg/2015Oct/0036.html 20:38:12 Topic: Removal of viewTarget attribute 20:39:08 AmeliaBR: viewTarget lets you identify a target element 20:39:15 ... it was designed to allow extra highlighting styles 20:39:19 ... right now it doesn't have an effect 20:39:26 ... but it could be important and useful for making views accessible 20:39:43 ... right now when you define a view, you're defining a rectangle that you're linking to, but that doesn't say anything about what actual content is inside the content is interesting 20:40:16 ... if you have a screen reader, it could theoretically try to guess based on what's visible, but it's not going to be as effective as simply having the author say "show this view, and here's the important item in the view which is the focus of the link" 20:40:28 ... and that would allow screen readers to have that link be meaningful 20:40:43 ... right now, from a meaning perspective, and for target/styling, you have to choose if you're targeting an element or targeting a view 20:40:57 ... if viewTarget was properly supported by screen readers, and as originally intended for :target stylilng, then you'd be able to do both 20:41:11 ... here's a link to the document, here's the rectangle you should display, and here's the content inside the rectangle that it's going to 20:41:29 shepazu: we've tried to specify this before, maybe not all the details you mentioned 20:41:40 ... I don't think there's any problem with doing so 20:42:06 AmeliaBR: there are two sides of it. one is to trigger the :target pseudoclass for CSS styling, and there's whether it should have a meaningful connection for screen readers 20:42:13 ... right now, afaik, screen readers don't do anything special for views 20:42:24 ... and it might end up being a dead link, as they don't see as something that is rendered 20:42:48 ... afaik it is treated as a link to an element, and the screen reader will you're assume you're "at" the element in terms of reading the document 20:42:58 shepazu: I'm all for specifying that kind of thing. are you volunteering to do that? 20:43:14 AmeliaBR: the draft writeup is in the SVG Accessibility Mapping, but it was based on the assumption that this viewTarget="" was in SVG 20:43:28 ... and as we were reviewing, we discovered the removal of the attribute 20:44:03 heycam: what was I testing, do you recall? 20:44:21 AmeliaBR: the tests that you had were for viewTarget="" to actually create a view based on an object bounding box, which was never something that was in the spec 20:44:23 heycam: I see 20:44:42 AmeliaBR: that's one thing. the viewTarget="" doesn't actually change the view, and was never supposed to. you'd still need to use a viewBox="" to define the rectangle. 20:45:35 heycam: ok. on that basis I would be fine for it to be reinstated. 20:45:54 AmeliaBR: are people interested in ensuring that viewTarget="" triggers :target style? 20:46:16 shepazu: I think that's the cleanest way of doing it 20:46:47 heycam: how do implementations do with bare identiifier :target styling? 20:47:15 AmeliaBR: it's mostly implemented as it works in HTML. I did find that Firefox had an issue where it wouldn't recognise a element has having that class, so you can do it with the sibling selector trick 20:47:20 ... if you markup is correctly arranged 20:47:51 heycam: ok I guess now with inheriting from HTMLElement we get class="" 20:47:54 ... on 20:48:53 ... the only thing I could possibly imagine being a difficulty, is if both the and the viewTarget="" match :target 20:49:04 AmeliaBR: well, viewTarget="" also allows multiple elements to be listed 20:49:09 ... so it could be a problem for implementations 20:49:17 ... but generally, :target is a host document language thing 20:49:28 ... it's just the case that the way it works in HTML is what CSS has been based on 20:49:55 ... I don't think anyone ever implemented the xlink target things, which could in theory do the same thing, but I don't think there are practical implementations of it 20:50:07 BogdanBrinza: from your email, I quite like the aria attribute approach 20:50:23 ... in every screen reader that would need that functionality, you'd need to add special handling for viewTarget, so ... 20:50:42 AmeliaBR: it would be part of the "SVG Accessibility Mapping" spec, which is defining how native SVG elements get mapped to ARIA-type behaviour 20:51:03 ... so the browsers would have to know what an SVG is and how it affects the accessible representation of the document, but individual screen readers would not 20:51:28 BogdanBrinza: if web authors provide already aria attributes [is that enough?] 20:51:43 AmeliaBR: there will need to be specific rules for s anyway, as there are other ways in which they're unlike HTML 20:52:13 ... as I said, we could put a lot of new authoring guidance out there to encourage people to use a new authoring pattern, when there's an existing authoring pattern in the spec, I'd rather use that, and get some backwards compat from that 20:52:41 ... the other thing is the svgView target fragment, if I'm as an author using someone else's SVG image, and I want to highlight a specific part of it, I can create a view in the URL 20:53:06 ... and in that case there isn't an element in the document I could put some aria- attributes on, it's only what I can put in the URL, and again we have this previous spec that says you could put a viewTarget in the URL 20:53:18 ... so you would have both the rectangle and the element you're interested in, and you could communicate both 20:53:27 ... and there's no way to do that with aria without modifying that document 20:53:51 shepazu: aria is also not meant to invoke special magical behaviour, but rather just be instructions to an AT 20:54:02 BogdanBrinza: for the presentation aspect, it would be hard to solve without those attributes 20:54:10 regarding the viewSpec syntax for links, is that information typically exposed in screen readers? 20:54:36 ... about existing patterns, at the meeting, people were unclear about the use of viewTarget="" 20:54:44 ... so I wonder whether it really is an existing known pattern 20:54:56 AmeliaBR: the intended purpose was for :target styling, and that was never clearly defined/implemented 20:55:01 ... so there's probably not a lot of content out there 20:55:15 ... s aren't used as much as they could be 20:55:20 shepazu: it's a bit chicken-and-egg 20:55:38 AmeliaBR: in all things accessibility-related, it's hard to convince them to put things in the document without visible impact 20:56:03 BogdanBrinza: specifically for viewTarget="", we couldn't identify the functionality that was supposed to be associated with it 20:56:17 ... we didn't discuss the styling/metadata aspect 20:56:28 ... different people had different expectations about what it was meant to do 20:56:38 ... and so I imagine authors would similarly be unclear about what viewTarget="" is for 20:57:19 shepazu: is it similar enough in HTML or CSS that it could be familiar, or is this just based on it being in the spec before? 20:57:50 AmeliaBR: if the alternative in aria doesn't have the potential to be extended to the #svgView fragment syntax... 20:58:03 BogdanBrinza: I don't think aria- attributes will solve all issues, like the presentation aspects here 20:58:37 ... might it be worth talking with the a11y TF to find out what kind of use cases we want to solve with it? 20:59:01 AmeliaBR: certainly having a clear description is one thing. the fact that members of this WG weren't sure what it was supposed to do is telling 20:59:23 ... but as far as educating authors, the viewTarget="" has the same meaning as the target you would use as an ID when linking to an element 20:59:54 ... SVG has added feature that you don't just scroll to that element, you want to define a 2D view, so you link to the , and the viewTarget="" provides that extra connection to the element in question 21:00:14 shepazu: in terms of familiarity to authors, I agree it's not been traditionally used 21:00:26 ... however this does seem to be the intuitive thing to do 21:00:42 BogdanBrinza: I don't have objections to specifying it this way 21:00:42 would viewTarget be different from the element that contains the element? 21:00:54 ... but at the same time I feel like it might not be enough to solve the problem 21:01:29 AmeliaBR: in the TF, we were trying to make sure that views are meaningful 21:01:40 ... because you often link to a view, you need to make sure that when you follow that link, you end up somewhere meaningful 21:01:58 ... and they don't end up in a random spot in the document, and which is unrelated to the intended perspective that a visual viewer would have 21:02:19 ... if I as a visual viewer, and I click on a link and it zooms to a specific section of the graph, I would expect the screen reader to do something similar, and start reading from there 21:02:35 ... so we need clear rules that views actually work that, so that the screen reader perspective matches the visual persecptive 21:02:52 ... part of that is author guidance to use these extra attributes, just like we suggest to use titles and descriptions, etc. 21:03:03 ... but part is also that browsers are able to go from the visual view to the content 21:03:25 shepazu: and to be clear, not everybody has accessibility needs is using AT, or if they are, they might be using say a screen magnifiier, not a screen reader... 21:03:57 ... can I suggest a path forward? maybe Amelia we can write up some use cases for the a11y TF, say this is how was specified, and then see if there might be a better way to define it 21:04:05 ... and then come back to this group with a recommendation? 21:04:06 AmeliaBR: I can do that 21:04:44 ... I was going to offer to rewrite up the text for the SVG spec that would build on what was in SVG 1.1 but clarify things a bit better than they had been, and at the same time I'll come up with a couple of examples of how it should work if everythin was implemented the way it want to be 21:04:58 ... and examples of good authoring practice so that something still makes sense even in an existing behaviour that doesn't have the special rules 21:05:40 shepazu: I think Bogdan was making the point that if it was specified at one point, it was underspecified, so let's look at it again and see if it meets the use cases that modern authors expect 21:05:49 ... and come back to the group with that. it may or may not match what the spec had before 21:05:59 BogdanBrinza: that sounds like a good plan 21:06:18 shepazu: Amelia I'll touch base with you on this one. there may or may not be something from 1.2T to reuse here. 21:06:40 ACTION: Amelia to draft text related to viewTarget and some examples 21:06:41 Created ACTION-3827 - Draft text related to viewtarget and some examples [on Amelia Bellamy-Royds - due 2015-11-12]. 21:07:14 Topic: SVG 2 progress update 21:07:47 heycam: let's just get an update on where people are with their chapters 21:09:27 heycam: Types and Style are done. Painting has two issues left: one is about marker orientation, just needs copying some text into the chapter, second is about the new vector-effects text, which should probably move into the Coords chapter 21:09:53 Bogdan: no updates on my chapters 21:10:21 AmeliaBR: I took over some issues in the Linking chapter, still some items on my todo list for that 21:10:28 ... I'm testing implementations before we change things 21:10:35 ... e.g. questions about links inside links 21:10:57 Tav: I'm making slow but steady progress on Text, getting things updated for CSS 3 21:11:08 ... I'm getting to a point where I could realise use heycam's finished text layout algorithm 21:11:13 ... I've got some baseline stuff to deal with 21:11:36 AmeliaBR: I was in the midst of writing a response to your email about the Text issues. some I think we need to follow up with CSS about 21:11:58 ... there are two different CSS specs, one that is published has a limited number of baselines, and there's another draft that reintroduces all the other SVG keywords 21:12:00 Tav: all of them? 21:12:13 AmeliaBR: all the baselines are introduced but these other keywords that nobody implemented got dropped 21:12:18 ... we need to follow up and coordinate 21:12:35 Tav: the one baseline I thought was dropped that might be interesting is ideographic 21:12:42 AmeliaBR: that should be there, if it's not in the one spec it'll be in the other one 21:12:55 ... but there were things like a keyword like "use-font" or something, that got dropped 21:13:29 AmeliaBR: I'll need to read the other changes you made, but I know we need clear descriptions -- for example text on path doesn't describe how RTL text works 21:13:48 ... and is horrible and inconsistent in implementations currently 21:13:56 Tav: shouldn't be any different from single normal lines of text 21:14:12 AmeliaBR: shouldn't be, but startOffset=""... 21:14:41 Tav: so I think I'm close to being done with what's in SVG, then I'll move my focus to the Shapes spec 21:15:05 nikos: Rendering Model is done 21:15:12 ... I picked up the animVal change, which I finished off last week 21:16:10 heycam: would you be willing to pick up the Coords chapter? 21:16:12 nikos: sure 21:17:10 Bogdan: in a Windows 10 update soon, we're adding external resources for . we identified some issues 21:17:18 ... we couldn't find any reference to enforcing CORS 21:17:26 ... and implementations are inconsistent 21:17:34 ... in Firefox there aren't restrictions about domain 21:17:40 ... in Edge it's same domain 21:17:52 ... the elements that can be used in external resources are not clear 21:18:05 ... e.g. we don't allow , but we do allow , 21:18:14 ... all implementations don't allow script to run 21:18:29 ... also, how many levels deep can you link to resources? 21:18:47 ... in Firefox there are no restrictions, Edge/Chrome does have 21:18:55 ... finally there's no way to handle errors loading external resources 21:19:15 ... some of these things might be too big for SVG 2, but others like CORS need to be specified somewhere 21:19:22 ... looks like the Linking chapter might be the best place to put this 21:19:24 error events should fire according to SVG2 AFAIK, wasn't explicitly required before 21:19:33 for the external loads 21:19:47 http://www.w3.org/TR/svg-integration/ 21:20:50 heycam: the Integration spec was the place we intended to put things 21:21:09 Bogdan: that spec looks like a good place to put this, yes 21:21:19 ... second question is whether inline is a replaced element 21:21:27 ... the good news is that Edge matches Firefox and Chrome, mostly 21:21:46 ... at the time it was implemented, in IE9 I think, all browsers did something different 21:22:15 ... but I think we arrived to a model that is pretty easy to specify, an algorithm, how intrinsic sizing / ratio / viewport in SVG integrates with CSS, etc. 21:22:31 ... that does sound like something that does work correctly in implemetnations but needs to be specified 21:22:46 ... for a newer implementer it would be good to specify this 21:22:55 AmeliaBR: I would definitely +1 for getting that written down 21:23:09 ... as you say, we've moved to a defacto standard with browsers matching each other but it's not written down anywhere 21:23:18 ... and it drives authors nuts they can't rely on existing behaviour 21:23:44 Bogdan: we developed a massive number of tests, close to 500 with min-width, max-width, viewBox or not, etc. 21:24:19 AmeliaBR: there's a section in the SVG spec that describes how SVG has an intrinsic size and/or aspect ratio 21:24:35 ... but then it's connecting that up with the CSS and HTML concept of a default size for replaced elements 21:25:23 Bogdan: there was a discussion this year about default replaced element sizes. but this issue here is wider than that -- how you calculate size given any amount of data, which includes 100s of different combinations of max-width, etc. 21:25:33 Bogdan: I'm not sure where in the spec that would fall 21:26:42 ... from an implementation perspective it's a very common use case 21:27:58 ... putting it in Integration might let it move faster 21:27:58 Current text on intrinsic sizing: https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing 21:28:28 ACTION: Bogdan to write up text about sizing, either in SVG 2 or Integration 21:28:28 Created ACTION-3828 - Write up text about sizing, either in svg 2 or integration [on Bogdan Brinza - due 2015-11-12]. 21:28:58 BogdanBrinza has joined #svg 21:29:19 https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing 21:29:38 AmeliaBR: looks like that section hasn't changed much from 1.1, apart from adding issues 21:29:44 ... if you wanted to flesh that out it might be a good starting point 21:31:51 trackbot: end telcon 21:31:51 Zakim, list attendees 21:31:51 As of this point the attendees have been ed, heycam, Tav, stakagi, BogdanBrinza, AmeliaBR, nikos 21:31:59 RRSAgent, please draft minutes 21:31:59 I have made the request to generate http://www.w3.org/2015/11/05-svg-minutes.html trackbot 21:32:00 RRSAgent, bye 21:32:00 I see 2 open action items saved in http://www.w3.org/2015/11/05-svg-actions.rdf : 21:32:00 ACTION: Amelia to draft text related to viewTarget and some examples [1] 21:32:00 recorded in http://www.w3.org/2015/11/05-svg-irc#T21-06-40 21:32:00 ACTION: Bogdan to write up text about sizing, either in SVG 2 or Integration [2] 21:32:00 recorded in http://www.w3.org/2015/11/05-svg-irc#T21-28-28