- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Fri, 15 Nov 2013 09:38:46 +0100
- To: www-svg@w3.org
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 08:39:19 UTC