SVG Working Group Teleconference -- 20 Jun 2016

<scribe> Meeting: Amsterdam editors meeting 2016

For those following along at home, we are going to do some editing to start

Then, we'll go through the open issues and work out what is critical for CR and what can be deferred

SVG 2 CR issue triage

<scribe> scribe: nikos

<scribe> scribenick: nikos

nikos: The list of issues assigned to the CR milestone is at https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html
... Anything that's not critical to the publication of CR - e.g. stuff that is just tidying up, or fixing lists, or markup we will move to another milestone
... Then we'll have the short list of stuff that must be done, which we'll work through at this meeting

Keep xlink:href in examples linked to in spec. #105

https://github.com/w3c/svgwg/issues/105

AmeliaBR: Tav brought this one up, we got rid of xlink from all our embedded examples

nikos: My issue with this is that we pull these examples into the spec as markup examples
... I don't think we should be recommending the use of xlink in those examples

AmeliaBR: it's still best practice at the moment to use xlink

nikos: In any case, we can move this and look at it after CR

Make "show" widget in element definitions boxes play nicely with screen readers #110

nikos: This is just a template fix
... we just need to fix our markup, which we can do after CR
... Rewrite all element descriptions to use normative language #111
... https://github.com/w3c/svgwg/issues/111
... this one is big and very vague
... as I touch text I've been updating descriptions to use proper normative language
... I think we keep this in the CR, but it's not going to block publication
... Remove redundant <dl> wrapper for the attribute table + prose block of each element #113

https://github.com/w3c/svgwg/issues/113

nikos: this is another markup fix

AmeliaBR: we shouldn't have a table embedded into a definition list
... Unfortunately I think this is more than template, we have to go over each chapter and do a sweep of the markup

nikos: I'd rather just switch to bikeshed
... it's not urgent, we'll fix it after CR

AmeliaBR: we need to document how our markup should be written

Does conditional processing mute sound playback? #44

https://github.com/w3c/svgwg/issues/44

AmeliaBR: we talked about this on a call recently
... TabAtkins mentioned how he thought this would work, but my testing showed it was implemented differently
... and doesn't seem to be specced that way
... can't find anything in HTML about display:none
... HTML doesn't specifically spec one way or the other
... it's more than just display:none for SVG
... what happens if it's in defs
... or an unactivated part of switch
... I think this is more than something we can decide in a triage session
... it's definitely a CR issue

https://github.com/w3c/svgwg/issues/93

Review content model and allowed attributes on all elements #93

nikos: definitely something needed before CR. Sounds like something a chair should do

https://github.com/w3c/svgwg/issues/94

nikos: Update Document Structure chapter to describe document's behaviour in terms of the DOM #94

AmeliaBR: think this is editorial, to say that no matter how you create the DOM, it works the same way

nikos: We'll make it CR2

https://github.com/w3c/svgwg/issues/99

nikos: We should define the behavior of ‘use’ in terms of Web Components #99

AmeliaBR: that's CR and it's next on my todo list
... #101 and #102 are also CR and I'm working on them right now

https://github.com/w3c/svgwg/issues/116

Multilingual titles and ARIA fallbacks don't work well together #116

AmeliaBR: I think this can be dealt with in authoring practices
... think we can take it off CR

https://github.com/w3c/svgwg/issues/117

Figure out where the list of aria-properties comes from, & sort them in logical/alphabetical order #117

nikos: I did find where in the scripts this happens
... but didn't exactly work out how to fix it
... but it's CR2

https://github.com/w3c/svgwg/issues/139

nikos: Fix switch & conditional processing #139
... this is a meta issue
... most aspects have been addressed, some haven't but they have their own issues
... so we'll take this one off the milestone
... Takagi-san added a new proposal here which we'll talk about over lunch or something and then discuss properly in a telcon

https://github.com/w3c/svgwg/issues/163

