W3C home > Mailing lists > Public > www-svg@w3.org > February 2012

Minutes, 9 February 2012 SVG WG telcon

From: Erik Dahlstrom <ed@opera.com>
Date: Thu, 09 Feb 2012 22:42:03 +0100
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.v9fk8dpqgeuyw5@mbp-2.local>
Minutes:

     http://www.w3.org/2012/02/09-svg-minutes.html

and as text:

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

09 Feb 2012

    [2]Agenda

       [2]  
http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0064.html

    See also: [3]IRC log

       [3] http://www.w3.org/2012/02/09-svg-irc

Attendees

    Present
           +1.415.832.aaaa, heycam, ed, krit, Tav, Doug_Schepers,
           cabanier, +61.2.980.5.aacc, cyril

    Regrets
    Chair
           Cameron

    Scribe
           ed

Contents

      * [4]Topics
          1. [5]SVG attributes to presentation attributes
          2. [6]SVG2 Requirements
          3. [7]the 'focusable' attribute
          4. [8]focusHighlight attribute
          5. [9]focus API
          6. [10]key events
          7. [11]SVGRotate event
          8. [12]svg attributes to presentation attributes
      * [13]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 09 February 2012

    <krit> thanks

    <krit> Zakim: help

    <krit> Zakim: +1.415.832.aaaa is me

    <scribe> scribeNick: ed

SVG attributes to presentation attributes

    Dirk: Microsoft wanted to attend for this discussion too, we can
    postpone it

SVG2 Requirements

    CM: the audio element

    <heycam>
    [14]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#t
    he_.3Caudio.3E_element

      [14]  
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Caudio.3E_element

    CM: we've already resolved for audio and video
    ... just copy that to here

    ED: yes

    <heycam>
    [15]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#i
    nitialVisibility

      [15]  
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#initialVisibility

    CM: initalvisibility
    ... remind me, what's it for?
    ... controlling visible before data is downloaded?
    ... control media elements' display before the duration has stared
    ... opera does this?

    ED: don't think so

    CM: seems simple

    <heycam>
    [16]http://www.w3.org/TR/SVGMobile12/multimedia.html#initialVisibili
    tyMediaAttribute

      [16]  
http://www.w3.org/TR/SVGMobile12/multimedia.html#initialVisibilityMediaAttribute

    "The 'initialVisibility' attribute applies to visual media elements
    ('video' and 'animation') and is used to control the visibility of
    the media object before its first active duration period has
    started."

    CM: to me it doesn't seem that useful to bring across,

    Dirk: do we have this in 1.1?

    CM: no, audio and video are not in 1.1

    ED: is there anything similar in html5 video?

    Dirk: i think so
    ... there's a poster attribute

    <krit>
    [17]http://dev.opera.com/articles/view/introduction-html5-video/

      [17] http://dev.opera.com/articles/view/introduction-html5-video/

    Dirk: and shows first frame of video if poster not available

    CM: don't think we need the initalVisibility attribute

    RESOLUTION: we will not add the initialVisibility attribute to SVG2

    CM: next, Run-time Synchronization attributes

    <krit>
    [18]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
    ommon_attributes

      [18]  
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Common_attributes

    <heycam>
    [19]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#R
    un-time_Synchronization_attributes

      [19]  
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Run-time_Synchronization_attributes

    CM: cyril would probably have an opinion on this

    "These attributes are: syncBehavior, syncBehaviorDefault,
    syncTolerance, syncToleranceDefault and syncMaster."

    Dirk: we wanted to specify some means of synchronizing across media,
    yes?

    CC: yes i think it's useful, for subtitles e.g
    ... to have them synchronized

    Dirk: subtitles for video and audio?

    CC: if you get subtitles from a different server, you can have an
    <animation> element and synchronize them with these attributes

    Dirk: there's also the track elements in html5, for subtitles
    ... why wouldn't you want to bind it to a specific video element?

    CC: don't they have to be same-origin?
    ... the track are in the same file, no?

    Dirk: no, they're separate files, not sure if they have cross-origin
    restrictions though

    CC: ok, yes you are right, track can point to anything

    CM: in html5 video, what kind of synch do you get?
    ... can you control it at all?

    Dirk: no, they're always synched with the videop

    CC: if you have subtitles and video from different servers coming in
    at different rates, you can lock the synch with the runtime synch
    attributes in svg

    Dirk: video synch is a good usecase, but subtitles are always
    synched to the video

    CM: right, but if they're slow from one site, e.g to pause the video
    if the subtitles are not loaded quickly enough

    Dirk: I think this should be handled by html5

    DS: agree
    ... if subs aren't downloaded on time they're synched to the
    timeline when available, they shouldn't get out of synch
    ... we shouldn't try to solve this if other groups are already
    working on this

    CM: what is the current state of synch of audio/video in html5
    ... synch between two video elements e.g

    Dirk: you'll have to do that yourself with script

    DS: right, there's no way to do it otherwise in html5
    ... don't think we should try to solve that in svg
    ... keep this around, but don't try to solve this in svg exclusively
    ... should be solved in the larger case, and svg shouldn't be
    different
    ... otherwise it won't get implemented

    CM: agree with that concern

    DS: we say html5, but we're talking about the platform
    ... we should keep the requirement, but push this upwards to
    something that needs to be solved for multimedia
    ... have had discussions with Apple about synchronization
    ... they should be in on the conversation
    ... many media companies that wan't to solve this for the web

    CM: CC does this sound ok?

    CC: i would really want the feature, but I don't really care how
    it's done
    ... you might want to synch with an animation
    ... a motionpath
    ... and then you want the motion to follow something in a video

    DS: we should push the requirement up...

    CC: so let the it be handled by another WG?

    DS: yes
    ... maintain the requirement, but that we're fine resolving it
    higher up the web stack

    RESOLUTION: svg2 should have synchronization support from somewhere
    in the web platform

    CM: the 'focusable' attribute

    <cyril>
    [20]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#t
    he_.27focusable.27_attribute

      [20]  
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27focusable.27_attribute

the 'focusable' attribute

    CM: so ED you said in your comment that 1.1 is unclear, and I agree
    ... but i'm not sure about the attribute itself
    ... who implements this?

    ED: Opera and IE9 I think

    CM: concern is that it's different from html5

    <heycam> [21]http://dev.w3.org/csswg/css3-ui/#keyboard

      [21] http://dev.w3.org/csswg/css3-ui/#keyboard

    DS: svg got focusable from CSS UI
    ... but it might have been dropped from CSS3 UI

    CM: no, still seems to be there
    ... i'm fine with the requirement to be able to control focusability

    DS: have been pinged about this offlist by accessibility folks
    ... since svg doesn't have focusable support
    ... we should have a focusing mechanism that is compatible with the
    rest of the web platform
    ... might be nice to have a css proeprty for if something is
    focusable or not
    ... don't think we've solved the problem for the web platform
    ... tab-index is doing two things at once
    ... it's not a great solution for svg content
    ... it's inadequate, our focusability solution is better
    ... don't think we should simply follow what html does here, because
    it's not necessarily appropriate
    ... but whatever we decide to do, should apply to the whole wbe
    platform

    CM: you can use tabindex=-1

    <krit>
    [22]http://viewplus.com/downloads/htmltests/accessibility/focus-even
    ts.xhtml

      [22]  
http://viewplus.com/downloads/htmltests/accessibility/focus-events.xhtml

    Dirk: ok, this example shows focusable support, works in webkit and
    opera

    ED: yes, this uses implicit focusability (as defined in the spec,
    the default is focusable=auto)
    ... the focusin/out event listeners make the elements focusable

    RESOLUTION: svg2 will have a solution for specifying focusability
    and navigation order, and be consistent with html

    CM: next one, navigation properties, we covered that by the previous
    resolution

