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

minutes, SVG TPAC 2013 F2F Day 1

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 14 Nov 2013 17:46:12 +0800
Message-ID: <52849BE4.7080801@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>

and below as text:


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

                                - DRAFT -

                     SVG Working Group Teleconference

14 Nov 2013


       [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


           Huangshan, TabAtkins, Eriik, Brian, Satoru, Fujisawa,
           Nikos, Doug, Chris, Dirk, Cyril, Rik, Dean, Cameron,


           nikos, Cameron


      * [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
         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


      [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
    ... 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
    ... 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"

    <krit> </svg>

    cabanier: PDF had the same problem
    ... creating huge maps
    ... they only had a certain position so edges of the map were
    ... 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

    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
    ... 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
    ... would people be amenable to removing the double precision

    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: 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

    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

    <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

    RESOLUTION: Remove performance class requirements from SVG 2

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


      [26] http://www.w3.org/mid/1383159383.2183.164.camel@chacal

    birtles: that's [$1\47] on the wiki page


      [27] http://lists.w3.org/Archives/Public/www-svg/2013Nov/0002.html


      [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


      [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
    ... 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

    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



    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
    ... 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

    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

    <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

    <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

    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

    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
    ... if you're in that mode you can put the unknown ones in

    shepazu: seems to me the only element that I expect (besides
    new SVG elements) to add that might cause problems is the HTML

    <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

    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
    ... 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
    ... 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: 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
    ... 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
    ... so we'd like to take an annotation approach where you can
    just, for example, add parentheses or overwrite the textual
    ... 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

    heycam: for case conversion

    shepazu: in any case it's a kind of whitelisting... it bears

    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

    <gcapiel> [35]http://www.w3.org/dpub/IG/wiki/MathSonifyA11y and

      [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
    ... 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
    ... 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

    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

    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: 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

    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

    richardschwerdtfeger: it's an API mapping issue more than

    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

    <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



    <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
    ... 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

    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

    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


      [42] http://www.w3.org/dpub/IG/wiki/SVGMediaQueriesA11y

    shepazu: I spoke to the hypothesis folks and I'm confident it's

    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
    ... 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

    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

    <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

    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

    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

shepherd for svg repo

    heycam: are there some standard rules to make it easy for us to

    plinss: there is documentation on shepherd as well

    <TabAtkins> Documetnation:


    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
    ... 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

    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

    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

    Chris: [Going crazy]

    heycam: Is the markup sufficient in SVG spec?

    plinss: no it is not, most of the things are not recognized at

    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

    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

    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

    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

    <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

    <trackbot> Error finding 'plinss'. You can review and register
    nicknames at

      [48] http://www.w3.org/Graphics/SVG/WG/track/users%3E.

    <scribe> ACTION: Peter Linss deliver document to adapt specs to
    Shepherd [recorded in

    <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
    ... what ever format you use, it must be machnine parable


    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

    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

    <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

    <birtles> shepazu: what is the goal of the proposal?

    <birtles> ... making a new root element is an outcome not a

    <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

    <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

    <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

    <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

    <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

    <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

    <birtles> ChrisL: we're focussing too much on the impact on

    <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

    <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

    <birtles> ... it will take 2~3 years until it is implemented

    <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

    <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

    <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

    <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

    <birtles> ... so we could dedicate more time to it at the next

    <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?


    <birtles> ed: it's only used in one place

    <birtles> krit: I doubt anyone uses it

    <birtles> heycam: was externalResourcesRequired the only other

    <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

    <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

    <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

    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: 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
    ... 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

    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
    ... 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

    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
    ... 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

    heycam: how much do we really need to keep

    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

    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

    <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

    <trackbot> Created ACTION-3543 - Make svgelement implement
    globaleventhandlers in svg2. [on Erik Dahlström - due

Is it future-proof to return SVGElement on nearestViewportElement and



    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

    heycam: is this when you have say a <circle> with no ancestor

    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

    <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

    <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


      [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
    ... 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

    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


    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

    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

    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

    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
    ... 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
    ... 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

    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: 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
    ... 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

    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

    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

    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
    ... 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


    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
    [NEW] ACTION: Dirk to remove SVGAnimatedBoolean and
    SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
    [recorded in
    [NEW] ACTION: Doug to clarify HTML content in <desc> and
    <title> elements [recorded in
    [NEW] ACTION: Doug to work with Gerardo and Tab to come up with
    haptic, tactile and 3d media queries [recorded in
    [NEW] ACTION: Erik to add use counters to see if
    nearestViewportElement/furthestViewportElement are used
    [recorded in
    [NEW] ACTION: Erik to ask in the thread about whether SVG
    specific event handlers should go on GlobalEventHandlers, or
    separately on SVGElement [recorded in
    [NEW] ACTION: Erik to make SVGElement implement
    GlobalEventHandlers in SVG2. [recorded in
    [NEW] ACTION: heycam to look at the performance class
    requirements and decide whether to remove points or move them
    into general requirements [recorded in
    [NEW] ACTION: heycam to review Resource Priorities
    specification [recorded in
    [NEW] ACTION: Peter Linss deliver document to adapt specs to
    Shepherd [recorded in
    [NEW] ACTION: plinss deliver document to adapt specs to
    Shepherd [recorded in
    [NEW] ACTION: Rich to reference ARIA 1.1 in SVG 2 [recorded in

    [End of minutes]
Received on Thursday, 14 November 2013 09:47:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:47 UTC