Minutes, June 2016 Amsterdam editors meeting, Day 2

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

Minutes, June 2016 Amsterdam editors meeting, Day 2

Nikos Andronikos


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

                               - DRAFT -

                    SVG Working Group Teleconference

21 Jun 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/06/21-svg-irc


          nikos, AmeliaBR, Tav, stakagi




     * [3]Topics
         1. [4]Title and desc re-write
         2. [5]Tav's Note on pattern overflow
         3. [6]Nesting
         4. [7]Width and height on use element
         5. [8]Break the new fill/stroke syntax into
         6. [9]<script> and <style> content model
         7. [10]Either make mesh a SVGGraphicsElement or make it
            not render to screen
         8. [11]Rounded rectangles on equivalent path for rect
     * [12]Summary of Action Items
     * [13]Summary of Resolutions

   <scribe> scribe: nikos

   <scribe> scribenick: nikos

   <scribe> Meeting: Amsterdam editors meeting 2016 Day 2

Title and desc re-write


     [14] https://github.com/w3c/svgwg/pull/170

   AmeliaBR: There's a list of the changes in the PR

   nikos: Could you summarise the normative changes?

   AmeliaBR: we had a 'should' about ua respecting svg mapping
   expose the text
   ... I changed that to a must and clarified the wording
   ... I added a new warning about do not add title or desc with
   empty or whitespace only
   ... made that authors should not and authoring tools must not
   ... I'm mostly worried about tools that ask for a title and
   accept an empty string
   ... that would be a mess on the accessibility side because we
   treat it as important
   ... and screenreaders will announce the object
   ... if every shape is announced as a shape it'll drive people

   Tav: ... would think that screenreaders would deal with that

   AmeliaBR: we're trying to tackle it on both ends

   Tav: I'm not against putting it there, just curious

   AmeliaBR: I've also made tooltips or some other way of exposing
   title a user agent 'should'
   ... I don't require tooltips but say titles should be available
   based on some sort of interaction
   ... bit of an issue for tablets that dont have an easy hover
   ... The rest of it is just rearranging and clarifying
   ... This addresses most of the issues.
   ... The remaining issue is content model and which should allow
   title and desc

   Tav: should be pretty much everything


     [15] https://github.com/w3c/svgwg/issues/102#issuecomment-225045785

   AmeliaBR: yes

   nikos: We already resolved on this

   AmeliaBR: I've got a comment in there that title and desc
   shouldn't have other title and desc
   ... which is logical, but since we're ignoring markup and
   treating as plain text it might not actually break anything

   nikos: It's probably a good idea anyway to not allow title and
   desc as child. If for some odd reason we change the content
   model tohandle markup differently

   AmeliaBR: I have prose saying you can have title and desc on
   non rendering elements and noting they're not going to be
   available to accessibility tools
   ... I haven't gone through the rest of the spec

   RESOLUTION: Accept Amelia's PR with normative changes for title
   and desc

Tav's Note on pattern overflow

   <AmeliaBR> [16]https://github.com/w3c/svgwg/pull/164/files

     [16] https://github.com/w3c/svgwg/pull/164/files

   <stakagi> Good afternoon!

   <Tav> Konichiwa!

   Tav: I changed the comment about overflow on pattern to be a
   note saying that UAs are encouraged to render the overflow

   nikos: So at the moment implementations all clip, so you're
   asking them to change behaviour

   Tav: We'll change our behaviour for sure

   nikos: Do you really want to turn it on while browsers don't
   show the overflow? That will just cause annoyance users.

   Tav: We'll manually do the repeats. It's something authors
   really want

   AmeliaBR: I think it's ok to merge

   nikos: I'm a bit uncomfortable saying this is undefined but you
   should do this
   ... but I'm not going to make a big fuss about it

   AmeliaBR: The z-index aspect is still undefined

   Tav: I could add a description saying top to bottom, left to

   nikos: Ok so accept the PR and then you can add that directly
   into the spec


   Tav: not in SVG 2, but long term I'd like to have circle inside
   a rectangle
   ... and percentages in the circle relate to the bounding box of
   the rectangle

   AmeliaBR: it's something that confuses people coming from html
   to svg
   ... you can do it now by defining a nested svg

   nikos: That's pretty clunky though

   Tav: I just want to make sure we're not doing anything with our
   content model that precludes us from doing this in future

   AmeliaBR: we already say shapes won't render in that case
   ... but we're not saying you can't put those elements there
   ... we allow non rendering things like clip path as a child

   Tav: what are the percentages for those relative to?

   AmeliaBR: depends on what the bounding box is chosen as
   ... it doesn't cause any problems

   Tav: ok good

   <stakagi> Amelia: I posted the improvement proposal on switch
   element. I would like you to review when you have time.

Width and height on use element


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

   AmeliaBR: Previously only certain elements allowed width and
   height. There was a statement saying all attributes on the
   original element get reproduced on the use element. Some
   browsers were copying over attributes that weren't valid on the
   original element, some weren't.
   ... All of this is complicated by the fact that width and
   height are presentation attributes and so should be able to be
   specified pretty much anywhere


     [18] http://wiki.inkscape.org/wiki/index.php/GTK+_3_migration

   nikos: I think your suggestion of allowing x,y, width, and
   height on symbol makes sense

   AmeliaBR: would result in no rendered difference between symbol
   and svg. The IDL is of course different

   nikos: symbol can't have scrollbars while svg can

   <Tav> [19]http://tavmjong.free.fr/SVG/VIEWPORT/viewport.svg

     [19] http://tavmjong.free.fr/SVG/VIEWPORT/viewport.svg

   AmeliaBR: looks 'correct' in Edge
   ... so correct is in terms of SVG 1.1 - ignoring the width and
   ... that's not the behaviour we're proposing
   ... Even separate from symbols, if you have a simple rectangle
   in percentage units
   ... then you reuse it in a different svg
   ... UAs convert percentages to absolute units in the source
   coordinate system and not in the used coordinate system
   ... that doesn't match with the shadow dom model
   ... assuming that width and height are regular css properties

   Tav: the main reason we want to break it right now is because
   we have width and height as presentation attributes

   AmeliaBR: there's two things - turning geometric attributes to
   properties, so we want them to behave the same on every element
   ... and define everything in terms of shadow dom so we can get
   consistent implementations
   ... I don't see anywhere in SVG 1.1 where it explicitly says
   percentages are resolved against the original coordinate system

   nikos: doesn't it say percentages are resolved against the
   parent viewport?

   AmeliaBR: There's a lot of examples that show the visual effect
   is different from browser behaviour


     [20] https://www.w3.org/TR/SVG11/struct.html#UseElement

   AmeliaBR: none of the examples explicitly use percentages
   ... I can't use the same argument for the issue with x and y
   because SVG 1.1 is very clear about x and y being treated as a
   ... Firefox changed x and y behaviour from what is logical to
   what is in the spec a couple of years ago and there were lots
   of questions on stackoverflow about why clip paths were broken

   <stakagi> shanaijinnzaino

   Tav: for width and height, we have InkScape, old Opera, and
   Edge doing it the way SVG 1.1 said it should be done
   ... that is ignoring the width and height on the symbol
   ... We have Firefox and Batik using the width
   ... And then Chrome ignores width and height on the symbol, but
   not x and y on the symbol

   nikos: Webkit is the same as Chrome
   ... My proposal is that width and height are valid on symbol.
   Since that makes sense now they're properties.

   AmeliaBR: I'm leaning toward having them behave the same
   ... It wouldn't change any content created with InkScape since
   you're not putting those attributes on symbols
   ... it would just change how you handle documents that are
   opened and parsed

   nikos: We're spending too long on this, let's talk about it
   over lunch

   Tav: I'd like some time to think about it some more, and I
   think we should talk to the wider group some more

   AmeliaBR: I can work on something this afternoon that we can
   send out and get others to comment on

   nikos: Can you do it as a PR?

   AmeliaBR: yes

Break the new fill/stroke syntax into sub-properties


     [21] https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint

   AmeliaBR: Oh it's changed, we're not doing CSS images as a
   valid paint?
   ... I don't remember when that was resolved. It's annoying
   because a lot of people were looking forward to referencing an
   image or a css gradient
   ... but I'm ok with this
   ... As long as we agree we'll do that eventually


     [22] https://github.com/w3c/svgwg/commit/2622cb24269fbd02178954ef243f63f693b2d89d

