07:52:23 <RRSAgent> RRSAgent has joined #svg
07:52:23 <RRSAgent> logging to http://www.w3.org/2016/06/21-svg-irc
07:52:25 <trackbot> RRSAgent, make logs public
07:52:27 <trackbot> Zakim, this will be GA_SVGWG
07:52:27 <Zakim> ok, trackbot
07:52:28 <trackbot> Meeting: SVG Working Group Teleconference
07:52:28 <trackbot> Date: 21 June 2016
07:53:23 <AmeliaBR> AmeliaBR has joined #svg
07:53:56 <nikos> scribe: nikos
07:54:02 <nikos> scribenick: nikos
07:54:11 <nikos> Meeting: Amsterdam editors meeting 2016 Day 2
07:54:22 <nikos> present+ nikos
07:54:25 <nikos> present+ AmeliaBR
07:54:30 <nikos> present+ Tav
07:54:35 <nikos> chair: nikos
07:54:41 <nikos> rrsagent, make minutes
07:54:41 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/21-svg-minutes.html nikos
07:56:59 <nikos> Topic: Title and desc re-write
07:57:01 <nikos> https://github.com/w3c/svgwg/pull/170
07:57:22 <nikos> AmeliaBR: There's a list of the changes in the PR
07:57:45 <nikos> nikos: Could you summarise the normative changes?
07:58:07 <nikos> AmeliaBR: we had a 'should' about ua respecting svg mapping expose the text
07:58:15 <nikos> ... I changed that to a must and clarified the wording
07:58:30 <nikos> ... I added a new warning about do not add title or desc with empty or whitespace only
07:58:39 <nikos> ... made that authors should not and authoring tools must not
07:58:58 <nikos> ... I'm mostly worried about tools that ask for a title and accept an empty string
07:59:09 <nikos> ... that would be a mess on the accessibility side because we treat it as important
07:59:14 <nikos> ... and screenreaders will announce the object
07:59:25 <nikos> ... if every shape is announced as a shape it'll drive people nuts
07:59:41 <nikos> Tav:
07:59:48 <nikos> Tav: would think that screenreaders would deal with that
07:59:54 <nikos> AmeliaBR: we're trying to tackle it on both ends
08:00:04 <nikos> Tav: I'm not against putting it there, just curious
08:00:49 <nikos> AmeliaBR: I've also made tooltips or some other way of exposing title a user agent 'should'
08:01:04 <nikos> ... I don't require tooltips but say titles should be available based on some sort of interaction
08:01:16 <nikos> ... bit of an issue for tablets that dont have an easy hover
08:01:59 <nikos> ... The rest of it is just rearranging and clarifying
08:02:18 <nikos> ... This addresses most of the issues.
08:02:29 <nikos> ... The remaining issue is content model and which should allow title and desc
08:02:52 <nikos> Tav: should be pretty much everything
08:02:53 <AmeliaBR> https://github.com/w3c/svgwg/issues/102#issuecomment-225045785
08:02:53 <nikos> AmeliaBR: yes
08:03:03 <nikos> nikos: We already resolved on this
08:03:16 <nikos> AmeliaBR: I've got a comment in there that title and desc shouldn't have other title and desc
08:03:33 <nikos> ... which is logical, but since we're ignoring markup and treating as plain text it might not actually break anything
08:04:23 <nikos> 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
08:04:50 <nikos> 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
08:05:04 <nikos> ... I haven't gone through the rest of the spec
08:06:21 <nikos> RESOLUTION: Accept Amelia's PR with normative changes for title and desc
08:11:36 <stakagi> present+ stakagi
08:14:46 <nikos> Topic: Tav's Note on pattern overflow
08:14:56 <AmeliaBR> https://github.com/w3c/svgwg/pull/164/files
08:14:56 <stakagi> Good afternoon!
08:15:49 <Tav> Konichiwa!
08:16:42 <nikos> Tav: I changed the comment about overflow on pattern to be a note saying that UAs are encouraged to render the overflow
08:16:59 <nikos> nikos: So at the moment implementations all clip, so you're asking them to change behaviour
08:17:08 <nikos> Tav: We'll change our behaviour for sure
08:18:01 <nikos> nikos: Do you really want to turn it on while browsers don't show the overflow? That will just cause annoyance users.
08:18:13 <nikos> Tav: We'll manually do the repeats. It's something authors really want
08:20:19 <nikos> AmeliaBR: I think it's ok to merge
08:21:01 <nikos> nikos: I'm a bit uncomfortable saying this is undefined but you should do this
08:21:07 <nikos> ... but I'm not going to make a big fuss about it
08:21:29 <nikos> AmeliaBR: The z-index aspect is still undefined
08:21:44 <nikos> Tav: I could add a description saying to to bottom, left to right
08:22:14 <nikos> nikos: Ok so accept the PR and then you can add that directly into the spec
08:22:24 <AmeliaBR> s/to to/top to/
08:25:11 <nikos> Topic: Nesting
08:25:21 <nikos> Tav: not in SVG 2, but long term I'd like to have circle inside a rectangle
08:25:32 <nikos> ... and percentages in the circle relate to the bounding box of the rectangle
08:25:40 <nikos> AmeliaBR: it's something that confuses people coming from html to svg
08:25:54 <nikos> ... you can do it now by defining a nested svg
08:26:00 <nikos> nikos: That's pretty clunky though
08:26:15 <nikos> Tav: I just want to make sure we're not doing anything with our content model that precludes us from doing this in future
08:26:24 <nikos> AmeliaBR: we already say shapes won't render in that case
08:26:42 <nikos> ... but we're not saying you can't put those elements there
08:27:06 <nikos> ... we allow non rendering things like clip path as a child currently
08:27:21 <nikos> Tav: what are the percentages for those relative to?
08:27:29 <nikos> AmeliaBR: depends on what the bounding box is chosen as
08:27:41 <nikos> ... it doesn't cause any problems
08:27:44 <nikos> Tav: ok good
08:30:28 <stakagi> Amelia: I posted the improvement proposal on switch element. I would like you to review when you have time.
08:31:16 <nikos> Topic: Width and height on use element
08:31:17 <nikos> https://github.com/w3c/svgwg/issues/142
08:32:06 <nikos> 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.
08:32:34 <nikos> AmeliaBR: 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
08:34:30 <Tav> http://wiki.inkscape.org/wiki/index.php/GTK%2B_3_migration
08:38:22 <nikos> nikos: I think your suggestion of allowing x,y, width, and height on symbol makes sense
08:38:47 <nikos> AmeliaBR: would result in no rendered difference between symbol and svg. The IDL is of course different
08:38:57 <nikos> nikos: symbol can't have scrollbars while svg can
08:40:14 <Tav> http://tavmjong.free.fr/SVG/VIEWPORT/viewport.svg
08:40:40 <nikos> AmeliaBR: looks 'correct' in Edge
08:41:53 <nikos> ... so correct is in terms of SVG 1.1 - ignoring the width and height
08:41:58 <nikos> ... that's not the behaviour we're proposing
08:51:53 <nikos> AmeliaBR: Even separate from symbols, if you have a symbol rectangle in percentage units
08:51:57 <nikos> ... then you reuse it in a different svg
08:52:15 <nikos> ... UAs convert percentages to absolute units in the source coordinate system and not in the used coordinate system
08:52:22 <nikos> ... that doesn't match with the shadow dom model
08:52:30 <nikos> ... assuming that width and height are regular css properties
08:54:16 <AmeliaBR> s/symbol rectangle/simple rectangle/
08:54:36 <nikos> Tav: the main reason we want to break it right now is because we have width and height as presentation attributes
08:54:53 <nikos> AmeliaBR: there's two things - turning geometric attributes to properties, so we want them to behave the same on every element
08:55:08 <nikos> ... and define everything in terms of shadow dom so we can get consistent implementations
08:55:50 <nikos> AmeliaBR: I don't see anywhere in SVG 1.1 where it explicitly says percentages are resolved against the original coordinate system
08:56:14 <nikos> nikos: doesn't it say percentages are resolved against the parent viewport?
08:56:44 <nikos> AmeliaBR: There's a lot of examples that show the visual effect is different from browser behaviour
08:56:54 <AmeliaBR> https://www.w3.org/TR/SVG11/struct.html#UseElement
08:57:10 <nikos> AmeliaBR: none of the examples explicitly use percentages
08:57:57 <nikos> AmeliaBR: 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
08:58:55 <nikos> ... 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
08:59:31 <stakagi> shanaijinnzaino
09:00:14 <nikos> Tav: for width and height, we have InkScape, old Opera, and Edge doing it the way SVG 1.1 said it should be done
09:00:26 <nikos> ... that is ignoring the width and height on the symbol
09:00:35 <nikos> ... We have Firefox and Batik using the width
09:00:55 <nikos> ... And then Chrome ignores width and height on the symbol, but not x and y on the symbol
09:01:36 <nikos> nikos: Webkit is the same as Chrome
09:02:10 <nikos> nikos: My proposal is that width and height are valid on symbol. Since that makes sense now they're properties.
09:02:21 <nikos> AmeliaBR: I'm leaning toward having them behave the same everywhere
09:02:48 <nikos> ... It wouldn't change any content created with InkScape since you're not putting those attributes on symbols
09:03:04 <nikos> ... it would just change how you handle documents that are opened and parsed
09:04:30 <nikos> nikos: We're spending too long on this, let's talk about it over lunch
09:04:51 <nikos> Tav: I'd like some time to think about it some more, and I think we should talk to the wider group some more
09:05:02 <AmeliaBR> AmeliaBR has joined #svg
09:05:08 <nikos> AmeliaBR: I can work on something this afternoon that we can send out and get others to comment on
09:05:24 <nikos> nikos: Can you do it as a PR?
09:05:27 <nikos> AmeliaBR: yes
09:07:06 <nikos> Topic: Break the new fill/stroke syntax into sub-properties
09:07:18 <AmeliaBR> https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint
09:08:28 <nikos> AmeliaBR: Oh it's changed, we're not doing CSS images as a valid paint?
09:08:55 <nikos> ... 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
09:08:57 <nikos> ... but I'm ok with this
09:09:13 <nikos> ... As long as we agree we'll do that eventually
09:09:51 <nikos> https://github.com/w3c/svgwg/commit/2622cb24269fbd02178954ef243f63f693b2d89d
09:19:28 <chaals> chaals has joined #svg
09:30:33 <nikos> Topic:  <script> and <style> content model
09:30:38 <AmeliaBR> https://github.com/w3c/svgwg/issues/163
09:30:39 <nikos> https://github.com/w3c/svgwg/issues/163
09:31:11 <nikos> nikos: Basically I want to spec what's implemented in browsers
09:31:23 <nikos> AmeliaBR: that means treating child elements as valid
09:31:58 <nikos> ... it has an effect on the new react syntax where you put chunks of markup in your script
09:32:35 <nikos> ... even if you have a quotation mark and then an element, it will treat the element as a definition
09:32:42 <nikos> ... the way you got around that in xml was to use CDATA tags
09:32:47 <nikos> ... not sure about the html parser
09:34:53 <AmeliaBR> http://jsbin.com/bijujizore/edit?html,console,output
09:34:59 <nikos> AmeliaBR: HTML parser respects CDATA blocks in svg
09:35:42 <nikos> ... Chrome, FF, and Edge are all consistent
09:36:30 <AmeliaBR> Version without JS syntax errors: http://jsbin.com/gihorozifa/1/edit?html,console,output
09:36:45 <nikos> nikos: Safari the same
09:37:11 <nikos> ... such weird behaviour
09:37:26 <nikos> ... but it's interoperable...
09:41:28 <nikos> AmeliaBR: So HTML scripts are definitely defined as character data
09:41:36 <nikos> ... browsers are treating svg scripts differently than html scripts
09:41:56 <nikos> nikos: In that case I'm more inclined to match HTMLs behaviour
09:42:41 <nikos> RRSAgent, make minutes
09:42:41 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/21-svg-minutes.html nikos
09:43:40 <nikos> AmeliaBR: I'm going to tweet about it and see what response I get back
09:46:13 <nikos> RESOLUTION: Change style and script elements content model to match HTML dependent on getting no negative feedback
09:48:42 <nikos> Topic:  Either make mesh a SVGGraphicsElement or make it not render to screen
09:48:50 <nikos> https://github.com/w3c/svgwg/issues/169
09:49:01 <nikos> Tav: Is there any problem making it a graphics element?
09:49:07 <nikos> AmeliaBR: it's a matter of it being both
09:49:16 <nikos> ... a paint server and a graphics element
09:49:38 <nikos> ... you would end up with dual inheritance
09:49:55 <nikos> ... and would be a problem one day doing the shapes inside shapes thing that we spoke about earlier
09:50:20 <nikos> nikos: I feel like we should have two different elements here
09:51:05 <nikos> ... was thinking you have one that's a paint server and one that's a graphics element
09:51:14 <nikos> ... and each one exactly matches the definition for those things that we already have
09:51:39 <nikos> AmeliaBR: another option is having another parent element that can inherit the outer path data of the mesh
09:51:46 <nikos> Tav: I like the sound of the first option
09:52:18 <nikos> ... In InkScape I was going t o implement via dummy rectangle
09:52:30 <nikos> AmeliaBR: that wouldn't work with hit testing, which isn't an issue for inkscape but it is for browsers
09:54:39 <nikos> ... 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
09:54:48 <nikos> ... and you extract the path from that other element
09:55:05 <nikos> ... and we define the path that you return is the outer bounds of all the mesh patches
09:55:24 <nikos> ... if we're going to do that we can only define it for now as a special case for meshes
09:55:34 <nikos> ... then we can define getPathData on all paths and shapes
09:56:39 <nikos> ... we already have a request for getPathData on basic shapes
09:56:55 <nikos> nikos: I think the problem there is converting from the internal representation to some normalised representation
09:57:00 <nikos> ... that's why it got deferred
09:57:39 <nikos> AmeliaBR: The other option is to just make mesh a paint server and talk about the rest later
09:58:02 <nikos> nikos: I really don't want to make mesh only a paint server
09:58:18 <nikos> Tav: could you just use prose to describe that mesh takes whichever IDL based on it's context?
09:59:07 <nikos> Tav: we have three possibilities
09:59:13 <nikos> ... one leave everything as is
09:59:21 <nikos> nikos: that's not an option we need to tidy this up
09:59:34 <nikos> Tav: so we can wrap it, or make a new element, or just leave it as a paint server
10:00:13 <nikos> 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
10:00:36 <nikos> AmeliaBR: so it would have an href and everything basic shapes have
10:00:52 <nikos> nikos: Or it could have the same content model as mesh - so meshRow, etc
10:01:11 <nikos> Tav: which chapter?
10:01:15 <nikos> nikos: would go in basic shapes
10:02:49 <AmeliaBR> AmeliaBR has joined #svg
10:03:36 <nikos> 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
10:03:47 <nikos> ... so what will we call the new element?
10:05:21 <nikos> 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.
10:05:43 <nikos> ... so let's call the shape element mesh and the paint server meshGradient and we can bikeshed later if we really have to
10:06:12 <nikos> RESOLUTION: mesh gradients will be broken into a shape element and a paint server element
10:06:20 <nikos> RRSAgent, make minutes
10:06:20 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/21-svg-minutes.html nikos
10:07:29 <nikos> AmeliaBR: The new mesh will be a graphics element but not a geometry element
11:23:15 <AmeliaBR> AmeliaBR has joined #svg
11:25:47 <nikos> Topic: Rounded rectangles on equivalent path for rect
11:25:50 <nikos> https://github.com/w3c/svgwg/issues/154
11:26:38 <nikos> nikos: Definitely don't want two markers on each corner for a rect that doesn't have rounded rectangles
11:27:33 <nikos> 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
11:27:46 <nikos> nikos: but that would have to be special cased because it would be a breaking change for paths
11:28:03 <nikos> Tav: so we say if rx is zero then you don't have an arc
11:28:21 <nikos> AmeliaBR: what do we do if one of the radius directions is zero but the other is non zero?
11:28:38 <nikos> ... in that case the effect is a sharp corner
11:30:58 <nikos> AmeliaBR: so do we define that if either of rx or ry are zero then no arc?
11:31:04 <nikos> Tav: yes
11:32:32 <nikos> RESOLUTION: the equivalent path for a rect with rx=0 or ry=0 will be a pure rectangle
11:33:19 <nikos> RRSAgent, make minutes
11:33:19 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/21-svg-minutes.html nikos
12:37:20 <chaals> chaals has joined #svg