See also: IRC log
649 040 824
svg
'svg' is the password
<scribe> Scribe: Nikos
<scribe> scribenick: nikos
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
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> <a href="foo">foo <a href="bar">bar</a></a>
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
https://www.w3.org/2002/09/wbs/19480/London2016/
nikos: Please register if you're coming
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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/why ?/why the HTML rules don't work for SVG?/ Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: nikos Present: nikos Tav stakagi AmeliaBR richardschwerdtfeger Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Feb/0047.html Found Date: 18 Feb 2016 Guessing minutes URL: http://www.w3.org/2016/02/18-svg-minutes.html People with action items: nikos[End of scribe.perl diagnostic output]