See also: IRC log
<scribe> Scribe: Nikos
<scribe> scribenick: nikos
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
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
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.
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:[End of scribe.perl diagnostic output]