- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Fri, 1 Jul 2016 03:32:34 +0000
- To: www-svg <www-svg@w3.org>
https://www.w3.org/2016/06/20-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
20 Jun 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/06/20-svg-irc
Attendees
Present
nikos, Tav, AmeliaBR, stakagi
Regrets
Chair
nikos
Scribe
nikos
Contents
* [3]Topics
1. [4]SVG 2 CR issue triage
2. [5]Full glyph cell for vertical text
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<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
[8]https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg
2-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
[8] https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html
Keep xlink:href in examples linked to in spec. #105
[9]https://github.com/w3c/svgwg/issues/105
[9] 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
... [10]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
[10] https://github.com/w3c/svgwg/issues/111
[11]https://github.com/w3c/svgwg/issues/113
[11] 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
[12]https://github.com/w3c/svgwg/issues/44
[12] 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
[13]https://github.com/w3c/svgwg/issues/93
[13] 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
[14]https://github.com/w3c/svgwg/issues/94
[14] 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
[15]https://github.com/w3c/svgwg/issues/99
[15] 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
[16]https://github.com/w3c/svgwg/issues/116
[16] 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
[17]https://github.com/w3c/svgwg/issues/117
[17] 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
[18]https://github.com/w3c/svgwg/issues/139
[18] 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
[19]https://github.com/w3c/svgwg/issues/163
[19] 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>
[20]http://jsbin.com/qekuribufi/edit?html,console,output
[20] 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
[21]https://github.com/w3c/svgwg/issues/74
[21] 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
[22]https://github.com/w3c/svgwg/issues/40
[22] 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
[23]https://github.com/w3c/svgwg/issues/159
[23] 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
[24]https://github.com/w3c/svgwg/issues/49
[24] 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
[25]https://github.com/w3c/svgwg/issues/119
[25] 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
[26]https://github.com/w3c/svgwg/issues/34
[26] 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
[27]https://github.com/w3c/svgwg/issues/125
[27] 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
[28]https://github.com/w3c/svgwg/issues/88
[28] 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:
[29]https://nikosandronikos.github.io/svg2-cr-issues/svg2-cr-is
sues.html
[29] 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
[30]https://github.com/w3c/svgwg/issues/150
[30] 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
[31]https://github.com/w3c/svgwg/issues/160
[31] https://github.com/w3c/svgwg/issues/160
nikos: some remaining preserveAspectRatio="defer" wording needs
removing #160
AmeliaBR: this is another editorial issue
[32]https://github.com/w3c/svgwg/issues/64
[32] 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
[33]https://github.com/w3c/svgwg/issues/141
[33] 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
... [34]https://github.com/w3c/svgwg/issues/167
... [35]https://github.com/w3c/svgwg/issues/168
[34] https://github.com/w3c/svgwg/issues/167
[35] https://github.com/w3c/svgwg/issues/168
[36]https://github.com/w3c/svgwg/issues/87
[36] https://github.com/w3c/svgwg/issues/87
Add diagram for mapping points inside Coon's patch to gradient
vales #87
nikos: definitely not CR
[37]https://github.com/w3c/svgwg/issues/121
[37] 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
[38]https://github.com/w3c/svgwg/issues/135
[38] 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
[39]https://github.com/w3c/svgwg/issues/140
[39] 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
[40]https://github.com/w3c/svgwg/issues/26
[40] 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
[41]https://github.com/w3c/svgwg/issues/61
[41] 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
[42]https://github.com/w3c/svgwg/issues/52
[42] 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
[43]https://github.com/w3c/svgwg/issues/71
[43] https://github.com/w3c/svgwg/issues/71
nikos: SVG 2 has un-used references #71
... this one is post cr
[44]https://github.com/w3c/svgwg/issues/82
[44] https://github.com/w3c/svgwg/issues/82
nikos: Property index (appendix) needs updating #82
... think this can be done after CR
[45]https://github.com/w3c/svgwg/issues/83
[45] https://github.com/w3c/svgwg/issues/83
nikos: Can we remove presentation attribute / element table
from Attribute Index appendix? #83
[46]https://github.com/w3c/svgwg/issues/84
[46] 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
[47]https://github.com/w3c/svgwg/issues/85
[47] 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
Full glyph cell for vertical text
Tav: For vertical text, use the vertical advance and em box
width
nikos: what happens if font has no vertical advance
Tav: use the em box height
Summary of Action Items
Summary of Resolutions
1. [48]getBBox() on text that uses inline-size will return the
union of the glyph cells rather than anything based on the
content box
[End of minutes]
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Friday, 1 July 2016 03:33:41 UTC