<scribe> Scribe: Nikos

<scribe> scribenick: nikos

Publishing SVG 2 CR

nikos: Deadline for review comments is next Monday (Australian time) and we haven't really had anything relevant to SVG 2 come up
... There's been some discussion of related topics with a11y
... and a18n mentioned the review in their minutes, but no comments yet
... so will talk to Doug early next week about getting approval to publish
... so I'll prepare everything with a publication date sometime in next week
... and do animation as well
... and for SVG Strokes, etc, I would like to update those on TR as well because the EDs have a note stating that SVG 2 is what implementors should currently be looking at, and there's been some confusion

AmeliaBR: We could name them like CSS and call them Level 3 specs
... I was playing around trying to build them and see if I could fix the style problem with the TOC
... if I can figure that out I'll push a change

For the issue regarding categories

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

nikos: I'll have a look at that today and try to make some sense of it
... there's categories that aren't referenced at all and they should be deleted

Remove support for "rev" attribute on <a> element

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

nikos: So Whatwg removed this from their spec, W3C put it back in
... Couldn't find any discussion as to why W3C want it in, so I think everyone would be mostly happy if we remove it from ours
... and let the HTML groups sort it out
... can add later if need be

Tav: I'm fine with that

AmeliaBR: As I said in the issue, I'm ok either way, I was just looking at the W3C HTML spec first

RESOLUTION: Remove rev attribute from SVG 2

Define equivalent paths for degenerate shapes

nikos: This isn't for SVG 2 CR, but there's been some discussion over the last week

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

AmeliaBR: Right now for SVG we have some things that are logically inconsistent
... because this isn't exposed to authors we don't strictly need to deal with it now
... basically the problem is that we have behaviour on shapes that isn't consistent with the path element that has the equivalent path
... when the shape is degenerate
... think I like the result that Nikos and Paul came to as well, which is to define it in terms of some extra switch that turns off rendering even though the equivalent path is something that would be a valid path, but is a shape that currently doesn't render
... agree with Nikos that it might be taking away useful functionality if the equivalent path returned were empty

Tav: I don't have a strong opinion on this

AmeliaBR: I think try to be as consistent as we can - the bounding box matches the equivalent path
... if we keep equivalent path as it's defined, the bounding box can be computed based on the equivalent path using whatever functions or algorithms are used
... the only place where it's inconsistent is that you don't actually draw the shape
... so that's where we can add in a switch or special rule to deal with teh backwards compat

nikos: And there was the suggestion of exposing that switch to authors
... so they can control whether degenerate shapes render

Tav: How much content would break if we change the default?

nikos: No idea, but maybe if people are using the behaviour to make the shape dissapear in their drawing that would be bad
... probably mostly animated content would be affected

AmeliaBR: We can agree that the equivalent path will be the equivalent path and the inconsistency will be at the rendering level
... And I can close that issue and create a new one about exposing the path data

RESOLUTION: For equivalent paths exposed to authors, the actual equivalent path must be returned, even if the basic shape would not render.

Should some SVG 2 list type syntax definitions include a trailing comma?

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

nikos: Now I think none of us have any idea why this change was originally made in SVG 2 - but SVG 1.1 grammars for lists didn't allow a trailing comma - SVG 2 did for a while, but I removed it
... The question is do we want to normatively specify that browsers need to be lenient in dealing with trailing commas
... or just leave it up to implementations and not spec it?

AmeliaBR: I did some testing - all UAs I tried didn't support trailing comma on presentation attributes but they did for text positioning attributes

<AmeliaBR> http://jsbin.com/wiwocutefe/1/edit?html,output

nikos: Maybe we just add a note advising implementors that content may exist that includes a trailing comma and that content would have worked in the path

AmeliaBR: Maybe we could ask Chrome to change and see if they get reports of breakage

Tav: I think we keep it the way it was in SVG 1.1. Various UAs don't support it - we don't

nikos: Yeah if there's no interop then it's not a big risk to spec with no trailing comma

RESOLUTION: SVG 2 list type grammars will not explicitly include a trailing comma

<AmeliaBR> trackbot, end telcon

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)

Found Scribe: Nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Default Present: Tav, nikos, stakagi, shepazu, AmeliaBR, shepazu_
Present: Tav nikos stakagi shepazu AmeliaBR shepazu_
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Aug/0046.html
Found Date: 18 Aug 2016
Guessing minutes URL: http://www.w3.org/2016/08/18-svg-minutes.html
People with action items: