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