<script> and <style> content model

   <AmeliaBR> [23]https://github.com/w3c/svgwg/issues/163

     [23] https://github.com/w3c/svgwg/issues/163


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

   nikos: Basically I want to spec what's implemented in browsers

   AmeliaBR: that means treating child elements as valid
   ... it has an effect on the new react syntax where you put
   chunks of markup in your script
   ... even if you have a quotation mark and then an element, it
   will treat the element as a definition
   ... the way you got around that in xml was to use CDATA tags
   ... not sure about the html parser


     [25] http://jsbin.com/bijujizore/edit?html,console,output

   AmeliaBR: HTML parser respects CDATA blocks in svg
   ... Chrome, FF, and Edge are all consistent

   <AmeliaBR> Version without JS syntax errors:

     [26] http://jsbin.com/gihorozifa/1/edit?html,console,output

   nikos: Safari the same
   ... such weird behaviour
   ... but it's interoperable...

   AmeliaBR: So HTML scripts are definitely defined as character
   ... browsers are treating svg scripts differently than html

   nikos: In that case I'm more inclined to match HTMLs behaviour

   AmeliaBR: I'm going to tweet about it and see what response I
   get back

   RESOLUTION: Change style and script elements content model to
   match HTML dependent on getting no negative feedback

Either make mesh a SVGGraphicsElement or make it not render to screen


     [27] https://github.com/w3c/svgwg/issues/169

   Tav: Is there any problem making it a graphics element?

   AmeliaBR: it's a matter of it being both
   ... a paint server and a graphics element
   ... you would end up with dual inheritance
   ... and would be a problem one day doing the shapes inside
   shapes thing that we spoke about earlier

   nikos: I feel like we should have two different elements here
   ... was thinking you have one that's a paint server and one
   that's a graphics element
   ... and each one exactly matches the definition for those
   things that we already have

   AmeliaBR: another option is having another parent element that
   can inherit the outer path data of the mesh

   Tav: I like the sound of the first option
   ... In InkScape I was going t o implement via dummy rectangle

   AmeliaBR: that wouldn't work with hit testing, which isn't an
   issue for inkscape but it is for browsers
   ... my proposal would be that you can create a path element
   whose d attribute is a reference to a mesh, either a child mesh
   or a url mesh
   ... and you extract the path from that other element
   ... and we define the path that you return is the outer bounds
   of all the mesh patches
   ... if we're going to do that we can only define it for now as
   a special case for meshes
   ... then we can define getPathData on all paths and shapes
   ... we already have a request for getPathData on basic shapes

   nikos: I think the problem there is converting from the
   internal representation to some normalised representation
   ... that's why it got deferred

   AmeliaBR: The other option is to just make mesh a paint server
   and talk about the rest later

   nikos: I really don't want to make mesh only a paint server

   Tav: could you just use prose to describe that mesh takes
   whichever IDL based on it's context?
   ... we have three possibilities
   ... one leave everything as is

   nikos: that's not an option we need to tidy this up

   Tav: so we can wrap it, or make a new element, or just leave it
   as a paint server

   nikos: my pref is to make a new element, because we can spec
   that quickly and it just has to be consistent with other basic

   AmeliaBR: so it would have an href and everything basic shapes

   nikos: Or it could have the same content model as mesh - so
   meshRow, etc

   Tav: which chapter?

   nikos: would go in basic shapes

   AmeliaBR: I don't think we have any DOM properties on paint
   server elements at this point, but for future compatibility I'd
   like to keep the content distinct
   ... so what will we call the new element?

   nikos: it makes sense to call the paint server meshGradient.
   And it should be camel cased because it's consistent with
   existing gradient elements, which are the rules we set.
   ... so let's call the shape element mesh and the paint server
   meshGradient and we can bikeshed later if we really have to

   RESOLUTION: mesh gradients will be broken into a shape element
   and a paint server element

   AmeliaBR: The new mesh will be a graphics element but not a
   geometry element

Rounded rectangles on equivalent path for rect


     [28] https://github.com/w3c/svgwg/issues/154

   nikos: Definitely don't want two markers on each corner for a
   rect that doesn't have rounded rectangles

   Tav: have special casing for zero length paths in terms of
   calculating direction, could we special case and say zero
   length segments don't have a marker

   nikos: but that would have to be special cased because it would
   be a breaking change for paths

   Tav: so we say if rx is zero then you don't have an arc

   AmeliaBR: what do we do if one of the radius directions is zero
   but the other is non zero?
   ... in that case the effect is a sharp corner
   ... so do we define that if either of rx or ry are zero then no

   Tav: yes

   RESOLUTION: the equivalent path for a rect with rx=0 or ry=0
   will be a pure rectangle

Summary of Action Items

Summary of Resolutions

    1. [29]Accept Amelia's PR with normative changes for title and
    2. [30]Change style and script elements content model to match
       HTML dependent on getting no negative feedback
    3. [31]mesh gradients will be broken into a shape element and
       a paint server element
    4. [32]the equivalent path for a rect with rx=0 or ry=0 will
       be a pure rectangle

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