W3C

- DRAFT -

SVG Working Group Teleconference

05 Nov 2015

Agenda

See also: IRC log

Attendees

Present
ed, heycam, Tav, stakagi, BogdanBrinza, AmeliaBR, nikos
Regrets
Chair
Cameron
Scribe
Cameron

Contents


<trackbot> Date: 05 November 2015

FYI, the meeting access code has changed

644 384 016

<shepazu> https://mit.webex.com/mit/j.php?MTID=mfbd328afdc7c85003ed6c87919f43c67

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

https://lists.w3.org/Archives/Public/www-svg/2015Oct/0036.html

Removal of viewTarget attribute

AmeliaBR: viewTarget lets you identify a target element
... it was designed to allow extra highlighting styles
... right now it doesn't have an effect
... but it could be important and useful for making views accessible
... 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
... 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"
... and that would allow screen readers to have that link be meaningful
... right now, from a meaning perspective, and for target/styling, you have to choose if you're targeting an element or targeting a view
... if viewTarget was properly supported by screen readers, and as originally intended for :target stylilng, then you'd be able to do both
... 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

shepazu: we've tried to specify this before, maybe not all the details you mentioned
... I don't think there's any problem with doing so

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
... right now, afaik, screen readers don't do anything special for views
... and it might end up being a dead link, as they don't see <view> as something that is rendered
... afaik it is treated as a link to an element, and the screen reader will you're assume you're "at" the <view> element in terms of reading the document

shepazu: I'm all for specifying that kind of thing. are you volunteering to do that?

AmeliaBR: the draft writeup is in the SVG Accessibility Mapping, but it was based on the assumption that this viewTarget="" was in SVG
... and as we were reviewing, we discovered the removal of the attribute

heycam: what was I testing, do you recall?

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

heycam: I see

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.

heycam: ok. on that basis I would be fine for it to be reinstated.

AmeliaBR: are people interested in ensuring that viewTarget="" triggers :target style?

shepazu: I think that's the cleanest way of doing it

heycam: how do implementations do with bare identiifier :target styling?

AmeliaBR: it's mostly implemented as it works in HTML. I did find that Firefox had an issue where it wouldn't recognise a <view> element has having that class, so you can do it with the sibling selector trick
... if you markup is correctly arranged

heycam: ok I guess now with inheriting from HTMLElement we get class=""
... on <view>
... the only thing I could possibly imagine being a difficulty, is if both the <view> and the viewTarget="" match :target

AmeliaBR: well, viewTarget="" also allows multiple elements to be listed
... so it could be a problem for implementations
... but generally, :target is a host document language thing
... it's just the case that the way it works in HTML is what CSS has been based on
... 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

BogdanBrinza: from your email, I quite like the aria attribute approach
... in every screen reader that would need that functionality, you'd need to add special handling for viewTarget, so ...

AmeliaBR: it would be part of the "SVG Accessibility Mapping" spec, which is defining how native SVG elements get mapped to ARIA-type behaviour
... so the browsers would have to know what an SVG <view> is and how it affects the accessible representation of the document, but individual screen readers would not

BogdanBrinza: if web authors provide already aria attributes [is that enough?]

AmeliaBR: there will need to be specific rules for <view>s anyway, as there are other ways in which they're unlike HTML
... 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
... 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
... 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
... so you would have both the rectangle and the element you're interested in, and you could communicate both
... and there's no way to do that with aria without modifying that document

shepazu: aria is also not meant to invoke special magical behaviour, but rather just be instructions to an AT

BogdanBrinza: for the presentation aspect, it would be hard to solve without those attributes

<ed> regarding the viewSpec syntax for links, is that information typically exposed in screen readers?

BogdanBrinza: about existing patterns, at the meeting, people were unclear about the use of viewTarget=""
... so I wonder whether it really is an existing known pattern

AmeliaBR: the intended purpose was for :target styling, and that was never clearly defined/implemented
... so there's probably not a lot of content out there
... <view>s aren't used as much as they could be

shepazu: it's a bit chicken-and-egg

AmeliaBR: in all things accessibility-related, it's hard to convince them to put things in the document without visible impact

BogdanBrinza: specifically for viewTarget="", we couldn't identify the functionality that was supposed to be associated with it
... we didn't discuss the styling/metadata aspect
... different people had different expectations about what it was meant to do
... and so I imagine authors would similarly be unclear about what viewTarget="" is for

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?

AmeliaBR: if the alternative in aria doesn't have the potential to be extended to the #svgView fragment syntax...

BogdanBrinza: I don't think aria- attributes will solve all issues, like the presentation aspects here
... might it be worth talking with the a11y TF to find out what kind of use cases we want to solve with it?

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
... 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
... 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 <view>, and the viewTarget="" provides that extra connection to the element in question

shepazu: in terms of familiarity to authors, I agree it's not been traditionally used
... however this does seem to be the intuitive thing to do

BogdanBrinza: I don't have objections to specifying it this way

<ed> would viewTarget be different from the <svg> element that contains the <view> element?

BogdanBrinza: but at the same time I feel like it might not be enough to solve the problem

