- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Fri, 16 Sep 2016 00:05:44 +0000
- To: www-svg <www-svg@w3.org>
https://www.w3.org/2016/09/15-svg-minutes.html
And as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
15 Sep 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2016Sep/0011.html
See also: [3]IRC log
[3] http://www.w3.org/2016/09/15-svg-irc
Attendees
Present
nikos, Tav, stakagi, shepazu, AmeliaBR
Regrets
Chair
Nikos
Scribe
nikos
Contents
* [4]Topics
1. [5]SVG 2 CR publication update
2. [6]TPAC meeting plans
3. [7]New charter
4. [8]'typographic character' should mention grapheme
clusters
5. [9]* UTF-16 code points for addressable characters
6. [10]Inline-blocks in text
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<stakagi> hi!
<shepazu> SVG published as CR! [13]https://www.w3.org/TR/SVG2/
[13] 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
... [14]https://github.com/karip
[14] https://github.com/karip
<shepazu> [15]https://twitter.com/_hmig
[15] https://twitter.com/_hmig
<shepazu>
[16]http://w3c.github.io/svgwg/specs/svg-authoring/#new-feature
s-in-svg-2
[16] 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>
[17]https://help.github.com/articles/configuring-a-publishing-s
ource-for-github-pages/
[17] 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
[18]https://github.com/w3c/svgwg/wiki/TPAC-2016-Agenda
[18] 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>
[19]https://w3c.github.io/charter-drafts/svg-2016.html
[19] https://w3c.github.io/charter-drafts/svg-2016.html
<shepazu>
[20]https://w3c.github.io/charter-drafts/svg-2016.html
[20] 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> [21]https://svgwg.org/
[21] https://svgwg.org/
[22]https://svgwg.org/specs/markers/
[22] https://svgwg.org/specs/markers/
[23]https://svgwg.org/specs/paths/
[23] https://svgwg.org/specs/paths/
[24]https://svgwg.org/specs/strokes/
[24] 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
[25]https://github.com/w3c/svgwg/issues/262
[25] 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
[26]https://github.com/w3c/svgwg/issues/259
[26] 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> [27]https://github.com/w3c/svgwg/issues/273
[27] 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> [28]https://github.com/w3c/svgwg/issues/275
[28] https://github.com/w3c/svgwg/issues/275
<stakagi> Mr. Shimizu of my substitute will attends svgwg TPAC.
Summary of Action Items
Summary of Resolutions
[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, 16 September 2016 00:06:21 UTC