W3C

- DRAFT -

SVG Working Group Teleconference

08 Oct 2015

Agenda

See also: IRC log

Attendees

Present
Cameron, ed, tav, amelia, nikos, fantasai, stakagi, shepazu
Regrets
Chair
Cameron
Scribe
Nikos

Contents


<trackbot> Date: 08 October 2015

<fantasai> passcode?

<scribe> Scribe: Nikos

<scribe> scribenick: nikos

writing modes

fantasai: I think we came to a bunch of conclusions at the F2F and I tried to edit them in
... then there was an issue about whethter the old values should compute to each other, or if they needed to be maintained separately in the layout engine just for SVG
... seems discussion on the list is that it's ok to compute them to new values
... so overall looks good
... Amelia may have wanted some clarifications?

AmeliaBR: just for text-orientation. I think the way you've approached it is great
... shorthand translates to new property
... but making sure all existing valid values are translated properly
... as an angle value rather than a string value
... it's tricky that no units at all doesn't map to a css angle

fantasai: there's a question of whether that's accepted in the css syntax as well
... there was discussion about unitess values and supporting them in css but there was push back on that

AmeliaBR: it currently works in the limited number of browsers that support that property
... that's consistent with svg 11
... you can leave off units if it's a property that was introduced for svg
... as this one was
... but as far as mapping, it's probably easiest to just describe it as two different ways
... a number and an angle option
... and map them both

<heycam> https://svgwg.org/svg2-draft/types.html#syntax

heycam: at the moment we have text in svg 2 about how to parse presentation attributes
... which effectively does a search and replace on the grammar to insert number at a ppropriate places
... so thats what let them accept zero
... for ones that aren't svg specific (come from css) we insert it into the grammar

fantasai: that's going to get confusing when moving properties back and forth
... but suppose you need to do that for backwards compat. Don't think it's a practice we should take forward

heycam: would you prefer we limit that to the set of properties that we already support - new svg properties don't get that ?

fantasai: think that would be a good idea - we are seeing cases where we're taking properties from svg
... and there really shouldn't be a distinction for the author

heycam: that's reasonable - I can come up with the list of properties to allow that for

fantasai: as far as glyph orientation vertical, the question is if we ignore other values
... current recommendation is to ignore and treat as unsupported
... unless you think there's content out there that relies on the weird values

heycam: I agree - I keep hearing dirk mention output from illustrator
... afaik it was using text-orientation: 0
... so it could do it's own glyph layout

fantasai: zero gets mapped to upright which does the same thing

<heycam> ACTION: Cameron to come up with a list of properties to explicitly allow unitless values in [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action01]

<trackbot> Created ACTION-3822 - Come up with a list of properties to explicitly allow unitless values in [on Cameron McCormack - due 2015-10-15].

AmeliaBR: only other comment I had was somewhere adding a comment about the html direction properties

fantasai: it's handled in the bidi section

AmeliaBR: I found in testing that IE responds to those things but it doesn't set the css in a way that will inherit into svg
... so if you say direction=rl on html or body it's not inherited into inline svg
... the way the css direction property would

fantasai: we had an appendix that had mapping rules for html4 but some html people asked us to take it out
... html5 defines this already in it's rendering section
... I can add a reference to that section if there isn't one already, but it is required by the HTML spec that you map to the CSS properties

AmeliaBR: I haven't tested in Edge - it may be fixed there. Pretty sure everyone else inherits as expected

fantasai: I just have to make a few clarifications regarding writing-mode - add some mappings, but don't know if anyone actually needs that
... what do you do for radian?
... it's not a rational number so don't know how you'd do that mapping

AmeliaBR: has to be exactly that value

fantasai: if svg wg wants me to specify radians and gradians as well I can do that, but please let me know what you want to do for radians
... if you don't need them we can drop that
... you'll have to tell me what range is accepted as 90 degrees, etc

AmeliaBR: yeah that was something that wasn't defined in the svg spec

Tav: it says they're restricted to 0, 90, 270, 180
... doubt anyone would use gradians

AmeliaBR: unitless numbers are out there in the real world, radians less likely

Tav: I'd ignore radians

heycam: that'd be fine with me

shepazu: Just one point - you were saying Amelia (meow) that IE doesn't inherit
... that's probably juts a bug

heycam: I think fantasai was referring to ua stylesheet where it maps
... I could see there may be ua style rules that reset those properties on svg elements
... It's unlikely the spec says that so I'd agree with Doug that it's probably a bug

Path stroking for paths that end with tight curves

<AmeliaBR> Yes, it's in HTML 5 here, so no change required in CSS Writing Modes: http://www.w3.org/TR/html5/rendering.html#bidi-rendering

Tav: I just had a question of whether we want to define how you do stroking

heycam: we do

<Tav> http://tavmjong.free.fr/SVG/STROKING/

Tav: I looked at how stroking is implemented while looking at the stroke alignment property
... there's one place where theres inconsistency between FF and other browsers and Postscript and PDF
... if you have a very tight curve at the end of the line you sometimes see this ugly behaviour and it surprises people

<heycam> https://svgwg.org/svg2-draft/painting.html#StrokeShape

heycam: I did add a section on what the exact shape of a stroke should be
... that describes it in the form of what set of points should be in the stroke
... so that matches the 'move a line of stroke width around the path' method
... I showed this to one of our graphics guys and he was a bit unhappy because it was too precisely defined
... because we're at the mercy of underlying graphics libraries
... theres no way we can change our implementation without creating a whole new renderer
... and as we move to using more os and gfx card libraries that will get even harder
... so he would have preferred some leway
... not sure how to do that - whether we allow two methods or what
... but practically we have to allow something like that

Tav: it would be nice to have some consistency, if you scroll down on the link and look at the dash pattern
... you can see the dash pattern is doing more what I would expect

shepazu: might have to consider hardware implementations also
... we should check with khronos about what hw is likely to do

Tav: good idea
... another consideration is the sweeping a perpendicular line around
... doesn't work with inside/outside
... you get things outside the area you would expect them in
... talking with the khronos guys might be a good idea

AmeliaBR: if the long term result is to get these features hw accelerated we want consistency with specs and whatever hw is calcaulating

Tav: my guess is they can probably do it either way

shepazu: I think they probably have some way they have chosen to do it

heycam: Tav do you you agree we should change the svg 2 spec wrt covering the various strategies
... should we make it a 'should' or what?

Tav: I'd prefer to take FFs approach but agree it may be hard if people rely on underlying libraries

nikos: what does PDF do?

Tav: matches FF
... as soon as you add a dash pattern you can see that they're doing something different

AmeliaBR: at that point each dash becomes it's own path
... so the rules change

heycam: you're probably seeing Cairos behaviour if you're testing FF on linux
... you might see different behaviour on other platforms

shepazu: underlying libraries can also change - that's not a totally inflexible requirement
... we should talk to khronos and library vendors etc and get agreement

nikos: Cairo implements PDF model so I think it would difficult to change

AmeliaBR: well that's the one it would be nice to fix upon
... but what are we going to do with SVG 2 for now, knowing other engines do things differently?

heycam: agree that option is the ideal
... I'd be happy with the spec saying here's the ideal stroke shape but you may differ in some particular ways

Tav: one way you may be able to make them look closer is if you connect the point where it goes in the opposite direction to the path itself
... at the end point

<ed> would be interesting to hear what the skia people have to say about this

<scribe> ACTION: Nikos to look into implementation of path stroking in various libraries with view to what recommendations svg 2 spec should make [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action02]

<trackbot> Created ACTION-3823 - Look into implementation of path stroking in various libraries with view to what recommendations svg 2 spec should make [on Nikos Andronikos - due 2015-10-15].

Declarative animation and conformance

ed: this was raised as an issue on github

<ed> https://github.com/w3c/svgwg/issues/23

ed: Brian responded but I'm not sure if we need to update the conformance chapter to say something about SMIL and declarative animations

AmeliaBR: it comes up in this case where teh chapter distinguishes between static and dynamic viewers
... in describing a dynamic viewer it mentions declarative animation and script
... in my sense, that is written as descriptive rather than prescriptive
... further on we have some more text about requirements
... maybe we need to clean up to say 'for example, dynamic content could be achieved in either of these ways'
... does that make sense?

heycam: think so and I think you're right about why it's mentioned there
... not meant to include or exclude SMIL explicitly, just that that was the only declarative method around at the time the spec was written

<AmeliaBR> Here's SVG 1.1 text http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers

heycam: conformance appendix hasn't had much attention yet
... could do with some reviews

<AmeliaBR> Latest SVG 2: https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers

heycam: maybe someone should rewrite - probably a lot of conformance classes we don't need are included
... if no one has an interest at the moment, we should probably add an issue saying conformance class wording needs to be reviewed
... as for the result of the issue, I agree and we should comment in the github issue to that effect

AmeliaBR: I can do that if Cam will add the issue to the spec

<fantasai> summary is, add gradiens and integers to glyph-orient, otherwise spec is okay?

<fantasai> or other edits/concerns?

<scribe> ACTION: heycam to add an issue to conformance appendix noting that it needs review/rewriting [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action03]

<trackbot> Created ACTION-3824 - Add an issue to conformance appendix noting that it needs review/rewriting [on Cameron McCormack - due 2015-10-15].

<heycam> fantasai, that sounds right.

back to writing modes

heycam: probably don't need to bother about gradiens, it's very unlikely anyone is using them

fantasai: works for me

shepazu: we can always add them later

fantasai: so conslusion is to add integers to represent unitless values
... gradiens and radians get dropped
... clarify that they are not part of the glyph orientation property going forwards
... clarifying the spec that values other than 0,90,180,270 are not supported

heycam: that sounds like what we agreed on

