See also: IRC log
<trackbot> Date: 09 February 2012
<krit> thanks
<krit> Zakim: help
<krit> Zakim: +1.415.832.aaaa is me
<scribe> scribeNick: ed
Dirk: Microsoft wanted to attend for this discussion too, we can postpone it
CM: the audio element
<heycam> 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> 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> 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> 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> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Common_attributes
<heycam> 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> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27focusable.27_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> 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> 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
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
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
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
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> http://www.w3.org/Graphics/fx/wiki/SVG_attribute_to_presentation_attribute
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> 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 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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0064.html Found Date: 09 Feb 2012 Guessing minutes URL: http://www.w3.org/2012/02/09-svg-minutes.html People with action items: dirk[End of scribe.perl diagnostic output]