Minutes, Paris F2F Day 1, 24 August 2015

Dear all,

Please find the minutes from yesterday's F2F meeting below. An HTML 
version is attached.


W3C
SVG Working Group F2F
24 Aug 2015

See also: IRC log <http://www.w3.org/2015/08/24-svg-irc>
Attendees

   Present
          Cameron McCormack (heycam), Erik Dahlström (ed),
          Tavmjong Bah (Tav), Bogdan Brinza (BogdanBrinza),
          Cyril Concolato (cyril), Dirk Schulze (krit), Jet Villegas,
          Brian Birtles (birtles)
   Regrets
          Nikos Andronikos, Jun Fujisawa, Tomoaki Konno, Chris Little,
          Rik Cabanier, Jean-Claude Moissinac, Thomas Smailus,
          Amelia Bellamy-Royds
   Chair
          Cameron
   Scribe
          birtles

Contents

     * Topics
         1. Chapter status update
         2. Assessment of measurements for removing getTransformToElement
         3. 'stroke-alignment' values
         4. Making getComputedTextLength not include dx/dy
     * Summary of Action Items
     * Summary of Resolutions


1. Chapter status update

     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


2. Assessment of measurements for removing getTransformToElement

     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


3. 'stroke-alignment' values

     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


4. Making getComputedTextLength not include dx/dy

     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.

Summary of Action Items

     [NEW] 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]

Summary of Resolutions

     Remove getTransformToElement
     Make getComputedTextLength ignore dx/dy

[End of minutes]