SVG Working Group Teleconference -- 25 Jul 2013

<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