Minutes, 18 August SVG WG telcon

https://www.w3.org/2016/08/18-svg-minutes.html



   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

18 Aug 2016

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/www-svg/2016Aug/0046.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/08/18-svg-irc

Attendees

   Present
          Tav, nikos, stakagi, shepazu, AmeliaBR, shepazu_

   Regrets
   Chair
          Nikos

   Scribe
          Nikos

Contents

     * [4]Topics
         1. [5]Publishing SVG 2 CR
         2. [6]Remove support for "rev" attribute on <a> element
         3. [7]Define equivalent paths for degenerate shapes
         4. [8]Should some SVG 2 list type syntax definitions
            include a trailing comma?
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   <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

   [11]https://github.com/w3c/svgwg/issues/229

     [11] 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

   [12]https://github.com/w3c/svgwg/issues/224

     [12] 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

   [13]https://github.com/w3c/svgwg/issues/235

     [13] 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?

   [14]https://github.com/w3c/svgwg/issues/233

     [14] 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> [15]http://jsbin.com/wiwocutefe/1/edit?html,output

     [15] 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

Summary of Action Items

Summary of Resolutions

    1. [16]Remove rev attribute from SVG 2
    2. [17]For equivalent paths exposed to authors, the actual
       equivalent path must be returned, even if the basic shape
       would not render.
    3. [18]SVG 2 list type grammars will not explicitly include a
       trailing comma

   [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Friday, 19 August 2016 00:20:29 UTC