AmeliaBR: in the TF, we were trying to make sure that views are meaningful
... because you often link to a view, you need to make sure that when you follow that link, you end up somewhere meaningful
... 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
... 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
... so we need clear rules that views actually work that, so that the screen reader perspective matches the visual persecptive
... part of that is author guidance to use these extra attributes, just like we suggest to use titles and descriptions, etc.
... but part is also that browsers are able to go from the visual view to the content

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...
... 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
... and then come back to this group with a recommendation?

AmeliaBR: I can do that
... 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
... and examples of good authoring practice so that something still makes sense even in an existing behaviour that doesn't have the special rules

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
... and come back to the group with that. it may or may not match what the spec had before

BogdanBrinza: that sounds like a good plan

shepazu: Amelia I'll touch base with you on this one. there may or may not be something from 1.2T to reuse here.

<scribe> ACTION: Amelia to draft text related to viewTarget and some examples [recorded in http://www.w3.org/2015/11/05-svg-minutes.html#action01]

<trackbot> Created ACTION-3827 - Draft text related to viewtarget and some examples [on Amelia Bellamy-Royds - due 2015-11-12].

SVG 2 progress update

heycam: let's just get an update on where people are with their chapters
... 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

Bogdan: no updates on my chapters

AmeliaBR: I took over some issues in the Linking chapter, still some items on my todo list for that
... I'm testing implementations before we change things
... e.g. questions about links inside links

Tav: I'm making slow but steady progress on Text, getting things updated for CSS 3
... I'm getting to a point where I could realise use heycam's finished text layout algorithm
... I've got some baseline stuff to deal with

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

Tav: all of them?

AmeliaBR: all the baselines are introduced but these other keywords that nobody implemented got dropped
... we need to follow up and coordinate

Tav: the one baseline I thought was dropped that might be interesting is ideographic

AmeliaBR: that should be there, if it's not in the one spec it'll be in the other one
... but there were things like a keyword like "use-font" or something, that got dropped
... 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
... and is horrible and inconsistent in implementations currently

Tav: shouldn't be any different from single normal lines of text

AmeliaBR: shouldn't be, but startOffset=""...

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

nikos: Rendering Model is done
... I picked up the animVal change, which I finished off last week

heycam: would you be willing to pick up the Coords chapter?

nikos: sure

Bogdan: in a Windows 10 update soon, we're adding external resources for <use>. we identified some issues
... we couldn't find any reference to enforcing CORS
... and implementations are inconsistent
... in Firefox there aren't restrictions about domain
... in Edge it's same domain
... the elements that can be used in external resources are not clear
... e.g. we don't allow <filter>, but we do allow <pattern>, <use>
... all implementations don't allow script to run
... also, how many levels deep can you link to resources?
... in Firefox there are no restrictions, Edge/Chrome does have
... finally there's no way to handle errors loading external resources
... some of these things might be too big for SVG 2, but others like CORS need to be specified somewhere
... looks like the Linking chapter might be the best place to put this

<ed> error events should fire according to SVG2 AFAIK, wasn't explicitly required before

<ed> for the external loads

http://www.w3.org/TR/svg-integration/

heycam: the Integration spec was the place we intended to put things

Bogdan: that spec looks like a good place to put this, yes
... second question is whether inline <svg> is a replaced element
... the good news is that Edge matches Firefox and Chrome, mostly
... at the time it was implemented, in IE9 I think, all browsers did something different
... 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.
... that does sound like something that does work correctly in implemetnations but needs to be specified
... for a newer implementer it would be good to specify this

AmeliaBR: I would definitely +1 for getting that written down
... as you say, we've moved to a defacto standard with browsers matching each other but it's not written down anywhere
... and it drives authors nuts they can't rely on existing behaviour

Bogdan: we developed a massive number of tests, close to 500 with min-width, max-width, viewBox or not, etc.

AmeliaBR: there's a section in the SVG spec that describes how SVG has an intrinsic size and/or aspect ratio
... but then it's connecting that up with the CSS and HTML concept of a default size for replaced elements

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.
... I'm not sure where in the spec that would fall
... from an implementation perspective it's a very common use case
... putting it in Integration might let it move faster

<AmeliaBR> Current text on intrinsic sizing: https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing

<scribe> ACTION: Bogdan to write up text about sizing, either in SVG 2 or Integration [recorded in http://www.w3.org/2015/11/05-svg-minutes.html#action02]

<trackbot> Created ACTION-3828 - Write up text about sizing, either in svg 2 or integration [on Bogdan Brinza - due 2015-11-12].

<AmeliaBR> https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing

AmeliaBR: looks like that section hasn't changed much from 1.1, apart from adding issues
... if you wanted to flesh that out it might be a good starting point

trackbot: end telcon

Summary of Action Items

[NEW] ACTION: Amelia to draft text related to viewTarget and some examples [recorded in http://www.w3.org/2015/11/05-svg-minutes.html#action01]
[NEW] ACTION: Bogdan to write up text about sizing, either in SVG 2 or Integration [recorded in http://www.w3.org/2015/11/05-svg-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/11/05 21:32:05 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: ed, heycam, Tav, stakagi, BogdanBrinza, AmeliaBR, nikos
Present: ed heycam Tav stakagi BogdanBrinza AmeliaBR nikos
Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Nov/0011.html
Found Date: 05 Nov 2015
Guessing minutes URL: http://www.w3.org/2015/11/05-svg-minutes.html
People with action items: amelia bogdan

[End of scribe.perl diagnostic output]