20:29:25 <RRSAgent> RRSAgent has joined #svg
20:29:25 <RRSAgent> logging to http://www.w3.org/2016/09/15-svg-irc
20:29:27 <trackbot> RRSAgent, make logs public
20:29:29 <trackbot> Zakim, this will be GA_SVGWG
20:29:29 <Zakim> ok, trackbot
20:29:30 <trackbot> Meeting: SVG Working Group Teleconference
20:29:30 <trackbot> Date: 15 September 2016
20:30:01 <nikos> Chair: Nikos
20:30:04 <nikos> Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Sep/0011.html
20:30:51 <nikos> present+ nikos
20:31:55 <Tav> present+ Tav
20:32:19 <stakagi> present+ stakagi
20:33:23 <stakagi> hi!
20:37:00 <shepazu> SVG published as CR! https://www.w3.org/TR/SVG2/
20:37:04 <nikos> scribe: nikos
20:37:08 <nikos> scribenick: nikos
20:37:11 <nikos> Topic: SVG 2 CR publication update
20:37:16 <stakagi> Congratulations!
20:37:19 <nikos> shepazu: yay!
20:37:58 <nikos> ... I've started reaching out to people to help with testing as invited experts
20:39:39 <nikos> ... https://github.com/karip
20:40:19 <shepazu> https://twitter.com/_hmig
20:43:51 <shepazu> http://w3c.github.io/svgwg/specs/svg-authoring/#new-features-in-svg-2
20:43:55 <nikos> shepazu: Also I updated the authoring the guide - added foreignObject and this
20:44:21 <nikos> ... it's a loaded question - should we add new features from svg 2 into this authoring guide?
20:44:40 <nikos> nikos: If you can't author with them yet, do they belong in the authoring guide?
20:44:43 <nikos> shepazu: that's one of the cons
20:45:10 <nikos> AmeliaBR: definitely they could be written up as how you can use these features in a progress way - a practical guide of where we are now
20:45:37 <nikos> ... things can become dated if discussion is focused on current browser support so we should have a periodic review and update planned
20:45:52 <nikos> shepazu: it doesn't actually have to be part of the authoring guide
20:47:06 <AmeliaBR> s/progress way/progressive enhancement way/
20:51:24 <AmeliaBR> https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/
20:51:38 <nikos> AmeliaBR: There's a way to host on github pages directy from master - for us it makes sense to just do this
20:52:44 <nikos> Topic: TPAC meeting plans
20:52:55 <nikos> https://github.com/w3c/svgwg/wiki/TPAC-2016-Agenda
20:53:08 <nikos> nikos: We plan to meet for a single day on Thursday
20:53:29 <nikos> ... hopefully we'll have someone from web platform tests
20:53:53 <nikos> ... come along to our testing session
20:54:03 <nikos> ... and i've started raising issues regarding testing so keep an eye on those
20:54:21 <nikos> Topic: New charter
20:54:48 <AmeliaBR> https://w3c.github.io/charter-drafts/svg-2016.html
20:55:00 <shepazu> https://w3c.github.io/charter-drafts/svg-2016.html
20:55:16 <nikos> Tav: how do things like the stroking spec fit into this?
20:55:28 <nikos> AmeliaBR: we are probably not going to get substantial work done on them
20:55:56 <nikos> nikos: one thing we may want to do is publish new working drafts with status updates
20:56:11 <AmeliaBR> https://svgwg.org/
20:56:25 <nikos> https://svgwg.org/specs/markers/
20:56:32 <nikos> https://svgwg.org/specs/paths/
20:56:37 <nikos> https://svgwg.org/specs/strokes/
20:58:25 <nikos> shepazu: they've all been published as FPWD. Why did we split them out?
20:58:34 <nikos> nikos: Mainly as a holding ground for features removed from SVG 2
20:59:00 <nikos> shepazu: there's two reasons for modularity - incremental change and reusability
20:59:30 <nikos> ... so they provide incremental change and we don't reference them from svg 2?
20:59:41 <nikos> AmeliaBR: yes - they are planned to replace the chapters for svg 2
21:00:35 <nikos> shepazu: are these specs planning to be reused in css or anything else?
21:00:56 <nikos> Tav: markers is more organisational - strokes the css group is interested in
21:01:17 <nikos> AmeliaBR: paths could be general and reused by svg, css, and canvas
21:01:54 <nikos> shepazu: is it reusable by css and canvas the way it's written now?
21:02:00 <nikos> AmeliaBR: right now it's written for svg
21:02:26 <nikos> shepazu: so if we were going to make it as a stand alone spec - we would have to do that
21:03:34 <nikos> ... are we planning on having them as seperate deliverables permanently? or is it something that should be folded back into svg 3?
21:03:42 <nikos> AmeliaBR: my goal is to make svg 3 modular
21:04:18 <nikos> nikos: I agree that's a good plan - and generally I think that was the working groups plan
21:04:26 <nikos> Tav: agree - that was what we'd talked about before
21:04:52 <nikos> shepazu: that may require some substantial rewriting because of the way the chapters are linked together
21:05:39 <nikos> shepazu: ok I'll add these to the charter
21:07:17 <nikos> ... but note that they are not the priority for the svg 2 timeframe
21:07:29 <stakagi> I would like to, still pursue feasibility of Levels of details.
21:08:36 <nikos> shepazu: is there a draft spec for Level of details? Before we add a spec to the charter for the next year we really need to have a draft published
21:08:45 <nikos> Tav: how long is this charter period?
21:08:58 <nikos> shepazu: this charter period is one year - intended to get us through the publication of svg 2
21:09:33 <nikos> ... we're not doing things in this charter period for svg 3
21:10:52 <nikos> ... the degree to which we get stuff done this year will inform w3c management about how feasible continued work by the svg wg will be
21:11:29 <nikos> ... I think zoom and level of details is useful, but right now we don't have anybody actively editing it so I didn't include it
21:11:47 <nikos> ... that's not to say you can't work on it
21:12:07 <nikos> ... if you put together a spec over the year then it could be included in the next charter
21:12:28 <nikos> ... this charter is just a placeholder for continuing the work that we're actively doing right now
21:13:21 <nikos> ... I don't want to put things in scope for this charter unless we have a spec that is being actively worked on
21:13:48 <nikos> ... some fx specs that we're not so active on are included because the css wg is working on them and it's listed in their charter
21:16:14 <nikos> nikos: is that acceptable takagi-san? You are most welcome to continue work on level of detail. We just won't plan it as a deliverable over the next year. But the group will recharter in one year or perhaps sooner.
21:17:39 <nikos> Topic: 'typographic character' should mention grapheme clusters
21:17:44 <nikos> https://github.com/w3c/svgwg/issues/262
21:17:57 <nikos> nikos: this is basically about where we have a definition in the svg 2 spec
21:18:12 <nikos> ... but there's also a definition in css
21:18:47 <nikos> ... so my thoughts are that we should totally remove the definition from svg 2 and have one definition in css
21:18:58 <nikos> Tav: I don't like that idea because it makes reading the spec harder
21:19:11 <nikos> ... I wouldn't mind saying the normative definition is in css
21:19:34 <nikos> ... there is a link to the css definition there
21:20:07 <nikos> nikos: in that case I think we should format the definition as a note rather than a normative block of text
21:21:47 <nikos> ... could we have two sections - css definitions used in this chapter (which is non normative)
21:21:54 <nikos> ... with a second section for new definitions
21:22:14 <nikos> AmeliaBR: I like the idea of having a definition in svg, with a link to the normative definition in css
21:22:40 <nikos> ... could be as simple as saying 'as defined in ... '
21:22:50 <nikos> Tav: so looking at 'character' - is that ok?
21:22:52 <nikos> AmeliaBR: yes
21:23:03 <nikos> nikos: it's more an issue where we've copied blocks of text from css, but not grabbed the whole definition
21:24:12 <nikos> ... so lets keep the definitions but make it clear that css is the normative definition. we can tidy up the writing to clarify this
21:24:23 <nikos> Topic: * UTF-16 code points for addressable characters
21:24:29 <nikos> https://github.com/w3c/svgwg/issues/259
21:25:03 <nikos> so this one is backwards compatibility issue? We agree and we know the issue exists, but we're sticking with backwards compatibility with svg 1.1
21:25:07 <nikos> Tav: it's more it was defined in dom 2
21:25:21 <nikos> ... it's not that we decided to use utf 16 code units, but dom 2 did
21:25:43 <nikos> AmeliaBR: and it's not something we can change because it could break content
21:25:51 <nikos> ... it would be nice to have some sort of switch
21:26:04 <nikos> Tav: i wonder how much utf 16 is used
21:26:24 <nikos> AmeliaBR: it doesn't matter how the encoding is - it takes whatever encoding you use, and it counts it as if it were utf 16
21:26:45 <nikos> ... so if you've got something where you're positioning emoji that are multi byte you're going to have extra numbers in the dx,dy string
21:28:38 <nikos> Tav: not sure what is meant by surrogate character
21:29:02 <nikos> nikos: that would be a character that depends on another - say an accent that's defined with a second code point but can't be split from it's dependent
21:29:27 <nikos> nikos: Tav are you happy to go through these issues and do editing where we need to?
21:29:28 <nikos> Tav: yes
21:30:40 <AmeliaBR> https://github.com/w3c/svgwg/issues/273
21:30:54 <nikos> Topic: Inline-blocks in text
21:31:10 <nikos> AmeliaBR: we don't support inline block layout so that has potential for a situation where we don't have a defined behaviour
21:31:38 <nikos> Tav: we were going to hold that off for a future version
21:31:39 <AmeliaBR> https://github.com/w3c/svgwg/issues/275
21:35:55 <stakagi> Mr. Shimizu of my substitute will attends svgwg TPAC.
21:36:29 <nikos> RRSAgent, make minutes
21:36:29 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/15-svg-minutes.html nikos
21:44:21 <chaals> has anyone *tested* using system-language switches with title elements?
21:45:00 <chaals> (given the weak support for title especially in accessibility APIs, and rubbish support for desc, I'm not hopeful of a lot…)
21:49:48 <AmeliaBR> chaals: I haven't heard of anyone starting implementation of language switches for title.  (Although general title support is getting much better!)  I nonetheless suggested that it should still be a priority for the  SVG Accessibility test suite, in the hopes of fostering some test-driven development.
21:51:04 <AmeliaBR> Or did you mean using the actual systemLanguage attribute from switch, instead of lang?
21:52:18 <AmeliaBR> Like <path><title><switch><a systemLanguage="fr">Bonjour</a><a systemLangauge="en">Hello</a></switch></title></path>
21:52:54 <chaals> Yes I meant the actual attribute.
21:53:07 <chaals> But no worky in FF/WK/Gecko here.
21:53:16 <chaals> s/Gecko/blink
21:54:51 <chaals> Sigh.
21:55:37 <AmeliaBR> Yeah, my switch demo gives me BonjourHello with various amounts of whitespace, on all browsers: http://jsbin.com/luneninoyu/1/edit?html,output
21:56:38 <chaals> Hmm. You're doing better than me.
21:56:46 <AmeliaBR> (Fixing the typo doesn't change results: http://jsbin.com/luneninoyu/2/edit?html,output )
21:57:10 <chaals> I had <switch><title systemLanguage="ru"> etc etc and got nothing at all.
21:58:23 <AmeliaBR> Yes, in that case the title would be the title of the <switch>, but the switch has no rendered content.
21:58:53 <chaals> well, its in a rect.
21:58:56 <chaals> But no worky.
21:59:27 <AmeliaBR> Are you trying to think of a polyfill / fallback for multilingual title?
21:59:42 <chaals> inside the switch nothing comes out, without the switch I get the first title, which is systemLanguage="zh" … just to make sure it isn't something I might accidentally have set somewhere.
21:59:43 <AmeliaBR> Currently, you'd have to duplicate and switch the entire shape.
22:00:50 <chaals> That's not how I read it.
22:01:04 <chaals> checks the chidren, renders the first one that evaluates true.
22:01:11 <chaals> read the switch element I mean.
22:02:12 <AmeliaBR> "renders" We're not talking about rendered content, though.  title/desc have a special relationship with their immediate parent.
22:02:49 <AmeliaBR> I mean, it would have been lovely if it had been clearly spec'd that way, but it wasn't clear, and the decision was to come up with a new, simpler mechanism (without the extra <switch> element) instead.
22:03:52 <chaals> Hmm. I think that was the wrong decision - and the switch element should be as unnecessary as it is for text - but I was a bit late to enjoy that party :S
22:04:13 <chaals> And I don't think it was mind-bogglingly wrong. Either approach can work.
22:04:37 <chaals> so time to get back under my rock for real.
22:05:26 <AmeliaBR> You're just running away and hiding so we don't assign you tests to write...
22:07:11 <chaals> You might think so. I couldn't possibly comment.
22:07:43 <chaals> And if I did it would be to point out that assigning me tasks related to SVG is often a recipe to go slower, not faster ;(
22:30:25 <shepazu> shepazu has joined #svg