nikos: <script> and <style> content model should allow only character data. #163

AmeliaBR: At the moment it just allows anything, not sure if anyone has tested that
... I expect you'll just get the text rather than objects

Tav: can we resolve that we only allow character data?

AmeliaBR: I'd like to. I'm writing a test
... nope, markup gets parsed as markup

<AmeliaBR> http://jsbin.com/qekuribufi/edit?html,console,output

AmeliaBR: it's cross browser, FF, Edge, Chrome all parse that as a valid link

Tav: why would you want to put an element inside?
... just because browsers parse it doesn't mean we have to spec it

nikos: Let's leave it in CR and come back to it

https://github.com/w3c/svgwg/issues/74

nikos: Initial value for the 'rx' and 'ry' properties #74
... I think this is CR and Amelia has mostly taken care of it

AmeliaBR: I'll take care of that this week

https://github.com/w3c/svgwg/issues/40

Full glyph cell term is not defined #40

nikos: I defined this but wanted to check it with Tav
... We'll talk about it after triage

https://github.com/w3c/svgwg/issues/159

nikos: Update bounding box algorithm for inline-size #159
... we were talking about this yesterday, and couldn't remember why the bounding box width is always the same width as the content box

AmeliaBR: my argument was that if you're calling getBBox() you're trying to find out information you don't know

Tav: I counter that by saying what you don't know is the height, and that's what you want here

AmeliaBR: so use getBBox() to get the height and get the inline-size value if that's what you need

nikos: It makes more sense to me that you would get the actual bbox of the glyphs

Tav: Ok, we'll go with that

RESOLUTION: getBBox() on text that uses inline-size will return the union of the glyph cells rather than anything based on the content box

Tav: this applies to bounding box that is used for paint servers also

AmeliaBR: I think if you want predictable box behaviour, use text in a shape
... do we have special rules for text in a shape?
... is it the bounding box of the text or the shape?

Tav: It should be the shape

AmeliaBR: I'll update the issue to not those points

Tav: ... I guess as the content box height increases the gradient is going to change as well
... so it probably not going to be as consistent as I'd like it to be anyway

https://github.com/w3c/svgwg/issues/49

nikos: `d` geometric property needs a clear & extensible name #49

AmeliaBR: I added this to CR yesterday, not sure if there's anything that needs addressing

nikos: we were only going to do the most basic option

AmeliaBR: have a separate issue for that so let's take CR off the big issue

https://github.com/w3c/svgwg/issues/119

nikos: Make d a presentation attribute on path #119
... Tav said he'd do that

Tav: I did?
... I'll do it this week

https://github.com/w3c/svgwg/issues/34

nikos: Adding default values for hanging and mathematical baselines #34

Tav: We're just waiting on CSS to add this to their spec
... it's not a CR issue for us

https://github.com/w3c/svgwg/issues/125

nikos: Spec behavior of ::before and ::after within SVG text #125

Tav: I think we don't do anything with this one
... it's a lot of work to figure out how to handle it

nikos: So we'll spec it up later in a module or something

https://github.com/w3c/svgwg/issues/88

nikos: Can we update image's href attribute description to reference HTML51's obtain the resource algorithm? #88

<AmeliaBR> Issue list: https://nikosandronikos.github.io/svg2-cr-issues/svg2-cr-issues.html

nikos: This is an area I'm not comfortable making changes

AmeliaBR: it's really just editorial if we're just referencing HTML
... Would be better to reference HTML, we don't want to unintentionally introduce variations
... someone needs to sit and go through and work out what the differences are

nikos: Let's leave it as CR for the moment and see if we get time to look at it

https://github.com/w3c/svgwg/issues/150

nikos: Simplify <image> element content model #150

AmeliaBR: this is CR, should be a case of going through definitions.xml and cleaning up

https://github.com/w3c/svgwg/issues/160

nikos: some remaining preserveAspectRatio="defer" wording needs removing #160

AmeliaBR: this is another editorial issue

https://github.com/w3c/svgwg/issues/64

nikos: Marker element percentages are missing reference values #64
... I resolved most of this last week
... didn't close issue because I wanted to talk about markerWidth and markerHeight percentages
... I think since UAs support them we leave it in

AmeliaBR: issue of what viewport the percentages are resolved against is part of a bigger bug - not marker specific

nikos: I'll take off CR milestone and note that we need to file a bug on the browsers

https://github.com/w3c/svgwg/issues/141

nikos: Define how to interpolate multiple paints in fill and stroke #141

AmeliaBR: this is about making it clear
... not sure if we need to do too much or if we can just reference css
... as far as multiples go, CSS has a rule that you pair things up and if you have the same number of elements in each list you interpolate between them
... I can take a look and see if there's tidy up to be done. But I think it's related to the new issues I added
... https://github.com/w3c/svgwg/issues/167
... https://github.com/w3c/svgwg/issues/168

https://github.com/w3c/svgwg/issues/87

Add diagram for mapping points inside Coon's patch to gradient vales #87

nikos: definitely not CR

https://github.com/w3c/svgwg/issues/121

nikos: Limit pattern & gradient attributes that are inheritable using href #121

AmeliaBR: I said I'd look at this one, but I've been delaying until I look at how things will be defined in terms of shadow dom

https://github.com/w3c/svgwg/issues/135

nikos: Shouldn't gradientTransform precede object bounding box to user space conversion? #135

AmeliaBR: I've been planning to sit down and work this out, to see if there is an issue there
... feel free to pick it up if you're keen

https://github.com/w3c/svgwg/issues/140

Define how meshes are rendered when children of shapes #140

AmeliaBR: I think the real issue is whether we should have meshes being a renderable obejct

s/obect/object

scribe: we have paint servers as children of other elements
... so we need special rules for meshes if they're going to be geometry elements
... the bigger issue is where paint servers and shapes have different dom representations

nikos: we could have mesh and meshGradient and they have the appropriate interface

AmeliaBR: I was thinking we could have a path that automatically takes on the shape of the mesh
... but that might be complicated with css

https://github.com/w3c/svgwg/issues/26

nikos: Two questions about the `<a>` element #26

AmeliaBR: we have a resolution, it may need revising
... the html parser doesn't allow nested elements
... the other question is should we borrow the html link attributes like rel, etc
... think we agreed and I was going to add them
... but links and nested may need to be revisited
... if anyone else wants to take this on, go ahead
... tests shows that it's still two links - not broken into three
... so whatever I saw about the html parser may not be true
... ohhh, Cameron had to inject the second link using script
... so parser doesn't allow it

nikos: we'll need to resolve one way or the other before CR

https://github.com/w3c/svgwg/issues/61

nikos: Possible to use `<use xlink:href="#id">` in the presence of an HTML `<base>` element? #61
... This one stays, just needs editing

https://github.com/w3c/svgwg/issues/52

nikos: Error Processing should talk about when to use initial values for attributes #52
... I think this one is already resolved, its just that the link to 'error processing' on viewbox isn't helpful

https://github.com/w3c/svgwg/issues/71

nikos: SVG 2 has un-used references #71
... this one is post cr

https://github.com/w3c/svgwg/issues/82

nikos: Property index (appendix) needs updating #82
... think this can be done after CR

https://github.com/w3c/svgwg/issues/83

nikos: Can we remove presentation attribute / element table from Attribute Index appendix? #83

https://github.com/w3c/svgwg/issues/84

nikos: Define conformance classes without reference to feature strings #84

AmeliaBR: We need to do this one before CR

https://github.com/w3c/svgwg/issues/85

nikos: Update SVG DOM object initialisation to reflect promoted properties #85

AmeliaBR: think we talked about DOM properties not reflecting the computed style, only the value of the presentation attribute