08:24:45 <RRSAgent> RRSAgent has joined #svg
08:24:45 <RRSAgent> logging to http://www.w3.org/2015/08/24-svg-irc
08:24:47 <trackbot> RRSAgent, make logs public
08:24:49 <trackbot> Zakim, this will be GA_SVGWG
08:24:50 <trackbot> Meeting: SVG Working Group Teleconference
08:24:50 <trackbot> Date: 24 August 2015
08:24:59 <heycam> Chair: Cameron
08:28:39 <birtles> Scribenick: birtles
08:28:43 <birtles> Scribe: birtles
08:28:48 <birtles> Topic: Chapter status update
08:29:16 <birtles> heycam: The main things I've been working on are the DOM interfaces and making sure that how attributes are reflected into the DOM properties is clear
08:29:27 <birtles> ...  there was a lot of undefined behavior in terms of the list interfaces
08:29:35 <birtles> ... e.g. if you take a reference to an object in the list and change it
08:29:42 <birtles> ... is it live? does it become disconnected? etc.
08:29:53 <birtles> ... most of that stuff should now be in the spec, especially the types chapter
08:30:02 <birtles> ... there are now only 2 issues remaining in the types chapter
08:30:08 <birtles> ... one of them needs Dirk's input
08:30:24 <birtles> ... the other one we may have already decided
08:30:30 <birtles> ... so the types chapter is pretty much done
08:30:41 <birtles> ... I haven't done anything on the styles chapter
08:30:51 <birtles> ... it's in the worst shape of the chapters I'm looking after
08:31:02 <birtles> ... I'm planning to rewrite that starting this week
08:31:09 <birtles> ... the presentation attributes list is one of the issues
08:31:22 <birtles> ... I'm going to put a list in there and then check everyone is on the same age
08:31:25 <birtles> s/age/page/
08:31:51 <birtles> ... the other part is properties other specifications and wording for how to support properties in other specs without having to update SVG every time
08:32:00 <birtles> ... they are the two things that really need discussion
08:32:06 <birtles> ... the rest of the work is just making that a useful chapter
08:32:14 <birtles> ... and talking about how CSS support is required etc.
08:32:19 <birtles> ... I'll work on that this week
08:32:34 <birtles> ... the third chapter which is mine is the painting issue
08:32:44 <birtles> ... there are only a few remaining issues left but I haven't made much progress on them yet
08:32:52 <birtles> ... however, I believe most of the decisions have been made
08:32:58 <birtles> ... the types chapter is now at a readiness of 4
08:33:12 <birtles> ... the other two chapters can remain at their existing levels
08:33:20 <birtles> ... styling: 2, painting: 4
08:33:40 <birtles> ... there's still a bit more work to do on the DOM interfaces but I'll finish that today
08:34:01 <birtles> ... I haven't yet enacted the change to make animVal the same as baseVal
08:34:10 <birtles> ... I thought I'd get the spec in good shape first before making that change
08:34:37 <birtles> ed: I was looking at the document structure chapter and I just posted an update to the wiki page with the updated chapter assessment
08:34:47 <birtles> ... I added a couple of missing issues and closed a few
08:34:59 <birtles> ... recently I was looking at unknown elements and I think that's mostly done
08:35:07 <birtles> ... it might need some more thought but I think it's mostly done
08:35:21 <birtles> ... there might be some things missing in terms of the describing the unknown element as anything
08:35:26 <birtles> ... it's almost there, however
08:35:32 <birtles> ... apart from that, most of the open issues are editorial
08:35:39 <birtles> ... there are a couple of issues that need some discussion
08:35:55 <birtles> ... the trickiest at probably xml:base and the <base> element
08:36:18 <birtles> s/trickiest at/trickiest are/
08:36:36 <birtles> cyril: I have an open issue to remove the xml namespace and I'm not quite sure what to do with that
08:37:08 <birtles> heycam: it's similar to what we have for xlink stuff where we now have some wording for how to prioritize different variations there
08:37:35 <birtles> ... I updated the spec so we have some clear behavior for that so we should probably do something similar for xml:
08:37:53 <birtles> ... were there any issues in the DOM section of that chapter? I might have fixed them when I was rewriting the DOM stuff
08:38:05 <birtles> ed: yes, there were a few... 60 & 61
08:38:11 <birtles> ... but those are related to xml:base
08:39:35 <birtles> cyril: just checking the xlink prose, is it backwards compatible?
08:40:05 <birtles> ... it doesn't seem to be in terms of new content being useable in an old reader
08:41:23 <birtles> heycam: it's only going to be a problem if you put different values on href and xlink:href
08:43:01 <birtles> ... also, in the definitions.xml file we need to make the href the real attribute and xlink:href not a real thing so that href gets linked (not xlink:href)
08:43:10 <birtles> ed: for the viewport property on SVGSVGElement
08:43:18 <birtles> ... there are some issues about that
08:43:27 <birtles> heycam: I've never been clear what it's supposed to return
08:43:46 <birtles> ed: so I think document structure is still level 3
08:44:00 <birtles> ... paint servers - I haven't looked at that one
08:44:18 <birtles> Tav: I still have to do editing of meshes
08:44:29 <birtles> ... with regards to transforms and things
08:44:40 <birtles> ed: interactivity - I don't think there's been any progress there
08:44:51 <birtles> ... I was trying to find a definition of document view but couldn't find anything
08:44:55 <birtles> heycam: the interface?
08:44:59 <birtles> ed: issue 5
08:45:16 <birtles> ... some of the events talk about the context in which the resize takes place, for example
08:45:23 <birtles> ... it occurs when the "document view" is being resized
08:45:51 <birtles> ... other specs talk about the document view but don't define it
08:46:22 <birtles> Tav: we've already mentioned paint servers which just needs some editing
08:46:33 <birtles> ... then there's text which I think I've done half the editing of yet
08:46:45 <birtles> ... I've landed some major structural changes to the chapter but I have more work to do
08:46:55 <birtles> heycam: is there anything that needs discussion or is it just editorial?
08:47:17 <birtles> Tav: at this point I think it's mostly editorial rewriting and I think later there will be some topics for discussion
08:47:39 <birtles> cyril: I am supposed to do the introduction chapter
08:48:06 <birtles> ... if I remember correctly I think the action was to move definitions out of the big list to their corresponding chapters
08:48:19 <birtles> heycam: there are a couple of issues in the introduction chapter
08:49:51 <birtles> (discussion about "Compatibility with other standards efforts section")
08:50:03 <birtles> krit: do we want to remove the reference to DOM2STYLE
08:50:44 <birtles> heycam: it gives us the stylesheet APIs and the .style property but probably both those things are covered by CSSOM something these days
08:51:07 <birtles> ... sounds like introduction is level 4
08:51:49 <birtles> krit: I am looking after the coordinates chapter
08:51:59 <birtles> ... I haven't had time yet but I should do before October
08:52:24 <birtles> ... I think we agreed everything at the last F2F and so everything now should be just editorial
08:53:04 <birtles> birtles: I was supposed to look after the animation chapter but I stopped working on it after it sounded like we would drop that chapter
08:53:46 <birtles> krit: were we going to split that out into a separate module
08:53:56 <birtles> heycam: yes, but unfortunately it's not that straightforward
08:54:48 <birtles> birtles: maybe I should try to do that
08:55:40 <birtles> ... I was working on a separate Animation Elements document that would redefine all of those features in terms of the Web Animations model
08:55:49 <birtles> ... however, it seems like there is less interest in supporting those features in the future
08:56:10 <birtles> ... so perhaps I should just move the animate chapter into a separate SVG Animation spec
08:56:25 <birtles> ... and forget about the Web Animations integration for now
09:15:36 <BogdanBrinza> BogdanBrinza has joined #svg
09:16:21 <birtles> BogdanBrinza: I updated the embedded content chapter to remove <video> etc. elements and linked to the HTML elements instead
09:16:38 <birtles> ... that's pretty much it. I plan to look at the embedded content chapter as a whole
09:16:50 <birtles> ... how the parts I've changed integrate with other parts etc.
09:17:04 <birtles> ... for other HTML elements, all but one are interoperable across all browsers
09:17:09 <birtles> ... <meta>, <link> ec.
09:17:33 <birtles> heycam: I added a short section just listing them saying that they have to work correctly
09:17:41 <birtles> BogdanBrinza: <base> was the only one that didn't work interoperably
09:18:13 <birtles> heycam: I think Amelia was pointing out that certain content breaks when you paste SVG content into an HTML doc with a <base> element
09:18:23 <birtles> ... because it applies that base to those paint server references
09:18:35 <birtles> ... I think we can fix that
09:18:56 <birtles> ... because it you put a url() reference in there then it gets resolved against the stylesheet URL (if it's an external stylesheet)
09:19:09 <birtles> ... so we can just paint other server references do the same thing
09:19:30 <birtles> ... so probably in the section where we describe that these HTML elements work (<meta>, <link> etc.) we could have a section...
09:19:43 <birtles> ... this already applies for the xlink references
09:19:55 <birtles> ... there's no definitive list of what gets resolved against <base> and what do
09:20:01 <birtles> ... we need to add that list
09:20:07 <birtles> ed: we already have an issue in the spec for this
09:20:13 <birtles> ... do you want to actually decide this
09:20:21 <birtles> heycam: I don't have a proposal so I'd have to have a think
09:20:26 <birtles> ... but it would be good to resolve this week
09:20:45 <birtles> BogdanBrinza: I plan to spend this week looking at other chapters and providing other feedback
09:24:17 <BogdanBrinza> BogdanBrinza has joined #svg
09:24:35 <birtles> topic: Assessment of measurements for removing getTransformToElement
09:24:59 <birtles> heycam: we decided to add some measurements to blink to see if anyone is using getTransformToElement
09:25:09 <birtles> ... and it's been 6 months since that was added
09:25:20 <birtles> ... so it's probably a reasonable time to reevaluate
09:25:53 <birtles> ed: it's below the threshold, 0.0001%
09:26:00 <ed_paris> https://www.chromestatus.com/metrics/feature/popularity#SVGGraphicsElementGetTransformToElement
09:26:21 <birtles> heycam: there were some open issues about how that method is supposed to behave
09:26:46 <birtles> ... and that authors should use the methods in GeometryUtils or whatever the other spec is
09:27:00 <birtles> ... and then if we can remove this method we don't need to resolve those issues
09:27:30 <birtles> ... I think Amelia might have had some reservations about removing it but only a concern about removing things in general that people might be using
09:27:36 <birtles> ... what do people think about removing it?
09:27:43 <birtles> Tav: you can do it in another way right?
09:27:59 <birtles> heycam: at very least you can use getCTM
09:28:27 <birtles> ... the tricky cases that the method needs to address are dealing with multiple fragments
09:28:35 <birtles> ... so you'd have to do a bit more work to cover that case, but you can do it
09:29:33 <birtles> dirk: it could be in CSSOMVIEW
09:32:44 <birtles> (we can't seem to find a method that lets you transform points between different elements' coordinate systems)
09:33:07 <birtles> heycam: we can bring that up at the FXTF and if there's interest, add it to a level 2 of GeometryUtils
09:33:26 <birtles> (GeometryUtils: https://drafts.csswg.org/cssom-view/#geometryutils)
09:34:25 <birtles> ... I don't think we need that before we drop getTransformToElement, however
09:34:42 <birtles> ... it's already possible to that using getCTM
09:34:48 <birtles> ... is anyone against removing it?
09:34:50 <birtles> (silence)
09:35:05 <birtles> RESOLUTION: Remove getTransformToElement
09:35:43 <birtles> topic:  'stroke-alignment' values
09:35:57 <birtles> Tav: I have student implementing this in Inkscape so I wanted to get some feedback
09:36:14 <cyril> http://www.w3.org/TR/2015/WD-svg-strokes-20150409/
09:36:48 <birtles> ... if you look at issues around stroke-alignment
09:36:49 <birtles> https://svgwg.org/specs/strokes/#SpecifyingStrokeAlignment
09:37:13 <birtles> ... specifically, "How does this apply to open path segments?"
09:37:27 <birtles> ... and I think we should just use left and right
09:38:18 <birtles> ... originally the spec talked about painting inside the fill region
09:38:33 <birtles> ... so can we just agree to translate inside/outside to left/right
09:38:47 <birtles> heycam: not sure I agree with having an alias from the start
09:39:07 <birtles> Tav: but you could have both open and closed subpaths
09:39:35 <birtles> krit: in adobe products sometimes we do different things in different products
09:40:05 <birtles> ... I agree it's useful but I'm not sure left/right are the correct terms
09:40:30 <birtles> cyril: I think left/right is good for open paths
09:40:47 <birtles> heycam: I wonder if left/right are useful for closed paths too
09:41:17 <birtles> cyril: but what if you have two paths that draw squares/circle-like objects you should be able to use the same keyword to make both of them inside
09:41:40 <birtles> heycam: so inside/outside are not fixed aliases for left/right but are context-dependent
09:42:02 <birtles> ... what happens if you don't have an inside/outside? which one do you choose?
09:42:09 <birtles> Tav: just arbitrarily choose one
09:42:30 <birtles> ... it's only a problem if you have both closed and open
09:42:41 <birtles> heycam: so I think having all four keywords is ok
09:43:01 <birtles> (agreement we should have both inside/outside and left/right)
09:43:09 <birtles> Tav: next issue is about how these apply to loops (#6)
09:43:51 <birtles> ... first example: it's clear what you do for left/right in this case.
09:44:03 <birtles> ... for inside/outside it's not quite clear
09:44:24 <birtles> ... if you have fill-rule: non-zero, then I think you take the outside path
09:44:29 <birtles> heycam: sounds complicated
09:44:39 <birtles> ... you need to do geometry intersection
09:44:59 <birtles> Tav: you have to do that, but you need to do that anyway, it's not hard geometry
09:45:27 <birtles> ... the example at the far right on the second row is tricky
09:45:40 <birtles> ... do you want to fill the bit circled in red
09:45:52 <birtles> cyril: why do you want to have interaction between fill-rule and the stroke position
09:46:03 <birtles> ... until today these were independent
09:46:26 <birtles> Tav: I think there are uses were you have something that is completely filled that you just want to stroke the outside of
09:46:47 <birtles> cyril: it seems odd here to have the fill-rule affect the stroking
09:46:55 <birtles> ... if we want to do that we want to have a stroke-rule or something
09:47:04 <birtles> Tav: that seems to be making it more complicated than it need be
09:48:55 <birtles> birtles: you could just re-author the path the achieve the desired effect
09:49:05 <birtles> BogdanBrinza: it does seem to be a trade-off between complexity and semantic purity
09:49:26 <birtles> cyril: complexity for implementors right
09:49:58 <birtles> BogdanBrinza: from an implementation point of view I would feel some resistance to this
09:50:07 <birtles> ... it would be hard to explain all the different effects
09:50:18 <birtles> ... all the different combinations of properties
09:50:28 <birtles> Tav: would you be interested in supporting stroke-alignment at all?
09:50:34 <birtles> BogdanBrinza: why not
09:50:43 <birtles> Tav: so how would you deal with these cases?
09:50:59 <birtles> cyril: ignore fill-rule and just limit it to the first row
09:51:28 <birtles> ... if you just left-right then it's not issue, only for inside/outside
09:51:38 <birtles> heycam: it makes me wonder if we should only have left-right
09:51:53 <birtles> ... then the results is always well-defined
09:52:12 <birtles> krit: it's easier from an implementation point-of-view but not for authors
09:52:22 <birtles> ... often authors just want to say inside
09:52:37 <birtles> heycam: I wonder if you could just count loops
09:53:14 <birtles> ... determine some way based on the number of loops in the path to make a global decision regarding whether inside means left or right for the whole subpath
09:54:13 <birtles> ... my impression is that the added complexity to do something smart for inside/outside for loops is probably not worth it
09:54:23 <birtles> ... clearly people want to do inside/outside for simple shapes
09:54:47 <birtles> ... if we can support that without the complexity that would be required for working out what inside/outside means for these cases then I would support that
09:55:27 <birtles> cyril: I think working out which side it should be isn't so hard, but actually generating the new path is complex
09:55:50 <birtles> ... and then you'll find differences in implementations tii
09:55:56 <birtles> s/tii/too/
09:56:21 <birtles> Tav: I think the issue is calculating intersections and maybe implementations don't want to do that
09:56:47 <birtles> heycam: I think taking existing stroking code and modifying it to push the stroke to one side is easy enough
09:57:14 <birtles> ... but doing the extra work of intersections, generating the new path etc. is complex and not needed for other features
09:57:23 <birtles> Tav: what about making loops undefined for level 1?
09:57:37 <birtles> heycam: what about just not allowing inside/outside initially?
09:57:48 <birtles> Tav: it's mostly a problem if you have paths going in different directions
09:58:04 <birtles> BogdanBrinza: then we can get feedback from authors who want to do inside/outside
09:58:48 <birtles> Tav: so I could just spec left/right and then add a note about possibly adding inside/outside in future with a description of the issues involved
09:59:11 <birtles> heycam: I think these new modules should not go overboard adding new features in order to have a better chance of being implemented
09:59:18 <birtles> Tav: I think I'm ok with that
09:59:47 <birtles> ... also, just going back to the examples in the issue
10:00:13 <birtles> ... if you look at the middle one in the last row
10:00:22 <birtles> ... to produce this effect is not easy
10:00:36 <birtles> ... so for now we have left/right with a note about having inside/outside in the future
10:00:55 <birtles> ... next issue is, "How are dashes handled? Are they based on original path?"
10:01:09 <birtles> ... one way of implementing this is to offset the path and then dash that
10:01:39 <birtles> ... that works for stroking outside the path, but not inside
10:01:58 <birtles> (Tav draws on whiteboard)
10:04:25 <birtles> (Tav explains how stroke-inside implemented as offsetting the path doesn't work)
10:05:10 <birtles> ... the advantage of having the dashes shift, is that if you could implement stroke-alignment but using a path offset and stroking *that*, then you could use existing renderers
10:05:42 <birtles> ... but since you can't implement stroke-alignment but simply offseting the path, there's not advantage to having the dashes shift
10:06:03 <birtles> heycam: so you're describing the difference between shifting the path then dashing, vs dashing then shifting the path
10:06:06 <birtles> Tav: yes
10:06:33 <birtles> heycam: I don't think it matters so much
10:06:58 <birtles> Tav: the advantage of using the path itself is that if you have multiple strokes on the path (one inside, one outside) the dashes will line up
10:07:05 <birtles> ... so I think dashing should be based on the original path
10:07:34 <birtles> ... you can't just implement stroke-alignment by just doubling the stroke-width and masking out the other half
10:08:17 <birtles> ... if you see the second diagram in issue 7
10:08:25 <birtles> heycam: maybe you should be an editor on this spec
10:08:28 <birtles> Tav: that's fine
10:08:46 <birtles> topic: Making getComputedTextLength not include dx/dy
10:09:07 <birtles> heycam: the existing spec text for this SVG DOM text method says it includes...
10:09:18 <birtles> ... this is the method that works out the length of the text in some sense
10:09:51 <birtles> ... it's defined to include the advance of each glyph, the letter-spacing and word-spacing and any spaces due to those and also any dx value for horizontal text and dy value that introduced extra space
10:10:17 <birtles> ... I think it doesn't really make sense to include dx/dy and make those post-layout presentation effects
10:10:31 <birtles> ... I was testing implementations and it looks like everyone except Edge does not include dx/dy values
10:10:53 <birtles> ... we might have included them in Firefox before we rewrote the SVG text support but at the moment we don't
10:11:00 <birtles> ... I was wondering if Edge would consider removing this
10:11:04 <birtles> BogdanBrinza: do you have a test case?
10:11:16 <heycam> http://mcc.id.au/temp/tl.svg
10:11:55 <birtles> ^ the two numbers reported are the corresponding getComputedTextLength values
10:12:02 <birtles> they will be the same if dx values are ignored
10:12:26 <birtles> Tav: so you want those to be the CSS text layout values
10:12:30 <birtles> ... not the SVG post-processing values
10:13:36 <birtles> heycam: I would surprised if anyone was relying on getComputedTextLength including dx
10:16:04 <birtles> ... you could just get the bounding box and take the appropriate dimension
10:16:34 <birtles> BogdanBrinza: it seems reasonable, and I'm not opposed to matching other browsers
10:16:42 <birtles> ... it seems like Edge just uses the bounding box
10:16:49 <birtles> birtles: does textLength attribute apply before dx?
10:18:01 <birtles> BogdanBrinza: when would you actually use this?
10:20:23 <birtles> ... as opposed to getting the bounding box?
10:21:29 <birtles> heycam: so the bounding box is defined to include the glyph cells as well... so it should be the roughly same
10:22:27 <birtles> (discussion about when the advance differs... e.g. underline uses the advance values so you can have glyphs that extend beyond the end of the underline)
10:27:22 <birtles> BogdanBrinza: I'm not really clear why this method exists
10:27:49 <birtles> (some about another example, text on a path simulated using dx/dy/rotate. What do you expect the computed text length to be in that case?)
10:33:33 <birtles> (also discussion about doing a fancy underline example. In that case you want the advance values, not the bounding box)
10:34:14 <birtles> (and the parallel between textLength attribute and getComputedTextLength() where both should probably behave the same regarding whether or not dx/dy are included)
10:34:38 <birtles> s/same regarding/same behavior regarding/
10:35:11 <birtles> (in effect getComputedTextLength() tells you what textLength equates to when you don't specify it)
10:35:39 <birtles> BogdanBrinza: I'll file a bug on Edge to make other implementations
10:36:02 <birtles> (everyone agrees that this method isn't very useful when dx/dy are used)
10:37:08 <birtles> RESOLUTION: Make getComputedTextLength ignore dx/dy
10:37:32 <birtles> ACTION: Cameron to update the definition of getComputedTextLength so that it ignores dx/dy
10:37:32 <trackbot> Created ACTION-3814 - Update the definition of getcomputedtextlength so that it ignores dx/dy [on Cameron McCormack - due 2015-08-31].
10:45:33 <heycam> trackbot, close ACTION-3814
10:45:34 <trackbot> Closed ACTION-3814.
11:03:38 <heycam> -- lunch --
11:40:38 <jdaggett> jdaggett has joined #svg
12:04:55 <BogdanBrinza> BogdanBrinza has joined #svg
12:06:09 <jdaggett> jdaggett has joined #svg
12:56:58 <nikos> What's the plan this afternoon? Spec editing?
13:06:55 <heycam> nikos, yep!
13:22:20 <nikos> cool, I'll head on down but need to check in and get sorted first
13:58:53 <BogdanBrinza_> BogdanBrinza_ has joined #svg
14:05:15 <shepazu> shepazu has joined #svg
14:33:22 <tantek> tantek has joined #svg
14:33:54 <heycam> tantek, Apero
14:57:06 <AmeliaBR> AmeliaBR has joined #svg
15:10:24 <birtles> nikos: please refer to https://tools.ietf.org/html/rfc6919 for requirements levels
15:10:45 <birtles> in this case SHOULD CONSIDER ?
15:46:20 <tantek> tantek has joined #svg
16:27:53 <ed_paris> https://www.w3.org/Graphics/SVG/WG/wiki/Test good stuff
16:46:44 <Tav> Tav has joined #svg
17:36:59 <ed> ed has joined #svg
17:47:55 <ed_> ed_ has joined #svg
18:02:04 <ed_> ed_ has joined #svg
18:54:17 <tkonno> tkonno has joined #svg
19:10:44 <jdaggett> jdaggett has joined #svg
19:22:50 <shepazu> shepazu has joined #svg
19:34:02 <shepazu> shepazu has joined #svg
20:30:13 <tantek> tantek has joined #svg
21:01:10 <ed_paris> ed_paris has joined #svg
21:23:56 <ed_paris> ed_paris has joined #svg
22:58:08 <jdaggett> jdaggett has joined #svg