W3C home > Mailing lists > Public > www-svg@w3.org > November 2013

Re: Proposed SVG Streaming CG (Re: minutes, SVG TPAC 2013 F2F Day 1)

From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Date: Fri, 15 Nov 2013 10:11:56 +0100
Message-ID: <5285E55C.8020103@telecom-paristech.fr>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:34 UTC