SVG Working Group Teleconference -- 18 Feb 2016

649 040 824

svg

'svg' is the password

<scribe> Scribe: Nikos

<scribe> scribenick: nikos

How should degenerate closed paths render in SVG

https://github.com/w3c/svgwg/issues/42

nikos: Think the spec intention is for zero length closed subpaths to render as open subpaths
... based on the cap

Tav: I disagree - I have a demo

<Tav> http://tavmjong.free.fr/SVG/line_cap.svg

Tav: Shows an animation - for the open path I think the result is correct

nikos: That is clearly specced in SVG at the moment

Tav: A closed path doesn't have any caps - it should use linejoins if anything

AmeliaBR: Behaviour is different for chrome and FF

Tav: I think I saw mention that a closed path should render as a circle of zero radius
... then you would have a stroke that gives a circle
... the end result is the same for round
... square and butt would also end up being a circle

AmeliaBR: Edge has same behaviour as FF

nikos: There's a table describing implementation behaviour in the github issue

https://svgwg.org/svg2-draft/paths.html#PathDataErrorHandling

nikos: strongest text is in path data error handling

https://svgwg.org/svg2-draft/painting.html#LineCaps

nikos: The painting chapter also talks about this for each cap - but not clear that it applies to zero length because they don't have caps
... I like the behaviour of the cap controlling the effect
... it gives the user complete control of what the behaviour will be
... it does slightly overload the linecap attribute
... it also matches most implementations and pdf

AmeliaBR: it's also the easiest to spec

nikos: I think we say open and closed subpaths are the same - that covers directionality

AmeliaBR: The continuity argument works for a circle but not for a square - you would animate down to a circle

nikos: Tav, could you love with linecaps?

Tav: I'm not going to jump up and down and scream if I don't get my way

shepazu: I'm inclined to agree with Nikos - on one hand it would be simpler to have a uniform behaviour and not have linecap have an effect
... but I think letting the linecap control it does make sense
... otherwise there's no way to control it - I might not be 100% in line with that decision, maybe swaying a little towards Tav as well

AmeliaBR: we already have this behaviour specced for open paths
... it's not a perfect solution but it's out there and it does give the author some little control

RESOLUTION: zero length closed subpaths should render the same as zero length open subpath using the stroke-linecap to determine the result

