<stakagi> hi!

<shepazu> SVG published as CR! https://www.w3.org/TR/SVG2/

<scribe> scribe: nikos

<scribe> scribenick: nikos

SVG 2 CR publication update

<stakagi> Congratulations!

shepazu: yay!
... I've started reaching out to people to help with testing as invited experts
... https://github.com/karip

<shepazu> https://twitter.com/_hmig

<shepazu> http://w3c.github.io/svgwg/specs/svg-authoring/#new-features-in-svg-2

shepazu: Also I updated the authoring the guide - added foreignObject and this
... it's a loaded question - should we add new features from svg 2 into this authoring guide?

nikos: If you can't author with them yet, do they belong in the authoring guide?

shepazu: that's one of the cons

AmeliaBR: definitely they could be written up as how you can use these features in a progressive enhancement way - a practical guide of where we are now
... things can become dated if discussion is focused on current browser support so we should have a periodic review and update planned

shepazu: it doesn't actually have to be part of the authoring guide

<AmeliaBR> https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/

AmeliaBR: There's a way to host on github pages directy from master - for us it makes sense to just do this

TPAC meeting plans

https://github.com/w3c/svgwg/wiki/TPAC-2016-Agenda

nikos: We plan to meet for a single day on Thursday
... hopefully we'll have someone from web platform tests
... come along to our testing session
... and i've started raising issues regarding testing so keep an eye on those

New charter

<AmeliaBR> https://w3c.github.io/charter-drafts/svg-2016.html

<shepazu> https://w3c.github.io/charter-drafts/svg-2016.html

Tav: how do things like the stroking spec fit into this?

AmeliaBR: we are probably not going to get substantial work done on them

nikos: one thing we may want to do is publish new working drafts with status updates

<AmeliaBR> https://svgwg.org/

https://svgwg.org/specs/markers/

https://svgwg.org/specs/paths/

https://svgwg.org/specs/strokes/

shepazu: they've all been published as FPWD. Why did we split them out?

nikos: Mainly as a holding ground for features removed from SVG 2

shepazu: there's two reasons for modularity - incremental change and reusability
... so they provide incremental change and we don't reference them from svg 2?

AmeliaBR: yes - they are planned to replace the chapters for svg 2

shepazu: are these specs planning to be reused in css or anything else?

Tav: markers is more organisational - strokes the css group is interested in

AmeliaBR: paths could be general and reused by svg, css, and canvas

shepazu: is it reusable by css and canvas the way it's written now?

AmeliaBR: right now it's written for svg

shepazu: so if we were going to make it as a stand alone spec - we would have to do that
... are we planning on having them as seperate deliverables permanently? or is it something that should be folded back into svg 3?

AmeliaBR: my goal is to make svg 3 modular

nikos: I agree that's a good plan - and generally I think that was the working groups plan

Tav: agree - that was what we'd talked about before

shepazu: that may require some substantial rewriting because of the way the chapters are linked together
... ok I'll add these to the charter
... but note that they are not the priority for the svg 2 timeframe

<stakagi> I would like to, still pursue feasibility of Levels of details.

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

Tav: how long is this charter period?

shepazu: this charter period is one year - intended to get us through the publication of svg 2
... we're not doing things in this charter period for svg 3
... 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
... 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
... that's not to say you can't work on it
... if you put together a spec over the year then it could be included in the next charter
... this charter is just a placeholder for continuing the work that we're actively doing right now
... I don't want to put things in scope for this charter unless we have a spec that is being actively worked on
... 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

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.

'typographic character' should mention grapheme clusters

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

nikos: this is basically about where we have a definition in the svg 2 spec
... but there's also a definition in css
... so my thoughts are that we should totally remove the definition from svg 2 and have one definition in css

Tav: I don't like that idea because it makes reading the spec harder
... I wouldn't mind saying the normative definition is in css
... there is a link to the css definition there

nikos: in that case I think we should format the definition as a note rather than a normative block of text
... could we have two sections - css definitions used in this chapter (which is non normative)
... with a second section for new definitions

AmeliaBR: I like the idea of having a definition in svg, with a link to the normative definition in css
... could be as simple as saying 'as defined in ... '

Tav: so looking at 'character' - is that ok?

AmeliaBR: yes

nikos: it's more an issue where we've copied blocks of text from css, but not grabbed the whole definition
... so lets keep the definitions but make it clear that css is the normative definition. we can tidy up the writing to clarify this

* UTF-16 code points for addressable characters

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

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

Tav: it's more it was defined in dom 2
... it's not that we decided to use utf 16 code units, but dom 2 did

AmeliaBR: and it's not something we can change because it could break content
... it would be nice to have some sort of switch

Tav: i wonder how much utf 16 is used

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

Tav: not sure what is meant by surrogate character

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
... Tav are you happy to go through these issues and do editing where we need to?

Tav: yes

<AmeliaBR> https://github.com/w3c/svgwg/issues/273

Inline-blocks in text

AmeliaBR: we don't support inline block layout so that has potential for a situation where we don't have a defined behaviour

Tav: we were going to hold that off for a future version

<AmeliaBR> https://github.com/w3c/svgwg/issues/275

<stakagi> Mr. Shimizu of my substitute will attends svgwg TPAC.

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/progress way/progressive enhancement way/
Found Scribe: nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: nikos Tav stakagi
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Sep/0011.html
Found Date: 15 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/15-svg-minutes.html
People with action items: