minutes, SVG TPAC 2013 F2F Day 1 from Cameron McCormack on 2013-11-14 (public-svg-wg@w3.org from October to December 2013)

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

http://www.w3.org/2013/11/14-svg-minutes.html

and below as text:

[1]W3C

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

- DRAFT -

SVG Working Group Teleconference

14 Nov 2013

[2]Agenda

[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2013/Agenda

See also: [3]IRC log

[3] http://www.w3.org/2013/11/14-svg-irc

Attendees

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

Regrets
Chair
ed

Scribe
nikos, Cameron

Contents

* [4]Topics
1. [5]Numeric Precision for SVG
2. [6]Proposals/ResourcePriorities for SVG
3. [7]definition of 'zoom' for zoom media feature
4. [8]SVG accessibility
5. [9]z-index in SVG
6. [10]Using Bikeshed for SVG specs
7. [11]shepherd for svg repo
8. [12]new SVG DOM proposal
9. [13]SVGAnimatedBoolean
10. [14]SVG DOM continued
11. [15]SVGElement implementing global event handlers
(onfoo)
12. [16]Is it future-proof to return SVGElement on
nearestViewportElement and farthestViewportElement?
13. [17]Animation Elements
14. [18]SVG streaming update
* [19]Summary of Action Items
__________________________________________________________

<nikos> scribe: nikos

<ed> scribeNick: nikos

<TabAtkins> Yo, we got polycom?

<ed> TabAtkins, we're setting it up

<TabAtkins> Cool, thanks.

<cyril> regarding the agenda, I think it would make more sense
to discuss "SVG streaming update" after Brian's "Web Animation"
this afternoon

<heycam> trackbot, start telcon

<trackbot> Date: 14 November 2013

<scribe> scribe: nikos

<heycam> TabAtkins, we can't call out from here

<TabAtkins> For god sakes, Zakim.

<TabAtkins> I know that, Zakim.

<TabAtkins> We all know that.

<TabAtkins> I'll be here the whole time, so don't worry.

<TabAtkins> It's 5pm to 2am for me, and I've already done this
for 2 days.

<TabAtkins> Heh.

Numeric Precision for SVG

<birtles>
[20]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/NumberPrec
ision

[20] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/NumberPrecision

birtles: Takagi-san prepared this wiki page. You can read the
issue yourself
... SVG 1.1 only requires single precision floating point
... but for mapping use cases it appears that double precision
is neccessary
... what are your thoughts?

heycam: We had a meeting recently with all our layout and
graphics people
... anytime graphics people heard double precision they cringed
... GPU HW only works in floats
... and it's going to me more and more likely we'll be
restricted to floats as we move more into HW
... currently changing graphics library layers and that uses
floats
... I feel it'll be difficult to require double precision

krit: SVG 1 doesn't require double but allows it

heycam: SVG 1 spec has different performance class requirements
... high quality viewer must support double
... I'm wondering how realistic that is now

TabAtkins: Takagi-san made a wiki page that describes a
requirement for precision of 5 decimal places
... floats have 7 digits
... so why is this a problem?

<TabAtkins> s/made a wiki page that has/said on the wiki page
that he needs/

birtles: I clarified with Takagi-san and if that's the case
thats ok
... but tests with IE show that it appears to use fixed point
... with only 3 digits of precision

krit: that's true. Firefox is the same

heycam: 16.16 fixed point stuff comes from Cairo
... I can't remember the exact plan for software rendering back
end
... but we are removing Cairo as the intermediate API layer
... most of the back ends will use single precision
... so perhaps for this use case it will get better in Firefox

krit: fixed point is coming from HTML
... It's not a requirement for Skia but Blink is still using
fixed point for that

heycam: you're talking about for CSS layout?

krit: yes
... Since SVG is using the same engine as HTML wouldn't it be
the case for both?

heycam: I think it could be reasonable to use different code
for layout of CSS boxes compared to 2d graphics APIs
... if IE uses fixed point for graphics stuff and CSS layout
then perhaps there's some reason for linking the two

Rossen__: what were the tests?

krit: viewbox with 0.00001 will render differently

Rossen__: for CSS values we use fixed point. For SVG we use as
much floating point as possible

krit: we parse all of CSS values to fixed point

Rossen__: we parse SVG to floating point

krit: I can write a test

heycam: one thing to clarify is whether single precision
floating point is enough?

birtles: It may be enough to render with single precision but
if you parse them as single precision, then by the time you
apply transformation matrices you may lose precision

[21] http://www.w3.org/2000/svg
[22] http://www.w3.org/1999/xlink

cabanier: PDF had the same problem
... creating huge maps
... they only had a certain position so edges of the map were
rough
... so to solve you translate
... it's an internal engine thing

heycam: so the answer is to not have everything in the one
co-ordinate system

birtles: I don't know how you'd specify it

krit: it doesn't need to be specified. It's an implementation
detail

cabanier: so when you zoom all the way out. fine details may
not be right
... it only matters when you zoom in

heycam: in reality you have different sources of data,
different tiles that are merged
... they're not going to be in the same co-ord system
originally
... some of the proposals we've seen before transform them into
a common co-ord system
... leaving the data like that and not having one co-ord system
seems to be the right thing to do
... when you combine global view and some fine detail - say if
you have country path information that can be viewed zoomed
out, but if you zoomed into a border town region and look at
the roads there, then by the time you do that you have lost the
precision of the global view
... maybe different data sources should be used

stakagi: that's ok

krit: the test case I posted previous shows that IE does
support floating point precision and Firefox doesn't
... that will hopefully change in the future

ed: so we don't need to make any change?

heycam: something to think about when defining conformance
classes
... would people be amenable to removing the double precision
requirement?

krit: for most things in WebKit and Blink we use single
precision internally even if API uses doubles
... exception is everything from CSS is still double
... but it's converted to single at some point

heycam: I was considering changing webidl to float to match JS
... but it makes sense to leave as float since APIs use that
... I don't think it's a great idea to have different classes
that give different results
... especially for path positions
... I'd rather remove it

birtles: the whole class?

shepazu: CSS resolved to use rfc6919

heycam: so these are the things that high quality viewers are
meant to do

<heycam>
[23]https://svgwg.org/svg2-draft/conform.html#ConformingHighQua
litySVGViewers

[23]
https://svgwg.org/svg2-draft/conform.html#ConformingHighQualitySVGViewers

heycam: this was written 12 years ago

shepazu: I don't think that these are modern constraints

heycam: they're the wrong level also

shepazu: let's remove this bit compeltely

krit: image rendering is specified in CSS
... might not be a good thing to have in SVG
... I would definitely remove point 4
... I would remove it as a requirement to decide if you use
high quality or low quality rendering

TabAtkins: are you saying people should always respect the
image rendering property regardless of mode you're in?
... if so I agree

krit: yes

shepazu: looking through these, I don't think they're
meaningful in today's market
... I don't know who this is written for
... we should just remove it
... if we decide we'll get better performance out of floats
rather than doubles

krit: I don't think floats or doubles are a good criteria for
quality

shepazu: all these requirements have that problem

<scribe> ACTION: heycam to look at the performance class
requirements and decide whether to remove points or move them
into general requirements [recorded in
[24]http://www.w3.org/2013/11/14-svg-minutes.html#action01]

<trackbot> Created ACTION-3535 - Look at the performance class
requirements and decide whether to remove points or move them
into general requirements [on Cameron McCormack - due
2013-11-21].

RESOLUTION: Remove performance class requirements from SVG 2

Proposals/ResourcePriorities for SVG

[25]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePr
iorities_for_SVG

[25]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePriorities_for_SVG

birtles: Takagi-san prepared this wiki page
... this is about resource priorities spec from web performance
working group
... first issue is about the postpone attribute
... and it's currently defined in terms of bounding boxes
... but Takagi-san has some feedback to suggest it would be
useful if it could also be used in regards to zooming
... currently says that things with bounding box outside
current viewport don't need to be loaded
... but it seems like that would be a good thing for
conditionally loading tiles
... We've sent feedback but I don't know if it's been taken on
board yet

krit: This sounds like a previous discussion on www-svg
... A thread about resource priorities and SVG

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

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

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

<krit>
[27]http://lists.w3.org/Archives/Public/www-svg/2013Nov/0002.ht
ml

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

<krit>
[28]http://lists.w3.org/Archives/Public/www-svg/2013Nov/0003.ht
ml

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

krit: this was my reply

birtles: the proposal is that you would have different tiles
(say several iframe elements in svg). For each you would have
the postpone attribute

<stakagi>
[29]http://lists.w3.org/Archives/Public/www-svg/2013Nov/0021.ht
ml

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

birtles: you would only load the ones within the bounding box
and at the right zoom level
... it's not part of one image resource, it's several resource
... the feedback here is that resource priorities only allows
you to base the conditional loading on the viewport and the
bounding box of the tile
... so it doesn't take into account zoom

krit: doesn't the zoom level also influence the viewport?

birtles: it's not enough by itself
... you could have several tiles that occupy the 2d space but
are at several zoom levels. You don't want to load them all
... the facility to achieve that might be to use media queries

krit: I think this discussion would have been better in FXTF

birtles: one piece did come up then - it's next on the agenda

heycam: If we did have a separate zoom media query, what things
about the resource priorities needs to be changed to
accommodate this use case?

birtles: the way postpone is currently described is purely
based on viewport and bounding box

heycam: so you want to link it to this future zoom media query
as well

birtles: I think that's Takagi-san's idea
... I think this is something that we can't decide in this
group
... but at least it has helped to clarify the requirements
... text in resource priorities spec doesn't quite align with
these use cases
... because it says tjat ot
... that it's bounding box or display:none that defines whether
resources are loaded

heycam: what about the fact that they're adding attributes to
SVG without asking?
... is that an issue? or do we just want to review their
changes?

krit: I did and initial review but would be happy if others did
as well
... right now the spec has more issues with HTML than with SVG
... it's an easy spec to review

heycam: I'll have a look to see how it fits with SVG

ed: this is basically the same functionality as external
resources required functionality of SVG 1.1

definition of 'zoom' for zoom media feature

[30]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/zoom_media
_feature

[30]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/zoom_media_feature

shepazu: did you see the email from Boeing about zoom and pan
and load events?

birtles: I think that's a separate issue
... this is something I don't think we need to discuss here
because there was discussion in CSS on Sunday
... Takagi-san, myself, and Dean spoke about this later
... Ted from Apple has an action to look at different zoom
media queries
... the current ones available aren't sufficient for pinch zoom
and such
... Takagi-san has explored other ways a zoom media query could
be specified and we've shown this to Dean to pass to Ted

TabAtkins: I notice all four of these definitions include scale
transforms
... do we have any clue how those work with media features?

heycam: so results of media query can't depend on property
values because that's cyclic?

TabAtkins: yes

heycam: there is at least one type of zooming that isn't
reflected in the styling
... the pinch zooming and the dot current scale

TabAtkins: there might still be a use case for pinch zooming
because you're going to want to tell when people are doing that
... things that are trying to do resolution based stuff don't
want to respond to pinch zoom but maps, etc would

dino: I think it's better they're all separated and
individually queryable

TabAtkins: that might make sense

dino: I think step 1 is to define all the terms

TabAtkins: they're defined in CSS OM view and referenced from
media queries

krit: it might make sense to see if the pinch zooming from SVG
is different
... it might be different if you want to pinch zoom in a
document without zooming the outer doc

Rossen__: how is that different to an iframe?

krit: just that SVG isn't an iframe

Rossen__: should generalise that behaviour
... shouldn't apply just to SVG but to all elements

heycam: that was how I thought we might be able to do zoom and
pan

shepazu: is SVG a special kind of content in HTML? A class that
both SVG and iframe fall into?

krit: SVG has a viewport
... makes it easier to define pinch and zoom

birtles: Also when you have SVG loaded in an iframe and the
parent doc is being zoomed that information also has to be
available to the SVG

krit: should be possible with media queries

heycam: do you need to know individual transforms in the stack?

stakagi: probably yes
... seems likely not not totally sure at the moment

<birtles> actually, not the individual transforms, but the
combined result

birtles: Next step is to see what Ted comes up with
... and provide feedback

<scribe> ACTION: heycam to review Resource Priorities
specification [recorded in
[31]http://www.w3.org/2013/11/14-svg-minutes.html#action02]

<trackbot> Created ACTION-3536 - Review resource priorities
specification [on Cameron McCormack - due 2013-11-21].

Topics: Should parsed unknown elements implement SVGElement?

[32]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23468

[32] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23468

<TabAtkins> Yes.

ed: when you parse elements that SVG doesn't know about but
that are in the SVG namespace
... it seems that all browsers put SVGElement interface on
those elements
... rather than Element or SVGUnknownElement
... which would be similar to HTML

krit: if we define one of these elements later it starts
rendering for all content
... I don't think this is an issue
... in this case since browsers already have behaviour, we
should just specify it

ed: so just specify that SVGElement should be used in this
case.

heycam: is there any advantage to doing things the HTML way?

shepazu: right now they're put in the SVG namespace

heycam: SVGElement has some things. e.g. nearest viewport

but SVGUnknownElement will inherit from SVGElement anyway

scribe: the only argument is for consistency with HTML

shepazu: the advantage I see is if you're trying to detect
whether a browser supports a particular - say star
... if the user agent doesn't know what to do with star, it
might be nice to know that the UA doesn't know what to do with
it

heycam: I think you can do that anyway because you can check
object.getPrototypeOf the dom node
... that would return a specific sub type

<TabAtkins> (el instanceof SVGElement) && (el.prototype ==
SVGElement.prototype) { /* Unknown element! */ }

shepazu: what about if it's an element of another namespace?

krit: if we decide to put every element into the HTML namespace
then SVG elements will use HTMLElement and HTMLUnknownElement

heycam: I think it depends on how we handle the parsing of that
... as long as you get the outer thing - SVG or graphics in my
proposal
... if you're in that mode you can put the unknown ones in
whatever

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

<TabAtkins> +1

shepazu: straw poll, who would like us to allow HTML root
element without the foreignObject wrapper

<TabAtkins> +1

shepazu: so will this cause problems in that context?

Rossen__: in this context inline content is treated how?
... I mean text in SVG

<TabAtkins> <svg>foo</svg>?

<Rossen__> <svg>Hello World</svg>

<krit> <svg>More examples</svg>

Are you saying first example is different to second example?

<Rossen__> <svg><span>Hellow World</span></svg>

<TabAtkins> Yes, different.

shepazu: yes that would be different

<TabAtkins> <span> makes HTML element. Raw text is just
ignored.

shepazu: do we need the HTML root?
... All i was proposing was that the HTML tag be required to
insert HTML content

Rossen__: I misunderstood

krit: I suggested HTML in SVG without the HTML tag
... just needs a viewport

shepazu: who is going to do this?

TabAtkins: I'll do it

shepazu: the question is whether it causes us problems

heycam: depends how we do parsing and namespaces and so on
... but should be able to test whether an element is recognised
or not in any case

shepazu: I wonder if inserting SVG dynamically will behave
different
... currently in implementations you get different behaviour

krit: CreateElement doesn't trigger the parser
... I think what Doug is saying is if you have inner html and
you use a rect
... you have to nest it in an SVG element

ed: I think we recently added inner html to SVG elements and it
does use the context

shepazu: Currently if I put an HTML element it's treated as an
SVG element
... if we specify the HTML elements as things that go in
another namespace
... will there be a hack (not to be specced just to be
considered) to allow developers to get what they expect in
older UAs
... I'll do some testing
... my only concern is that specific case of what happens when
there's the bare name HTML
... For the original question, let's specify what browsers are
already doing

RESOLUTION: We will spec what browsers are currently doing -
use SVGElement interface for unknown elements.

<ed> -- break until 11am --

<TabAtkins> The conf was only for 1 hour, maybe zakim doesn't
want to let new people in?

<birtles> scribenick: birtles

SVG accessibility

gcapiel: I lead engineering at Benetech
... for Benetech we have a few projects were accessibility is a
big projects
... including bookshare
... which is a very large library of accessible books
... we also have a project which is in collaboration with DAISY
and NCAM
... we are working on "diagram center"
... we are focussing on, "How do we lower the cost of creating
accessible images?"
... "What standards do we need to achieve that goal?"
... we want accessible images in e-books and across the open
web
... I'm in the digital publishing group composed of people from
the book publishing industry
... we have some representatives around accessibility
... and some w3c staff
... as part of that we've been working to identify gaps in the
open web platform that publishers need
... I've been focussing on accessibility

<gcapiel>
[33]http://www.w3.org/dpub/IG/wiki/UseCase_Directory#General_Ac
cessibility_Use_Cases

[33]
http://www.w3.org/dpub/IG/wiki/UseCase_Directory#General_Accessibility_Use_Cases

gcapiel: it's tricky because you really need to accessibility
for everything
... not just ebooks
... the link above is a set of use cases I'll walk through
... the first use case is about rendering mathematics using SVG
instead of MathML
... MathML support is either missing or inconsistent
... it's not clear when that issue will be resolve
... so what publishers are doing is using images (esp. PNG and
JPEG)
... they do that because inexpensive devices like kindle don't
support mathml at all
... some of those devices don't support SVG either but some do
... so we're not going to be able to get publishers to push out
MathML in the near future but we can do better than bitmaps
... so we've been looking at using MathJAX on the server using
Node.js to convert MathML to SVG
... that also lets us work with open-source technology and
using ChromeVox, Google's screen reader technology
... using that tool, you can feed it MathML and get back both
SVG and a description of that math

heycam: is it a problem that Blink is dropping MathML support?

gcapiel: no it's not really since it's still in the DOM
... even if it's not rendered
... I've been thinking about how we can improve this situation
and one thing we could do is add the source MathML in the SVG
... that would allow screen readers to pick it up

<richardschwerdtfeger> q

gcapiel: the problem with the textual description is that the
cognitive load of hearing it all is significant--you really
need to be able to navigate the mathml
... one more thing, Rich was involved in adding tabindex to SVG
which is great
... but I think there may be uses for that with math too
... so you can navigate the tree

richardschwerdtfeger, one of the things I asked for was to have
direct access to the mathml

scribe: are you suggesting embedding it in the SVG?

gcapiel: yes, that's what I'm suggesting

richardschwerdtfeger: makes sense

gcapiel: the last requirement I would add around that is that
mathml that renders visually nicely, often doesn't have enough
semantics for a screen reader
... for example, you might need additional parentheses

heycam: is that because people generally write presentational
mathml not content mathml

gcapiel: yes, content mathml hasn't really gone anywhere
... we've been putting work into how to use crowdsourcing to
improve the accessibility of existing math content
... and have had a lot of success
... but often they don't have access to the source or the web
server
... so we'd like to take an annotation approach where you can
just, for example, add parentheses or overwrite the textual
description
... the screen reader would notice this URI and pull down the
additional annotations from the cloud
... so it would be great if there was a standard way for
marking up those URIs

heycam: I have some practical questions about how to markup
MathML in the SVG spec so I might get your help on that later

gcapiel: yes, of course.
... aria-describedby might help with this

richardschwerdtfeger: I could help with adding that

heycam: do we reference that properly yet?

richardschwerdtfeger: yes we do
... is it a problem that ARIA 1.1 is only a FPWD?

heycam: I think it's fine for now

<scribe> ACTION: Rich to reference ARIA 1.1 in SVG 2 [recorded
in [34]http://www.w3.org/2013/11/14-svg-minutes.html#action03]

<trackbot> Created ACTION-3537 - Reference aria 1.1 in svg 2
[on Richard Schwerdtfeger - due 2013-11-21].

krit: putting presentation mathml into SVG, this should already
be possible using foreignObject
... with the limitation that you need to specify width/height
which is not very convenient
... it would be nice to allow mathml to be included directly
but that would require changes to the html parser

heycam: might be good to keep in mind when we discuss HTML in
SVG later

shepazu: that might just fall out of the HTML model

heycam: I suspect that MathML names when you're parsing in SVG
parsing mode will become SVG elements

shepazu: I wonder if that's the case since SVG elements are
whitelisted

heycam: for case conversion

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

krit: if we really want to move MathML names in to the SVG
space... that might be a problem

heycam: we should consider this when we talk about HTML in SVG
later

<gcapiel> [35]http://www.w3.org/dpub/IG/wiki/MathSonifyA11y and
[36]http://dl.dropboxusercontent.com/u/39156804/graph.html

[35] http://www.w3.org/dpub/IG/wiki/MathSonifyA11y
[36] http://dl.dropboxusercontent.com/u/39156804/graph.html

gcapiel: I'll move onto the next use case
... this concerns sonification using multi-modal delivery for
SVG
... I have a use case and a demo using Web Audio and Web Speec
to sonify
... the demo works with that specific SVG and similar ones but
is not generally useful
... since it needs semantic data like axes and tick marks

ChrisL: how do you find that data in the demo

shepazu: in this demo it works since the files have a
consistent layout
... it's something I'd like to aria
... e.g. a "data-point" role or something of that ilk
... it distinguishes that piece of information from the other
graphics on the page
... likewise for axes

heycam: how broadly do you want to look at semantics of
diagrammatic content
... there's quite a range

gcapiel: I guess it could be a wider range because not
everything can be sonified
... but some of this might apply to tactile output too

<gcapiel> [37]http://www.w3.org/dpub/IG/wiki/SVGStructDesc

[37] http://www.w3.org/dpub/IG/wiki/SVGStructDesc

gcapiel: the next use case (above) covers including HTML inside
SVG
... and the reason we care about that is [paused for demo]

(shepazu demos sonification)

shepazu: we want to distinguish sonification from vocalization
... we can read out different values but that doesn't give the
use the gist of the function

(demo makes sounds whose pitch varies with the y-value of the
graph)

scribe: compare this to existing SVG accessibility features
... there's also a Web Speech API that would read off text
... so we can make it read out this chart as a list
... it would be better if we could allow users to navigate
around the chart
... using the keyboard

richardschwerdtfeger: so you're looking at adding semantics to
assist the textual description of the chart?

shepazu: yes, I don't want to boil the ocean, but for common
items

richardschwerdtfeger: I think I can help with this

<richardschwerdtfeger> ack

ChrisL: often stuff which is for accessibility gets a boost
when it also has some use in another context
... this reminds me of an experiment where they sonified
various properties of blood so you didn't have to switch
between looking down a microscope and a chart
... so it was a real benefit for sighted people as well

gcapiel: there is also research that you retain information
better if you receive it in a multi-modal way

shepazu: yes, but we're not proposing adding sonification to
SVG but to add the hooks for these alternative representations

heycam: and these hooks would be aria features

shepazu: yes

heycam: so then we don't need to do anything much accept
allowing these new attributes

ChrisL: yes, you just need the hooks

shepazu: having the ability to markup in a commonly understood
way allows easier extraction and re-use of the data

<gcapiel>
[38]http://diagramcenter.org/standards-and-practices/content-mo
del.html

[38]
http://diagramcenter.org/standards-and-practices/content-model.html

gcapiel: now I'd like to talk about more general descriptions
... this is an image and its description
... it's an infographic really
... it has a lot of information that would be hard to capture
in an alt attribute
... I guess you could use describedby but then the description
might be separated from the image itself
... this is where having HTML in SVG might be useful

heycam: how would you imagine this working?

shepazu: so currently the content model of <desc> is text
... if that allowed markup we could have tables, lists etc.

ChrisL: putting bare-name elements inside <desc> is fine since
it doesn't need positioning information etc.
... seems reasonable to put bare-name HTML there

heycam: so I think the HTML parser already switches into
allowing HTML content inside <desc>, <title>, and
<foreignObject>

gcapiel: it's not in the spec though

shepazu: we need to clarify in the spec and make test cases

heycam: one part is to make sure the HTML parser does the right
thing and the other part is blessing that pattern in SVG
... and we only really need to do the second part

shepazu: any objections?

heycam: is that idea that you target that <desc> with an ARIA
describedby

richardschwerdtfeger: it's an API mapping issue more than
anything

gcapiel: here's a use case: I'm a publisher and want to put
some images in my text book
... I get a water cycle image from a site in SVG format
... I want the description to be packaged inside the SVG

heycam: my question is more about how to refer to the <desc>
... currently <desc> applies to its parent element
... and that may or may not be appropriate
... sometimes you may want to have multiple elements targetting
the same desc

richardschwerdtfeger: one difficulty is you have HTML content
that is not actually rendered
... I assume that stuff is in the DOM and an AT can navigate it
... a magnifier will have challenges if it's not rendered
... one way around that is to have it as an iframe
... but you want it all in the same document?

shepazu: I see what you're saying but I think this is an
implementation detail

richardschwerdtfeger: ok

RESOLUTION: <desc> should allow HTML markup and we should have
tests for this and recommend this practice

shepazu: we should cross-reference this when we talk about
inline HTML in general

<scribe> ACTION: Doug to clarify HTML content in <desc> and
<title> elements [recorded in
[39]http://www.w3.org/2013/11/14-svg-minutes.html#action04]

<trackbot> Created ACTION-3538 - Clarify html content in <desc>
and <title> elements [on Doug Schepers - due 2013-11-21].

heycam: I checked the HTML parsing and yes, for <title>,
<desc>, and <foreignObject> parsing switches back to HTML

<heycam>
[40]http://www.whatwg.org/specs/web-apps/current-work/#html-int
egration-point

[40]
http://www.whatwg.org/specs/web-apps/current-work/#html-integration-point

<gcapiel> [41]http://www.w3.org/dpub/IG/wiki/SVGCrowdDesc

[41] http://www.w3.org/dpub/IG/wiki/SVGCrowdDesc

gcapiel: the next use case is around post-production of
descriptions
... I have an SVG in an ePUB and it has been shipped but it's
not until it reaches a student that someone notices that the
description is missing or incorrect
... we want to have a way to fix that
... the author might actually describe in the SVG a link to a
point where those crowdsource improvements could be pulled in
... after some content has been created how does someone
annotate it

ChrisL: so is this about forking or about having an extension
point?

gcapiel: the latter since there may be copyright issues

ChrisL: it opens up issues about an approval process
... it sounds similar to crowdsourcing captions for videos

gcapiel: yes, it's similar to that which has been very
successful

shepazu: gcapiel and I talked about this and I think this is a
general use case
... we might want to plug into the work going on in the open
annotations world
... so perhaps you could hook your user agent into a particular
open annotation framework
... so we just need the hooks

gcapiel: so we need to look into whether that can be applied to
SVG

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

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

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

gcapiel: here is another use case
... this SVG is very useful for a sighted user
... but a lot of the information is decorative and so if this
was converted to a tactile format a lot of that information
would actually obscure the information
... so currently the way this is handled is by creating a
separate image
... but I'd like to make it so you could use the same format
... and going forward we might even use 3D printers for tactile
output
... which might have slightly different requirements still
... so we might need media queries for this

shepazu: I think this is actually a CSS questions

heycam: I agree. It would be good to know if the kind of
modifications you want to make can be all styled with CSS
properties

shepazu: I'm pretty sure they could be. e.g. hiding/displaying
content, replacing a pattern with a fill etc.
... we'll look into this and come back with a proposal

heycam: if there are things that can't be styled with CSS then
we'll need to handle that

TabAtkins: I'm editing media queries now
... just a note, we are deprecating media types nw

<scribe> ACTION: Doug to work with Gerardo and Tab to come up
with haptic, tactile and 3d media queries [recorded in
[43]http://www.w3.org/2013/11/14-svg-minutes.html#action05]

<trackbot> Created ACTION-3539 - Work with gerardo and tab to
come up with haptic, tactile and 3d media queries [on Doug
Schepers - due 2013-11-21].

<gcapiel> [44]http://www.w3.org/dpub/IG/wiki/SVGReuse

[44] http://www.w3.org/dpub/IG/wiki/SVGReuse

gcapiel: the final use case related to re-using the same SVG
multiple times in the same page
... one idea was referencing it from an iframe
... the challenge with that is that from a useability
point-of-view they are quite painful

krit: can you repeat the use case

gcapiel: I have an image of a basketball and it's going to
appear three times on page 5, then page 8 and then in another
text book
... I want to reference it as a file

<ChrisL> sounds like "fix the screen readers to not break on
iframe"

shepazu: you can use the <use> element for this

<TabAtkins> (Chrome, maybe others, don't allow external <use>,
but otherwise yeah. <use> in-document is fine. <iframe> or
whatever out-of-document is good.)

gcapiel: we need to look at iframes for this

krit: if it's a basketball and <img> is probably better

richardschwerdtfeger: regarding iframes and JAWS is that we're
getting to treat them basically like navs

gcapiel: no that's fine. I'm just concerned about useability

heycam: the seamless attribute on <iframe> might also be a hint
here

richardschwerdtfeger: people are using iframes more for mashups
... to isolate part of the content
... I can help work with the useability issues

gcapiel: sounds good

z-index in SVG

kurosawa_: my question is, is z-index a requirement for SVG2?

heycam: I think Tab might have been assigned to this?

<TabAtkins> Was I?

<TabAtkins> Sure, okay.

heycam: if he or somebody could start adding that to the spec
before the end of the year then it will be in SVG2

shepazu: is that good or bad for accessibility?

kurosawa_: to make SVG content accessibility we need to care
about reading order
... but SVG using forces a certain rendering order

shepazu: so a z-index will allow to provide a different reading
order to rendering order?

kurosawa_: yes

ChrisL: yes, that's right--sometimes that's how you'd do it
... but sometimes you want to allow different reading orders
... and you wouldn't have to keep manipulate the document every
time for each different reading order

kurosawa_: I agree that are multiple reading orders but if we
consider if I hover over some graphics and they move them to
the front... we'd need to re-attach them at a different point
of the document (without z-index)

ChrisL: I agree that for that use case z-index is the
appropriate way to do it

shepazu: yes, we do want z-index in SVG2 because it also helps
with accessibility

Using Bikeshed for SVG specs

krit: I'd like to have the discussion with Peter first

(deferred for now)

(break for lunch)

<krit> [45]http://memedad.com

[45] http://memedad.com/

<krit> ScribeNick: krit

plinss: Shepherd has a couple of purposes
... manager of test suite

heycam: yes, one part we want to use it
... are interested in anchors

plinss: yes, shepherd does that as well
... tries to clasify anchors
... but needs understanding what is defined and the
relationship to element, attribute and values
... in relies on markup in the spec
... tab and I came up with different ways to do it
... I don’t care which way, I ‘ll adapt to the spec style as
well

shepherd for svg repo

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

plinss: there is documentation on shepherd as well

<TabAtkins> Documetnation:
[46]https://github.com/tabatkins/bikeshed/blob/master/docs/defi
nitions-autolinks.md

[46]
https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md

heycam: we use combination of Bikeshed and sag pre-processor on
some FX specs

cyril: what is Bikeshed?

<TabAtkins> (For the in-spec markup that Bikeshed recognizes.)

heycam: a CSS pre-processor

plinss: with automatic cross linking of specs based on data of
shepeherd
... Bikeshed calls shepherd and asks for anchors
... and specs can link back as welll

<TabAtkins> krit, one word Bikeshed.

heycam: we have similar things in SVG pre-processor but data is
in external XML file

plinss: we use json

TabAtkins: sheperd watches changes on other specs, no need to
manually update an XML file

heycam: if shepherd watch our specs as well would be great and
having the right meta data in our specs as well

<TabAtkins> Bikeshed also does automatic IDL linking/defining
markup, generates railroad diagrams, and a bunch of other
things.

plinss: shepherd is watching all specs in FX already (with
exception of ReSpec specs)

<TabAtkins> Big weakness for SVG right now is that Bikeshed
doesn't know how to generate multi-page specs yet.

<TabAtkins> (I plan to do so, but haven't gotten to it yet.)

plinss: I do want to have SVG scanned daily as well, and do it
already

cyril: shepherd is the server env that scans things? How is it
related to bike shed?

Chris: Is checking the specs

<heycam> I sometimes wonder whether we should make SVG2
primarily a one page spec, but also to have generated
multi-page version.

Chris: you can do links by automatic cross linking between
specs and tests can reference specs as well
... [explaining some things of Bikeshed from the docs]

shepazu: Bikeshed does not yet support multipage steps

plinss: no problem for Shepherd at least
... Shepherd can find specs where ever sections move within the
spec

Chris: [Going crazy]

heycam: Is the markup sufficient in SVG spec?

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

heycam: using propdef even for element and attribute defintions

plinss: that is bad for identifying things
... data-def type is a way to identify

<TabAtkins> <dfn attribute>foo</dfn> becomes <dfn
data-dfn-type="attribute">foo</dfn> after Bikeshedding.

plinss: another way is a lot of short cuts
... propdef is another one as is elementdef and attributedef

<TabAtkins> <div class="propdef"><dfn>foo</dfn></div> makes
"foo" a property def.

plinss: Shepherd understands all IDL

krit: we can auto generate many things so we can change things
easily with exception for attributes

TabAtkins: since propdef is used for styling purposes, there is
a new class .defintion with the same purpose now

heycam: we want the big blue element definition tables
... with content model and a lot more information and Shepher
could use that in the future

plinss: they were defining elements in definition sections
... so you could just link to the section headings
... HTML spec does not have all id’s set correctly yet

shepazu: we adapted in the past already and adapting
confincient the CSS WG is using makes sense...
... easier to maintain
... does SVG WG object to use convenients Shepherd is
expecting?

ChrisL: depends.. on testing yes. Bikeshed? maybe not

shepazu: mean we should adapt spec styling so that Shepherd can
pick things up more easily

ChrisL: yes, we should definitely

<ChrisL> bikeshed is fine if it could do a multi-doc spec like
svg2

plinss: yes, Shepherd picks up tests already and don’t care
about the markup as long as it is explicitly

shepazu: yeah, we do not care about the markup, we want things
to work

ChrisL: and we don’t have the maintainance

<TabAtkins> SVG just splits up pages by chapter, right?

ChrisL: what is the minimal set for HTML5 so that we can auto
link into that?

plinss: I am identifying most attributes but not all elements

<TabAtkins> I think HTML tries to have the pages roughly
balanced.

krit: you pick up attributes on HTML but not elements? what
about the reference to elements from attribute?

<TabAtkins> <a element>filter</a>, or <a
data-link-type="element">filter</a> if you're not Bikeshedding.

plinss: not sure if Shepherd does

<SimonSapin> FWIW, MDN also wants to parse spec to be notified
when something changes that needs doc changes

shepazu: what is the best way to learn what is needed for
shepherd

<TabAtkins> To mark up attributes for elements, <dfn attribute
for="filter">x</dfn> (or whatever).

plinss: I can generate a document explaining it

<scribe> ACTION: plinss deliver document to adapt specs to
Shepherd [recorded in
[47]http://www.w3.org/2013/11/14-svg-minutes.html#action06]

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

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

<scribe> ACTION: Peter Linss deliver document to adapt specs to
Shepherd [recorded in
[49]http://www.w3.org/2013/11/14-svg-minutes.html#action07]

<trackbot> Created ACTION-3540 - Linss deliver document to
adapt specs to shepherd [on Peter Sorotokin - due 2013-11-21].

plinss: so you have attribute def table, we have the same for
properties but we do not analyze the table in detail
... plan to do it
... will be done soon and pick up values and relations
automatically
... what ever format you use, it must be machnine parable

parseable

cyril: how do you link back from specs and attributes?

plinss: in the past we have backinks from tests to the spec

krit: can we add anchor detections on tests and Shepherd will
pick them up and auto link?

plinss: came up before, but doesn’t work right now
... TabAtkins will probably discuss testable assertions and how
Bikeshed can help in the future
... one thing, the test suite and test suite generation is
independent of Shepherd, but Shepherd is used to build it

ChrisL: prefer to have links to TR. If we send people to ED,
then TR get irrelevant

plinss: Tim says we can host a TR spec somewhere else and have
a link to TR form that spec

ChrisL: we have a rule against external script

plinss: all tools are open sourced, I do not care on which
server they run on

ChrisL: [discussing publish policies of W3C]

new SVG DOM proposal

heycam: want to make SVG DOM a bit saner
... how could it be possible to opt in to this new DOM
... otherwise existing script could break

<heycam> [50]http://dev.w3.org/SVG/proposals/improving-svg-dom/

[50] http://dev.w3.org/SVG/proposals/improving-svg-dom/

heycam: to sumaries: key idea… not have SVG elements in a
different NS than HTML elements
... so we would use the NS of the element to decide to use new
SVG DOM or old SVG DOM and element defintions

ChrisL: HTML parser parses a lot of staff. So what happens to
this which adds elements ti SVG NS?

heycam: HTML parser would need to change to switch to new NS
unless there is a new elements where the SVG content is used
which will do the switch to the new NS
... I called it graphics
... <graphics>HTML NS of SVG elements</graphics>
... problem is support for older UAs
... a new element would not help

krit: unless you wrap the SVG content in an extra <svg> element

heycam: yes

krit: when we want backward compatibility then...

heycam: not sure if we want that

slightlyoff: If I have an old school element and move it to and
old school element what happens
... what happens to importNode, adoptNode, appendChild and so
on

heycam: most functionality would still work
... didn’t thought about that

slightlyoff: what about createElement
... new SVGPath() which interface do I get?

heycam: there are no Ctors for SVG element yet
... and createElementNS would give you old school element
... now that they are in HTML, are they HTML*Element
... but we can’t easily use the same interfaces if you have
linking within the same document

<birtles> krit: so can't you just use an attribute instead?

<heycam> (slightlyoff = Alex Russell)

<TabAtkins> Haha, I was wondering who slightlyoff was supposed
to be.

<birtles> heycam: well typically the prototype of an object is
decided at creation time

<birtles> ... since you need to decide the interface of the
object at object creation time

<birtles> ... I thought that if you document.createElement it,
it can't start off with the old interface

<birtles> ... then you do .setAttribute and suddenly get the
new interface

<slightlyoff> OH HAI

<birtles> TabAtkins: so in Custom Elements you can say what the
prototype is but only at parse time

<birtles> heycam: do you agree that it would be weird to change
the interface on a object after it start existing?

<birtles> slightlyoff: I think you can get there using some
esoteric ways (ES6 proxies etc.) but none of them are
attractive

<birtles> ... the downside is that in the transition period is
that we double the surface area

<birtles> ... I'd like to find ways to reduce the surface area
of the SVG DOM

<birtles> ... the number of interfaces created by the SVG DOM
is a burden on implementations

<birtles> shepazu: to what extent could we trim them away from
the existing DOM without harming existing content

<slightlyoff> heycam, sorry I wasn't in the channel before, can
you link me to the proposal again?

shepazu: q-

<nikos> [51]http://dev.w3.org/SVG/proposals/improving-svg-dom/

[51] http://dev.w3.org/SVG/proposals/improving-svg-dom/

<cyril> [52]http://dev.w3.org/SVG/proposals/improving-svg-dom/

[52] http://dev.w3.org/SVG/proposals/improving-svg-dom/

<slightlyoff> thanks

<birtles> heycam: the section of reflecting attributes in the
proposal gets rid of a lot of the interfaces (from the new
world)

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

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

<birtles> heycam: right, it's not a goal, but a means to an end

<birtles> shepazu: I mean is putting SVG elements into the HTML
namespace a goal or a means?

<birtles> heycam: it wasn't a goal per se

<birtles> shepazu: I'd like to see the goals be more explicit

<birtles> cyril: my experience of teaching SVG is that students
gets confused by namespaces

<birtles> ... they are surprised that they can't create SVG
elements in the same way as they can HTML elements

<birtles> krit: I also think namespaces introduce an
implementation burden

<birtles> ... we should be able to assume people are just using
the new DOM or the old DOM

<birtles> heycam: I'd love to drop the old DOM but
unfortunately we can't given existing usage

<birtles> krit: what if we keep the existing naming, interfaces
etc. and remove just the namespace requirement

<birtles> ... i.e. SVGElement inherits from HTMLElement

<birtles> heycam: my proposal includes SVGElement inheriting
from HTMLElement

<slightlyoff> heycam, this proposal looks very good overall

<birtles> ChrisL: I don't think the goal is necessarily to move
SVG elements into the HTML namespace as much as helping
namespaces fade away

<birtles> ... but Dirk, how do you propose we fix existing
problems such as getting rid of animVal

<ChrisL> the proposals for reflecting values and getting rid of
animval and baseval is valuable

<birtles> krit: I don't think we can get rid of those now

<birtles> dino: but we should take the view that the future is
bigger that the past so we should fix it now

<birtles> slightlyoff: I also agree that these old interfaces
are creating drag that stops SVG from developing

<birtles> krit: but there are existing libraries like raphael
and snap that rely on the current SVG DOM

<birtles> ChrisL: I don't see any removal of functionality...
just expressing it in a different way

<birtles> krit: so what do you suggest?

<birtles> heycam: the proposal doesn't remove the old DOM

<birtles> ... there is duplication, but I think that's the only
way we can move forward without breaking other content

<birtles> ChrisL: so this would double the footprint for SVG
but then we hope the old footprint would fade away quickly

<birtles> shepazu: in terms of footprint... you have these
reflectors in there

<birtles> ... is it possible they reduce the footprint of the
new DOM by aliasing etc.

<birtles> slightlyoff: this is the Web, we have a transition
period, add a suitable carrot for the new version then use data
to determine when switch off the old version

<birtles> shepazu: I'm just wondering how we can reduce the
footprint

<birtles> slightlyoff: there are things you can do like turn
off some of the optimizations from the old DOM as an incentive
to move to the new DOM

<birtles> heycam: Doug, you don't need two implementations, you
can re-use code

<birtles> krit: can we remove the liveness of animVal?

<birtles> ... i.e. make it an alias for baseVal

<birtles> ... that would be a big saving

<birtles> heycam: we can probably discuss that separately

<birtles> ... the basic strategy I've applied to these members
is to expose attributes as strings...

<birtles> ... we have, for example, the polygon element that
has a list of points

<birtles> ... in the old SVG DOM we have a live list of points
you can manipulate

<birtles> ... in the new SVG DOM we have a pair of methods to
set and get an array

<birtles> ... that makes it slightly more awkward to use

<birtles> ... if you just want to change one point, say, for
animation, you have to set the whole thing

<birtles> ... but what do you think Alex?

<birtles> slightlyoff: lists in javascript are currently
particularly painful

<birtles> ... in the post-ES6 world things might get easier

<birtles> ... currently you might use a proxying approach which
is basically what the old DOM does

<birtles> ... but my suggestion for the time being is to do
whatever is closest to current javascript which is arrays

<birtles> heycam: what will things look like in the distant
future?

<birtles> slightlyoff: it's end-of-turn... I assume you're not
doing synchronous layout?

<birtles> heycam: actually if you update stuff and do getBBox
then I think you will get the updated result

<birtles> slightlyoff: that's problematic, we should try to fix
that

<birtles> ... we should try to avoid that

<birtles> heycam: at least in SVG it's more contained since you
don't have reflow, just absolutely positioned elements

<birtles> krit: can we take on some parts of the proposal

<birtles> ... the most important part is that we don't have
many namespaces

<birtles> heycam: I agree, but I don't think we can do it
separately

<birtles> ... since otherwise you'll have SVG elements in the
HTML namespace with the old DOM then we could never change it

<birtles> ... so it would poison our ability to change things

<birtles> krit: I don't think the swapping works

<birtles> ... it's a huge mess... you add more code and it's
unlikely that you can ever remove the old code

<birtles> slightlyoff: if you say "unlikely" then you're
talking about probabilities--we can set it up so these features
"could possibly" be removed or "can never" be removed

<TabAtkins> I suspect that, given replacements and aggressive
metrics, we could trim out a bunch of the legacy right now. Not
all, but a bunch.

<birtles> krit: I think we should change the namespace as a
first step and then we fix things progressively in the future
in a backwards compatible way

<birtles> slightlyoff, ChrisL: I don't think that gets you a
lot

<birtles> slightlyoff: it means you have to keep the old
interfaces forever

<birtles> heycam: I don't want to do things slowly, I want to
add the new features at once

<birtles> krit: if we switch the namespace now what can you
*not* do in the future?

<birtles> heycam: you can't use the namespace as the switch for
opting into the new DOM

<birtles> krit: everything you want to add to the new DOM, you
can detect this stuff

<birtles> slightlyoff: how does that work?

<birtles> ... this makes compatibility more difficult since you
have to detect this stuff

<birtles> ... I don't think we should give weight to
implementation issues here

<birtles> TabAtkins: I think we could trim out a lot of stuff
already

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

<birtles> ... we should focus more on authors and this proposal
makes it easier for authors

<birtles> ... one way to introduce this is to say that all the
new SVG2 stuff only works in this new method

<birtles> ... as an incentive to switch to this

<TabAtkins> +1 to carrot

<birtles> heycam: e.g. a method to get the stroke bounding box
etc.

<TabAtkins> Old DOM freezes on the current set, and shrinks as
metrics show we can kill things.

<birtles> ... krit, what do you think is the problem with this?

<TabAtkins> New DOM is better, and grows with new abilities as
we think of them.

<birtles> krit: I think we'll never be able to get rid of the
old interfaces

<birtles> ... it will be 10 years before we can start removing
things

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

<birtles> ChrisL: but you were saying we drop animVal?

<birtles> krit: it's not being used

<birtles> ChrisL: it is

<birtles> shepazu: there was a small but active community of
SVG developers from 1999-2006

<TabAtkins> shepazu: Maybe 12 or so.

<birtles> ... (more background)

<birtles> ... there is lot of content out there that may not
even work due to namespace issues

<birtles> ... in any case, I think we need to involve the
community in this decision

<birtles> ... people like maintainers of script libraries

<birtles> krit: I don't think many people have reviewed it yet

<birtles> heycam: I just want to know (a) if I should keep
driving this, and (b) what sort of timeframe?

<birtles> shepazu: I'm still uncomfortable about changing the
root element

<birtles> ... it introduces confusion about what you should be
doing

<birtles> ... there are definite risks

<birtles> ... but that may be ok

<birtles> ... I'd like to be explicit about the goals

<birtles> heycam: the 1.5 goals are, 1) changing to the
reflecting of attributes, 1.5) changing namespaces

<birtles> ... the change of namespaces just happened to be a
good way of opting into the new DOM

<birtles> ... the new root element is not a goal, just a means

<birtles> cyril: the goal to change the reflecting of
attributes

<birtles> ... is it to make writing SVG easier? or reduce code
size in implementations?

<birtles> heycam: for useability for authors

<birtles> krit: "is this something important enough for SVG 2?"
is a good question

<birtles> ... is it worth delaying SVG 2 for?

<birtles> dino: if we delay it, it will only make the decision
harder

<birtles> ... there will be more content to break

<birtles> ChrisL: and by bringing forward the namespace change
you'd remove one of the drivers for switching

<birtles> krit: so, should it be in SVG2?

<birtles> heycam: I feel like it should

<birtles> ChrisL: I don't think we could do this in SVG3

<birtles> krit: in which case we should prioritize this work

<birtles> ... we should focus on the details at the next F2F

<birtles> slightlyoff: I'd like to help set up a process for
you all to talk to major library authors and get their input

<birtles> ... are these meetings to do design work or just
making decisions?

<birtles> heycam: we do both

<birtles> ... this is the first f2f where I've brought up the
proposal

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

<birtles> ChrisL: I think we can get new data before then

<birtles> krit: I think we should delay LC anyway

<birtles> heycam: I think January was a bit optimistic anyway

<birtles> ... but we will discuss that later

<birtles> krit: how do we reach out to developers from here

<birtles> heycam: I haven't really announced it yet

<birtles> shepazu: for svg developers there's the d3 list,
svg-developers, we can tweet, etc.

<birtles> krit: if we want people to read the proposal I think
we could rework it to make it easier to follow

<birtles> shepazu: does your document talk about the problems
with the existing DOM?

<birtles> ... I think we should add that

<birtles> heycam: is there anything else to cover?

SVGAnimatedBoolean

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

<birtles> krit: I doubt anyone uses it

<birtles> heycam: was externalResourcesRequired the only other
use?

<birtles> ed: yes

<birtles> ... so can we remove it?

<birtles> ChrisL: let's remove it

<ChrisL> getAttr still works

<birtles> RESOLUTION: We will remove SVGAnimatedBoolean and
SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM

<birtles> ACTION: Dirk to remove SVGAnimatedBoolean and
SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
[recorded in
[53]http://www.w3.org/2013/11/14-svg-minutes.html#action08]

<trackbot> Created ACTION-3541 - Remove svganimatedboolean and
svgfeconvolvematrixelement.preservealpha from the svg2 dom [on
Dirk Schulze - due 2013-11-21].

<birtles> slightlyoff: I'll talk to Google folk about how they
transitioned from the old DART DOM to the new DOM to get their
advice

<ed> -- break time --

<TabAtkins> Yay!

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

SVG DOM continued

krit: any new SVG DOM should not have any reference to
x/y/width/r/rx/ry/cx/cy

ChrisL: because?

krit: because they'll get presentation attributes, and it
doesn't make sense to have a second way to access them, apart
from the CSS OM

heycam: I really want to do rect.x = 10

ed: I'd like to be able to assign a full rectangle in one go

ChrisL: rect.xywh = ...

krit: happy if SVG WG to ask the CSS WG to prioritise the CSSOM
for SVG 2
... like heycam's proposal
... but up to the WG

SVGElement implementing global event handlers (onfoo)

ed: should these be on Element?

<ed>
[54]http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-Oc
tober/040980.html

[54]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/040980.html

ed: I think in Blink recently there was some code reshuffling
... it was discovered that SVG elements did not have the global
event handlers like HTML does
... so you couldn't do rectElement.onload = ... and have that
assign a function
... so this is something that most SVG authors would like to
have
... and the way it works in browsers, even if the SVG spec
doesn't require it
... I think we should have this in the spec
... in this thread, further down, we have feedback from Hixie
saying we can't really put this on Element, as it would affect
any XML dialect

krit: and that would be bad?

ed: yes
... but having it on SVGElement would be fine

heycam: are all HTML event listener attributes defined on
HTMLElement?

ed: yes, apart from special things with <body>
... this is the way Gecko already does it
... it does mean we have some additional events supported
automatically
... things which we don't require in SVG at the moment

heycam: what if one day SVGElement inherits from HTMLElement?

ed: we could still make both implement GlobalEventHandlers

heycam: if we do have SVGElement inherit from HTMLElement one
day, we can just remove the duplicated ones on SVGElement

ed: any objections to this? :

SVGElement implements GlobalEventHandlers;

scribe: I think Cameron has an action already relating to this

heycam: does SVG have onzoom or something that isn't in HTML?

ed: a few, yes... not sure if that already works on an
HTMLElement

heycam: if they aren't on GlobalEventHandlers, should they be?

ed: yes

<TabAtkins> Ah, there's someone's voice.

birtles: on HTMLElement, you have onfocus, but SVG has
onfocusin/onfocusout
... is there some mismatch?

Takagi-san noticed this

TabAtkins: in HTML the focusout event is called blur

ed: which already works in all browsers

birtles: so would we end up with
onfocusin/onfocusout/onfocus/onblur?

heycam: how much do we really need to keep
onfocusin/onfocusout?

ed: we have a later topic on removing some SVG-specific events,
discuss it then?

heycam: is Ian alright with having any SVG specific ones on
GlobalEventHandlers?

ed: I haven't asked him that

<TabAtkins> But, probably, yes.

<scribe> ACTION: Erik to ask in the thread about whether SVG
specific event handlers should go on GlobalEventHandlers, or
separately on SVGElement [recorded in
[55]http://www.w3.org/2013/11/14-svg-minutes.html#action09]

<trackbot> Created ACTION-3542 - Ask in the thread about
whether svg specific event handlers should go on
globaleventhandlers, or separately on svgelement [on Erik
Dahlström - due 2013-11-21].

RESOLUTION: We will have "SVGElement implements
GlobalEventHandlers" in SVG2's IDL.

<scribe> ACTION: Erik to make SVGElement implement
GlobalEventHandlers in SVG2. [recorded in
[56]http://www.w3.org/2013/11/14-svg-minutes.html#action10]

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

Is it future-proof to return SVGElement on nearestViewportElement and
farthestViewportElement?

<krit>
[57]https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsE
lement__farthestViewportElement

[57]
https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__farthestViewportElement

krit: I have a question about these two
... farthestViewportElement, isn't that always SVGSVGElement?
can we just use that?
... it's true, today at least
... is is true in the future? if we should ever allow
SVGCircleElement to be an HTMLElement, what should it return?
... my question is should we rather replace SVGElement with
just Element?
... or in this case, should it return null as in some other
cases?

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

krit: I guess we return null currently

heycam: I am ok with it being Element; the spec will still say
what objects get returned
... we still would return null from <circle> when there is no
ancestor <svg>

RESOLUTION: We will make nearestViewportElement /
furthestViewportElement be Elements, not SVGElement

ed: I've rarely seen these used, could we not just remove them?

krit: add UseCounters and see if we can remove it?

ed: sure

<scribe> ACTION: Erik to add use counters to see if
nearestViewportElement/furthestViewportElement are used
[recorded in
[58]http://www.w3.org/2013/11/14-svg-minutes.html#action11]

<trackbot> Created ACTION-3544 - Add use counters to see if
nearestviewportelement/furthestviewportelement are used [on
Erik Dahlström - due 2013-11-21].

<scribe> ACTION: Dirk to change
nearestViewportElement/furthestViewportElement to be Element
[recorded in
[59]http://www.w3.org/2013/11/14-svg-minutes.html#action12]

<trackbot> Created ACTION-3545 - Change
nearestviewportelement/furthestviewportelement to be element
[on Dirk Schulze - due 2013-11-21].

Animation Elements

birtles: you all know about Web Animations, the model for
animations and an API on top of that model
... the intention is to define CSS Animations/Transitions and
SVG's animation features in terms of that model

<birtles>
[60]http://dev.w3.org/fxtf/web-animations/animation-elements.ht
ml

[60] http://dev.w3.org/fxtf/web-animations/animation-elements.html

birtles: so Animation Elements is what I've called the spec
where I've started to describe how SVG animation features can
be implemented in terms of the Web Animations model
... skeleton document I've made
... the only parts I've filled in are some use cases at the
top, and describing how it relates to SVG 1.1
... and also some other specifications
... I can introduce briefly some of the changes, but today I
just want to decide on is whether it's OK to work on this as an
SVG Working Group work item
... it's an Unofficial Draft at the moment
... if you're OK with me working on this as an Editor's Draft,
I'd like to decide on that

cyril: does it cover the timing model and the animation model,
or just the animation model?

birtles: the 1st requirement of this is that it's backwards
compatible with SVG 1.1's animation support
... so yes, it has to cover both of those things

shepazu: to what extent is it backwards compatibel?
... you've documented the bits that aren't going to be?

birtles: there are three exceptions, marked at the start of
section 1.2, regarding backwards compatibility
... crazy frozen to-animation that nobody implemented won't be
in here
... second point, I want to rewrite how cycles in syncbase
dependencies are resolved, as these are implemented
inconsistently
... might be some minor changes as to how that works, but I
don't think people rely on the details
... third is animateColor -- waiting on use counters to see
whether people use this
... and drop it if not

cyril: is the shim you have already supporting this?

birtles: no
... there's no shim for this markup
... there's fakeSmil, but that's the existing featureset
... you can see there's a list of new features
... some of them are exposing things which are already in the
Web Animations model as markup
... there's also the <discard> element, which was in SVG 2 but
I think it belongs in this specification instead
... timelineStart="" as well
... most of the new things are requirements we had for SVG 2,
and I put them in this spec

shepazu: for every feature of element-based SVG animation,
there will be an equivalent API/model aspect? and possibly CSS
syntax?

birtles: roughly
... there are some things which only appear in one form
... e.g. timing groups, we don't know how yet to express that
with CSS syntax
... likely that will be in the model, exposed here in element
markup, but not exposed in CSS syntax, at least initially
... you don't get the full feature set across both syntaxes

shepazu: one of my frustrations with SVG animation syntax was
the lack of reusability
... the same animation for multiple elements, I had to repeat
the animation
... is this now possible with element syntax?

birtles: yes, you can use the select="" attribute to target
multiple elmeents
... some examples in the use cases -- frame based animation use
case, you can see that uses select="" to match on a class name,
and repeat the animation
... it's also possible to define the animation with markup, and
then with script to instantiate it on a different element, to
say play this animation targetting a different element

cyril: so you can put an animation in a defs?

birtles: yes

shepazu: that's great
... if I'm animating something with the element syntax, the CSS
syntax and the script, what happens?
... I assume you have some order of priorities?

birtles: that ordering is covered in the Web Animations model
... there are priorities based firstly on start time, but also
on document order, and facilities for changing the priotity too

<ed> minor nit, "timelineStart" was actually called
"timelineBegin" in SVG Tiny 1.2, was the change of name
intentional?
[61]http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementTimeli
neBegin

[61]
http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementTimelineBegin

birtles: but it is well defined
... that's an advantage to having a unified animation model

ChrisL: but before it was undefined

birtles: re timelineStart, that wasn't intentional

krit: can I see a WD?

birtles: I want permission to do that yes

dino: I enthusiastically support this
... I'm glad Brian is doing this
... wanted something like this for 18 months
... Apple is going to propose something like this in a few
weeks anyway, so this is great

ChrisL: MS said they wouldn't implement either of these, before
there was a consistent model explaining how it works together

dino: I have comments on the content, but i'll wait until the
document exists
... one is one of the first things people will do with this, is
still write much their animation in CSS -- their keyframes,
animation parameters
... and just use this as a way to do declarative timing
separate from the animation
... in most cases you won't use <animate> elements, but
toggling classes at particular times, or in response to
particular events
... I said to Brian: it would be nice if the example using
<set> on class="", we could have declarative forms of the
class-list API; add class, remove class
... something not covered here, should we define a MIME type
for a document like this? <link rel=stylesheet>
... you will want this inline in some cases, so in the document
you could have a <timesheet> element in HTML
... adding elements to the <head> is difficult, but this could
be in the <body> as well

birtles: one reason I called it Animation Elements, is it
doesn't have to be just for SVG, but these kinds of use cases
too

shepazu: what namespace should they be in?

birtles: I'd like to see what happens with Cameron's proposal

dino: I want these to apply to HTML too, so the namespace
doesn't matter
... it should follow HTML-like parsing rules as much as
possible

birtles: perhaps for each element, we need to define the
content model so that it can be used in either parsing mode?

heycam: it's difficult to add new empty elements in HTML, which
don't have closing tags

shepazu: we should consider how we can expose animations in an
accessible way

dino: I think this is the great thing about having the model,
you can get at the animations

shepazu: I was thinking more of having a <title> for the
animation

krit: there might already be a document describing
accessibility of SMIL

cyril: I had another comment
... one of the next steps is to synchronise animations with
media elements

birtles: yes

cyril: that's something I'm trying to work on
... the next topic is Streaming, and it's somehow related

birtles: I think that's a common question
... just to reiterate the status there, we have left
synchronisation with media out of the first level of Web
Animations
... just in the interest of progressing it more quickly
... it's definitely intended to be part of that model
... we already have an idea of how it should work, and a
polyfill to demonstrate that
... the current thinking is that we'll write a separate
document just for that feature, to say to integrate media with
the model
... and the markup for it
... I think Cyril and Dean have shown some interest on working
on that before

ChrisL: how do you expect that to work? event based?

birtles: you'd have another kind of timed item, which is a
reference to the media element
... the <video> element needs to be in a particular part of the
document for layout purposes
... you would set the timing parameters on the pointer object,
and it would trigger the <video> as appropriate

cyril: two aspects, controlling the media element, and using
the media element to control the timing of other things

birtles: wrt Web Animations, we only support the former, where
the media is slaved to the timing groups
... but for the reverse, where you put the animations inside
the media, I think the Streams stuff you've been working on is
the way to approach that

dino: are you saying you don't intend to have animations slaved
to media unless they're inline in the media?

birtles: when you seek the video, you don't have the animations
follow; rather you put them both in the group, and you seek the
group
... if you need it the other way around, I suggest the
Streaming approach

dino: that use case is very important to us
... if the answer is put it in a group and seek the group, we
can do that

cyril: where's the right forum to work on this spec?
... FXTF? SVGWG?

ChrisL: I think FX is an obvious home
... LC or before is a good time to get other people involved in
reviewing it

RESOLUTION: We will take on Animation Elements as an official
WD.

cyril: we talked about this in the past, the dur="" attribute,
does the model cover that?
... on an SVG document?

birtles: why on a document, not on a group?

cyril: if you want to loop the document?

birtles: you'd put it on the root
... every outermost SVG element will act as a nested timeline
... it's like a simple group
... you can't repeat it, but you can seek it

cyril: can you put a dur on that?

birtles: no
... just put a group around everything you want to repeat

ChrisL: could you just construct groups as you want and point
them to items to repeat them?

birtles: yes
... in the use cases, typically I found it was easier to
separate out the timing from the content
... only simple cases can you put them side-by-side

SVG streaming update

cyril: we have three types of animations
... [cyril reads out the slides]

<cyril>
[62]http://concolato.wp.mines-telecom.fr/2013/10/24/streaming-o
f-svg-animations-on-the-web/

[62]
http://concolato.wp.mines-telecom.fr/2013/10/24/streaming-of-svg-animations-on-the-web/

cyril: I'd like to be able to use SVG in <video> and in <track>
... I implemented this with a shim

krit: regarding the same origin restrictions, what do you want
to reference? svg documents?

cyril: I think the same restrictions should apply as images
... so what is needed for standardisation is:
... first, the guideline document
... support for SVG in the video and track elements
... and support for annotations either in the SVG document, or
outside it, to give information about the streaming units
... we have everything else that we need from SVG, CSS, etc.
... the generation tool is open source
... the players aren't yet, but only because they're badly
implemented
... I'll put them on GitHub soon

krit: I don't have anything against working on that in the WG,
but we might not have the expertise here

cyril: first step is to apply it to SVG, since SVG works well,
has a timeline per document
... HTML doesn't

birtles: Web Animations defines a timeline per HTML document

cyril: maybe the Guidelines for Streaming SVG is good for this
WG though

krit: I don't want to push the spec out of this WG, but it
sounds like you need expertise from other people

cyril: tomorrow we have a session on WebVTT, I hope to present
at that
... the HTML Media TF has a lot of activity atm

shepazu: I personally like to see this work go forward
... I think Dirk raises good points about who needs to be
involved

heycam: for identifying the chunks in the document, can you
just use IDs?

cyril: when the client uses an ID, someone needs to convert
that to a byte range
... in my case, I didn't do any server side processing to
determine the byte range
... when it's packaged in WebVTT or MP4 you don't have this
problem

mohamed: what about if we want to use svgz?
... then the byte offsets changed

cyril: I'm using Content-Encoding
... so the byte offsets remain the same
... IDs would require adding them to every frame
... when you concatenate two animations, you might have to
rename IDs

mohamed: how will you deal with the background that is
preloaded? will you do complex like intermediate frames?

cyril: you could imagine either it's an external resource, or
you could data: uri embed it in the svg, or for an mp4 file,
you could store it natively without base64 encoding it
... you can put the common elements in the "header" of the
document

dino: from the Apple part of WebKit, looking cool isn't enough
to contribute impl resources
... we need demand from users
... then we have to balance that against what can you achieve
currently int he platform without having to implement it
... comparing it to Brian's animation example, that's enabling
a subset of developers that don't have as much experience with
how to write animations to do something that they couldn't do
before, in a nice declarative way
... every time you add a new declarative format to the web,
there is a lot of maintenance, security, etc. overhead
... there's a good balance there
... with this proposal I am more concerned
... there's JS in there
... that's not me making a value judgement on the technology in
any way
... if we looked at this and saw it could take a couple of
person years of impl work, we have to prioritise against many
other things

cyril: I hear that
... not asking for any browser changes
... the purpose of this was to demonstrate that with a shim you
can do it
... then if users want it, let them use it, and if they see
perf problems, sync problems, then we might think about
embedding that natively in the browser

dino: yeah

dsinger: what would you need the browsers to do natively? which
bits are likely?

dino: a great example of this is MSE
... the content distributors asked the browsers that we need to
do this thing, and we can't do it unless we have this
particular feature
... the ability to generate media streams from js
... that's the way you have to ask browser vendors to do things

cyril: I'm not asking browser vendors to do things
... I'm asking agreement to publish guidelines on svg
streamable content
... if authors want to stream their svg content, it would be
better if they did it this way
... any streaming tool would need some annotations
... but from the browser point of view, there's nothing to be
changed, unless users demand it because perf is not there, or
...

dsinger: where would that be?

cyril: the sync you can achieve here is best effort
... if you need frame accurate ...

dino: I think it sounds like a great CG effort

cyril: if I'm alone in the CG...

dino: if you're alone in the CG, maybe it shouldn't take WG
time
... I don't think you will be though

shepazu: I think the dedicated conversations you could have
there wouldn't distract this group

cyril: I think it's also relevant to this group
... not completely, but somehow
... it's related to timed elements
... if you want all these things to be synced, looped, then you
could do it with web aimations

*animations

shepazu: I'd like to see SVG WG people in that CG
... speaking as a W3C person, I want to see smooth transitions
from CG to Rec track stuff

cyril: having a CG sounds ok

<ed> trackbot, end telcon

Summary of Action Items

[NEW] ACTION: Dirk to change
nearestViewportElement/furthestViewportElement to be Element
[recorded in
[63]http://www.w3.org/2013/11/14-svg-minutes.html#action12]
[NEW] ACTION: Dirk to remove SVGAnimatedBoolean and
SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
[recorded in
[64]http://www.w3.org/2013/11/14-svg-minutes.html#action08]
[NEW] ACTION: Doug to clarify HTML content in <desc> and
<title> elements [recorded in
[65]http://www.w3.org/2013/11/14-svg-minutes.html#action04]
[NEW] ACTION: Doug to work with Gerardo and Tab to come up with
haptic, tactile and 3d media queries [recorded in
[66]http://www.w3.org/2013/11/14-svg-minutes.html#action05]
[NEW] ACTION: Erik to add use counters to see if
nearestViewportElement/furthestViewportElement are used
[recorded in
[67]http://www.w3.org/2013/11/14-svg-minutes.html#action11]
[NEW] ACTION: Erik to ask in the thread about whether SVG
specific event handlers should go on GlobalEventHandlers, or
separately on SVGElement [recorded in
[68]http://www.w3.org/2013/11/14-svg-minutes.html#action09]
[NEW] ACTION: Erik to make SVGElement implement
GlobalEventHandlers in SVG2. [recorded in
[69]http://www.w3.org/2013/11/14-svg-minutes.html#action10]
[NEW] ACTION: heycam to look at the performance class
requirements and decide whether to remove points or move them
into general requirements [recorded in
[70]http://www.w3.org/2013/11/14-svg-minutes.html#action01]
[NEW] ACTION: heycam to review Resource Priorities
specification [recorded in
[71]http://www.w3.org/2013/11/14-svg-minutes.html#action02]
[NEW] ACTION: Peter Linss deliver document to adapt specs to
Shepherd [recorded in
[72]http://www.w3.org/2013/11/14-svg-minutes.html#action07]
[NEW] ACTION: plinss deliver document to adapt specs to
Shepherd [recorded in
[73]http://www.w3.org/2013/11/14-svg-minutes.html#action06]
[NEW] ACTION: Rich to reference ARIA 1.1 in SVG 2 [recorded in
[74]http://www.w3.org/2013/11/14-svg-minutes.html#action03]

[End of minutes]

Received on Thursday, 14 November 2013 09:47:22 UTC