SVG Working Group Teleconference -- 14 Nov 2013

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

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

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> http://www.w3.org/mid/1383159383.2183.164.camel@chacal

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

<krit> http://lists.w3.org/Archives/Public/www-svg/2013Nov/0002.html

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

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

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> 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 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> http://www.w3.org/dpub/IG/wiki/MathSonifyA11y and 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> 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> 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 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> http://www.whatwg.org/specs/web-apps/current-work/#html-integration-point

<gcapiel> 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> 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 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> 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> 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: 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 http://www.w3.org/2013/11/14-svg-minutes.html#action06]

<trackbot> Error finding 'plinss'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: Peter Linss deliver document to adapt specs to Shepherd [recorded in 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> 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> http://dev.w3.org/SVG/proposals/improving-svg-dom/

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

- DRAFT -

SVG Working Group Teleconference

14 Nov 2013

Attendees

Contents