SVG Working Group Teleconference

21 Jun 2016

See also: IRC log


nikos, AmeliaBR, Tav, stakagi


<scribe> scribe: nikos

<scribe> scribenick: nikos

<scribe> Meeting: Amsterdam editors meeting 2016 Day 2

Title and desc re-write


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 nuts

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

<AmeliaBR> 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> 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 right

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 currently

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


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

<Tav> http://wiki.inkscape.org/wiki/index.php/GTK%2B_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> 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 height
... 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

<AmeliaBR> 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 transform
... 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 everywhere
... 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

<AmeliaBR> 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


<script> and <style> content model

<AmeliaBR> 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

<AmeliaBR> 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: 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 data
... browsers are treating svg scripts differently than html scripts

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


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 shapes

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

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


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 arc?

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. Accept Amelia's PR with normative changes for title and desc
  2. Change style and script elements content model to match HTML dependent on getting no negative feedback
  3. mesh gradients will be broken into a shape element and a paint server element
  4. the equivalent path for a rect with rx=0 or ry=0 will be a pure rectangle
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/06/21 11:33:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Succeeded: s/to to/top to/
Succeeded: s/symbol rectangle/simple rectangle/
Found Scribe: nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: nikos AmeliaBR Tav stakagi
Found Date: 21 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/21-svg-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]