focusHighlight attribute

    CM: i think this should be left up to content, like :focus or that
    sort of thing

    DS: i think you're right
    ... don't know if we resolved about the outline property
    ... we should resolve to have outline in svg as well

    CM: so to turn off the border for focus in html, you do something
    like :focus { outline: none }

    ?

    DS: it should work like in html

    Dirk: is this related to hit testing in any way?

    CM: think that's separate

    DS: suggest that svg2 has a web-consistent focus highlight mechanism
    that relies on css

    ED: or with svg?

    DS: right, you can turn off default focus and get your own shape as
    showing the focus, e.g some special outline, then you could use
    script and css to hide and show those at the approproiate time
    ... there should be an easy default solution (probably just an
    outline)

    CM: so let's agree to be able to control this

    RESOLUTION: svg2 will have a mechanism for controlling focus
    indication, consistent with css and html

focus API

    dirk: we have a resolution to do this the html way

    CM: agree with ED's comment in the table

    RESOLUTION: svg2 will support an API to control focus consistent
    with html

key events

    Dirk: don't we have this already?

    CM: we should just depend on the right specs to get this, we
    shouldn't need to define this ourselves

    CC: put it becuase it's different in 1.2T and 1.1

    DS: right, because 1.2T added key events
    ... but what 1.2T did was to subset what was in dom 3 events

    RESOLUTION: svg2 will have support for key events from DOM Level 3
    Events

SVGRotate event

    CM: what did we decide with zoom and pan?

    CC: not sure why i put only svgrotate and not svgzoom and pan

    CM: this is just the event, if you change the dom property
    ... or rotate in some other way
    ... but if we decided to not have the zoom and pan gesture things,
    then maybe it doesn't make sense to have the event

    DS: i think we should have events for zoom, pan and rotate
    ... adn that they are enableable individually
    ... the zoomAndPan attribute should be split out

    CM: so we decided to not have a built in widget for zoom and pan

    CC: right, but we decided to make it easy to make widgets for
    zooming and panning
    ... we decided to accept the API, but not require UA widgets for it

    DS: you could do it with the component model
    ... to me it makes it more important that we expose these things
    (SVGRotate)

    CM: the zoomAndPan attribute is for contorlling the built-in
    functionality for zooming and panning
    ... SVGRotate, is dispatched in tiny1.2 when you set currentRotate
    or when the UA rotates the svg

    DS: there might be UAs that allow rotating, or panning, or
    zooming... and you want to let content authors control whetehr they
    want this
    ... nonscalingstroke
    ... and transform=ref(svg)

    CM: you can prevent events from being dispatched

    DS: true

    CM: before or after things happen

    DS: that's scripted, but it's a reasonable solution

    CM: does Opera support currentRotate?

    ED: would have to check the code, the web support docs don't mention
    it

    CM: what are the events for the others? svgscroll?
    ... yes, SVGScroll, SVGResize, and SVGZoom
    ... don't liek them because they're different from the standard ones
    ... but for rotate yes, there's no similar event
    ... i don't mind having SVGRotate

    CC: can we resolve then?

    CM: everyone ok with this?

    (silence)

    RESOLUTION: svg2 will have an SVGRotate event

    <krit>
    [23]http://www.w3.org/Graphics/fx/wiki/SVG_attribute_to_presentation
    _attribute

      [23]  
http://www.w3.org/Graphics/fx/wiki/SVG_attribute_to_presentation_attribute

svg attributes to presentation attributes

    Dirk: presentation attributes use their own stylesheet, called it
    presentation attributes stylehseet
    ... then inline stylesheet
    ... external stylesheet, document stylesheet

    CC: inline is the style attribute?

    Dirk: yes
    ... svgdom has the base and animated value
    ... base value points to presentation attribute stylersheet
    ... but animation congtrols the override stylesheet
    ... so overrides computed style
    ... noramlly animated attributes control the override styles
    ... but we can't do that for current svg attributes

    can someone point to where in the wikipage we are?

    dirk: don't think override styles are the correct way of doing this

    CM: does css animation say to have a stylesheet in there?

    dirk: no it doesn't

    <krit> [24]http://dev.w3.org/csswg/css3-animations/

      [24] http://dev.w3.org/csswg/css3-animations/

    dirk: go down, intrinsic styles and the ?? style
    ... what we have now is computed style
    ... the animation style is between the computed style and the ??
    style

    CM: seems natural to have a stylesheet for this

    dirk: css wants to keep smil separate

    CM: still preferable to override style

    dirk: yes, but you want the svgdom to represent the animated value
    ... but override style is in conflict
    ... you can say you have something like override style, after the
    computed style, taht's one solution
    ... everyone agree that we have one stylesheet for smil animation?

    CM: yes, agree that the smil animation values to go somewhere other
    than the override stylesheet
    ... that they should go somewhere else

    dirk: so where in the cascade?
    ... would choose right before computed style

    CM: talking about the position in the stack?

    Dirk: the picture is for css animation
    ... css don't want css animation and smil animation using the same
    stylesheet, to avoid conflicts
    ... aslo talked to patrick and he thought we should put the smil
    animation right after the presentation attributes styles
    ... problem with that is that any new style would override the ...
    animation
    ... smil animation would run, but nothing would show on the screen

    CM: agree
    ... even normal css styles would override the animation
    ... which isn't good

    dirk: so outting it before or after the override stylesheet?

    CM: doesn't override stlyes affect the final values?
    ... or the used values?
    ... after you get the computed value, maybe override styles affect
    that final values
    ... if you get computed style, would that be the animated value?
    cause i think it should
    ... so above the computed stylesheet

    dirk: so between computed styles and ???
    ... either before css animation or after
    ... not sure how it's implemetned at the moment

    CM: do you think it's reasonable to let getComputedStyle be the
    animated values?

    dirk: i think that would make sense
    ... still a question how to combine, first smil then css animation,
    or the other way around?

    CM: no strong opinion atm
    ... we can look at what implementations do
    ... would you expect there to be a separate stylesheet vs ... by
    style animation?

    dirk: for animVal I would expect to get a combination of css
    animation and smil animation, what you see on screen
    ... good idea to look at implementations first

    <scribe> ACTION: dirk to investigate how implementatons prioritize
    smil vs css animations of the same property [recorded in
    [25]http://www.w3.org/2012/02/09-svg-minutes.html#action01]

    <trackbot> Created ACTION-3237 - Investigate how implementatons
    prioritize smil vs css animations of the same property [on Dirk
    Schulze - due 2012-02-16].

    trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: dirk to investigate how implementatons prioritize smil
    vs css animations of the same property [recorded in
    [26]http://www.w3.org/2012/02/09-svg-minutes.html#action01]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [27]scribe.perl version 1.136
     ([28]CVS log)
     $Date: 2012/02/09 21:35:02 $
      _________________________________________________________

      [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [28] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [29]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/SVG???/SVGZoom/
Succeeded: s/css animation/presentation attributes/
Found ScribeNick: ed
Inferring Scribes: ed
Default Present: +1.415.832.aaaa, heycam, ed, krit, Tav, Doug_Schepers,
  cabanier, +61.2.980.5.aacc, cyril
Present: +1.415.832.aaaa heycam ed krit Tav Doug_Schepers cabanier +61.
2.980.5.aacc cyril
Agenda: [30]http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMa
r/0064.html
Found Date: 09 Feb 2012
Guessing minutes URL: [31]http://www.w3.org/2012/02/09-svg-minutes.html
People with action items: dirk

      [30]  
http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0064.html
      [31] http://www.w3.org/2012/02/09-svg-minutes.html

    End of [32]scribe.perl diagnostic output]

      [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Thursday, 9 February 2012 21:41:45 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:50 GMT