- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Fri, 15 Nov 2013 10:11:56 +0100
- To: www-svg@w3.org
Hi,
The group is now created, thank you to those who supported its creation.
People can now join using this link:
http://www.w3.org/community/svgstreaming/
Cyril
Le 15/11/2013 09:38, Cyril Concolato a écrit :
> Hi all,
>
> Following the recommendation of the group, I am proposing a new
> community group to work on SVG streaming. This work will include
> develop guidelines and possible extensions to the SVG language to
> enable the authoring of streamable SVG content. The use cases
> envisaged so far are:
> - streamable cartoons, enabling e.g. web-based vector graphics
> cartoons channels,
> - streamable and synchronized audio and graphics content like
> graphically-rich karaoke,
> - streamable and synchronized graphical annotations overlayed on top
> of videos.
>
> If you are interested to work in this area, please support and join
> this community group:
> http://www.w3.org/community/groups/proposed/#svgstreaming
>
> Cyril
>
>
>
> Le 14/11/2013 10:46, Cameron McCormack a écrit :
>> http://www.w3.org/2013/11/14-svg-minutes.html
>>
>> and below as text:
>>
>>
>> [1]W3C
>>
>> [1] http://www.w3.org/
>>
>> - DRAFT -
>>
>> SVG Working Group Teleconference
>>
>> 14 Nov 2013
>>
>> [2]Agenda
>>
>> [2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2013/Agenda
>>
>> See also: [3]IRC log
>>
>> [3] http://www.w3.org/2013/11/14-svg-irc
>>
>> Attendees
>>
>> Present
>> Huangshan, TabAtkins, Eriik, Brian, Satoru, Fujisawa,
>> Nikos, Doug, Chris, Dirk, Cyril, Rik, Dean, Cameron,
>> Rich
>>
>> Regrets
>> Chair
>> ed
>>
>> Scribe
>> nikos, Cameron
>>
>> Contents
>>
>> * [4]Topics
>> 1. [5]Numeric Precision for SVG
>> 2. [6]Proposals/ResourcePriorities for SVG
>> 3. [7]definition of 'zoom' for zoom media feature
>> 4. [8]SVG accessibility
>> 5. [9]z-index in SVG
>> 6. [10]Using Bikeshed for SVG specs
>> 7. [11]shepherd for svg repo
>> 8. [12]new SVG DOM proposal
>> 9. [13]SVGAnimatedBoolean
>> 10. [14]SVG DOM continued
>> 11. [15]SVGElement implementing global event handlers
>> (onfoo)
>> 12. [16]Is it future-proof to return SVGElement on
>> nearestViewportElement and farthestViewportElement?
>> 13. [17]Animation Elements
>> 14. [18]SVG streaming update
>> * [19]Summary of Action Items
>> __________________________________________________________
>>
>> <nikos> scribe: nikos
>>
>> <ed> scribeNick: nikos
>>
>> <TabAtkins> Yo, we got polycom?
>>
>> <ed> TabAtkins, we're setting it up
>>
>> <TabAtkins> Cool, thanks.
>>
>> <cyril> regarding the agenda, I think it would make more sense
>> to discuss "SVG streaming update" after Brian's "Web Animation"
>> this afternoon
>>
>> <heycam> trackbot, start telcon
>>
>> <trackbot> Date: 14 November 2013
>>
>> <scribe> scribe: nikos
>>
>> <heycam> TabAtkins, we can't call out from here
>>
>> <TabAtkins> For god sakes, Zakim.
>>
>> <TabAtkins> I know that, Zakim.
>>
>> <TabAtkins> We all know that.
>>
>> <TabAtkins> I'll be here the whole time, so don't worry.
>>
>> <TabAtkins> It's 5pm to 2am for me, and I've already done this
>> for 2 days.
>>
>> <TabAtkins> Heh.
>>
>> Numeric Precision for SVG
>>
>> <birtles>
>> [20]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/NumberPrec
>> ision
>>
>> [20]
>> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/NumberPrecision
>>
>> birtles: Takagi-san prepared this wiki page. You can read the
>> issue yourself
>> ... SVG 1.1 only requires single precision floating point
>> ... but for mapping use cases it appears that double precision
>> is neccessary
>> ... what are your thoughts?
>>
>> heycam: We had a meeting recently with all our layout and
>> graphics people
>> ... anytime graphics people heard double precision they cringed
>> ... GPU HW only works in floats
>> ... and it's going to me more and more likely we'll be
>> restricted to floats as we move more into HW
>> ... currently changing graphics library layers and that uses
>> floats
>> ... I feel it'll be difficult to require double precision
>>
>> krit: SVG 1 doesn't require double but allows it
>>
>> heycam: SVG 1 spec has different performance class requirements
>> ... high quality viewer must support double
>> ... I'm wondering how realistic that is now
>>
>> TabAtkins: Takagi-san made a wiki page that describes a
>> requirement for precision of 5 decimal places
>> ... floats have 7 digits
>> ... so why is this a problem?
>>
>> <TabAtkins> s/made a wiki page that has/said on the wiki page
>> that he needs/
>>
>> birtles: I clarified with Takagi-san and if that's the case
>> thats ok
>> ... but tests with IE show that it appears to use fixed point
>> ... with only 3 digits of precision
>>
>> krit: that's true. Firefox is the same
>>
>> heycam: 16.16 fixed point stuff comes from Cairo
>> ... I can't remember the exact plan for software rendering back
>> end
>> ... but we are removing Cairo as the intermediate API layer
>> ... most of the back ends will use single precision
>> ... so perhaps for this use case it will get better in Firefox
>>
>> krit: fixed point is coming from HTML
>> ... It's not a requirement for Skia but Blink is still using
>> fixed point for that
>>
>> heycam: you're talking about for CSS layout?
>>
>> krit: yes
>> ... Since SVG is using the same engine as HTML wouldn't it be
>> the case for both?
>>
>> heycam: I think it could be reasonable to use different code
>> for layout of CSS boxes compared to 2d graphics APIs
>> ... if IE uses fixed point for graphics stuff and CSS layout
>> then perhaps there's some reason for linking the two
>>
>> Rossen__: what were the tests?
>>
>> krit: viewbox with 0.00001 will render differently
>>
>> Rossen__: for CSS values we use fixed point. For SVG we use as
>> much floating point as possible
>>
>> krit: we parse all of CSS values to fixed point
>>
>> Rossen__: we parse SVG to floating point
>>
>> krit: I can write a test
>>
>> heycam: one thing to clarify is whether single precision
>> floating point is enough?
>>
>> birtles: It may be enough to render with single precision but
>> if you parse them as single precision, then by the time you
>> apply transformation matrices you may lose precision
>>
>> <krit> <svg xmlns="[21]http://www.w3.org/2000/svg"
>> xmlns:xlink="[22]http://www.w3.org/1999/xlink" width="800"
>> height="800" viewBox="0 0 0.0000001 0.0000001">
>>
>> [21] http://www.w3.org/2000/svg
>> [22] http://www.w3.org/1999/xlink
>>
>> <krit> <rect width="0.00000005" height="0.00000005"
>> fill="blue"/>
>>
>> <krit> </svg>
>>
>> cabanier: PDF had the same problem
>> ... creating huge maps
>> ... they only had a certain position so edges of the map were
>> rough
>> ... so to solve you translate
>> ... it's an internal engine thing
>>
>> heycam: so the answer is to not have everything in the one
>> co-ordinate system
>>
>> birtles: I don't know how you'd specify it
>>
>> krit: it doesn't need to be specified. It's an implementation
>> detail
>>
>> cabanier: so when you zoom all the way out. fine details may
>> not be right
>> ... it only matters when you zoom in
>>
>> heycam: in reality you have different sources of data,
>> different tiles that are merged
>> ... they're not going to be in the same co-ord system
>> originally
>> ... some of the proposals we've seen before transform them into
>> a common co-ord system
>> ... leaving the data like that and not having one co-ord system
>> seems to be the right thing to do
>> ... when you combine global view and some fine detail - say if
>> you have country path information that can be viewed zoomed
>> out, but if you zoomed into a border town region and look at
>> the roads there, then by the time you do that you have lost the
>> precision of the global view
>> ... maybe different data sources should be used
>>
>> stakagi: that's ok
>>
>> krit: the test case I posted previous shows that IE does
>> support floating point precision and Firefox doesn't
>> ... that will hopefully change in the future
>>
>> ed: so we don't need to make any change?
>>
>> heycam: something to think about when defining conformance
>> classes
>> ... would people be amenable to removing the double precision
>> requirement?
>>
>> krit: for most things in WebKit and Blink we use single
>> precision internally even if API uses doubles
>> ... exception is everything from CSS is still double
>> ... but it's converted to single at some point
>>
>> heycam: I was considering changing webidl to float to match JS
>> ... but it makes sense to leave as float since APIs use that
>> ... I don't think it's a great idea to have different classes
>> that give different results
>> ... especially for path positions
>> ... I'd rather remove it
>>
>> birtles: the whole class?
>>
>> shepazu: CSS resolved to use rfc6919
>>
>> heycam: so these are the things that high quality viewers are
>> meant to do
>>
>> <heycam>
>> [23]https://svgwg.org/svg2-draft/conform.html#ConformingHighQua
>> litySVGViewers
>>
>> [23]
>> https://svgwg.org/svg2-draft/conform.html#ConformingHighQualitySVGViewers
>>
>> heycam: this was written 12 years ago
>>
>> shepazu: I don't think that these are modern constraints
>>
>> heycam: they're the wrong level also
>>
>> shepazu: let's remove this bit compeltely
>>
>> krit: image rendering is specified in CSS
>> ... might not be a good thing to have in SVG
>> ... I would definitely remove point 4
>> ... I would remove it as a requirement to decide if you use
>> high quality or low quality rendering
>>
>> TabAtkins: are you saying people should always respect the
>> image rendering property regardless of mode you're in?
>> ... if so I agree
>>
>> krit: yes
>>
>> shepazu: looking through these, I don't think they're
>> meaningful in today's market
>> ... I don't know who this is written for
>> ... we should just remove it
>> ... if we decide we'll get better performance out of floats
>> rather than doubles
>>
>> krit: I don't think floats or doubles are a good criteria for
>> quality
>>
>> shepazu: all these requirements have that problem
>>
>> <scribe> ACTION: heycam to look at the performance class
>> requirements and decide whether to remove points or move them
>> into general requirements [recorded in
>> [24]http://www.w3.org/2013/11/14-svg-minutes.html#action01]
>>
>> <trackbot> Created ACTION-3535 - Look at the performance class
>> requirements and decide whether to remove points or move them
>> into general requirements [on Cameron McCormack - due
>> 2013-11-21].
>>
>> RESOLUTION: Remove performance class requirements from SVG 2
>>
>> Proposals/ResourcePriorities for SVG
>>
>> [25]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePr
>> iorities_for_SVG
>>
>> [25]
>> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePriorities_for_SVG
>>
>> birtles: Takagi-san prepared this wiki page
>> ... this is about resource priorities spec from web performance
>> working group
>> ... first issue is about the postpone attribute
>> ... and it's currently defined in terms of bounding boxes
>> ... but Takagi-san has some feedback to suggest it would be
>> useful if it could also be used in regards to zooming
>> ... currently says that things with bounding box outside
>> current viewport don't need to be loaded
>> ... but it seems like that would be a good thing for
>> conditionally loading tiles
>> ... We've sent feedback but I don't know if it's been taken on
>> board yet
>>
>> krit: This sounds like a previous discussion on www-svg
>> ... A thread about resource priorities and SVG
>>
>> <shepazu>
>> [26]http://www.w3.org/mid/1383159383.2183.164.camel@chacal
>>
>> [26] http://www.w3.org/mid/1383159383.2183.164.camel@chacal
>>
>> birtles: that's [$1\47] on the wiki page
>>
>> <krit>
>> [27]http://lists.w3.org/Archives/Public/www-svg/2013Nov/0002.ht
>> ml
>>
>> [27] http://lists.w3.org/Archives/Public/www-svg/2013Nov/0002.html
>>
>> <krit>
>> [28]http://lists.w3.org/Archives/Public/www-svg/2013Nov/0003.ht
>> ml
>>
>> [28] http://lists.w3.org/Archives/Public/www-svg/2013Nov/0003.html
>>
>> krit: this was my reply
>>
>> birtles: the proposal is that you would have different tiles
>> (say several iframe elements in svg). For each you would have
>> the postpone attribute
>>
>> <stakagi>
>> [29]http://lists.w3.org/Archives/Public/www-svg/2013Nov/0021.ht
>> ml
>>
>> [29] http://lists.w3.org/Archives/Public/www-svg/2013Nov/0021.html
>>
>> birtles: you would only load the ones within the bounding box
>> and at the right zoom level
>> ... it's not part of one image resource, it's several resource
>> ... the feedback here is that resource priorities only allows
>> you to base the conditional loading on the viewport and the
>> bounding box of the tile
>> ... so it doesn't take into account zoom
>>
>> krit: doesn't the zoom level also influence the viewport?
>>
>> birtles: it's not enough by itself
>> ... you could have several tiles that occupy the 2d space but
>> are at several zoom levels. You don't want to load them all
>> ... the facility to achieve that might be to use media queries
>>
>> krit: I think this discussion would have been better in FXTF
>>
>> birtles: one piece did come up then - it's next on the agenda
>>
>> heycam: If we did have a separate zoom media query, what things
>> about the resource priorities needs to be changed to
>> accommodate this use case?
>>
>> birtles: the way postpone is currently described is purely
>> based on viewport and bounding box
>>
>> heycam: so you want to link it to this future zoom media query
>> as well
>>
>> birtles: I think that's Takagi-san's idea
>> ... I think this is something that we can't decide in this
>> group
>> ... but at least it has helped to clarify the requirements
>> ... text in resource priorities spec doesn't quite align with
>> these use cases
>> ... because it says tjat ot
>> ... that it's bounding box or display:none that defines whether
>> resources are loaded
>>
>> heycam: what about the fact that they're adding attributes to
>> SVG without asking?
>> ... is that an issue? or do we just want to review their
>> changes?
>>
>> krit: I did and initial review but would be happy if others did
>> as well
>> ... right now the spec has more issues with HTML than with SVG
>> ... it's an easy spec to review
>>
>> heycam: I'll have a look to see how it fits with SVG
>>
>> ed: this is basically the same functionality as external
>> resources required functionality of SVG 1.1
>>
>> definition of 'zoom' for zoom media feature
>>
>> [30]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/zoom_media
>> _feature
>>
>> [30]
>> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/zoom_media_feature
>>
>> shepazu: did you see the email from Boeing about zoom and pan
>> and load events?
>>
>> birtles: I think that's a separate issue
>> ... this is something I don't think we need to discuss here
>> because there was discussion in CSS on Sunday
>> ... Takagi-san, myself, and Dean spoke about this later
>> ... Ted from Apple has an action to look at different zoom
>> media queries
>> ... the current ones available aren't sufficient for pinch zoom
>> and such
>> ... Takagi-san has explored other ways a zoom media query could
>> be specified and we've shown this to Dean to pass to Ted
>>
>> TabAtkins: I notice all four of these definitions include scale
>> transforms
>> ... do we have any clue how those work with media features?
>>
>> heycam: so results of media query can't depend on property
>> values because that's cyclic?
>>
>> TabAtkins: yes
>>
>> heycam: there is at least one type of zooming that isn't
>> reflected in the styling
>> ... the pinch zooming and the dot current scale
>>
>> TabAtkins: there might still be a use case for pinch zooming
>> because you're going to want to tell when people are doing that
>> ... things that are trying to do resolution based stuff don't
>> want to respond to pinch zoom but maps, etc would
>>
>> dino: I think it's better they're all separated and
>> individually queryable
>>
>> TabAtkins: that might make sense
>>
>> dino: I think step 1 is to define all the terms
>>
>> TabAtkins: they're defined in CSS OM view and referenced from
>> media queries
>>
>> krit: it might make sense to see if the pinch zooming from SVG
>> is different
>> ... it might be different if you want to pinch zoom in a
>> document without zooming the outer doc
>>
>> Rossen__: how is that different to an iframe?
>>
>> krit: just that SVG isn't an iframe
>>
>> Rossen__: should generalise that behaviour
>> ... shouldn't apply just to SVG but to all elements
>>
>> heycam: that was how I thought we might be able to do zoom and
>> pan
>>
>> shepazu: is SVG a special kind of content in HTML? A class that
>> both SVG and iframe fall into?
>>
>> krit: SVG has a viewport
>> ... makes it easier to define pinch and zoom
>>
>> birtles: Also when you have SVG loaded in an iframe and the
>> parent doc is being zoomed that information also has to be
>> available to the SVG
>>
>> krit: should be possible with media queries
>>
>> heycam: do you need to know individual transforms in the stack?
>>
>> stakagi: probably yes
>> ... seems likely not not totally sure at the moment
>>
>> <birtles> actually, not the individual transforms, but the
>> combined result
>>
>> birtles: Next step is to see what Ted comes up with
>> ... and provide feedback
>>
>> <scribe> ACTION: heycam to review Resource Priorities
>> specification [recorded in
>> [31]http://www.w3.org/2013/11/14-svg-minutes.html#action02]
>>
>> <trackbot> Created ACTION-3536 - Review resource priorities
>> specification [on Cameron McCormack - due 2013-11-21].
>>
>> Topics: Should parsed unknown elements implement SVGElement?
>>
>> [32]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23468
>>
>> [32] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23468
>>
>> <TabAtkins> Yes.
>>
>> ed: when you parse elements that SVG doesn't know about but
>> that are in the SVG namespace
>> ... it seems that all browsers put SVGElement interface on
>> those elements
>> ... rather than Element or SVGUnknownElement
>> ... which would be similar to HTML
>>
>> krit: if we define one of these elements later it starts
>> rendering for all content
>> ... I don't think this is an issue
>> ... in this case since browsers already have behaviour, we
>> should just specify it
>>
>> ed: so just specify that SVGElement should be used in this
>> case.
>>
>> heycam: is there any advantage to doing things the HTML way?
>>
>> shepazu: right now they're put in the SVG namespace
>>
>> heycam: SVGElement has some things. e.g. nearest viewport
>>
>> but SVGUnknownElement will inherit from SVGElement anyway
>>
>> scribe: the only argument is for consistency with HTML
>>
>> shepazu: the advantage I see is if you're trying to detect
>> whether a browser supports a particular - say star
>> ... if the user agent doesn't know what to do with star, it
>> might be nice to know that the UA doesn't know what to do with
>> it
>>
>> heycam: I think you can do that anyway because you can check
>> object.getPrototypeOf the dom node
>> ... that would return a specific sub type
>>
>> <TabAtkins> (el instanceof SVGElement) && (el.prototype ==
>> SVGElement.prototype) { /* Unknown element! */ }
>>
>> shepazu: what about if it's an element of another namespace?
>>
>> krit: if we decide to put every element into the HTML namespace
>> then SVG elements will use HTMLElement and HTMLUnknownElement
>>
>> heycam: I think it depends on how we handle the parsing of that
>> ... as long as you get the outer thing - SVG or graphics in my
>> proposal
>> ... if you're in that mode you can put the unknown ones in
>> whatever
>>
>> shepazu: seems to me the only element that I expect (besides
>> new SVG elements) to add that might cause problems is the HTML
>> element
>>
>> <TabAtkins> +1
>>
>> shepazu: straw poll, who would like us to allow HTML root
>> element without the foreignObject wrapper
>>
>> <TabAtkins> +1
>>
>> shepazu: so will this cause problems in that context?
>>
>> Rossen__: in this context inline content is treated how?
>> ... I mean text in SVG
>>
>> <TabAtkins> <svg>foo</svg>?
>>
>> <Rossen__> <svg>Hello World</svg>
>>
>> <krit> <svg>More examples</svg>
>>
>> Are you saying first example is different to second example?
>>
>> <Rossen__> <svg><span>Hellow World</span></svg>
>>
>> <TabAtkins> Yes, different.
>>
>> shepazu: yes that would be different
>>
>> <TabAtkins> <span> makes HTML element. Raw text is just
>> ignored.
>>
>> shepazu: do we need the HTML root?
>> ... All i was proposing was that the HTML tag be required to
>> insert HTML content
>>
>> Rossen__: I misunderstood
>>
>> krit: I suggested HTML in SVG without the HTML tag
>> ... just needs a viewport
>>
>> shepazu: who is going to do this?
>>
>> TabAtkins: I'll do it
>>
>> shepazu: the question is whether it causes us problems
>>
>> heycam: depends how we do parsing and namespaces and so on
>> ... but should be able to test whether an element is recognised
>> or not in any case
>>
>> shepazu: I wonder if inserting SVG dynamically will behave
>> different
>> ... currently in implementations you get different behaviour
>>
>> krit: CreateElement doesn't trigger the parser
>> ... I think what Doug is saying is if you have inner html and
>> you use a rect
>> ... you have to nest it in an SVG element
>>
>> ed: I think we recently added inner html to SVG elements and it
>> does use the context
>>
>> shepazu: Currently if I put an HTML element it's treated as an
>> SVG element
>> ... if we specify the HTML elements as things that go in
>> another namespace
>> ... will there be a hack (not to be specced just to be
>> considered) to allow developers to get what they expect in
>> older UAs
>> ... I'll do some testing
>> ... my only concern is that specific case of what happens when
>> there's the bare name HTML
>> ... For the original question, let's specify what browsers are
>> already doing
>>
>> RESOLUTION: We will spec what browsers are currently doing -
>> use SVGElement interface for unknown elements.
>>
>> <ed> -- break until 11am --
>>
>> <TabAtkins> The conf was only for 1 hour, maybe zakim doesn't
>> want to let new people in?
>>
>> <birtles> scribenick: birtles
>>
>> SVG accessibility
>>
>> gcapiel: I lead engineering at Benetech
>> ... for Benetech we have a few projects were accessibility is a
>> big projects
>> ... including bookshare
>> ... which is a very large library of accessible books
>> ... we also have a project which is in collaboration with DAISY
>> and NCAM
>> ... we are working on "diagram center"
>> ... we are focussing on, "How do we lower the cost of creating
>> accessible images?"
>> ... "What standards do we need to achieve that goal?"
>> ... we want accessible images in e-books and across the open
>> web
>> ... I'm in the digital publishing group composed of people from
>> the book publishing industry
>> ... we have some representatives around accessibility
>> ... and some w3c staff
>> ... as part of that we've been working to identify gaps in the
>> open web platform that publishers need
>> ... I've been focussing on accessibility
>>
>> <gcapiel>
>> [33]http://www.w3.org/dpub/IG/wiki/UseCase_Directory#General_Ac
>> cessibility_Use_Cases
>>
>> [33]
>> http://www.w3.org/dpub/IG/wiki/UseCase_Directory#General_Accessibility_Use_Cases
>>
>> gcapiel: it's tricky because you really need to accessibility
>> for everything
>> ... not just ebooks
>> ... the link above is a set of use cases I'll walk through
>> ... the first use case is about rendering mathematics using SVG
>> instead of MathML
>> ... MathML support is either missing or inconsistent
>> ... it's not clear when that issue will be resolve
>> ... so what publishers are doing is using images (esp. PNG and
>> JPEG)
>> ... they do that because inexpensive devices like kindle don't
>> support mathml at all
>> ... some of those devices don't support SVG either but some do
>> ... so we're not going to be able to get publishers to push out
>> MathML in the near future but we can do better than bitmaps
>> ... so we've been looking at using MathJAX on the server using
>> Node.js to convert MathML to SVG
>> ... that also lets us work with open-source technology and
>> using ChromeVox, Google's screen reader technology
>> ... using that tool, you can feed it MathML and get back both
>> SVG and a description of that math
>>
>> heycam: is it a problem that Blink is dropping MathML support?
>>
>> gcapiel: no it's not really since it's still in the DOM
>> ... even if it's not rendered
>> ... I've been thinking about how we can improve this situation
>> and one thing we could do is add the source MathML in the SVG
>> ... that would allow screen readers to pick it up
>>
>> <richardschwerdtfeger> q
>>
>> gcapiel: the problem with the textual description is that the
>> cognitive load of hearing it all is significant--you really
>> need to be able to navigate the mathml
>> ... one more thing, Rich was involved in adding tabindex to SVG
>> which is great
>> ... but I think there may be uses for that with math too
>> ... so you can navigate the tree
>>
>> richardschwerdtfeger, one of the things I asked for was to have
>> direct access to the mathml
>>
>> scribe: are you suggesting embedding it in the SVG?
>>
>> gcapiel: yes, that's what I'm suggesting
>>
>> richardschwerdtfeger: makes sense
>>
>> gcapiel: the last requirement I would add around that is that
>> mathml that renders visually nicely, often doesn't have enough
>> semantics for a screen reader
>> ... for example, you might need additional parentheses
>>
>> heycam: is that because people generally write presentational
>> mathml not content mathml
>>
>> gcapiel: yes, content mathml hasn't really gone anywhere
>> ... we've been putting work into how to use crowdsourcing to
>> improve the accessibility of existing math content
>> ... and have had a lot of success
>> ... but often they don't have access to the source or the web
>> server
>> ... so we'd like to take an annotation approach where you can
>> just, for example, add parentheses or overwrite the textual
>> description
>> ... the screen reader would notice this URI and pull down the
>> additional annotations from the cloud
>> ... so it would be great if there was a standard way for
>> marking up those URIs
>>
>> heycam: I have some practical questions about how to markup
>> MathML in the SVG spec so I might get your help on that later
>>
>> gcapiel: yes, of course.
>> ... aria-describedby might help with this
>>
>> richardschwerdtfeger: I could help with adding that
>>
>> heycam: do we reference that properly yet?
>>
>> richardschwerdtfeger: yes we do
>> ... is it a problem that ARIA 1.1 is only a FPWD?
>>
>> heycam: I think it's fine for now
>>
>> <scribe> ACTION: Rich to reference ARIA 1.1 in SVG 2 [recorded
>> in [34]http://www.w3.org/2013/11/14-svg-minutes.html#action03]
>>
>> <trackbot> Created ACTION-3537 - Reference aria 1.1 in svg 2
>> [on Richard Schwerdtfeger - due 2013-11-21].
>>
>> krit: putting presentation mathml into SVG, this should already
>> be possible using foreignObject
>> ... with the limitation that you need to specify width/height
>> which is not very convenient
>> ... it would be nice to allow mathml to be included directly
>> but that would require changes to the html parser
>>
>> heycam: might be good to keep in mind when we discuss HTML in
>> SVG later
>>
>> shepazu: that might just fall out of the HTML model
>>
>> heycam: I suspect that MathML names when you're parsing in SVG
>> parsing mode will become SVG elements
>>
>> shepazu: I wonder if that's the case since SVG elements are
>> whitelisted
>>
>> heycam: for case conversion
>>
>> shepazu: in any case it's a kind of whitelisting... it bears
>> investigation
>>
>> krit: if we really want to move MathML names in to the SVG
>> space... that might be a problem
>>
>> heycam: we should consider this when we talk about HTML in SVG
>> later
>>
>> <gcapiel> [35]http://www.w3.org/dpub/IG/wiki/MathSonifyA11y and
>> [36]http://dl.dropboxusercontent.com/u/39156804/graph.html
>>
>> [35] http://www.w3.org/dpub/IG/wiki/MathSonifyA11y
>> [36] http://dl.dropboxusercontent.com/u/39156804/graph.html
>>
>> gcapiel: I'll move onto the next use case
>> ... this concerns sonification using multi-modal delivery for
>> SVG
>> ... I have a use case and a demo using Web Audio and Web Speec
>> to sonify
>> ... the demo works with that specific SVG and similar ones but
>> is not generally useful
>> ... since it needs semantic data like axes and tick marks
>>
>> ChrisL: how do you find that data in the demo
>>
>> shepazu: in this demo it works since the files have a
>> consistent layout
>> ... it's something I'd like to aria
>> ... e.g. a "data-point" role or something of that ilk
>> ... it distinguishes that piece of information from the other
>> graphics on the page
>> ... likewise for axes
>>
>> heycam: how broadly do you want to look at semantics of
>> diagrammatic content
>> ... there's quite a range
>>
>> gcapiel: I guess it could be a wider range because not
>> everything can be sonified
>> ... but some of this might apply to tactile output too
>>
>> <gcapiel> [37]http://www.w3.org/dpub/IG/wiki/SVGStructDesc
>>
>> [37] http://www.w3.org/dpub/IG/wiki/SVGStructDesc
>>
>> gcapiel: the next use case (above) covers including HTML inside
>> SVG
>> ... and the reason we care about that is [paused for demo]
>>
>> (shepazu demos sonification)
>>
>> shepazu: we want to distinguish sonification from vocalization
>> ... we can read out different values but that doesn't give the
>> use the gist of the function
>>
>> (demo makes sounds whose pitch varies with the y-value of the
>> graph)
>>
>> scribe: compare this to existing SVG accessibility features
>> ... there's also a Web Speech API that would read off text
>> ... so we can make it read out this chart as a list
>> ... it would be better if we could allow users to navigate
>> around the chart
>> ... using the keyboard
>>
>> richardschwerdtfeger: so you're looking at adding semantics to
>> assist the textual description of the chart?
>>
>> shepazu: yes, I don't want to boil the ocean, but for common
>> items
>>
>> richardschwerdtfeger: I think I can help with this
>>
>> <richardschwerdtfeger> ack
>>
>> ChrisL: often stuff which is for accessibility gets a boost
>> when it also has some use in another context
>> ... this reminds me of an experiment where they sonified
>> various properties of blood so you didn't have to switch
>> between looking down a microscope and a chart
>> ... so it was a real benefit for sighted people as well
>>
>> gcapiel: there is also research that you retain information
>> better if you receive it in a multi-modal way
>>
>> shepazu: yes, but we're not proposing adding sonification to
>> SVG but to add the hooks for these alternative representations
>>
>> heycam: and these hooks would be aria features
>>
>> shepazu: yes
>>
>> heycam: so then we don't need to do anything much accept
>> allowing these new attributes
>>
>> ChrisL: yes, you just need the hooks
>>
>> shepazu: having the ability to markup in a commonly understood
>> way allows easier extraction and re-use of the data
>>
>> <gcapiel>
>> [38]http://diagramcenter.org/standards-and-practices/content-mo
>> del.html
>>
>> [38]
>> http://diagramcenter.org/standards-and-practices/content-model.html
>>
>> gcapiel: now I'd like to talk about more general descriptions
>> ... this is an image and its description
>> ... it's an infographic really
>> ... it has a lot of information that would be hard to capture
>> in an alt attribute
>> ... I guess you could use describedby but then the description
>> might be separated from the image itself
>> ... this is where having HTML in SVG might be useful
>>
>> heycam: how would you imagine this working?
>>
>> shepazu: so currently the content model of <desc> is text
>> ... if that allowed markup we could have tables, lists etc.
>>
>> ChrisL: putting bare-name elements inside <desc> is fine since
>> it doesn't need positioning information etc.
>> ... seems reasonable to put bare-name HTML there
>>
>> heycam: so I think the HTML parser already switches into
>> allowing HTML content inside <desc>, <title>, and
>> <foreignObject>
>>
>> gcapiel: it's not in the spec though
>>
>> shepazu: we need to clarify in the spec and make test cases
>>
>> heycam: one part is to make sure the HTML parser does the right
>> thing and the other part is blessing that pattern in SVG
>> ... and we only really need to do the second part
>>
>> shepazu: any objections?
>>
>> heycam: is that idea that you target that <desc> with an ARIA
>> describedby
>>
>> richardschwerdtfeger: it's an API mapping issue more than
>> anything
>>
>> gcapiel: here's a use case: I'm a publisher and want to put
>> some images in my text book
>> ... I get a water cycle image from a site in SVG format
>> ... I want the description to be packaged inside the SVG
>>
>> heycam: my question is more about how to refer to the <desc>
>> ... currently <desc> applies to its parent element
>> ... and that may or may not be appropriate
>> ... sometimes you may want to have multiple elements targetting
>> the same desc
>>
>> richardschwerdtfeger: one difficulty is you have HTML content
>> that is not actually rendered
>> ... I assume that stuff is in the DOM and an AT can navigate it
>> ... a magnifier will have challenges if it's not rendered
>> ... one way around that is to have it as an iframe
>> ... but you want it all in the same document?
>>
>> shepazu: I see what you're saying but I think this is an
>> implementation detail
>>
>> richardschwerdtfeger: ok
>>
>> RESOLUTION: <desc> should allow HTML markup and we should have
>> tests for this and recommend this practice
>>
>> shepazu: we should cross-reference this when we talk about
>> inline HTML in general
>>
>> <scribe> ACTION: Doug to clarify HTML content in <desc> and
>> <title> elements [recorded in
>> [39]http://www.w3.org/2013/11/14-svg-minutes.html#action04]
>>
>> <trackbot> Created ACTION-3538 - Clarify html content in <desc>
>> and <title> elements [on Doug Schepers - due 2013-11-21].
>>
>> heycam: I checked the HTML parsing and yes, for <title>,
>> <desc>, and <foreignObject> parsing switches back to HTML
>>
>> <heycam>
>> [40]http://www.whatwg.org/specs/web-apps/current-work/#html-int
>> egration-point
>>
>> [40]
>> http://www.whatwg.org/specs/web-apps/current-work/#html-integration-point
>>
>> <gcapiel> [41]http://www.w3.org/dpub/IG/wiki/SVGCrowdDesc
>>
>> [41] http://www.w3.org/dpub/IG/wiki/SVGCrowdDesc
>>
>> gcapiel: the next use case is around post-production of
>> descriptions
>> ... I have an SVG in an ePUB and it has been shipped but it's
>> not until it reaches a student that someone notices that the
>> description is missing or incorrect
>> ... we want to have a way to fix that
>> ... the author might actually describe in the SVG a link to a
>> point where those crowdsource improvements could be pulled in
>> ... after some content has been created how does someone
>> annotate it
>>
>> ChrisL: so is this about forking or about having an extension
>> point?
>>
>> gcapiel: the latter since there may be copyright issues
>>
>> ChrisL: it opens up issues about an approval process
>> ... it sounds similar to crowdsourcing captions for videos
>>
>> gcapiel: yes, it's similar to that which has been very
>> successful
>>
>> shepazu: gcapiel and I talked about this and I think this is a
>> general use case
>> ... we might want to plug into the work going on in the open
>> annotations world
>> ... so perhaps you could hook your user agent into a particular
>> open annotation framework
>> ... so we just need the hooks
>>
>> gcapiel: so we need to look into whether that can be applied to
>> SVG
>>
>> <gcapiel>
>> [42]http://www.w3.org/dpub/IG/wiki/SVGMediaQueriesA11y
>>
>> [42] http://www.w3.org/dpub/IG/wiki/SVGMediaQueriesA11y
>>
>> shepazu: I spoke to the hypothesis folks and I'm confident it's
>> possible
>>
>> gcapiel: here is another use case
>> ... this SVG is very useful for a sighted user
>> ... but a lot of the information is decorative and so if this
>> was converted to a tactile format a lot of that information
>> would actually obscure the information
>> ... so currently the way this is handled is by creating a
>> separate image
>> ... but I'd like to make it so you could use the same format
>> ... and going forward we might even use 3D printers for tactile
>> output
>> ... which might have slightly different requirements still
>> ... so we might need media queries for this
>>
>> shepazu: I think this is actually a CSS questions
>>
>> heycam: I agree. It would be good to know if the kind of
>> modifications you want to make can be all styled with CSS
>> properties
>>
>> shepazu: I'm pretty sure they could be. e.g. hiding/displaying
>> content, replacing a pattern with a fill etc.
>> ... we'll look into this and come back with a proposal
>>
>> heycam: if there are things that can't be styled with CSS then
>> we'll need to handle that
>>
>> TabAtkins: I'm editing media queries now
>> ... just a note, we are deprecating media types nw
>>
>> <scribe> ACTION: Doug to work with Gerardo and Tab to come up
>> with haptic, tactile and 3d media queries [recorded in
>> [43]http://www.w3.org/2013/11/14-svg-minutes.html#action05]
>>
>> <trackbot> Created ACTION-3539 - Work with gerardo and tab to
>> come up with haptic, tactile and 3d media queries [on Doug
>> Schepers - due 2013-11-21].
>>
>> <gcapiel> [44]http://www.w3.org/dpub/IG/wiki/SVGReuse
>>
>> [44] http://www.w3.org/dpub/IG/wiki/SVGReuse
>>
>> gcapiel: the final use case related to re-using the same SVG
>> multiple times in the same page
>> ... one idea was referencing it from an iframe
>> ... the challenge with that is that from a useability
>> point-of-view they are quite painful
>>
>> krit: can you repeat the use case
>>
>> gcapiel: I have an image of a basketball and it's going to
>> appear three times on page 5, then page 8 and then in another
>> text book
>> ... I want to reference it as a file
>>
>> <ChrisL> sounds like "fix the screen readers to not break on
>> iframe"
>>
>> shepazu: you can use the <use> element for this
>>
>> <TabAtkins> (Chrome, maybe others, don't allow external <use>,
>> but otherwise yeah. <use> in-document is fine. <iframe> or
>> whatever out-of-document is good.)
>>
>> gcapiel: we need to look at iframes for this
>>
>> krit: if it's a basketball and <img> is probably better
>>
>> richardschwerdtfeger: regarding iframes and JAWS is that we're
>> getting to treat them basically like navs
>>
>> gcapiel: no that's fine. I'm just concerned about useability
>>
>> heycam: the seamless attribute on <iframe> might also be a hint
>> here
>>
>> richardschwerdtfeger: people are using iframes more for mashups
>> ... to isolate part of the content
>> ... I can help work with the useability issues
>>
>> gcapiel: sounds good
>>
>> z-index in SVG
>>
>> kurosawa_: my question is, is z-index a requirement for SVG2?
>>
>> heycam: I think Tab might have been assigned to this?
>>
>> <TabAtkins> Was I?
>>
>> <TabAtkins> Sure, okay.
>>
>> heycam: if he or somebody could start adding that to the spec
>> before the end of the year then it will be in SVG2
>>
>> shepazu: is that good or bad for accessibility?
>>
>> kurosawa_: to make SVG content accessibility we need to care
>> about reading order
>> ... but SVG using forces a certain rendering order
>>
>> shepazu: so a z-index will allow to provide a different reading
>> order to rendering order?
>>
>> kurosawa_: yes
>>
>> ChrisL: yes, that's right--sometimes that's how you'd do it
>> ... but sometimes you want to allow different reading orders
>> ... and you wouldn't have to keep manipulate the document every
>> time for each different reading order
>>
>> kurosawa_: I agree that are multiple reading orders but if we
>> consider if I hover over some graphics and they move them to
>> the front... we'd need to re-attach them at a different point
>> of the document (without z-index)
>>
>> ChrisL: I agree that for that use case z-index is the
>> appropriate way to do it
>>
>> shepazu: yes, we do want z-index in SVG2 because it also helps
>> with accessibility
>>
>> Using Bikeshed for SVG specs
>>
>> krit: I'd like to have the discussion with Peter first
>>
>> (deferred for now)
>>
>> (break for lunch)
>>
>> <krit> [45]http://memedad.com
>>
>> [45] http://memedad.com/
>>
>> <krit> ScribeNick: krit
>>
>> plinss: Shepherd has a couple of purposes
>> ... manager of test suite
>>
>> heycam: yes, one part we want to use it
>> ... are interested in anchors
>>
>> plinss: yes, shepherd does that as well
>> ... tries to clasify anchors
>> ... but needs understanding what is defined and the
>> relationship to element, attribute and values
>> ... in relies on markup in the spec
>> ... tab and I came up with different ways to do it
>> ... I don’t care which way, I ‘ll adapt to the spec style as
>> well
>>
>> shepherd for svg repo
>>
>> heycam: are there some standard rules to make it easy for us to
>> adapt
>>
>> plinss: there is documentation on shepherd as well
>>
>> <TabAtkins> Documetnation:
>> [46]https://github.com/tabatkins/bikeshed/blob/master/docs/defi
>> nitions-autolinks.md
>>
>> [46]
>> https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md
>>
>> heycam: we use combination of Bikeshed and sag pre-processor on
>> some FX specs
>>
>> cyril: what is Bikeshed?
>>
>> <TabAtkins> (For the in-spec markup that Bikeshed recognizes.)
>>
>> heycam: a CSS pre-processor
>>
>> plinss: with automatic cross linking of specs based on data of
>> shepeherd
>> ... Bikeshed calls shepherd and asks for anchors
>> ... and specs can link back as welll
>>
>> <TabAtkins> krit, one word Bikeshed.
>>
>> heycam: we have similar things in SVG pre-processor but data is
>> in external XML file
>>
>> plinss: we use json
>>
>> TabAtkins: sheperd watches changes on other specs, no need to
>> manually update an XML file
>>
>> heycam: if shepherd watch our specs as well would be great and
>> having the right meta data in our specs as well
>>
>> <TabAtkins> Bikeshed also does automatic IDL linking/defining
>> markup, generates railroad diagrams, and a bunch of other
>> things.
>>
>> plinss: shepherd is watching all specs in FX already (with
>> exception of ReSpec specs)
>>
>> <TabAtkins> Big weakness for SVG right now is that Bikeshed
>> doesn't know how to generate multi-page specs yet.
>>
>> <TabAtkins> (I plan to do so, but haven't gotten to it yet.)
>>
>> plinss: I do want to have SVG scanned daily as well, and do it
>> already
>>
>> cyril: shepherd is the server env that scans things? How is it
>> related to bike shed?
>>
>> Chris: Is checking the specs
>>
>> <heycam> I sometimes wonder whether we should make SVG2
>> primarily a one page spec, but also to have generated
>> multi-page version.
>>
>> Chris: you can do links by automatic cross linking between
>> specs and tests can reference specs as well
>> ... [explaining some things of Bikeshed from the docs]
>>
>> shepazu: Bikeshed does not yet support multipage steps
>>
>> plinss: no problem for Shepherd at least
>> ... Shepherd can find specs where ever sections move within the
>> spec
>>
>> Chris: [Going crazy]
>>
>> heycam: Is the markup sufficient in SVG spec?
>>
>> plinss: no it is not, most of the things are not recognized at
>> all
>>
>> heycam: using propdef even for element and attribute defintions
>>
>> plinss: that is bad for identifying things
>> ... data-def type is a way to identify
>>
>> <TabAtkins> <dfn attribute>foo</dfn> becomes <dfn
>> data-dfn-type="attribute">foo</dfn> after Bikeshedding.
>>
>> plinss: another way is a lot of short cuts
>> ... propdef is another one as is elementdef and attributedef
>>
>> <TabAtkins> <div class="propdef"><dfn>foo</dfn></div> makes
>> "foo" a property def.
>>
>> plinss: Shepherd understands all IDL
>>
>> krit: we can auto generate many things so we can change things
>> easily with exception for attributes
>>
>> TabAtkins: since propdef is used for styling purposes, there is
>> a new class .defintion with the same purpose now
>>
>> heycam: we want the big blue element definition tables
>> ... with content model and a lot more information and Shepher
>> could use that in the future
>>
>> plinss: they were defining elements in definition sections
>> ... so you could just link to the section headings
>> ... HTML spec does not have all id’s set correctly yet
>>
>> shepazu: we adapted in the past already and adapting
>> confincient the CSS WG is using makes sense...
>> ... easier to maintain
>> ... does SVG WG object to use convenients Shepherd is
>> expecting?
>>
>> ChrisL: depends.. on testing yes. Bikeshed? maybe not
>>
>> shepazu: mean we should adapt spec styling so that Shepherd can
>> pick things up more easily
>>
>> ChrisL: yes, we should definitely
>>
>> <ChrisL> bikeshed is fine if it could do a multi-doc spec like
>> svg2
>>
>> plinss: yes, Shepherd picks up tests already and don’t care
>> about the markup as long as it is explicitly
>>
>> shepazu: yeah, we do not care about the markup, we want things
>> to work
>>
>> ChrisL: and we don’t have the maintainance
>>
>> <TabAtkins> SVG just splits up pages by chapter, right?
>>
>> ChrisL: what is the minimal set for HTML5 so that we can auto
>> link into that?
>>
>> plinss: I am identifying most attributes but not all elements
>>
>> <TabAtkins> I think HTML tries to have the pages roughly
>> balanced.
>>
>> krit: you pick up attributes on HTML but not elements? what
>> about the reference to elements from attribute?
>>
>> <TabAtkins> <a element>filter</a>, or <a
>> data-link-type="element">filter</a> if you're not Bikeshedding.
>>
>> plinss: not sure if Shepherd does
>>
>> <SimonSapin> FWIW, MDN also wants to parse spec to be notified
>> when something changes that needs doc changes
>>
>> shepazu: what is the best way to learn what is needed for
>> shepherd
>>
>> <TabAtkins> To mark up attributes for elements, <dfn attribute
>> for="filter">x</dfn> (or whatever).
>>
>> plinss: I can generate a document explaining it
>>
>> <scribe> ACTION: plinss deliver document to adapt specs to
>> Shepherd [recorded in
>> [47]http://www.w3.org/2013/11/14-svg-minutes.html#action06]
>>
>> <trackbot> Error finding 'plinss'. You can review and register
>> nicknames at
>> <[48]http://www.w3.org/Graphics/SVG/WG/track/users>.
>>
>> [48] http://www.w3.org/Graphics/SVG/WG/track/users%3E.
>>
>> <scribe> ACTION: Peter Linss deliver document to adapt specs to
>> Shepherd [recorded in
>> [49]http://www.w3.org/2013/11/14-svg-minutes.html#action07]
>>
>> <trackbot> Created ACTION-3540 - Linss deliver document to
>> adapt specs to shepherd [on Peter Sorotokin - due 2013-11-21].
>>
>> plinss: so you have attribute def table, we have the same for
>> properties but we do not analyze the table in detail
>> ... plan to do it
>> ... will be done soon and pick up values and relations
>> automatically
>> ... what ever format you use, it must be machnine parable
>>
>> parseable
>>
>> cyril: how do you link back from specs and attributes?
>>
>> plinss: in the past we have backinks from tests to the spec
>>
>> krit: can we add anchor detections on tests and Shepherd will
>> pick them up and auto link?
>>
>> plinss: came up before, but doesn’t work right now
>> ... TabAtkins will probably discuss testable assertions and how
>> Bikeshed can help in the future
>> ... one thing, the test suite and test suite generation is
>> independent of Shepherd, but Shepherd is used to build it
>>
>> ChrisL: prefer to have links to TR. If we send people to ED,
>> then TR get irrelevant
>>
>> plinss: Tim says we can host a TR spec somewhere else and have
>> a link to TR form that spec
>>
>> ChrisL: we have a rule against external script
>>
>> plinss: all tools are open sourced, I do not care on which
>> server they run on
>>
>> ChrisL: [discussing publish policies of W3C]
>>
>> new SVG DOM proposal
>>
>> heycam: want to make SVG DOM a bit saner
>> ... how could it be possible to opt in to this new DOM
>> ... otherwise existing script could break
>>
>> <heycam> [50]http://dev.w3.org/SVG/proposals/improving-svg-dom/
>>
>> [50] http://dev.w3.org/SVG/proposals/improving-svg-dom/
>>
>> heycam: to sumaries: key idea… not have SVG elements in a
>> different NS than HTML elements
>> ... so we would use the NS of the element to decide to use new
>> SVG DOM or old SVG DOM and element defintions
>>
>> ChrisL: HTML parser parses a lot of staff. So what happens to
>> this which adds elements ti SVG NS?
>>
>> heycam: HTML parser would need to change to switch to new NS
>> unless there is a new elements where the SVG content is used
>> which will do the switch to the new NS
>> ... I called it graphics
>> ... <graphics>HTML NS of SVG elements</graphics>
>> ... problem is support for older UAs
>> ... a new element would not help
>>
>> krit: unless you wrap the SVG content in an extra <svg> element
>>
>> heycam: yes
>>
>> krit: when we want backward compatibility then...
>>
>> heycam: not sure if we want that
>>
>> slightlyoff: If I have an old school element and move it to and
>> old school element what happens
>> ... what happens to importNode, adoptNode, appendChild and so
>> on
>>
>> heycam: most functionality would still work
>> ... didn’t thought about that
>>
>> slightlyoff: what about createElement
>> ... new SVGPath() which interface do I get?
>>
>> heycam: there are no Ctors for SVG element yet
>> ... and createElementNS would give you old school element
>> ... now that they are in HTML, are they HTML*Element
>> ... but we can’t easily use the same interfaces if you have
>> linking within the same document
>>
>> <birtles> krit: so can't you just use an attribute instead?
>>
>> <heycam> (slightlyoff = Alex Russell)
>>
>> <TabAtkins> Haha, I was wondering who slightlyoff was supposed
>> to be.
>>
>> <birtles> heycam: well typically the prototype of an object is
>> decided at creation time
>>
>> <birtles> ... since you need to decide the interface of the
>> object at object creation time
>>
>> <birtles> ... I thought that if you document.createElement it,
>> it can't start off with the old interface
>>
>> <birtles> ... then you do .setAttribute and suddenly get the
>> new interface
>>
>> <slightlyoff> OH HAI
>>
>> <birtles> TabAtkins: so in Custom Elements you can say what the
>> prototype is but only at parse time
>>
>> <birtles> heycam: do you agree that it would be weird to change
>> the interface on a object after it start existing?
>>
>> <birtles> slightlyoff: I think you can get there using some
>> esoteric ways (ES6 proxies etc.) but none of them are
>> attractive
>>
>> <birtles> ... the downside is that in the transition period is
>> that we double the surface area
>>
>> <birtles> ... I'd like to find ways to reduce the surface area
>> of the SVG DOM
>>
>> <birtles> ... the number of interfaces created by the SVG DOM
>> is a burden on implementations
>>
>> <birtles> shepazu: to what extent could we trim them away from
>> the existing DOM without harming existing content
>>
>> <slightlyoff> heycam, sorry I wasn't in the channel before, can
>> you link me to the proposal again?
>>
>> shepazu: q-
>>
>> <nikos> [51]http://dev.w3.org/SVG/proposals/improving-svg-dom/
>>
>> [51] http://dev.w3.org/SVG/proposals/improving-svg-dom/
>>
>> <cyril> [52]http://dev.w3.org/SVG/proposals/improving-svg-dom/
>>
>> [52] http://dev.w3.org/SVG/proposals/improving-svg-dom/
>>
>> <slightlyoff> thanks
>>
>> <birtles> heycam: the section of reflecting attributes in the
>> proposal gets rid of a lot of the interfaces (from the new
>> world)
>>
>> <birtles> shepazu: what is the goal of the proposal?
>>
>> <birtles> ... making a new root element is an outcome not a
>> goal
>>
>> <birtles> heycam: right, it's not a goal, but a means to an end
>>
>> <birtles> shepazu: I mean is putting SVG elements into the HTML
>> namespace a goal or a means?
>>
>> <birtles> heycam: it wasn't a goal per se
>>
>> <birtles> shepazu: I'd like to see the goals be more explicit
>>
>> <birtles> cyril: my experience of teaching SVG is that students
>> gets confused by namespaces
>>
>> <birtles> ... they are surprised that they can't create SVG
>> elements in the same way as they can HTML elements
>>
>> <birtles> krit: I also think namespaces introduce an
>> implementation burden
>>
>> <birtles> ... we should be able to assume people are just using
>> the new DOM or the old DOM
>>
>> <birtles> heycam: I'd love to drop the old DOM but
>> unfortunately we can't given existing usage
>>
>> <birtles> krit: what if we keep the existing naming, interfaces
>> etc. and remove just the namespace requirement
>>
>> <birtles> ... i.e. SVGElement inherits from HTMLElement
>>
>> <birtles> heycam: my proposal includes SVGElement inheriting
>> from HTMLElement
>>
>> <slightlyoff> heycam, this proposal looks very good overall
>>
>> <birtles> ChrisL: I don't think the goal is necessarily to move
>> SVG elements into the HTML namespace as much as helping
>> namespaces fade away
>>
>> <birtles> ... but Dirk, how do you propose we fix existing
>> problems such as getting rid of animVal
>>
>> <ChrisL> the proposals for reflecting values and getting rid of
>> animval and baseval is valuable
>>
>> <birtles> krit: I don't think we can get rid of those now
>>
>> <birtles> dino: but we should take the view that the future is
>> bigger that the past so we should fix it now
>>
>> <birtles> slightlyoff: I also agree that these old interfaces
>> are creating drag that stops SVG from developing
>>
>> <birtles> krit: but there are existing libraries like raphael
>> and snap that rely on the current SVG DOM
>>
>> <birtles> ChrisL: I don't see any removal of functionality...
>> just expressing it in a different way
>>
>> <birtles> krit: so what do you suggest?
>>
>> <birtles> heycam: the proposal doesn't remove the old DOM
>>
>> <birtles> ... there is duplication, but I think that's the only
>> way we can move forward without breaking other content
>>
>> <birtles> ChrisL: so this would double the footprint for SVG
>> but then we hope the old footprint would fade away quickly
>>
>> <birtles> shepazu: in terms of footprint... you have these
>> reflectors in there
>>
>> <birtles> ... is it possible they reduce the footprint of the
>> new DOM by aliasing etc.
>>
>> <birtles> slightlyoff: this is the Web, we have a transition
>> period, add a suitable carrot for the new version then use data
>> to determine when switch off the old version
>>
>> <birtles> shepazu: I'm just wondering how we can reduce the
>> footprint
>>
>> <birtles> slightlyoff: there are things you can do like turn
>> off some of the optimizations from the old DOM as an incentive
>> to move to the new DOM
>>
>> <birtles> heycam: Doug, you don't need two implementations, you
>> can re-use code
>>
>> <birtles> krit: can we remove the liveness of animVal?
>>
>> <birtles> ... i.e. make it an alias for baseVal
>>
>> <birtles> ... that would be a big saving
>>
>> <birtles> heycam: we can probably discuss that separately
>>
>> <birtles> ... the basic strategy I've applied to these members
>> is to expose attributes as strings...
>>
>> <birtles> ... we have, for example, the polygon element that
>> has a list of points
>>
>> <birtles> ... in the old SVG DOM we have a live list of points
>> you can manipulate
>>
>> <birtles> ... in the new SVG DOM we have a pair of methods to
>> set and get an array
>>
>> <birtles> ... that makes it slightly more awkward to use
>>
>> <birtles> ... if you just want to change one point, say, for
>> animation, you have to set the whole thing
>>
>> <birtles> ... but what do you think Alex?
>>
>> <birtles> slightlyoff: lists in javascript are currently
>> particularly painful
>>
>> <birtles> ... in the post-ES6 world things might get easier
>>
>> <birtles> ... currently you might use a proxying approach which
>> is basically what the old DOM does
>>
>> <birtles> ... but my suggestion for the time being is to do
>> whatever is closest to current javascript which is arrays
>>
>> <birtles> heycam: what will things look like in the distant
>> future?
>>
>> <birtles> slightlyoff: it's end-of-turn... I assume you're not
>> doing synchronous layout?
>>
>> <birtles> heycam: actually if you update stuff and do getBBox
>> then I think you will get the updated result
>>
>> <birtles> slightlyoff: that's problematic, we should try to fix
>> that
>>
>> <birtles> ... we should try to avoid that
>>
>> <birtles> heycam: at least in SVG it's more contained since you
>> don't have reflow, just absolutely positioned elements
>>
>> <birtles> krit: can we take on some parts of the proposal
>>
>> <birtles> ... the most important part is that we don't have
>> many namespaces
>>
>> <birtles> heycam: I agree, but I don't think we can do it
>> separately
>>
>> <birtles> ... since otherwise you'll have SVG elements in the
>> HTML namespace with the old DOM then we could never change it
>>
>> <birtles> ... so it would poison our ability to change things
>>
>> <birtles> krit: I don't think the swapping works
>>
>> <birtles> ... it's a huge mess... you add more code and it's
>> unlikely that you can ever remove the old code
>>
>> <birtles> slightlyoff: if you say "unlikely" then you're
>> talking about probabilities--we can set it up so these features
>> "could possibly" be removed or "can never" be removed
>>
>> <TabAtkins> I suspect that, given replacements and aggressive
>> metrics, we could trim out a bunch of the legacy right now. Not
>> all, but a bunch.
>>
>> <birtles> krit: I think we should change the namespace as a
>> first step and then we fix things progressively in the future
>> in a backwards compatible way
>>
>> <birtles> slightlyoff, ChrisL: I don't think that gets you a
>> lot
>>
>> <birtles> slightlyoff: it means you have to keep the old
>> interfaces forever
>>
>> <birtles> heycam: I don't want to do things slowly, I want to
>> add the new features at once
>>
>> <birtles> krit: if we switch the namespace now what can you
>> *not* do in the future?
>>
>> <birtles> heycam: you can't use the namespace as the switch for
>> opting into the new DOM
>>
>> <birtles> krit: everything you want to add to the new DOM, you
>> can detect this stuff
>>
>> <birtles> slightlyoff: how does that work?
>>
>> <birtles> ... this makes compatibility more difficult since you
>> have to detect this stuff
>>
>> <birtles> ... I don't think we should give weight to
>> implementation issues here
>>
>> <birtles> TabAtkins: I think we could trim out a lot of stuff
>> already
>>
>> <birtles> ChrisL: we're focussing too much on the impact on
>> implementors
>>
>> <birtles> ... we should focus more on authors and this proposal
>> makes it easier for authors
>>
>> <birtles> ... one way to introduce this is to say that all the
>> new SVG2 stuff only works in this new method
>>
>> <birtles> ... as an incentive to switch to this
>>
>> <TabAtkins> +1 to carrot
>>
>> <birtles> heycam: e.g. a method to get the stroke bounding box
>> etc.
>>
>> <TabAtkins> Old DOM freezes on the current set, and shrinks as
>> metrics show we can kill things.
>>
>> <birtles> ... krit, what do you think is the problem with this?
>>
>> <TabAtkins> New DOM is better, and grows with new abilities as
>> we think of them.
>>
>> <birtles> krit: I think we'll never be able to get rid of the
>> old interfaces
>>
>> <birtles> ... it will be 10 years before we can start removing
>> things
>>
>> <birtles> ... it will take 2~3 years until it is implemented
>> properly
>>
>> <birtles> ChrisL: but you were saying we drop animVal?
>>
>> <birtles> krit: it's not being used
>>
>> <birtles> ChrisL: it is
>>
>> <birtles> shepazu: there was a small but active community of
>> SVG developers from 1999-2006
>>
>> <TabAtkins> shepazu: Maybe 12 or so.
>>
>> <birtles> ... (more background)
>>
>> <birtles> ... there is lot of content out there that may not
>> even work due to namespace issues
>>
>> <birtles> ... in any case, I think we need to involve the
>> community in this decision
>>
>> <birtles> ... people like maintainers of script libraries
>>
>> <birtles> krit: I don't think many people have reviewed it yet
>>
>> <birtles> heycam: I just want to know (a) if I should keep
>> driving this, and (b) what sort of timeframe?
>>
>> <birtles> shepazu: I'm still uncomfortable about changing the
>> root element
>>
>> <birtles> ... it introduces confusion about what you should be
>> doing
>>
>> <birtles> ... there are definite risks
>>
>> <birtles> ... but that may be ok
>>
>> <birtles> ... I'd like to be explicit about the goals
>>
>> <birtles> heycam: the 1.5 goals are, 1) changing to the
>> reflecting of attributes, 1.5) changing namespaces
>>
>> <birtles> ... the change of namespaces just happened to be a
>> good way of opting into the new DOM
>>
>> <birtles> ... the new root element is not a goal, just a means
>>
>> <birtles> cyril: the goal to change the reflecting of
>> attributes
>>
>> <birtles> ... is it to make writing SVG easier? or reduce code
>> size in implementations?
>>
>> <birtles> heycam: for useability for authors
>>
>> <birtles> krit: "is this something important enough for SVG 2?"
>> is a good question
>>
>> <birtles> ... is it worth delaying SVG 2 for?
>>
>> <birtles> dino: if we delay it, it will only make the decision
>> harder
>>
>> <birtles> ... there will be more content to break
>>
>> <birtles> ChrisL: and by bringing forward the namespace change
>> you'd remove one of the drivers for switching
>>
>> <birtles> krit: so, should it be in SVG2?
>>
>> <birtles> heycam: I feel like it should
>>
>> <birtles> ChrisL: I don't think we could do this in SVG3
>>
>> <birtles> krit: in which case we should prioritize this work
>>
>> <birtles> ... we should focus on the details at the next F2F
>>
>> <birtles> slightlyoff: I'd like to help set up a process for
>> you all to talk to major library authors and get their input
>>
>> <birtles> ... are these meetings to do design work or just
>> making decisions?
>>
>> <birtles> heycam: we do both
>>
>> <birtles> ... this is the first f2f where I've brought up the
>> proposal
>>
>> <birtles> ... so we could dedicate more time to it at the next
>> f2f
>>
>> <birtles> ChrisL: I think we can get new data before then
>>
>> <birtles> krit: I think we should delay LC anyway
>>
>> <birtles> heycam: I think January was a bit optimistic anyway
>>
>> <birtles> ... but we will discuss that later
>>
>> <birtles> krit: how do we reach out to developers from here
>>
>> <birtles> heycam: I haven't really announced it yet
>>
>> <birtles> shepazu: for svg developers there's the d3 list,
>> svg-developers, we can tweet, etc.
>>
>> <birtles> krit: if we want people to read the proposal I think
>> we could rework it to make it easier to follow
>>
>> <birtles> shepazu: does your document talk about the problems
>> with the existing DOM?
>>
>> <birtles> ... I think we should add that
>>
>> <birtles> heycam: is there anything else to cover?
>>
>> SVGAnimatedBoolean
>>
>> <birtles> ed: it's only used in one place
>>
>> <birtles> krit: I doubt anyone uses it
>>
>> <birtles> heycam: was externalResourcesRequired the only other
>> use?
>>
>> <birtles> ed: yes
>>
>> <birtles> ... so can we remove it?
>>
>> <birtles> ChrisL: let's remove it
>>
>> <ChrisL> getAttr still works
>>
>> <birtles> RESOLUTION: We will remove SVGAnimatedBoolean and
>> SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
>>
>> <birtles> ACTION: Dirk to remove SVGAnimatedBoolean and
>> SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
>> [recorded in
>> [53]http://www.w3.org/2013/11/14-svg-minutes.html#action08]
>>
>> <trackbot> Created ACTION-3541 - Remove svganimatedboolean and
>> svgfeconvolvematrixelement.preservealpha from the svg2 dom [on
>> Dirk Schulze - due 2013-11-21].
>>
>> <birtles> slightlyoff: I'll talk to Google folk about how they
>> transitioned from the old DART DOM to the new DOM to get their
>> advice
>>
>> <ed> -- break time --
>>
>> <TabAtkins> Yay!
>>
>> <heycam> Scribe: Cameron
>>
>> <heycam> ScribeNick: heycam
>>
>> SVG DOM continued
>>
>> krit: any new SVG DOM should not have any reference to
>> x/y/width/r/rx/ry/cx/cy
>>
>> ChrisL: because?
>>
>> krit: because they'll get presentation attributes, and it
>> doesn't make sense to have a second way to access them, apart
>> from the CSS OM
>>
>> heycam: I really want to do rect.x = 10
>>
>> ed: I'd like to be able to assign a full rectangle in one go
>>
>> ChrisL: rect.xywh = ...
>>
>> krit: happy if SVG WG to ask the CSS WG to prioritise the CSSOM
>> for SVG 2
>> ... like heycam's proposal
>> ... but up to the WG
>>
>> SVGElement implementing global event handlers (onfoo)
>>
>> ed: should these be on Element?
>>
>> <ed>
>> [54]http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-Oc
>> tober/040980.html
>>
>> [54]
>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/040980.html
>>
>> ed: I think in Blink recently there was some code reshuffling
>> ... it was discovered that SVG elements did not have the global
>> event handlers like HTML does
>> ... so you couldn't do rectElement.onload = ... and have that
>> assign a function
>> ... so this is something that most SVG authors would like to
>> have
>> ... and the way it works in browsers, even if the SVG spec
>> doesn't require it
>> ... I think we should have this in the spec
>> ... in this thread, further down, we have feedback from Hixie
>> saying we can't really put this on Element, as it would affect
>> any XML dialect
>>
>> krit: and that would be bad?
>>
>> ed: yes
>> ... but having it on SVGElement would be fine
>>
>> heycam: are all HTML event listener attributes defined on
>> HTMLElement?
>>
>> ed: yes, apart from special things with <body>
>> ... this is the way Gecko already does it
>> ... it does mean we have some additional events supported
>> automatically
>> ... things which we don't require in SVG at the moment
>>
>> heycam: what if one day SVGElement inherits from HTMLElement?
>>
>> ed: we could still make both implement GlobalEventHandlers
>>
>> heycam: if we do have SVGElement inherit from HTMLElement one
>> day, we can just remove the duplicated ones on SVGElement
>>
>> ed: any objections to this? :
>>
>> SVGElement implements GlobalEventHandlers;
>>
>> scribe: I think Cameron has an action already relating to this
>>
>> heycam: does SVG have onzoom or something that isn't in HTML?
>>
>> ed: a few, yes... not sure if that already works on an
>> HTMLElement
>>
>> heycam: if they aren't on GlobalEventHandlers, should they be?
>>
>> ed: yes
>>
>> <TabAtkins> Ah, there's someone's voice.
>>
>> birtles: on HTMLElement, you have onfocus, but SVG has
>> onfocusin/onfocusout
>> ... is there some mismatch?
>>
>> Takagi-san noticed this
>>
>> TabAtkins: in HTML the focusout event is called blur
>>
>> ed: which already works in all browsers
>>
>> birtles: so would we end up with
>> onfocusin/onfocusout/onfocus/onblur?
>>
>> heycam: how much do we really need to keep
>> onfocusin/onfocusout?
>>
>> ed: we have a later topic on removing some SVG-specific events,
>> discuss it then?
>>
>> heycam: is Ian alright with having any SVG specific ones on
>> GlobalEventHandlers?
>>
>> ed: I haven't asked him that
>>
>> <TabAtkins> But, probably, yes.
>>
>> <scribe> ACTION: Erik to ask in the thread about whether SVG
>> specific event handlers should go on GlobalEventHandlers, or
>> separately on SVGElement [recorded in
>> [55]http://www.w3.org/2013/11/14-svg-minutes.html#action09]
>>
>> <trackbot> Created ACTION-3542 - Ask in the thread about
>> whether svg specific event handlers should go on
>> globaleventhandlers, or separately on svgelement [on Erik
>> Dahlström - due 2013-11-21].
>>
>> RESOLUTION: We will have "SVGElement implements
>> GlobalEventHandlers" in SVG2's IDL.
>>
>> <scribe> ACTION: Erik to make SVGElement implement
>> GlobalEventHandlers in SVG2. [recorded in
>> [56]http://www.w3.org/2013/11/14-svg-minutes.html#action10]
>>
>> <trackbot> Created ACTION-3543 - Make svgelement implement
>> globaleventhandlers in svg2. [on Erik Dahlström - due
>> 2013-11-21].
>>
>> Is it future-proof to return SVGElement on nearestViewportElement and
>> farthestViewportElement?
>>
>> <krit>
>> [57]https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsE
>> lement__farthestViewportElement
>>
>> [57]
>> https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__farthestViewportElement
>>
>> krit: I have a question about these two
>> ... farthestViewportElement, isn't that always SVGSVGElement?
>> can we just use that?
>> ... it's true, today at least
>> ... is is true in the future? if we should ever allow
>> SVGCircleElement to be an HTMLElement, what should it return?
>> ... my question is should we rather replace SVGElement with
>> just Element?
>> ... or in this case, should it return null as in some other
>> cases?
>>
>> heycam: is this when you have say a <circle> with no ancestor
>> <svg>?
>>
>> krit: I guess we return null currently
>>
>> heycam: I am ok with it being Element; the spec will still say
>> what objects get returned
>> ... we still would return null from <circle> when there is no
>> ancestor <svg>
>>
>> RESOLUTION: We will make nearestViewportElement /
>> furthestViewportElement be Elements, not SVGElement
>>
>> ed: I've rarely seen these used, could we not just remove them?
>>
>> krit: add UseCounters and see if we can remove it?
>>
>> ed: sure
>>
>> <scribe> ACTION: Erik to add use counters to see if
>> nearestViewportElement/furthestViewportElement are used
>> [recorded in
>> [58]http://www.w3.org/2013/11/14-svg-minutes.html#action11]
>>
>> <trackbot> Created ACTION-3544 - Add use counters to see if
>> nearestviewportelement/furthestviewportelement are used [on
>> Erik Dahlström - due 2013-11-21].
>>
>> <scribe> ACTION: Dirk to change
>> nearestViewportElement/furthestViewportElement to be Element
>> [recorded in
>> [59]http://www.w3.org/2013/11/14-svg-minutes.html#action12]
>>
>> <trackbot> Created ACTION-3545 - Change
>> nearestviewportelement/furthestviewportelement to be element
>> [on Dirk Schulze - due 2013-11-21].
>>
>> Animation Elements
>>
>> birtles: you all know about Web Animations, the model for
>> animations and an API on top of that model
>> ... the intention is to define CSS Animations/Transitions and
>> SVG's animation features in terms of that model
>>
>> <birtles>
>> [60]http://dev.w3.org/fxtf/web-animations/animation-elements.ht
>> ml
>>
>> [60] http://dev.w3.org/fxtf/web-animations/animation-elements.html
>>
>> birtles: so Animation Elements is what I've called the spec
>> where I've started to describe how SVG animation features can
>> be implemented in terms of the Web Animations model
>> ... skeleton document I've made
>> ... the only parts I've filled in are some use cases at the
>> top, and describing how it relates to SVG 1.1
>> ... and also some other specifications
>> ... I can introduce briefly some of the changes, but today I
>> just want to decide on is whether it's OK to work on this as an
>> SVG Working Group work item
>> ... it's an Unofficial Draft at the moment
>> ... if you're OK with me working on this as an Editor's Draft,
>> I'd like to decide on that
>>
>> cyril: does it cover the timing model and the animation model,
>> or just the animation model?
>>
>> birtles: the 1st requirement of this is that it's backwards
>> compatible with SVG 1.1's animation support
>> ... so yes, it has to cover both of those things
>>
>> shepazu: to what extent is it backwards compatibel?
>> ... you've documented the bits that aren't going to be?
>>
>> birtles: there are three exceptions, marked at the start of
>> section 1.2, regarding backwards compatibility
>> ... crazy frozen to-animation that nobody implemented won't be
>> in here
>> ... second point, I want to rewrite how cycles in syncbase
>> dependencies are resolved, as these are implemented
>> inconsistently
>> ... might be some minor changes as to how that works, but I
>> don't think people rely on the details
>> ... third is animateColor -- waiting on use counters to see
>> whether people use this
>> ... and drop it if not
>>
>> cyril: is the shim you have already supporting this?
>>
>> birtles: no
>> ... there's no shim for this markup
>> ... there's fakeSmil, but that's the existing featureset
>> ... you can see there's a list of new features
>> ... some of them are exposing things which are already in the
>> Web Animations model as markup
>> ... there's also the <discard> element, which was in SVG 2 but
>> I think it belongs in this specification instead
>> ... timelineStart="" as well
>> ... most of the new things are requirements we had for SVG 2,
>> and I put them in this spec
>>
>> shepazu: for every feature of element-based SVG animation,
>> there will be an equivalent API/model aspect? and possibly CSS
>> syntax?
>>
>> birtles: roughly
>> ... there are some things which only appear in one form
>> ... e.g. timing groups, we don't know how yet to express that
>> with CSS syntax
>> ... likely that will be in the model, exposed here in element
>> markup, but not exposed in CSS syntax, at least initially
>> ... you don't get the full feature set across both syntaxes
>>
>> shepazu: one of my frustrations with SVG animation syntax was
>> the lack of reusability
>> ... the same animation for multiple elements, I had to repeat
>> the animation
>> ... is this now possible with element syntax?
>>
>> birtles: yes, you can use the select="" attribute to target
>> multiple elmeents
>> ... some examples in the use cases -- frame based animation use
>> case, you can see that uses select="" to match on a class name,
>> and repeat the animation
>> ... it's also possible to define the animation with markup, and
>> then with script to instantiate it on a different element, to
>> say play this animation targetting a different element
>>
>> cyril: so you can put an animation in a defs?
>>
>> birtles: yes
>>
>> shepazu: that's great
>> ... if I'm animating something with the element syntax, the CSS
>> syntax and the script, what happens?
>> ... I assume you have some order of priorities?
>>
>> birtles: that ordering is covered in the Web Animations model
>> ... there are priorities based firstly on start time, but also
>> on document order, and facilities for changing the priotity too
>>
>> <ed> minor nit, "timelineStart" was actually called
>> "timelineBegin" in SVG Tiny 1.2, was the change of name
>> intentional?
>> [61]http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementTimeli
>> neBegin
>>
>> [61]
>> http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementTimelineBegin
>>
>> birtles: but it is well defined
>> ... that's an advantage to having a unified animation model
>>
>> ChrisL: but before it was undefined
>>
>> birtles: re timelineStart, that wasn't intentional
>>
>> krit: can I see a WD?
>>
>> birtles: I want permission to do that yes
>>
>> dino: I enthusiastically support this
>> ... I'm glad Brian is doing this
>> ... wanted something like this for 18 months
>> ... Apple is going to propose something like this in a few
>> weeks anyway, so this is great
>>
>> ChrisL: MS said they wouldn't implement either of these, before
>> there was a consistent model explaining how it works together
>>
>> dino: I have comments on the content, but i'll wait until the
>> document exists
>> ... one is one of the first things people will do with this, is
>> still write much their animation in CSS -- their keyframes,
>> animation parameters
>> ... and just use this as a way to do declarative timing
>> separate from the animation
>> ... in most cases you won't use <animate> elements, but
>> toggling classes at particular times, or in response to
>> particular events
>> ... I said to Brian: it would be nice if the example using
>> <set> on class="", we could have declarative forms of the
>> class-list API; add class, remove class
>> ... something not covered here, should we define a MIME type
>> for a document like this? <link rel=stylesheet>
>> ... you will want this inline in some cases, so in the document
>> you could have a <timesheet> element in HTML
>> ... adding elements to the <head> is difficult, but this could
>> be in the <body> as well
>>
>> birtles: one reason I called it Animation Elements, is it
>> doesn't have to be just for SVG, but these kinds of use cases
>> too
>>
>> shepazu: what namespace should they be in?
>>
>> birtles: I'd like to see what happens with Cameron's proposal
>>
>> dino: I want these to apply to HTML too, so the namespace
>> doesn't matter
>> ... it should follow HTML-like parsing rules as much as
>> possible
>>
>> birtles: perhaps for each element, we need to define the
>> content model so that it can be used in either parsing mode?
>>
>> heycam: it's difficult to add new empty elements in HTML, which
>> don't have closing tags
>>
>> shepazu: we should consider how we can expose animations in an
>> accessible way
>>
>> dino: I think this is the great thing about having the model,
>> you can get at the animations
>>
>> shepazu: I was thinking more of having a <title> for the
>> animation
>>
>> krit: there might already be a document describing
>> accessibility of SMIL
>>
>> cyril: I had another comment
>> ... one of the next steps is to synchronise animations with
>> media elements
>>
>> birtles: yes
>>
>> cyril: that's something I'm trying to work on
>> ... the next topic is Streaming, and it's somehow related
>>
>> birtles: I think that's a common question
>> ... just to reiterate the status there, we have left
>> synchronisation with media out of the first level of Web
>> Animations
>> ... just in the interest of progressing it more quickly
>> ... it's definitely intended to be part of that model
>> ... we already have an idea of how it should work, and a
>> polyfill to demonstrate that
>> ... the current thinking is that we'll write a separate
>> document just for that feature, to say to integrate media with
>> the model
>> ... and the markup for it
>> ... I think Cyril and Dean have shown some interest on working
>> on that before
>>
>> ChrisL: how do you expect that to work? event based?
>>
>> birtles: you'd have another kind of timed item, which is a
>> reference to the media element
>> ... the <video> element needs to be in a particular part of the
>> document for layout purposes
>> ... you would set the timing parameters on the pointer object,
>> and it would trigger the <video> as appropriate
>>
>> cyril: two aspects, controlling the media element, and using
>> the media element to control the timing of other things
>>
>> birtles: wrt Web Animations, we only support the former, where
>> the media is slaved to the timing groups
>> ... but for the reverse, where you put the animations inside
>> the media, I think the Streams stuff you've been working on is
>> the way to approach that
>>
>> dino: are you saying you don't intend to have animations slaved
>> to media unless they're inline in the media?
>>
>> birtles: when you seek the video, you don't have the animations
>> follow; rather you put them both in the group, and you seek the
>> group
>> ... if you need it the other way around, I suggest the
>> Streaming approach
>>
>> dino: that use case is very important to us
>> ... if the answer is put it in a group and seek the group, we
>> can do that
>>
>> cyril: where's the right forum to work on this spec?
>> ... FXTF? SVGWG?
>>
>> ChrisL: I think FX is an obvious home
>> ... LC or before is a good time to get other people involved in
>> reviewing it
>>
>> RESOLUTION: We will take on Animation Elements as an official
>> WD.
>>
>> cyril: we talked about this in the past, the dur="" attribute,
>> does the model cover that?
>> ... on an SVG document?
>>
>> birtles: why on a document, not on a group?
>>
>> cyril: if you want to loop the document?
>>
>> birtles: you'd put it on the root
>> ... every outermost SVG element will act as a nested timeline
>> ... it's like a simple group
>> ... you can't repeat it, but you can seek it
>>
>> cyril: can you put a dur on that?
>>
>> birtles: no
>> ... just put a group around everything you want to repeat
>>
>> ChrisL: could you just construct groups as you want and point
>> them to items to repeat them?
>>
>> birtles: yes
>> ... in the use cases, typically I found it was easier to
>> separate out the timing from the content
>> ... only simple cases can you put them side-by-side
>>
>> SVG streaming update
>>
>> cyril: we have three types of animations
>> ... [cyril reads out the slides]
>>
>> <cyril>
>> [62]http://concolato.wp.mines-telecom.fr/2013/10/24/streaming-o
>> f-svg-animations-on-the-web/
>>
>> [62]
>> http://concolato.wp.mines-telecom.fr/2013/10/24/streaming-of-svg-animations-on-the-web/
>>
>> cyril: I'd like to be able to use SVG in <video> and in <track>
>> ... I implemented this with a shim
>>
>> krit: regarding the same origin restrictions, what do you want
>> to reference? svg documents?
>>
>> cyril: I think the same restrictions should apply as images
>> ... so what is needed for standardisation is:
>> ... first, the guideline document
>> ... support for SVG in the video and track elements
>> ... and support for annotations either in the SVG document, or
>> outside it, to give information about the streaming units
>> ... we have everything else that we need from SVG, CSS, etc.
>> ... the generation tool is open source
>> ... the players aren't yet, but only because they're badly
>> implemented
>> ... I'll put them on GitHub soon
>>
>> krit: I don't have anything against working on that in the WG,
>> but we might not have the expertise here
>>
>> cyril: first step is to apply it to SVG, since SVG works well,
>> has a timeline per document
>> ... HTML doesn't
>>
>> birtles: Web Animations defines a timeline per HTML document
>>
>> cyril: maybe the Guidelines for Streaming SVG is good for this
>> WG though
>>
>> krit: I don't want to push the spec out of this WG, but it
>> sounds like you need expertise from other people
>>
>> cyril: tomorrow we have a session on WebVTT, I hope to present
>> at that
>> ... the HTML Media TF has a lot of activity atm
>>
>> shepazu: I personally like to see this work go forward
>> ... I think Dirk raises good points about who needs to be
>> involved
>>
>> heycam: for identifying the chunks in the document, can you
>> just use IDs?
>>
>> cyril: when the client uses an ID, someone needs to convert
>> that to a byte range
>> ... in my case, I didn't do any server side processing to
>> determine the byte range
>> ... when it's packaged in WebVTT or MP4 you don't have this
>> problem
>>
>> mohamed: what about if we want to use svgz?
>> ... then the byte offsets changed
>>
>> cyril: I'm using Content-Encoding
>> ... so the byte offsets remain the same
>> ... IDs would require adding them to every frame
>> ... when you concatenate two animations, you might have to
>> rename IDs
>>
>> mohamed: how will you deal with the background that is
>> preloaded? will you do complex like intermediate frames?
>>
>> cyril: you could imagine either it's an external resource, or
>> you could data: uri embed it in the svg, or for an mp4 file,
>> you could store it natively without base64 encoding it
>> ... you can put the common elements in the "header" of the
>> document
>>
>> dino: from the Apple part of WebKit, looking cool isn't enough
>> to contribute impl resources
>> ... we need demand from users
>> ... then we have to balance that against what can you achieve
>> currently int he platform without having to implement it
>> ... comparing it to Brian's animation example, that's enabling
>> a subset of developers that don't have as much experience with
>> how to write animations to do something that they couldn't do
>> before, in a nice declarative way
>> ... every time you add a new declarative format to the web,
>> there is a lot of maintenance, security, etc. overhead
>> ... there's a good balance there
>> ... with this proposal I am more concerned
>> ... there's JS in there
>> ... that's not me making a value judgement on the technology in
>> any way
>> ... if we looked at this and saw it could take a couple of
>> person years of impl work, we have to prioritise against many
>> other things
>>
>> cyril: I hear that
>> ... not asking for any browser changes
>> ... the purpose of this was to demonstrate that with a shim you
>> can do it
>> ... then if users want it, let them use it, and if they see
>> perf problems, sync problems, then we might think about
>> embedding that natively in the browser
>>
>> dino: yeah
>>
>> dsinger: what would you need the browsers to do natively? which
>> bits are likely?
>>
>> dino: a great example of this is MSE
>> ... the content distributors asked the browsers that we need to
>> do this thing, and we can't do it unless we have this
>> particular feature
>> ... the ability to generate media streams from js
>> ... that's the way you have to ask browser vendors to do things
>>
>> cyril: I'm not asking browser vendors to do things
>> ... I'm asking agreement to publish guidelines on svg
>> streamable content
>> ... if authors want to stream their svg content, it would be
>> better if they did it this way
>> ... any streaming tool would need some annotations
>> ... but from the browser point of view, there's nothing to be
>> changed, unless users demand it because perf is not there, or
>> ...
>>
>> dsinger: where would that be?
>>
>> cyril: the sync you can achieve here is best effort
>> ... if you need frame accurate ...
>>
>> dino: I think it sounds like a great CG effort
>>
>> cyril: if I'm alone in the CG...
>>
>> dino: if you're alone in the CG, maybe it shouldn't take WG
>> time
>> ... I don't think you will be though
>>
>> shepazu: I think the dedicated conversations you could have
>> there wouldn't distract this group
>>
>> cyril: I think it's also relevant to this group
>> ... not completely, but somehow
>> ... it's related to timed elements
>> ... if you want all these things to be synced, looped, then you
>> could do it with web aimations
>>
>> *animations
>>
>> shepazu: I'd like to see SVG WG people in that CG
>> ... speaking as a W3C person, I want to see smooth transitions
>> from CG to Rec track stuff
>>
>> cyril: having a CG sounds ok
>>
>> <ed> trackbot, end telcon
>>
>> Summary of Action Items
>>
>> [NEW] ACTION: Dirk to change
>> nearestViewportElement/furthestViewportElement to be Element
>> [recorded in
>> [63]http://www.w3.org/2013/11/14-svg-minutes.html#action12]
>> [NEW] ACTION: Dirk to remove SVGAnimatedBoolean and
>> SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
>> [recorded in
>> [64]http://www.w3.org/2013/11/14-svg-minutes.html#action08]
>> [NEW] ACTION: Doug to clarify HTML content in <desc> and
>> <title> elements [recorded in
>> [65]http://www.w3.org/2013/11/14-svg-minutes.html#action04]
>> [NEW] ACTION: Doug to work with Gerardo and Tab to come up with
>> haptic, tactile and 3d media queries [recorded in
>> [66]http://www.w3.org/2013/11/14-svg-minutes.html#action05]
>> [NEW] ACTION: Erik to add use counters to see if
>> nearestViewportElement/furthestViewportElement are used
>> [recorded in
>> [67]http://www.w3.org/2013/11/14-svg-minutes.html#action11]
>> [NEW] ACTION: Erik to ask in the thread about whether SVG
>> specific event handlers should go on GlobalEventHandlers, or
>> separately on SVGElement [recorded in
>> [68]http://www.w3.org/2013/11/14-svg-minutes.html#action09]
>> [NEW] ACTION: Erik to make SVGElement implement
>> GlobalEventHandlers in SVG2. [recorded in
>> [69]http://www.w3.org/2013/11/14-svg-minutes.html#action10]
>> [NEW] ACTION: heycam to look at the performance class
>> requirements and decide whether to remove points or move them
>> into general requirements [recorded in
>> [70]http://www.w3.org/2013/11/14-svg-minutes.html#action01]
>> [NEW] ACTION: heycam to review Resource Priorities
>> specification [recorded in
>> [71]http://www.w3.org/2013/11/14-svg-minutes.html#action02]
>> [NEW] ACTION: Peter Linss deliver document to adapt specs to
>> Shepherd [recorded in
>> [72]http://www.w3.org/2013/11/14-svg-minutes.html#action07]
>> [NEW] ACTION: plinss deliver document to adapt specs to
>> Shepherd [recorded in
>> [73]http://www.w3.org/2013/11/14-svg-minutes.html#action06]
>> [NEW] ACTION: Rich to reference ARIA 1.1 in SVG 2 [recorded in
>> [74]http://www.w3.org/2013/11/14-svg-minutes.html#action03]
>>
>> [End of minutes]
>>
>
>
--
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 Friday, 15 November 2013 09:12:38 UTC