Minutes, 30 June 2016 SVG WG telcon

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Minutes, 30 June 2016 SVG WG telcon

Nikos Andronikos


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

                               - DRAFT -

                    SVG Working Group Teleconference

30 Jun 2016


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

   See also: [3]IRC log

      [3] http://www.w3.org/2016/06/30-svg-irc


          nikos, stakagi, AmeliaBR, Tav




     * [4]Topics
         1. [5]Publishing new drafts of SVG Accessibility specs
         2. [6]Avoiding camel case name for meshGradient
         3. [7]Better error handling for nested links
         4. [8]SVG 2 CR publishing plans
         5. [9]Restore SVGSVGElement.prototype.getElementById
         6. [10]Gradient stop colours with transparency values
         7. [11]Unknown elements behaving as g
     * [12]Summary of Action Items
     * [13]Summary of Resolutions

   <stakagi> hello

   <scribe> scribe: nikos

   <scribe> scribenick: nikos

Publishing new drafts of SVG Accessibility specs


     [14] https://lists.w3.org/Archives/Public/www-svg/2016Jun/0016.html

   AmeliaBR: Does anyone need to know anything not in the email?
   ... We're looking to publish the three specs
   ... The one that has the most interesting content from the SVG
   side is the SVG AM
   ... which talks about how the basic svg semantics should be
   interpreted from an SVG perspective
   ... the changes had to do with tricky little things
   ... like if you have conflicting information from an author,
   which should you expose
   ... a lot was based on implementer feedback
   ... there's definitely still some open issues
   ... the graphics spec is pretty innocuous
   ... but the AAM spec has issues about use elements, view
   elements, and we've created new roles for graphics, but
   creating them for ARIA isn't enough - you have to have
   something in the OS API
   ... so there's a lot of collaborative work to go on there

   nikos: what's the timeline that you expect to get these to CR?

   AmeliaBR: think the goal is this year
   ... There's dependencies. The SVG AAM relies on changes being
   made to SVG 2 - especially wrt to use elements
   ... similarly it's dependent on changes to ARIA 1.1, which
   we're trying to lock down this summer
   ... once those two specs are CR it'll be easier to sort out the
   remaining issue
   ... and there'll be more peple with more time to work on them

   RESOLUTION: SVG WG agrees to publish FPWD of SVG Graphics API
   Mappings, and updated WD for WAI-ARIA Graphics Module and SVG
   Accessibility API Mappings

Avoiding camel case name for meshGradient


     [15] https://github.com/w3c/svgwg/issues/181

   nikos: So we recently agreed that mesh gradients will be split
   into a geometry element and a paint server element
   ... currently the paint server element is called meshGradient,
   but we've had complaints from implementers, particularly Tab

   Tav: I'd like to get feedback from other implementers

   AmeliaBR: I would like more feedback, but I'm not sure if we're
   going to get it
   ... I personally don't think there's an optimal solution

   nikos: I agree

   AmeliaBR: we still have this situation where old elements are
   camel cased and new elements are not

   Tav: my thinking is that if anyone besides Tab complains then
   I'd be willing to drop the camel case
   ... and go with meshgradient

   nikos: +1 to meshgradient

   Tav: no one is going to be writing meshgradients by hand

   AmeliaBR: Simple four point gradients maybe?

   Tav: I've done it but it's very tough

   AmeliaBR: there's other places where you get tripped up - not
   just writing SVG code. E.g. you might defining selectors

   nikos: Having a quick look at an old conversation


     [16] https://www.w3.org/2015/02/11-svg-minutes.html#item03

   scribe: looks like general consensus is for consistency

   nikos: How about we try for more feedback. If we get feedback
   that camel case is bad, we'll make it gradientmesh, otherwise
   we'll keep it meshGradient and see what happens
   ... it's only a very small spec change
   ... at least we know what names we'll pick in each case