<scribe> ACTION: nikos to file a bug on chrome regarding zero length subpaths [recorded in http://www.w3.org/2016/02/18-svg-minutes.html#action01]

<trackbot> Created ACTION-3837 - File a bug on chrome regarding zero length subpaths [on Nikos Andronikos - due 2016-02-25].

AmeliaBR: I'm not seeing the star on FF nightly on Windows

Can we resolve on nested a elements?

https://github.com/w3c/svgwg/issues/26

nikos: This is an old issue - wondering if based on issue discussion we can resolve and close this?

AmeliaBR: html clearly specs you shouldn't nest links. We don't
... second thing is giving user agent advice on how to handle this
... Cam's test shows inner test takes precedence over outer link in html

richardschwerdtfeger: that makes sense

shepazu: I think it makes sense to have the inner link take precedence over the outer link
... if it's interop there's no sense in telling authors not to do that
... it makes semantic sense to be able to do that
... you can't always predict what will be a link when generating the svg (e.g. with some data vis package)
... not allowing them to have nested links decreases the ability to have good semantic structures

AmeliaBR: Rich, do you know how screen readers deal with this?

richardschwerdtfeger: That's a great question
... I don't think they handle it well - they usually treat them as the single line text
... if you put a link inside of it - I think they'd have problems with it

shepazu: Do you think they would actually behave differently?
... don't they just present things as a list of links?
... so why would it care whether there's an outer and inner link?

richardschwerdtfeger: it does a name computation on the link

shepazu: let me give an example

http://mcc.id.au/temp/nested-links.html

shepazu: Here the name computation for the outer link is foobar
... the inner is bar
... doesn't matter if there's an image or anything else
... don't see how screen reader should be affected

richardschwerdtfeger: not sure if they would treat that as a single entity
... or if they'd skip over the link
... they do bring up a list of links on the page - but as you know, having a list of links on a page isn't always helpful
... some things act like links that aren't links, etc

shepazu: if we strip it down they should be able to do something sensible

richardschwerdtfeger: think this group shouldn't worry about this - think the behaviour of allowing inner link is ok

AmeliaBR: we could add a sentence of authoring guidance that this may be a risky area without making it a strict problem
... either way I think the best solution is to make sure the behaviour of svg match html
... html has interop behaviour for a validity error

shepazu: doesn't matter if spec says no, let's ignore that

Tav: inner links are useful

richardschwerdtfeger: is there a reason we don't just point at html defintion?

AmeliaBR: there's some other inconsistencies

RESOLUTION: the content model of the a element in SVG will allow nested a elements

nikos: Just for clarity, the other aspect of that issue - the inclusion of extra attributes on SVG has already been discussed

AmeliaBR: I'd like to defer to html

Linking: ID + SVGViewSpec

AmeliaBR: It's an interesting idea - but not something I want to dive into for SVG 2
... summary is why can't you use svg view specs to embed svg fragments from other parts of the document - either from other parts of a html document or child svg
... there's definitely good use cases, but it's really complicated
... the svg view spec assumes you're embedding a distinct separate file
... we don't have ways to use view when svg is inline - if you add an anchor tag it's going to behave like normal html rules for target fragments

nikos: I'm happy with that - you're the expert in this area

https://github.com/w3c/svgwg/issues/48

AmeliaBR: I'll respond on the issue

nikos: We need a future feature tag for ideas we like but can't work on straight away

London F2F

https://www.w3.org/2002/09/wbs/19480/London2016/

nikos: Please register if you're coming

Accessibility update

richardschwerdtfeger: we've been very busy

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/graphics-aam/graphics-aam.html

richardschwerdtfeger: we have a small vocab for the graphics module
... here's the mapping spec we created over teh last week
... we'll be doing some final edits
... Jonie is putting the last drop of the svg accessibility mapping work into webkit
... that's our first step forward

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

richardschwerdtfeger: we've also reflected the graphics additions into the new svg accessibility api mapping guide
... what we project is that next month we'll refresh tehse heartbeat drafts
... other thing we're doing is working to get aria 1 locked down and completed
... over the next couple of months
... we're trying to lock svg 2 down by the end of march?

nikos: it'll be a little later than that

AmeliaBR: final edits in April, approval in May

richardschwerdtfeger: we want to have aria 1.1 conssitent in it's support for html and svg
... then we'll have a set of mapping for both html and svg
... going forward we don't want to just have html - we want them to happen at the same time
... we're focusing for SVG 2 on getting the basic accessibility work working across browsers
... so not a lot of new semantics at this point
... that'll be a huge win for the group though

AmeliaBR: just following up - I took some actions for the TF to make some edits that'll change SVG 2
... we figured the best way to handle issues with svg elements that should not logically have any interaction is to come up with some clear definitions for a category of an element that we can reference
... the way we have it now is to be general - any svg element can have tabindex for example
... but there are lots of elements where this doesn't make sense
... we want to have some clear definitions about elements that never represent anything on screen
... e.g. if you put tabindex on a linear gradient it's ignored

richardschwerdtfeger: what about clarifications for title?

AmeliaBR: we have this new feature of switching languages on title and desc
... brad came up with a couple of unspecified issues
... what happens if you have title or desc but it's empty
... accessibility team felt we should keep it simple and not do anything fancy with that
... not a useful result but a straight forward one
... other question -what if lang is empty?
... it means unknown language or no particular language
... not quite sure how that should match as far as finding the best matched langauge rules

richardschwerdtfeger: how do the browsers handle that today?

AmeliaBR: the language switching rules don't exist right now, but I'm going to see whatpeople do with an empty tooltip

richardschwerdtfeger: I guess no one knows the answer right now?

nikos: that's right

AmeliaBR: I'm not getting anything with a tooltip

shepazu: you don't know that neccessarily

AmeliaBR: that's right they could be creating it but I can't see it

shepazu: might be getting discounted because of bounding box or something

richardschwerdtfeger: ok we don't have the answer to that right now
... I understand at the F2F there were some decisions on pointing to the html tabindex part
... it's not as simple as that because the navigation for tab index includes form elements taht we don't have in svg
... also there's a whole list of issues around event handlers on certain elemetns and where they apply
... I agree it would be nice to point to one place, but what we need to do is create a module that is re-used by both html and svg
... don't think we can point to html - having gone through this, the reason I didn't point to html was
... 1. it was in flux
... 2. we really need to have one module we share for all the other erasons
... html has gone for module design anyways
... do you want to do this for svg 2 or do you want to follow up

<AmeliaBR> https://github.com/w3c/svgwg/issues

https://github.com/w3c/svgwg/issues

nikos: probably a good idea to raise a github issue so more people can comment

AmeliaBR: have you made an itemised list of reasons why the HTML rules don't work for SVG?

richardschwerdtfeger: no, but there's a lot of them
... I'll try to write them down when I raise the issue

adjourned

- DRAFT -

SVG Working Group Teleconference

18 Feb 2016

Attendees

Contents

How should degenerate closed paths render in SVG

Can we resolve on nested a elements?

Linking: ID + SVGViewSpec

London F2F

Accessibility update

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output