IRC log of svg on 2016-09-15

Timestamps are in UTC.

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