Better error handling for nested links


     [17] https://github.com/w3c/svgwg/issues/178

   AmeliaBR: At the F2F I made some changes to allow nested links,
   because it seemed logical to allow them
   ... got feedback that supporting it is a complete disaster
   ... both in SVG and creating nested links via script
   ... the HTML parser doesn't allow them, but they can be created
   in the DOM using JS
   ... given there's no pressing need for nested links - you can
   still have sibling elements that visually interact
   ... and there's no easy way to address the problems on the
   accessibility side - they just don't expect to find nested
   ... my argument is to revert that and go back to nested links
   being invalid
   ... second part is the error handling
   ... the way it's currently worded in SVG is that any element
   that appears when it shouldn't don't render at all
   ... so for browsers that follow that, any nested link doesn't
   ... so along with unknown elements now rendering, we should
   allow nested links to at least render

   Tav: For me the question is having nested links useful?
   ... even having special forgiving behaviour is going to require

   AmeliaBR: anything is going to require changes somewhere - we
   don't have interop

   Tav: so is having nested links something we'd want long term?
   ... we had the example of tspan inside text
   ... text links somewhere, tspan links somewhere else
   ... if we have nested graphical elements, like circle inside a
   rectangle, then you might want to have nested links
   ... I don't have a strong feeling for this
   ... if we do allow fallback, it might prevent us having nested
   links in future

   AmeliaBR: if we define it as an invalid case. It's not changing
   the handling of a valid document, it's changing error handling
   ... if it was supported it could be useful, but I don't think
   it's essential
   ... there's other ways to achieve the same effect

   Tav: I'd prefer to leave things but won't object

   nikos: I don't have a strong opinion either way. If we drop the
   href, they'd still be usable as an anchor
   ... we'd need to be clear on that

   AmeliaBR: yeah we wouldn't mess with the DOM

   nikos: My thinking of not rendering it at all is that at least
   it's a clear indication that you're doing something wrong

   AmeliaBR: I'm more concerned about accidental things - if you
   have an svg with a link inside and you put that inside a html

   Tav: I like immediate feedback

   nikos: The other argument is that unknown elements currently
   render. That may change as it's at risk

   AmeliaBR: are we talking nested links or nested a elements? Not
   all a elements are links

   nikos: So all nested a elements should show. Only link a
   elements wouldn't function as links

   AmeliaBR: we can mark it at risk and keep it in sync with
   unknown elements

   nikos: Which implementations do what?

   AmeliaBR: Blink and Webkit don't render. FF and Edge do - links
   work if you're clicking, but they're not effectively exposed to
   screen readers
   ... I haven't tracked whether that's a browser issue, screen
   reader issue, or API issue
   ... My preference is to allow rendering but require nested link
   functionality be ignore

   RESOLUTION: Nested a elements will render but href attribute
   will be ignored. But if unknown elements (at risk) are changed
   to not render, a elements will also then not render.

   <scribe> ACTION: Amelia to make changes wrt nested a elements
   [recorded in

     [18] http://www.w3.org/2016/06/30-svg-minutes.html#action01]

   <trackbot> Created ACTION-3847 - Make changes wrt nested a
   elements [on Amelia Bellamy-Royds - due 2016-07-07].

   AmeliaBR: I'll add an at risk note also

SVG 2 CR publishing plans

   nikos: At the end of the Amsterdam F2F I said two more weeks to
   get everything we want done
   ... how are people going for that?

   Tav: I haven't had a chance. That was expected though. Will
   have time this week

   nikos: I was having a look at the inline issues in the spec.
   Making sure no normative ones are in there. One biggish one
   with coords chapter, but I'll do that next week
   ... also been looking into what I need to do to publish
   ... should take me a day to work through the steps that Cameron
   wrote up

   AmeliaBR: I just need to look at the use element stuff

   nikos: The document structure had some inline issues so they
   should go when you do use element rewrite
   ... ok so let's review progress at next week's telcon, then
   I'll publish the week after

   AmeliaBR: we have a few issues that would be good to get more
   feedback. They're tagged 'needs resolution' in GH

   nikos: I'll send an email to the group today and try to get
   wider input

   <AmeliaBR> "Needs WG input":

     [19] https://github.com/w3c/svgwg/issues?q=is:issue+is:open+label:"Needs+WG+input"

   <AmeliaBR> "Needs resolution":

     [20] https://github.com/w3c/svgwg/issues?q=is:issue+is:open+label:"Needs+resolution"

   nikos: Add CR milestone too
   ... to cut down the list

Restore SVGSVGElement.prototype.getElementById

   AmeliaBR: I'm fine with it's a method that's widely supported
   and moderalyte useful so why not put it back in the spec

   <AmeliaBR> [21]https://github.com/w3c/svgwg/issues/182

     [21] https://github.com/w3c/svgwg/issues/182

   nikos: There was no question I was going to add it back into
   the spec
   ... Just wanted to understand the WG thinking in the past

   AmeliaBR: I like your suggestion of add it back in and suggest
   using other options

   nikos: I was curious of the perf difference of getDocumentById
   vs querySelector for ids
   ... jsperf is down =(

   AmeliaBR: logically it shouldn't be that different for a simple
   id selector

Gradient stop colours with transparency values


     [22] https://github.com/w3c/svgwg/issues/180

   AmeliaBR: We don't define what to do if gradient stop colour
   values have transparency
   ... CSS specs say to premultiply so that the colour strength is
   proportional to the transparency
   ... main reason to doing this is so that blue to transparent
   looks as people would expect - fading out blue rather than
   fading blue to transparent black
   ... my argument is that we should follow those rules
   ... problem with that is that there is still some debate on css
   side as to whether that's the best behaviour
   ... also canvas gradients do the opposite

   Tav: answer is what happens with opacity 0.99?

   AmeliaBR: It's scaled - strength is proportional

   Tav: I need to think about this

   nikos: I want to do some testing too - I haven't had time so

   AmeliaBR: There's a little extra math for implementers if we go
   with this
   ... my argument is for consistency
   ... good for authors and hopefully good for implementers
   ... but because we have three techs making gradients, and we're
   not going to have interop between all of them I'm feeling less
   strongly that we need to align with CSS rather than canvas
   ... right now we have lots of implementations

   nikos: I was also wondering if it's a platform dependent result
   rather than just a browser result
   ... curious what Cairo does for example

   <AmeliaBR> [23]http://codepen.io/AmeliaBR/pen/jrBOBv/

     [23] http://codepen.io/AmeliaBR/pen/jrBOBv/

   nikos: would be good to try FF on linux and WebKit GTK

   Tav: FF on linux, the top one matches the bottom one and the
   middle two match

   AmeliaBR: so that's the same as what we get everywhere except
   for with WebKit

   nikos: Let's leave as an open issue. We need more time to
   investigate. At least with multiple different implementations,
   we can align with the one we think is most correct

   AmeliaBR: I'd like to get feedback from CSS as to how close
   they are to resolving this issue

Unknown elements behaving as g


     [24] https://github.com/w3c/svgwg/issues/179

   AmeliaBR: We say unknown elements behave as the g element
   ... but g isn't allowed everywhere
   ... my suggestion is to make it an a without an href - that can
   go in more places

   Tav: I don't think an a is a good model

   <AmeliaBR> <text>Some <i>fancy</i> text</text>

   nikos: I think the point is that where it makes some sense to
   render, then we can render via g. If it doesn't make sense for
   g then it probably makes sense to actually ignore

   AmeliaBR: use case is with text
   ... so treat unknown as tspan inside text

   RESOLUTION: Treat unknown elements as tspan when inside text.
   Presentation and inherited style apply, but nothing specific.

Summary of Action Items

   [NEW] ACTION: Amelia to make changes wrt nested a elements
   [recorded in

     [25] http://www.w3.org/2016/06/30-svg-minutes.html#action01

Summary of Resolutions

    1. [26]SVG WG agrees to publish FPWD of SVG Graphics API
       Mappings, and updated WD for WAI-ARIA Graphics Module and
       SVG Accessibility API Mappings
    2. [27]Nested a elements will render but href attribute will
       be ignored. But if unknown elements (at risk) are changed
       to not render, a elements will also then not render.
    3. [28]Treat unknown elements as tspan when inside text.
       Presentation and inherited style apply, but nothing

   [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.