fantasai: I'll make those edits and take the spec back to CSS for a resolution to publish CR
... concludes what I need from you guys wrt writing modes

Anchor tag nesting and HTML harmonization

<ed> https://github.com/w3c/svgwg/issues/26

ed: two questions in this issue
... first, we disallow nesting of anchor tag in svg 2

AmeliaBR: that's something that should have been disallowed anyway
... but it maybe wasn't clearly stated before
... right now we've got a content model that is generic and it should not allow that

ed: i think it would be good to have a small note explaining why we did this and why it wasn't disallowed before

heycam: to be clear, this is just about author conformance requirements right?

ed: yeah - not quite sure what implementations do right now. They may differ in how they handle the case.

AmeliaBR: theoretically if they were just a elements with anchors and not links they might not break anything
... but otherwise things are not going to work properly, and I think HTML explicitly disallows it

heycam: I would probably put it down to a mistake when I was generating those blue boxes
... it's difficult to construct nested a elements because of how the html parser work
... but you can do it in the dom

<ed> html: https://html.spec.whatwg.org/multipage/semantics.html#the-a-element "Content model: Transparent, but there must be no interactive content descendant."

heycam: hope the HTML spec says something about that, and we can do something similar

ed: we might want to clarify what happens if you have nested links in svg 2
... which link is clicked

heycam: agree we should write that up
... whos the owner of the linking chapter?

AmeliaBR: it's been myself and Bogdan

heycam: is it something you'd be willing to work on Amelia?

AmeliaBR: I can tidy that up. Will do some quick tests to see what happens
... do people like Erik's idea of which link should be active?

heycam: yes

AmeliaBR: do we have a preference ?

ed: I'd like it to be the same as HTML

<scribe> ACTION: Amelia to investigate behaviour of nested links in SVG and HTML [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action04]

<trackbot> Created ACTION-3825 - Investigate behaviour of nested links in svg and html [on Amelia Bellamy-Royds - due 2015-10-15].

ed: that covers the first question, second question is whether we should add additional attributes that HTML defines

AmeliaBR: I like that idea

heycam: doesn't sound like those three would be problematic

<AmeliaBR> For reference, here's the HTML 5 spec: http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element

heycam: we've already decided to have the same set of attributes for style and script
... so I think it makes sense to have the same set of attributes on a

ed: agree

AmeliaBR: there's about eight different attributes in HTML
... all of which would be applicable

heycam: would we want to add the corresponding DOM properties?
... so duplicate what's on HTML anchor elements?

AmeliaBR: I'd opt for consistency unless there's some issue. There may be accessibility interfaces that use these extra attributes
... would make it much easier if SVG supports them as well

heycam: let's assume we will have the same attributes and DOM properties then and if we find anything that will be problematic then we can discuss skipping
... but I think it should all be fine

AmeliaBR: right now the only special dom property we have is for target, and I'm pretty sure that's consistent with the HTML one

ed: for href we have an svg animated string as the interface

AmeliaBR: same with target, listed as animated string rather than simple string

<ed> so it's aElement.href.baseVal = "#foo"

AmeliaBR: which is inconsistent with the html interface
... so if we bring new things in, are we consistent to the existing svg dom or the html dom?

heycam: for non animated thing I think we tend to do something similar to the html spec already
... so I think in a way it would be consistent with existing things in html if we took the idl from html
... for everything other than href

<scribe> ACTION: amelia to look at adding extra html attributes onto svg a element [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action05]

<trackbot> Created ACTION-3826 - Look at adding extra html attributes onto svg a element [on Amelia Bellamy-Royds - due 2015-10-15].

AmeliaBR: to be clear, href and target are animated string and the rest are just dom strings?

<ed> https://svgwg.org/svg2-draft/linking.html#InterfaceSVGAElement

heycam: yes
... I'm surprised target is an animated string

Summary of Action Items

[NEW] ACTION: Amelia to investigate behaviour of nested links in SVG and HTML [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action04]
[NEW] ACTION: amelia to look at adding extra html attributes onto svg a element [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action05]
[NEW] ACTION: Cameron to come up with a list of properties to explicitly allow unitless values in [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action01]
[NEW] ACTION: heycam to add an issue to conformance appendix noting that it needs review/rewriting [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action03]
[NEW] ACTION: Nikos to look into implementation of path stroking in various libraries with view to what recommendations svg 2 spec should make [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/08 21:40:30 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/gradients/gradians/
Succeeded: s/radains/radians/
Succeeded: s/and add/if Cam will add/
Succeeded: s/gradiens and radians get mapped/gradiens and radians get dropped/
Succeeded: s/strg/string/
Succeeded: s/animated strings/animated string/
Found Scribe: Nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: Cameron ed tav amelia nikos fantasai stakagi shepazu
Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Oct/0025.html
Found Date: 08 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/08-svg-minutes.html
People with action items: amelia cameron heycam nikos

[End of scribe.perl diagnostic output]