- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Fri, 1 Jul 2016 03:32:32 +0000
- To: www-svg <www-svg@w3.org>
https://www.w3.org/2016/06/21-svg-minutes.html
[1]W3C
[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
Attendees
Present
nikos, AmeliaBR, Tav, stakagi
Regrets
Chair
nikos
Scribe
nikos
Contents
* [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
sub-properties
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
[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
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>
[15]https://github.com/w3c/svgwg/issues/102#issuecomment-225045
785
[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
right
nikos: Ok so accept the PR and then you can add that directly
into the spec
Nesting
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
[17]https://github.com/w3c/svgwg/issues/142
[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
<Tav>
[18]http://wiki.inkscape.org/wiki/index.php/GTK%2B_3_migration
[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
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>
[20]https://www.w3.org/TR/SVG11/struct.html#UseElement
[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
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>
[21]https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint
[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/2622cb24269fbd02178954e
f243f63f693b2d89d
[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
[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
<AmeliaBR>
[25]http://jsbin.com/bijujizore/edit?html,console,output
[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
[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
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
[27]https://github.com/w3c/svgwg/issues/169
[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
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
[28]https://github.com/w3c/svgwg/issues/154
[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
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. [29]Accept Amelia's PR with normative changes for title and
desc
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.
Received on Friday, 1 July 2016 03:33:08 UTC