minutes, 25 July 2013 SVG WG telcon

The minutes from this week's SVG WG telcon are below:
http://www.w3.org/2013/07/25-svg-minutes.html

- DRAFT -
SVG Working Group Teleconference
25 Jul 2013

Agenda

See also: IRC log
Attendees

Present
Regrets
Chair
     SV_MEETING_CHAIR
Scribe
     Cyril

Contents

     Topics
         Review of css-fonts-3 LCWD
         review request for css-variables-1 LCWD
         Event definitions in SVG 2
         SVG in OpenType update
         media fragment identifiers
         xml namespace prefix
     Summary of Action Items

<trackbot> Date: 25 July 2013

<scribe> Scribe: Cyril

<scribe> ScribeNick: Cyril
Review of css-fonts-3 LCWD

http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0005.html

heycam: we've received review requests from many specs
... CSS fonts 3
... the new things in there is font variant
... related to SVG fonts in Open Type
... relevant for us, because we turn off ligatures in text paths
... we might want to review it
... has anyone interest in reviewing it ?
... if not, I can review it

Cyril: Chris might be interested in reviewing it

nikos: quickly how is font variant related to SVG in open type

heycam: will talk about that in the next topics

<scribe> ACTION: heycam to review css-fonts-3 LCWD spec and coordinate 
with Chris [recorded in 
http://www.w3.org/2013/07/25-svg-minutes.html#action01]

<trackbot> Created ACTION-3514 - Review css-fonts-3 LCWD spec and 
coordinate with Chris [on Cameron McCormack - due 2013-08-01].

heycam: it's probably a good idea to send an email, saying we had a look 
and have no particular comment
review request for css-variables-1 LCWD

http://www.w3.org/mid/51F05942.2070603@mcc.id.au

heycam: overlap with the SVG Params spec we discussed in the past
... apart from that, shouldn't impact us too much

Cyril: what about the use element and the shadow dom

heycam: I don't think it is related

Cyril: is CSS variables about defining your own property but then it 
follow normal inheritance

heycam: yes, that's right
... we haven't sorted out what we have to do with use and shadow DOM but 
it seems unrelated
... unless someone has an interest, I'm happy to review it and 
coordinate with Doug, as he seems to be the relevant person

<scribe> ACTION: heycam to review css-variables-1 LCWD spec and 
coordinate with Doug [recorded in 
http://www.w3.org/2013/07/25-svg-minutes.html#action02]

<trackbot> Created ACTION-3515 - Review css-variables-1 LCWD spec and 
coordinate with Doug [on Cameron McCormack - due 2013-08-01].
Event definitions in SVG 2

heycam: we had a short discussion on the mailing list about that
... it seems resolved by now

richardschwerdtfeger: the issue in the event section of our spec
... I want to figure out how to reduce it
... the mutation event will be removed from the spec
... but how do we remove them
... do we deprecate them or remove them completely
... that's the first issue

heycam: leaving aside that we don't want to support mutation event, they 
are pretty orthogonal to the spec and shouldn't be defined in our spec 
anyway
... they redefine a lot of thing in our spec
... probably this was an editorial choice

richardschwerdtfeger: we want to try to rely on normal definitions in 
other specifications
... do we want to remove any reference mutation events from our spec

heycam: yes
... there is no specific behaviour for them in SVG

richardschwerdtfeger: the second thing discussed is click vs. activate
... should we remove the activate event and go with the click

Cyril: activate was triggered by Enter

heycam: click events should be dispatched as well with links

richardschwerdtfeger: we have support for keyboard events that we did 
not have before
... I added keyboard events last week
... I referenced the UI event spec, in TR space now

<richardschwerdtfeger> https://svgwg.org/svg2-draft/interact.html#SVGEvents

Cyril: a bit annoying that it is changing from what we had in SVG Tiny 1.2

<richardschwerdtfeger> https://svgwg.org/svg2-draft/interact.html#SVGEvents

richardschwerdtfeger: yes, the DOM 3 Events spec is gone and replaced by 
UI EVents

<richardschwerdtfeger> 
https://dvcs.w3.org/hg/d4e/raw-file/default/source_respec.htm#keyboard-events

Cyril: it is ok with me if it is the stable spec now
... wouldn't like it to change again for SVG 3.0
... is it still possible to start an animation from a key name, like it 
was in SVG Tiny 1.2 ?

heycam: don't know yet
... what's the current thinking on starting an animation with keys

Cyril: my recollection from Brian's explanation is that accessKey 
wouldn't work in some mode, as defined in the SVG integration spec

heycam: looking a DOM 4 Events, I can't see the activate event

richardschwerdtfeger: Doug said that activate was gone indeed

heycam: that means all events from the SVG spec named DOM_* can go

richardschwerdtfeger: there is a DOMFocusIn, DOMFocusout and DOMActivate

<richardschwerdtfeger> 
https://dvcs.w3.org/hg/d4e/raw-file/default/source_respec.htm#

richardschwerdtfeger: you mentionned that we probably want to refer to a 
spec than define it

heycam: I don't like the big table in the interaction chapter
... I don't think that other specs that use DOM events define what click 
means
... I don't know what level of description is required in the SVG spec

Cyril: redefining is bad, but have a short summary of possible events 
with references is useful

richardschwerdtfeger: I will take another look at the event spec
SVG in OpenType update

http://lists.w3.org/Archives/Public/public-svgopentype/2013Jul/0003.html

heycam: Sirus and I have been on working on merging our proposals
... to have a unified proposal to bring to the Open Type people
... Sairus has been working on the editing

<heycam> 
http://lists.w3.org/Archives/Public/public-svgopentype/2013Jul/0003.html

heycam: that's a Word document
... we thought the best approach would be to have the main stuff in the 
Open Type specification itself
... and specific SVG stuff (context ...) in SVG 2
... we probably won't have many normative SVG things
... I'll probably work also on integration in HTML
... one of the issue resolved recently, how to identify that an SVG 
element is used for a particular glyph id
... in our spec we have a glyph id attribute
... in Sairus, he used the id attribute with a particular name

<heycam> id="g4"

<heycam> id="glyph5"

<heycam> we had glyphid="6"

Cyril: wasn't there another option to have a table in Open Type giving 
the mapping

heycam: my concern with using the plain id was to go into author space 
and require specific id
... that was the reason to have a new attribute
... the other option was to map glyph id to names
... but it's probably unnecessary
... in the end, I agreed to use the id attribute with glyph and number

nikos: why was Sairus going to other way?

heycam: he wanted to avoid adding features to SVG when possible
... to not modify the SVG engine when possible

nikos: in a way it's nice to not have in SVG things just used for SVG in 
Open Type

heycam: yes, the specification changes will be small anyway

Cyril: maybe people want to use SVG 1.1 rendering engine as is

heycam: we haven't decided on that
... probably SVG 2 because of the context thing
... the question of profile also hasn't been decided
... the other main difference in that new copy of the spec
... is in the definition of palette
... to be used inside the SVG content

nikos: it wasn't clear in the spec

heycam: there was a proposal from Microsoft to combine multiple glyphs 
and define a color for each glyph
... apparently shipping in MS Windows 8.1
... it's nice but has limitations in what you can do (e.g gradients or 
animations)
... but it had palette
... in the spec at the moment, color 0, color 1, color 2 ... in the font 
as a palette and have multiple palettes
... and in the SVG spec, you can use CSS variables to use the palette
... with names: color0, color1, ...
... the question is how to select which palette
... maybe a font variant or property
... and how do we support custom colors from the outside

nikos: you would need to tknow the number of colors in the font

heycam: yes, similar to other features
... so that's it, please read it and send feedback

nikos: looks pretty good except selecting colors from outside

heycam: yes, needs collaboration from outside
media fragment identifiers

Cyril: I've worked an ACTION 3442

<heycam> action-3442?

<trackbot> ACTION-3442 -- Cyril Concolato to add Media Fragments support 
to SVG 2. -- due 2013-02-14 -- CLOSED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3442

Cyril: and committed some changes to the spec
... would like people to review it

<heycam> https://svgwg.org/svg2-draft/linking.html#SVGFragmentIdentifiers

heycam: is it the same as HTML

Cyril: no, not applicable

heycam: I'm not sure t= would have been valid id anyway
... I have not seen that syntax: * before parenthesis
... what happens when you use Media Fragments has well as SVG view at 
the same time

Cyril: that's possible only if you combine timesegments and svg view

heycam: you cant' have svgView and xywh at the same time

Cyril: right

heycam: ok, not sure what that would mean anyway

The rendering of the SVG Document shall be as if the setCurrentTime 
method on the SVG Document element had been called with the begin time 
value from the fragment identifier

heycam: in MF, is there a way to specify a duration

Cyril: you can specify start and end

Additionally, if an end time value is provided in the fragment 
identifier, the effect is equivalent to calling the pauseAnimations 
method on the SVG Document when the document time reaches the end time 
of the fragment identifier.

Cyril: that part should probably be reviewed by the Web Animation guys

heycam: from a very brief look, that section looks ok
xml namespace prefix

Cyril: I need advice on how to carry ACTION 3412

<heycam> action-3412?

<trackbot> ACTION-3412 -- Cyril Concolato to fix spec to remove need for 
xml namespace prefix -- due 2013-02-10 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3412

http://lists.w3.org/Archives/Public/www-svg/2013Jul/0023.html

<nikos> http://www.w3.org/2012/09/18-svg-minutes.html#item13

heycam: I think the base element prceded the xml:base attribute in the 
HTML spec

Cyril: for xml:lang, in HTML5 it's defined in no namespace and xml:

http://lists.w3.org/Archives/Public/www-svg/2013Jul/0023.html

http://www.w3.org/html/wg/drafts/html/master/dom.html#the-lang-and-xml:lang-attributes

Cyril: xml:space is easier
... we just deprecate it

<heycam> we were going to have a UA style sheet rule that maps xml:space 
to the white-space property

Cyril: we should continue to discuss xml:base by email and for the 
others the action is clear (do as HTML (lang), and deprecate (space))

heycam: yes
Summary of Action Items
[NEW] ACTION: heycam to review css-fonts-3 LCWD spec and coordinate with 
Chris [recorded in http://www.w3.org/2013/07/25-svg-minutes.html#action01]
[NEW] ACTION: heycam to review css-variables-1 LCWD spec and coordinate 
with Doug [recorded in 
http://www.w3.org/2013/07/25-svg-minutes.html#action02]

-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.wp.mines-telecom.fr/

Received on Thursday, 25 July 2013 21:43:56 UTC