Minutes, June 2016 Amsterdam editors meeting, Day 1

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Minutes, June 2016 Amsterdam editors meeting, Day 1

Nikos Andronikos


      [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


          nikos, Tav, AmeliaBR, stakagi




     * [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
   ... 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

   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
   ... [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
   ... 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

   nikos: this is another markup fix

   AmeliaBR: we shouldn't have a table embedded into a definition
   ... 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

   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

   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

   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

   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

   Multilingual titles and ARIA fallbacks don't work well together

   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

   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

   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

   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


     [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

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


     [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

   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

   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

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

   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

   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

   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

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

   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

   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-issues.html

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

   AmeliaBR: it's really just editorial if we're just referencing
   ... 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

   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

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

   AmeliaBR: this is another editorial issue


     [32] https://github.com/w3c/svgwg/issues/64

   nikos: Marker element percentages are missing reference values
   ... 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

   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

   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

   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


     [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

   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


   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

   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
   ... 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

   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

   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

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


     [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

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


     [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

   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

Full glyph cell for vertical text

   Tav: For vertical text, use the vertical advance and em box

   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.