See also: IRC log
<scribe> scribe: nikos
<scribe> scribenick: nikos
<scribe> Meeting: Amsterdam editors meeting 2016 Day 2
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
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
<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.
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
<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
<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
https://github.com/w3c/svgwg/commit/2622cb24269fbd02178954ef243f63f693b2d89d
<AmeliaBR> https://github.com/w3c/svgwg/issues/163
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
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 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
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
arc?
Tav: yes
RESOLUTION: the equivalent path for a rect with rx=0 or ry=0 will be a pure rectangle
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]