IRC log of svg on 2013-11-14

Timestamps are in UTC.

01:07:43 [RRSAgent]
RRSAgent has joined #svg
01:07:43 [RRSAgent]
logging to
01:08:01 [ed]
chair: ed
01:08:21 [ed]
01:09:23 [nikos]
nikos has joined #svg
01:10:12 [nikos]
scribe: nikos
01:10:28 [ed]
scribeNick: nikos
01:10:46 [TabAtkins]
Yo, we got polycom?
01:11:16 [Rossen__]
Rossen__ has joined #svg
01:11:32 [ed]
TabAtkins, we're setting it up
01:11:37 [TabAtkins]
Cool, thanks.
01:11:39 [heycam]
RRSAgent, start telcon
01:11:39 [RRSAgent]
I'm logging. I don't understand 'start telcon', heycam. Try /msg RRSAgent help
01:11:41 [cyril]
regarding the agenda, I think it would make more sense to discuss "SVG streaming update" after Brian's "Web Animation" this afternoon
01:11:44 [heycam]
trackbot, start telcon
01:11:46 [trackbot]
RRSAgent, make logs public
01:11:46 [Zakim]
Zakim has joined #svg
01:11:48 [trackbot]
Zakim, this will be GA_SVGWG
01:11:49 [trackbot]
Meeting: SVG Working Group Teleconference
01:11:49 [trackbot]
Date: 14 November 2013
01:11:49 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
01:12:01 [heycam]
Zakim, call huangshan
01:12:01 [Zakim]
sorry, heycam, I don't know what conference this is
01:12:04 [thorton]
thorton has joined #svg
01:12:19 [TabAtkins]
Zakim, room for 4 for 8 hours
01:12:19 [Zakim]
I don't understand 'room for 4 for 8 hours', TabAtkins
01:12:20 [nikos]
scribe: nikos
01:12:32 [TabAtkins]
Zakim, room for 4 for 600m
01:12:32 [Zakim]
I don't understand 'room for 4 for 600m', TabAtkins
01:13:02 [heycam]
TabAtkins, we can't call out from here
01:13:19 [heycam]
Zakim, call huangshan
01:13:19 [Zakim]
sorry, heycam, I don't know what conference this is
01:13:24 [heycam]
Zakim, this is SVG
01:13:24 [Zakim]
sorry, heycam, I do not see a conference named 'SVG' in progress or scheduled at this time
01:13:30 [TabAtkins]
Zakim, room for 4
01:13:30 [Zakim]
I don't understand 'room for 4', TabAtkins
01:13:36 [TabAtkins]
Zakim, room for 4
01:13:36 [Zakim]
I don't understand 'room for 4', TabAtkins
01:13:40 [TabAtkins]
Zakim, room for 4?
01:13:41 [Zakim]
ok, TabAtkins; conference Team_(svg)01:13Z scheduled with code 26632 (CONF2) for 60 minutes until 0213Z
01:13:48 [TabAtkins]
For god sakes, Zakim.
01:13:50 [heycam]
Zakim, call huangshan
01:13:50 [Zakim]
ok, heycam; the call is being made
01:13:51 [Zakim]
Team_(svg)01:13Z has now started
01:13:52 [Zakim]
01:14:05 [heycam]
Zakim, who is on the call?
01:14:05 [Zakim]
On the phone I see Huangshan
01:14:07 [TabAtkins]
Zakim, a goddamned thing
01:14:07 [Zakim]
I don't understand 'a goddamned thing', TabAtkins
01:14:10 [TabAtkins]
I know that, Zakim.
01:14:17 [jun]
jun has joined #svg
01:14:23 [TabAtkins]
We all know that.
01:14:56 [TabAtkins]
I'll be here the whole time, so don't worry.
01:15:07 [TabAtkins]
It's 5pm to 2am for me, and I've already done this for 2 days.
01:15:35 [heycam]
heycam has changed the topic to: Agenda:
01:15:45 [heycam]
heycam has changed the topic to: Agenda: code for today is 26632
01:17:02 [astearns]
astearns has left #svg
01:17:40 [Zakim]
01:19:40 [Zakim]
01:20:15 [TabAtkins]
01:20:37 [heycam]
Zakim, dial huangshan
01:20:37 [Zakim]
ok, heycam; the call is being made
01:20:39 [Zakim]
01:22:25 [nikos]
Topic: Numeric Precision for SVG
01:22:33 [birtles]
01:23:22 [nikos]
birtles: Takagi-san prepared this wiki page. You can read the issue yourself
01:23:31 [nikos]
... SVG 1.1 only requires single precision floating point
01:23:40 [nikos]
... but for mapping use cases it appears that double precision is neccessary
01:23:45 [nikos]
... what are your thoughts?
01:23:59 [nikos]
heycam: We had a meeting recently with all our layout and graphics people
01:24:08 [nikos]
... anytime graphics people heard double precision they cringed
01:24:12 [nikos]
... GPU HW only works in floats
01:24:26 [nikos]
... and it's going to me more and more likely we'll be restricted to floats as we move more into HW
01:24:39 [nikos]
... currently changing graphics library layers and that uses floats
01:24:48 [nikos]
... I feel it'll be difficult to require double precision
01:24:51 [shepazu]
shepazu has joined #svg
01:24:55 [nikos]
krit: SVG 1 doesn't require double but allows it
01:25:05 [nikos]
heycam: SVG 1 spec has different performance class requirements
01:25:12 [nikos]
... high quality viewer must support double
01:25:18 [nikos]
... I'm wondering how realistic that is now
01:25:47 [nikos]
TabAtkins: Takagi-san made a wiki page that has a precision of 5 decimal places
01:25:50 [nikos]
... floats have 7 digits
01:25:56 [nikos]
... so why is this a problem?
01:26:33 [nikos]
s/has a precision/describes a requirement for precision
01:26:37 [TabAtkins]
s/made a wiki page that has/said on the wiki page that he needs/
01:27:20 [nikos]
birtles: I clarified with Takagi-san and if that's the case thats ok
01:27:29 [nikos]
... but tests with IE show that it appears to use fixed point
01:27:33 [jeroskim]
jeroskim has joined #svg
01:27:37 [nikos]
... with only 3 digits of precision
01:27:42 [nikos]
krit: that's true. Firefox is the same
01:27:59 [nikos]
heycam: 16.16 fixed point stuff comes from Cairo
01:28:09 [nikos]
... I can't remember the exact plan for software rendering back end
01:28:17 [nikos]
... but we are removing Cairo as the intermediate API layer
01:28:29 [nikos]
... most of the back ends will use single precision
01:28:39 [nikos]
... so perhaps for this use case it will get better in Firefox
01:29:17 [nikos]
krit: fixed point is coming from HTML
01:29:56 [nikos]
... It's not a requirement for Skia but Blink is still using fixed point for that
01:30:04 [nikos]
heycam: you're talking about for CSS layout?
01:30:06 [nikos]
krit: yes
01:30:20 [nikos]
krit: Since SVG is using the same engine as HTML wouldn't it be the case for both?
01:30:39 [nikos]
heycam: I think it could be reasonable to use different code for layout of CSS boxes compared to 2d graphics APIs
01:30:44 [dino]
dino has joined #svg
01:31:01 [nikos]
... if IE uses fixed point for graphics stuff and CSS layout then perhaps there's some reason for linking the two
01:31:10 [nikos]
Rossen__: what were the tests?
01:31:30 [nikos]
krit: viewbox with 0.00001 will render differently
01:31:46 [nikos]
Rossen__: for CSS values we use fixed point. For SVG we use as much floating point as possible
01:32:01 [nikos]
krit: we parse all of CSS values to floating point
01:32:21 [nikos]
s/CSS values to floating point/CSS values to fixed point
01:32:35 [nikos]
Rossen__: we parse SVG to floating point
01:33:01 [nikos]
krit: I can write a test
01:33:14 [nikos]
heycam: one thing to clarify is whether single precision floating point is enough?
01:34:33 [nikos]
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
01:34:37 [krit]
<svg xmlns="" xmlns:xlink="" width="800" height="800" viewBox="0 0 0.0000001 0.0000001">
01:34:37 [krit]
<rect width="0.00000005" height="0.00000005" fill="blue"/>
01:34:37 [krit]
01:34:57 [nikos]
cabanier: PDF had the same problem
01:34:59 [nikos]
... creating huge maps
01:35:16 [nikos]
... they only had a certain position so edges of the map were rough
01:35:35 [nikos]
... so to solve you translate
01:35:46 [nikos]
... it's an internal engine thing
01:35:57 [nikos]
heycam: so the answer is to not have everything in the one co-ordinate system
01:36:51 [nikos]
birtles: I don't know how you'd specify it
01:36:54 [MikeSmith]
MikeSmith has joined #svg
01:37:00 [nikos]
krit: it doesn't need to be specified. It's an implementation detail
01:37:11 [nikos]
cabanier: so when you zoom all the way out. fine details may not be right
01:37:17 [nikos]
... it only matters when you zoom in
01:37:32 [nikos]
heycam: in reality you have different sources of data, different tiles that are merged
01:37:40 [nikos]
... they're not going to be in the same co-ord system originally
01:37:50 [nikos]
... some of the proposals we've seen before transform them into a common co-ord system
01:38:05 [nikos]
... leaving the data like that and not having one co-ord system seems to be the right thing to do
01:39:04 [nikos]
heycam: 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
01:39:22 [nikos]
... maybe different data sources should be used
01:39:43 [nikos]
stakagi: that's ok
01:40:08 [nikos]
krit: the test case I posted previous shows that IE does support floating point precision and Firefox doesn't
01:40:13 [nikos]
... that will hopefully change in the future
01:40:32 [nikos]
ed: so we don't need to make any change?
01:40:56 [nikos]
heycam: something to think about when defining conformance classes
01:41:09 [nikos]
... would people be amenable to removing the double precision requirement?
01:41:26 [nikos]
krit: for most things in WebKit and Blink we use single precision internally even if API uses doubles
01:41:31 [nikos]
... exception is everything from CSS is still double
01:41:42 [nikos]
... but it's converted to single at some point
01:41:51 [nikos]
heycam: I was considering changing webidl to float to match JS
01:42:02 [nikos]
... but it makes sense to leave as float since APIs use that
01:42:59 [nikos]
heycam: I don't think it's a great idea to have different classes that give different results
01:43:10 [nikos]
... especially for path positions
01:43:14 [nikos]
... I'd rather remove it
01:43:16 [nikos]
birtles: the whole class?
01:43:33 [nikos]
shepazu: CSS resolved to use rfc6919
01:43:48 [nikos]
heycam: sothese are the things that high quality viewers are meant to do
01:44:14 [heycam]
01:44:28 [nikos]
s/sothese/so these
01:44:40 [nikos]
heycam: this was written 12 years ago
01:45:05 [nikos]
shepazu: I don't think that these are modern constraints
01:45:09 [nikos]
heycam: they're the wrong level also
01:45:14 [nikos]
shepazu: let's remove this bit compeltely
01:46:39 [nikos]
krit: image rendering is specified in CSS
01:46:43 [nikos]
... might not be a good thing to have in SVG
01:46:48 [nikos]
... I would definitely remove point 4
01:47:03 [nikos]
... I would remove it as a requirement to decide if you use high quality or low quality rendering
01:47:27 [nikos]
TabAtkins: are you saying people should always respect the image rendering property regardless of mode you're in?
01:47:30 [nikos]
... if so I agree
01:47:32 [nikos]
krit: yes
01:47:59 [nikos]
shepazu: looking through these, I don't think they're meaningful in today's market
01:48:10 [nikos]
... I don't know who this is written for
01:48:15 [nikos]
... we should just remove it
01:48:26 [nikos]
... if we decide we'll get better performance out of floats rather than doubles
01:48:37 [nikos]
krit: I don't think floats or doubles are a good criteria for quality
01:48:43 [nikos]
shepazu: all these requirements have that problem
01:48:56 [nikos]
ACTION: heycam to look at the performance class requirements and decide whether to remove points or move them into general requirements
01:48:56 [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].
01:49:34 [nikos]
RESOLUTION: Remove performance class requirements from SVG 2
01:50:01 [nikos]
Topic: Proposals/ResourcePriorities for SVG
01:50:04 [nikos]
01:50:25 [nikos]
birtles: Takagi-san prepared this wiki page
01:50:35 [nikos]
... this is about resource priorities spec from web performance working group
01:50:41 [nikos]
... first issue is about the postpone attribute
01:50:47 [nsakai]
nsakai has joined #svg
01:50:48 [nikos]
... and it's currently defined in terms of bounding boxes
01:51:03 [nikos]
... but Takagi-san has some feedback to suggest it would be useful if it could also be used in regards to zooming
01:51:18 [nikos]
... currently says that things with bounding box outside current viewport don't need to be loaded
01:51:35 [nikos]
... but it seems like that would be a good thing for conditionally loading tiles
01:51:51 [nikos]
... We've sent feedback but I don't know if it's been taken on board yet
01:52:38 [nikos]
krit: This sounds like a previous discussion on www-svg
01:52:48 [nikos]
... A thread about resource priorities and SVG
01:53:10 [shepazu]
01:53:42 [nikos]
birtles: that's [1] on the wiki page
01:54:18 [krit]
01:54:33 [krit]
01:54:39 [nikos]
krit: this was my reply
01:56:16 [nikos]
birtles: the proposal is that you would have different tiles (say several iframe elements in svg). For each you would have the postpone attribute
01:56:20 [stakagi]
01:56:28 [nikos]
... you would only load the ones within the bounding box and at the right zoom level
01:56:35 [nikos]
... it's not part of one image resource, it's several resource
01:57:14 [nikos]
... 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
01:57:25 [nikos]
... so it doesn't take into account zoom
01:58:39 [nikos]
krit: doesn't the zoom level also influence the viewport?
01:58:43 [nikos]
birtles: it's not enough by itself
01:59:02 [nikos]
... you could have several tiles that occupy the 2d space but are at several zoom levels. You don't want to load them all
01:59:16 [nikos]
... the facility to achieve that might be to use media queries
01:59:28 [nikos]
krit: I think this discussion would have been better in FXTF
01:59:39 [nikos]
birtles: one piece did come up then - it's next on the agenda
02:00:03 [nikos]
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?
02:00:19 [nikos]
birtles: the way postpone is currently described is purely based on viewport and bounding box
02:00:31 [nikos]
heycam: so you want to link it to this future zoom media query as well
02:00:38 [nikos]
birtles: I think that's Takagi-san's idea
02:02:41 [nikos]
birtles: I think this is something that we can't decide in this group
02:02:49 [nikos]
... but at least it has helped to clarify the requirements
02:03:04 [nikos]
... text in resource priorities spec doesn't quite align with these use cases
02:03:21 [nikos]
... because it says tjat ot
02:03:42 [nikos]
... that it's bounding box or display:none that defines whether resources are loaded
02:04:32 [nikos]
heycam: what about the fact that they're adding attributes to SVG without asking?
02:04:57 [nikos]
heycam: is that an issue? or do we just want to review their changes?
02:05:06 [nikos]
krit: I did and initial review but would be happy if others did as well
02:05:19 [nikos]
... right now the spec has more issues with HTML than with SVG
02:05:42 [nikos]
krit: it's an easy spec to review
02:05:50 [nikos]
heycam: I'll have a look to see how it fits with SVG
02:06:34 [nikos]
ed: this is basically the same functionality as external resources required functionality of SVG 1.1
02:07:07 [nikos]
Topic: definition of 'zoom' for zoom media feature
02:07:16 [nikos]
02:07:40 [nikos]
shepazu: did you see the email from Boeing about zoom and pan and load events?
02:07:47 [nikos]
birtles: I think that's a separate issue
02:08:02 [nikos]
... this is something I don't think we need to discuss here because there was discussion in CSS on Sunday
02:08:13 [nikos]
... Takagi-san, myself, and Dean spoke about this later
02:08:25 [nikos]
... Ted from Apple has an action to look at different zoom media queries
02:08:38 [nikos]
... the current ones available aren't sufficient for pinch zoom and such
02:08:58 [nikos]
... Takagi-san has explored other ways a zoom media query could be specified and we've shown this to Dean to pass to Ted
02:09:12 [nikos]
TabAtkins: I notice all four of these definitions include scale transforms
02:09:19 [nikos]
... do we have any clue how those work with media features?
02:09:35 [nikos]
heycam: so results of media query can't depend on property values because that's cyclic?
02:09:38 [nikos]
TabAtkins: yes
02:09:50 [nikos]
heycam: there is at least one type of zooming that isn't reflected in the styling
02:10:12 [nikos]
... the pinch zooming and the dot current scale
02:10:53 [nikos]
TabAtkins: there might still be a use case for pinch zooming because you're going to want to tell when people are doing that
02:11:10 [nikos]
... things that are trying to do resolution based stuff don't want to respond to pinch zoom but maps, etc would
02:11:43 [nikos]
dino: I think it's better they're all separated and individually queryable
02:11:53 [nikos]
TabAtkins: that might make sense
02:12:14 [nikos]
dino: I think step 1 is to define all the terms
02:12:31 [nikos]
TabAtkins: they're defined in CSS OM view and referenced from media queries
02:12:41 [nikos]
krit: it might make sense to see if the pinch zooming from SVG is different
02:12:59 [nikos]
krit: it might be different if you want to pinch zoom in a document without zooming the outer doc
02:13:08 [nikos]
Rossen__: how is that different to an iframe?
02:13:12 [nikos]
krit: just that SVG isn't an iframe
02:13:18 [nikos]
Rossen__: should generalise that behaviour
02:13:29 [nikos]
... shouldn't apply just to SVG but to all elements
02:13:42 [nikos]
heycam: that was how I thought we might be able to do zoom and pan
02:14:23 [nikos]
shepazu: is SVG a special kind of content in HTML? A class that both SVG and iframe fall into?
02:14:27 [nikos]
krit: SVG has a viewport
02:14:35 [nikos]
... makes it easier to define pinch and zoom
02:15:23 [nsakai]
nsakai has joined #svg
02:15:31 [nikos]
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
02:15:36 [nikos]
krit: should be possible with media queries
02:15:47 [nikos]
heycam: do you need to know individual transforms in the stack?
02:16:18 [nikos]
stakagi: probably yes
02:16:34 [nikos]
... seems likely not not totally sure at the moment
02:16:59 [birtles]
actually, not the individual transforms, but the combined result
02:17:17 [nikos]
birtles: Next step is to see what Ted comes up with
02:17:21 [nikos]
... and provide feedback
02:18:11 [nikos]
ACTION: heycam to review Resource Priorities specification
02:18:12 [trackbot]
Created ACTION-3536 - Review resource priorities specification [on Cameron McCormack - due 2013-11-21].
02:18:50 [nikos]
Topics: Should parsed unknown elements implement SVGElement?
02:18:56 [nikos]
02:19:52 [TabAtkins]
02:20:09 [nikos]
ed: when you parse elements that SVG doesn't know about but that are in the SVG namespace
02:20:18 [nikos]
... it seems that all browsers put SVGElement interface on those elements
02:20:24 [nikos]
... rather than Element or SVGUnknownElement
02:20:33 [nikos]
... which would be similar to HTML
02:20:46 [nikos]
krit: if we define one of these elements later it starts rendering for all content
02:20:53 [nikos]
... I don't think this is an issue
02:21:21 [nikos]
krit: in this case since browsers already have behaviour, we should just specify it
02:21:46 [nikos]
ed: so just specify that SVGElement should be used in this case.
02:21:54 [nikos]
heycam: is there any advantage to doing things the HTML way?
02:22:11 [nikos]
shepazu: right now they're put in the SVG namespace
02:22:34 [nikos]
heycam: SVGElement has some things. e.g. nearest viewport
02:22:46 [nikos]
but SVGUnknownElement will inherit from SVGElement anyway
02:22:56 [nikos]
... the only argument is for consistency with HTML
02:23:38 [nikos]
shepazu: the advantage I see is if you're trying to detect whether a browser supports a particular - say star
02:23:51 [nikos]
... 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
02:24:21 [nikos]
heycam: I think you can do that anyway because you can check object.getPrototypeOf the dom node
02:24:56 [nikos]
... that would return a specific sub type
02:24:58 [TabAtkins]
(el instanceof SVGElement) && (el.prototype == SVGElement.prototype) { /* Unknown element! */ }
02:25:07 [dholbert]
dholbert has joined #svg
02:25:08 [nikos]
shepazu: what about if it's an element of another namespace?
02:25:28 [nikos]
krit: if we decide to put every element into the HTML namespace then SVG elements will use HTMLElement and HTMLUnknownElement
02:25:55 [nikos]
heycam: I think it depends on how we handle the parsing of that
02:26:04 [nikos]
... as long as you get the outer thing - SVG or graphics in my proposal
02:26:10 [nikos]
... if you're in that mode you can put the unknown ones in whatever
02:27:34 [nikos]
shepazu: seems to me the only element that I expect (besides new SVG elements) to add that might cause problems is the HTML element
02:27:55 [TabAtkins]
02:27:57 [nikos]
... straw poll, who would like us to allow HTML root element without the foreignObject wrapper
02:28:03 [TabAtkins]
02:28:15 [nsakai_]
nsakai_ has joined #svg
02:29:12 [nikos]
shepazu: so will this cause problems in that context?
02:29:14 [gcapiel]
gcapiel has joined #svg
02:29:20 [nikos]
Rossen__: in this context inline content is treated how?
02:29:32 [nikos]
... I mean text in SVG
02:29:43 [TabAtkins]
02:29:55 [Rossen__]
<svg>Hello World</svg>
02:30:05 [nsakai]
nsakai has joined #svg
02:30:05 [krit]
<svg>More examples</svg>
02:30:07 [nikos]
Are you saying first example is different to second example?
02:30:11 [Rossen__]
<svg><span>Hellow World</span></svg>
02:30:18 [TabAtkins]
Yes, different.
02:30:32 [nikos]
shepazu: yes that would be different
02:30:38 [TabAtkins]
<span> makes HTML element. Raw text is just ignored.
02:30:39 [nikos]
... do we need the HTML root?
02:31:06 [nikos]
shepazu: All i was proposing was that the HTML tag be required to insert HTML content
02:31:10 [nikos]
Rossen__: I misunderstood
02:31:38 [nikos]
krit: I suggested HTML in SVG without the HTML tag
02:31:42 [nikos]
... just needs a viewport
02:31:46 [nikos]
shepazu: who is going to do this?
02:32:07 [nikos]
TabAtkins: I'll do it
02:32:41 [nikos]
shepazu: the question is whether it causes us problems
02:32:48 [nikos]
heycam: depends how we do parsing and namespaces and so on
02:32:59 [nikos]
... but should be able to test whether an element is recognised or not in any case
02:33:18 [nikos]
shepazu: I wonder if inserting SVG dynamically will behave different
02:33:33 [nikos]
... currently in implementations you get different behaviour
02:34:00 [nikos]
krit: CreateElement doesn't trigger the parser
02:34:12 [nikos]
... I think what Doug is saying is if you have inner html and you use a rect
02:34:19 [nikos]
... you have to nest it in an SVG element
02:34:34 [nikos]
ed: I think we recently added inner html to SVG elements and it does use the context
02:35:02 [nikos]
shepazu: Currently if I put an HTML element it's treated as an SVG element
02:35:07 [MikeSmith]
MikeSmith has left #svg
02:35:19 [nikos]
... if we specify the HTML elements as things that go in another namespace
02:35:45 [nikos]
... will there be a hack (not to be specced just to be considered) to allow developers to get what they expect in older UAs
02:36:00 [nikos]
... I'll do some testing
02:36:15 [nikos]
... my only concern is that specific case of what happens when there's the bare name HTML
02:36:38 [nikos]
shepazu: For the original question, let's specify what browsers are already doing
02:37:07 [nikos]
RESOLUTION: We will spec what browsers are currently doing - use SVGElement interface for unknown elements.
02:37:49 [ed]
-- break until 11am --
02:38:31 [kurosawa_]
kurosawa_ has joined #svg
02:38:31 [gcapiel1]
gcapiel1 has joined #svg
02:44:03 [nsakai_]
nsakai_ has joined #svg
02:54:23 [myakura]
myakura has joined #svg
02:58:10 [gcapiel]
gcapiel has joined #svg
03:00:48 [Zakim]
03:02:30 [jun]
jun has joined #svg
03:03:59 [ed]
Zakim, call huangsong
03:03:59 [Zakim]
I am sorry, ed; I do not know a number for huangsong
03:04:20 [ed]
Zakim, call huangshan
03:04:20 [Zakim]
ok, ed; the call is being made
03:04:22 [Zakim]
03:05:01 [Zakim]
03:05:03 [ed]
Zakim, room for 4?
03:05:04 [Zakim]
ok, ed; conference Team_(svg)03:05Z scheduled with code 26631 (CONF1) for 60 minutes until 0405Z
03:05:09 [ed]
Zakim, call huangshan
03:05:09 [Zakim]
ok, ed; the call is being made
03:05:10 [Zakim]
03:05:15 [ed]
ed has changed the topic to: Agenda: code for today is 26631
03:08:25 [birtles]
birtles has joined #svg
03:09:16 [heycam]
Zakim, code?
03:09:16 [Zakim]
the conference code is 26632 (tel:+1.617.761.6200, heycam
03:10:00 [Zakim]
03:10:05 [ed]
Zakim, call huangshan
03:10:05 [Zakim]
ok, ed; the call is being made
03:10:07 [Zakim]
03:10:11 [heycam]
Zakim, code?
03:10:11 [Zakim]
the conference code is 26632 (tel:+1.617.761.6200, heycam
03:10:26 [TabAtkins]
The conf was only for 1 hour, maybe zakim doesn't want to let new people in?
03:11:34 [Zakim]
03:11:35 [Zakim]
Team_(svg)01:13Z has ended
03:11:35 [Zakim]
Attendees were Huangshan, TabAtkins
03:11:44 [heycam]
Zakim, dial huangshan
03:11:44 [Zakim]
ok, heycam; the call is being made
03:11:45 [Zakim]
Team_(svg)03:05Z has now started
03:11:47 [Zakim]
03:11:49 [heycam]
Zakim, code?
03:11:49 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200, heycam
03:12:07 [Zakim]
03:12:14 [Zakim]
03:13:12 [nikos]
nikos has joined #svg
03:13:17 [birtles]
scribenick: birtles
03:14:44 [birtles]
topic: SVG accessibility
03:15:14 [birtles]
gcapiel: I lead engineering at Benetech
03:15:36 [birtles]
... for Benetech we have a few projects were accessibility is a big projects
03:15:46 [birtles]
... including bookshare
03:15:55 [birtles]
... which is a very large library of accessible books
03:16:12 [birtles]
... we also have a project which is in collaboration with DAISY and NCAM
03:16:23 [birtles]
... we are working on "diagram center"
03:16:36 [birtles]
... we are focussing on, "How do we lower the cost of creating accessible images?"
03:16:46 [birtles]
... "What standards do we need to achieve that goal?"
03:17:00 [birtles]
... we want accessible images in e-books and across the open web
03:17:12 [birtles]
... I'm in the digital publishing group composed of people from the book publishing industry
03:17:19 [birtles]
... we have some representatives around accessibility
03:17:23 [birtles]
... and some w3c staff
03:17:37 [birtles]
... as part of that we've been working to identify gaps in the open web platform that publishers need
03:17:42 [birtles]
... I've been focussing on accessibility
03:18:04 [gcapiel]
03:18:06 [birtles]
... it's tricky because you really need to accessibility for everything
03:18:12 [birtles]
... not just ebooks
03:18:20 [birtles]
... the link above is a set of use cases I'll walk through
03:18:32 [birtles]
... the first use case is about rendering mathematics using SVG instead of MathML
03:18:38 [birtles]
... MathML support is either missing or inconsistent
03:18:46 [birtles]
... it's not clear when that issue will be resolve
03:18:57 [birtles]
... so what publishers are doing is using images (esp. PNG and JPEG)
03:19:11 [birtles]
... they do that because inexpensive devices like kindle don't support mathml at all
03:19:20 [birtles]
... some of those devices don't support SVG either but some do
03:19:37 [birtles]
... 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
03:19:53 [birtles]
... so we've been looking at using MathJAX on the server using Node.js to convert MathML to SVG
03:20:12 [birtles]
... that also lets us work with open-source technology and using ChromeBox, Google's screen reader technology
03:20:38 [birtles]
... using that tool, you can feed it MathML and get back both SVG and a description of that math
03:20:53 [birtles]
heycam: is it a problem that Blink is dropping MathML support?
03:20:59 [kurosawa_]
03:21:06 [birtles]
gcapiel: no it's not really since it's still in the DOM
03:21:12 [birtles]
... even if it's not rendered
03:21:27 [birtles]
... 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
03:21:37 [birtles]
... that would allow screen readers to pick it up
03:22:01 [richardschwerdtfeger]
03:22:05 [richardschwerdtfeger]
03:22:07 [birtles]
... 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
03:22:19 [birtles]
... one more thing, Rich was involved in adding tabindex to SVG which is great
03:22:27 [birtles]
... but I think there may be uses for that with math too
03:22:31 [birtles]
... so you can navigate the tree
03:22:51 [krit]
03:22:52 [birtles]
richardschwerdtfeger, one of the things I asked for was to have direct access to the mathml
03:23:04 [birtles]
... are you suggesting embedding it in the SVG?
03:23:12 [birtles]
gcapiel: yes, that's what I'm suggesting
03:23:22 [birtles]
richardschwerdtfeger: makes sense
03:23:51 [birtles]
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
03:24:02 [birtles]
... for example, you might need additional parentheses
03:24:18 [birtles]
heycam: is that because people generally write presentational mathml not content mathml
03:24:27 [birtles]
gcapiel: yes, content mathml hasn't really gone anywhere
03:24:55 [birtles]
... we've been putting work into how to use crowdsourcing to improve the accessibility of existing math content
03:25:00 [birtles]
... and have had a lot of success
03:25:15 [birtles]
... but often they don't have access to the source or the web server
03:25:37 [birtles]
... so we'd like to take an annotation approach where you can just, for example, add parentheses or overwrite the textual description
03:25:42 [stakagi]
stakagi has joined #svg
03:25:56 [birtles]
... the screen reader would notice this URI and pull down the additional annotations from the coud
03:26:17 [birtles]
... so it would be great if there was a standard way for marking up those URIs
03:26:20 [birtles]
03:26:36 [wonsuk]
wonsuk has joined #svg
03:26:40 [richardschwerdtfeger]
03:26:46 [birtles]
heycam: I have some practical questions about how to markup MathML in the SVG spec so I might get your help on that later
03:27:04 [birtles]
richardschwerdtfeger: yes, of course.
03:27:15 [birtles]
... aria-describedby might help with this
03:27:35 [birtles]
s/richardschwerdtfeger: yes,/gcapiel: yes,/
03:27:45 [birtles]
richardschwerdtfeger: I could help with adding that
03:27:50 [birtles]
heycam: do we reference that properly yet?
03:27:54 [birtles]
richardschwerdtfeger: yes we do
03:29:10 [birtles]
... is it a problem that ARIA 1.1 is only a FPWD?
03:29:14 [birtles]
heycam: I think it's fine for now
03:29:18 [birtles]
ACTION: Rich to reference ARIA 1.1 in SVG 2
03:29:19 [trackbot]
Created ACTION-3537 - Reference aria 1.1 in svg 2 [on Richard Schwerdtfeger - due 2013-11-21].
03:29:48 [birtles]
krit: putting presentation mathml into SVG, this should already be possible using foreignObject
03:30:01 [birtles]
... with the limitation that you need to specify width/height which is not very convenient
03:30:15 [birtles]
... it would be nice to allow mathml to be included directly but that would require changes to the html parser
03:30:33 [birtles]
heycam: might be good to keep in mind when we discuss HTML in SVG later
03:30:42 [birtles]
shepazu: that might just fall out of the HTML model
03:31:00 [Rossen__]
Rossen__ has joined #svg
03:31:08 [birtles]
heycam: I suspect that MathML names when you're parsing in SVG parsing mode will become SVG elements
03:31:23 [birtles]
shepazu: I wonder if that's the case since SVG elements are whitelisted
03:31:26 [birtles]
heycam: for case conversion
03:31:44 [birtles]
shepazu: in any case it's a kind of whitelisting... it bears investigation
03:32:44 [birtles]
krit: if we really want to move MathML names in to the SVG space... that might be a problem
03:32:53 [birtles]
heycam: we should consider this when we talk about HTML in SVG later
03:32:57 [gcapiel] and
03:33:01 [birtles]
gcapiel: I'll move onto the next use case
03:33:13 [birtles]
... this concerns sonification using multi-modal delivery for SVG
03:33:29 [birtles]
... I have a use case and a demo using Web Audio and Web Speec to sonify
03:33:44 [birtles]
... the demo works with that specific SVG and similar ones but is not generally useful
03:33:57 [birtles]
... since it needs semantic data like axes and tick marks
03:34:19 [birtles]
ChrisL: how do you find that data in the demo
03:34:35 [birtles]
shepazu: in this demo it works since the files have a consistent layout
03:34:41 [birtles]
... it's something I'd like to aria
03:34:59 [birtles]
... e.g. a "data-point" role or something of that ilk
03:35:12 [birtles]
... it distinguishes that piece of information from the other graphics on the page
03:35:17 [birtles]
... likewise for axes
03:35:30 [ChrisL]
ChrisL has joined #svg
03:35:31 [birtles]
heycam: how broadly do you want to look at semantics of diagrammatic content
03:35:35 [birtles]
... there's quite a range
03:35:52 [birtles]
gcapiel: I guess it could be a wider range because not everything can be sonified
03:36:16 [birtles]
... but some of this might apply to tactile output too
03:37:10 [gcapiel]
03:37:22 [birtles]
gcapiel: the next use case (above) covers including HTML inside SVG
03:37:45 [birtles]
... and the reason we care about that is [paused for demo]
03:38:29 [birtles]
(shepazu demos sonification)
03:38:41 [birtles]
shepazu: we want to distinguish sonification from vocalization
03:40:04 [birtles]
... we can read out different values but that doesn't give the use the gist of the function
03:40:53 [birtles]
(demo makes sounds whose pitch varies with the y-value of the graph)
03:41:29 [birtles]
... compare this to existing SVG accessibility features
03:42:01 [birtles]
... there's also a Web Speech API that would read off text
03:42:13 [birtles]
... so we can make it read out this chart as a list
03:42:37 [birtles]
... it would be better if we could allow users to navigate around the chart
03:42:50 [birtles]
... using the keyboard
03:42:59 [richardschwerdtfeger]
03:43:15 [ChrisL]
03:43:36 [birtles]
richardschwerdtfeger: so you're looking at adding semantics to assist the textual description of the chart?
03:43:50 [birtles]
shepazu: yes, I don't want to boil the ocean, but for common items
03:43:54 [ChrisL]
03:43:57 [birtles]
richardschwerdtfeger: I think I can help with this
03:43:58 [richardschwerdtfeger]
03:44:00 [ChrisL]
ack richardschwerdtfeger
03:44:00 [masatakayakura]
masatakayakura has joined #svg
03:44:10 [krit]
03:44:38 [birtles]
ChrisL: often stuff which is for accessibility gets a boost when it also has some use in another context
03:45:31 [birtles]
... 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
03:45:47 [birtles]
... so it was a real benefit for sighted people as well
03:46:08 [birtles]
gcapiel: there is also research that you retain information better if you receive it in a multi-modal way
03:46:29 [birtles]
shepazu: yes, but we're not proposing adding sonification to SVG but to add the hooks for these alternative representations
03:46:38 [ChrisL]
ChrisL has joined #svg
03:46:43 [birtles]
heycam: and these hooks would be aria features
03:46:46 [birtles]
shepazu: yes
03:47:00 [birtles]
heycam: so then we don't need to do anything much accept allowing these new attributes
03:47:28 [birtles]
ChrisL: yes, you just need the hooks
03:47:29 [cyril]
cyril has joined #svg
03:47:55 [birtles]
shepazu: having the ability to markup in a commonly understood way allows easier extraction and re-use of the data
03:48:06 [gcapiel]
03:48:13 [birtles]
gcapiel: now I'd like to talk about more general descriptions
03:48:19 [birtles]
... this is an image and its description
03:48:30 [birtles]
... it's an infographic really
03:48:42 [birtles]
... it has a lot of information that would be hard to capture in an alt attribute
03:49:03 [birtles]
... I guess you could use describedby but then the description might be separated from the image itself
03:49:18 [birtles]
... this is where having HTML in SVG might be useful
03:49:26 [birtles]
heycam: how would you imagine this working?
03:49:56 [birtles]
shepazu: so currently the content model of <desc> is text
03:50:10 [birtles]
... if that allowed markup we could have tables, lists etc.
03:50:19 [ChrisL]
ChrisL has joined #svg
03:50:47 [birtles]
ChrisL: putting bare-name elements inside <desc> is fine since it doesn't need positioning information etc.
03:51:02 [birtles]
... seems reasonable to put bare-name HTML there
03:51:27 [birtles]
heycam: so I think the HTML parser already switches into allowing HTML content inside <desc>, <title>, and <foreignObject>
03:51:34 [birtles]
gcapiel: it's not in the spec though
03:51:47 [birtles]
shepazu: we need to clarify in the spec and make test cases
03:51:56 [ChrisL]
ChrisL has joined #svg
03:52:11 [birtles]
heycam: one part is to make sure the HTML parser does the right thing and the other part is blessing that pattern in SVG
03:52:19 [birtles]
... and we only really need to do the second part
03:52:20 [richardschwerdtfeger]
03:52:23 [birtles]
shepazu: any objections?
03:52:36 [birtles]
heycam: is that idea that you target that <desc> with an ARIA describedby
03:52:44 [birtles]
richardschwerdtfeger: it's an API mapping issue more than anything
03:52:45 [ChrisL]
ack ChrisL
03:53:07 [birtles]
gcapiel: here's a use case: I'm a publisher and want to put some images in my text book
03:53:17 [birtles]
... I get a water cycle image from a site in SVG format
03:53:33 [birtles]
... I want the description to be packaged inside the SVG
03:53:46 [birtles]
heycam: my question is more about how to refer to the <desc>
03:53:55 [birtles]
... currently <desc> applies to its parent element
03:53:59 [birtles]
... and that may or may not be appropriate
03:54:54 [richardschwerdtfeger]
03:55:06 [ChrisL]
ack richardschwerdtfeger
03:55:11 [birtles]
... sometimes you may want to have multiple elements targetting the same desc
03:55:33 [birtles]
richardschwerdtfeger: one difficulty is you have HTML content that is not actually rendered
03:56:29 [birtles]
... I assume that stuff is in the DOM and an AT can navigate it
03:56:38 [birtles]
... a magnifier will have challenges if it's not rendered
03:56:47 [birtles]
... one way around that is to have it as an iframe
03:57:07 [birtles]
... but you want it all in the same document?
03:57:17 [birtles]
shepazu: I see what you're saying but I think this is an implementation detail
03:57:20 [birtles]
richardschwerdtfeger: ok
03:58:29 [birtles]
RESOLUTION: <desc> should allow HTML markup and we should have tests for this and recommend this practice
03:59:09 [birtles]
shepazu: we should cross-reference this when we talk about inline HTML in general
03:59:37 [birtles]
ACTION: Doug to clarify HTML content in <desc> and <title> elements
03:59:37 [trackbot]
Created ACTION-3538 - Clarify html content in <desc> and <title> elements [on Doug Schepers - due 2013-11-21].
04:00:15 [birtles]
heycam: I checked the HTML parsing and yes, for <title>, <desc>, and <foreignObject> parsing switches back to HTML
04:00:18 [heycam]
04:00:33 [gcapiel]
04:00:55 [birtles]
gcapiel: the next use case is around post-production of descriptions
04:01:20 [birtles]
... 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 incorrct
04:01:24 [ChrisL]
04:01:26 [birtles]
... we want to have a way to fix that
04:01:31 [birtles]
04:01:57 [birtles]
... the author might actually describe in the SVG a link to a point where those crowdsource improvements could be pulled in
04:02:07 [ChrisL]
ChrisL has joined #svg
04:02:21 [birtles]
... after some content has been created how does someone annotate it
04:02:37 [shepazu]
04:02:38 [birtles]
ChrisL: so is this about forking or about having an extension point?
04:02:49 [birtles]
gcapiel: the latter since there may be copyright issues
04:02:49 [heycam]
q- ChrisL
04:03:02 [birtles]
ChrisL: it opens up issues about an approval process
04:03:11 [birtles]
... it sounds similar to crowdsourcing captions for videos
04:03:21 [birtles]
gcapiel: yes, it's similar to that which has been very successful
04:03:26 [heycam]
q- shepazu
04:04:00 [birtles]
shepazu: gcapiel and I talked about this and I think this is a general use case
04:04:15 [birtles]
... we might want to plug into the work going on in the open annotations world
04:04:34 [birtles]
... so perhaps you could hook your user agent into a particular open annotation framework
04:04:45 [birtles]
... so we just need the hooks
04:04:55 [birtles]
gcapiel: so we need to look into whether that can be applied to SVG
04:05:05 [gcapiel]
04:05:19 [birtles]
shepazu: I spoke to the hypothesis folks and I'm confident it's possible
04:05:22 [birtles]
gcapiel: here is another use case
04:05:29 [birtles]
... this SVG is very useful for a sighted user
04:05:59 [birtles]
... 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
04:06:10 [birtles]
... so currently the way this is handled is by creating a separate image
04:06:21 [birtles]
... but I'd like to make it so you could use the same format
04:06:43 [birtles]
... and going forward we might even use 3D printers for tactile output
04:06:47 [birtles]
... which might have slightly different requirements still
04:06:47 [shepazu]
04:06:56 [birtles]
... so we might need media queries for this
04:07:06 [birtles]
shepazu: I think this is actually a CSS questions
04:07:26 [birtles]
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
04:07:46 [birtles]
shepazu: I'm pretty sure they could be. e.g. hiding/displaying content, replacing a pattern with a fill etc.
04:08:08 [birtles]
... we'll look into this and come back with a proposal
04:08:20 [birtles]
heycam: if there are things that can't be styled with CSS then we'll need to handle that
04:08:42 [birtles]
richardschwerdtfeger: I'm editing media queries now
04:08:50 [birtles]
... just a note, we are deprecating media types nw
04:09:19 [birtles]
s/richardschwerdtfeger: I'm editing/TabAtkins: I'm editing/
04:10:23 [birtles]
ACTION: Doug to work with Gerardo and Tab to come up with haptic, tactile and 3d media queries
04:10:23 [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].
04:10:26 [gcapiel]
04:10:49 [birtles]
gcapiel: the final use case related to re-using the same SVG multiple times in the same page
04:10:53 [shepazu]
04:10:57 [birtles]
... one idea was referencing it from an iframe
04:11:15 [birtles]
... the challenge with that is that from a useability point-of-view they are quite painful
04:11:25 [birtles]
krit: can you repeat the use case
04:11:49 [birtles]
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
04:12:01 [birtles]
... I want to reference it as a file
04:12:16 [ChrisL]
sounds like "fix the screen readers to not break on iframe"
04:12:28 [richardschwerdtfeger]
04:12:32 [birtles]
shepazu: you can use the <use> element for this
04:13:02 [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.)
04:13:14 [birtles]
gcapiel: we need to look at iframes for this
04:13:22 [birtles]
krit: if it's a basketball and <img> is probably better
04:13:48 [birtles]
richardschwerdtfeger: regarding iframes and JAWS is that we're getting to treat them basically like navs
04:14:11 [birtles]
gcapiel: no that's fine. I'm just concerned about useability
04:14:28 [birtles]
heycam: the seamless attribute on <iframe> might also be a hint here
04:14:43 [birtles]
richardschwerdtfeger: people are using iframes more for mashups
04:14:47 [birtles]
... to isolate part of the content
04:14:57 [birtles]
... I can help work with the useability issues
04:15:04 [birtles]
gcapiel: sounds good
04:16:09 [birtles]
topic: z-index in SVG
04:16:15 [birtles]
kurosawa_: my question is, is z-index a requirement for SVG2?
04:16:39 [birtles]
heycam: I think Tab might have been assigned to this?
04:16:45 [TabAtkins]
Was I?
04:16:59 [TabAtkins]
Sure, okay.
04:16:59 [birtles]
... if he or somebody could start adding that to the spec before the end of the year then it will be in SVG2
04:17:13 [birtles]
shepazu: is that good or bad for accessibility?
04:17:31 [birtles]
kurosawa_: to make SVG content accessibility we need to care about reading order
04:17:43 [birtles]
... but SVG using forces a certain rendering order
04:18:01 [birtles]
shepazu: so a z-index will allow to provide a different reading order to rendering order?
04:18:04 [birtles]
kurosawa_: yes
04:18:35 [birtles]
ChrisL: yes, that's right--sometimes that's how you'd do it
04:18:44 [ChrisL]
ChrisL has joined #svg
04:18:46 [birtles]
... but sometimes you want to allow different reading orders
04:19:06 [birtles]
... and you wouldn't have to keep manipulate the document every time for each different reading order
04:20:10 [birtles]
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)
04:20:28 [birtles]
ChrisL: I agree that for that use case z-index is the appropriate way to do it
04:20:47 [birtles]
shepazu: yes, we do want z-index in SVG2 because it also helps with accessibility
04:21:06 [birtles]
topic: Using Bikeshed for SVG specs
04:21:45 [birtles]
krit: I'd like to have the discussion with Peter first
04:21:50 [birtles]
(deferred for now)
04:22:16 [Zakim]
04:23:01 [birtles]
(break for lunch)
04:23:15 [Zakim]
04:25:15 [richardschwerdtfeger]
richardschwerdtfeger has left #svg
04:28:15 [Zakim]
disconnecting the lone participant, TabAtkins, in Team_(svg)03:05Z
04:28:17 [Zakim]
Team_(svg)03:05Z has ended
04:28:17 [Zakim]
Attendees were Huangshan, Rich_Schwerdtfeger, TabAtkins
04:29:20 [nsakai]
nsakai has joined #svg
05:24:37 [nsakai]
nsakai has joined #svg
05:27:18 [myakura]
myakura has joined #svg
05:43:25 [stakagi]
stakagi has joined #svg
05:49:30 [cyril]
cyril has joined #svg
05:53:15 [dino]
dino has joined #svg
05:55:59 [birtles]
birtles has joined #svg
05:56:28 [krit]
05:58:17 [stakagi]
stakagi has joined #svg
05:58:50 [shepazu]
shepazu has joined #svg
06:00:40 [kurosawa]
kurosawa has joined #svg
06:01:06 [myakura]
myakura has joined #svg
06:01:29 [krit]
ScribeNick: krit
06:01:57 [nsakai]
nsakai has joined #svg
06:02:00 [heycam]
Zakim, room for 4?
06:02:01 [Zakim]
ok, heycam; conference Team_(svg)06:02Z scheduled with code 26632 (CONF2) for 60 minutes until 0702Z
06:02:06 [heycam]
Zakim, call huangshan
06:02:06 [Zakim]
ok, heycam; the call is being made
06:02:07 [Zakim]
Team_(svg)06:02Z has now started
06:02:08 [Zakim]
06:03:22 [krit]
plinss: Shepherd has a couple of purposes
06:03:33 [krit]
plinss: manager of test suite
06:03:42 [krit]
heycam: yes, one part we want to use it
06:03:56 [krit]
heycam: are interested in anchors
06:04:07 [krit]
plinss: yes, shepherd does that as well
06:04:14 [krit]
plinss: tries to clasify anchors
06:04:34 [nikos]
nikos has joined #svg
06:04:36 [krit]
plinss: but needs understanding what is defined and the relationship to element, attribute and values
06:04:42 [krit]
plinss: in relies on markup in the spec
06:04:54 [krit]
plinss: tab and I came up with different ways to do it
06:05:08 [krit]
plinss: I don’t care which way, I ‘ll adapt to the spec style as well
06:05:19 [Zakim]
06:05:21 [ed]
topic: shepherd for svg repo
06:05:27 [krit]
heycam: are there some standard rules to make it easy for us to adapt
06:05:42 [krit]
plinss: there is documentation on shepherd as well
06:06:03 [TabAtkins]
06:06:03 [krit]
heycam: we use combination of bike shed and sag pre-processor on some FX specs
06:06:10 [krit]
cyril: what is bike shed?
06:06:13 [TabAtkins]
(For the in-spec markup that Bikeshed recognizes.)
06:06:17 [krit]
heycam: a CSS pre-processor
06:06:41 [krit]
plinss: with automatic cross linking of specs based on data of shepeherd
06:06:56 [krit]
plinss: bike shed calls shepherd and asks for anchors
06:07:05 [krit]
plinss: and specs can link back as welll
06:07:09 [TabAtkins]
krit, one word Bikeshed.
06:07:24 [krit]
heycam: we have similar things in SVG pre-processor but data is in external XML file
06:07:28 [TabAtkins]
s/bike shed/Bikeshed/g
06:07:50 [krit]
plinss: we use Jsonx
06:08:06 [heycam]
06:08:15 [krit]
TabAtkins: sheperd watches changes on other specs, no need to manually update an XML file
06:08:52 [krit]
heycam: if shepherd watch our specs as well would be great and having the right meta data in our specs as well
06:09:04 [TabAtkins]
Bikeshed also does automatic IDL linking/defining markup, generates railroad diagrams, and a bunch of other things.
06:09:17 [krit]
plinss: shepherd is watching all specs in FX already (with exception of ReSpec specs)
06:09:31 [TabAtkins]
Big weakness for SVG right now is that Bikeshed doesn't know how to generate multi-page specs yet.
06:09:41 [TabAtkins]
(I plan to do so, but haven't gotten to it yet.)
06:09:45 [krit]
plinss: I do want to have SVG scanned daily as well, and do it already
06:10:08 [krit]
cyril: shepherd is the server env that scans things? How is it related to bike shed?
06:10:23 [krit]
chirs: Is checking the specs
06:10:33 [krit]
06:10:37 [heycam]
I sometimes wonder whether we should make SVG2 primarily a one page spec, but also to have generated multi-page version.
06:10:59 [danielkim]
danielkim has joined #svg
06:11:01 [krit]
Chris: you can do links by automatic cross linking between specs and tests can reference specs as well
06:11:25 [krit]
Chris: [explaining some things of Bikeshed from the docs]
06:12:10 [krit]
shepazu: Bikeshed does not yet support multipage steps
06:12:24 [krit]
plinss: no problem for Shepherd at least
06:12:55 [krit]
plinss: Shepherd can find specs where ever sections move within the spec
06:13:15 [krit]
Chris: [Going crazy]
06:13:41 [krit]
heycam: Is the markup sufficient in SVG spec?
06:13:56 [krit]
plinss: no it is not, most of the things are not recognized at all
06:14:07 [krit]
heycam: using propdef even for element and attribute defintions
06:14:18 [krit]
plinss: that is bad for identifying things
06:14:32 [ChrisL]
ChrisL has joined #svg
06:14:42 [krit]
plinss: data-def type is a way to identify
06:14:44 [TabAtkins]
<dfn attribute>foo</dfn> becomes <dfn data-dfn-type="attribute">foo</dfn> after Bikeshedding.
06:14:51 [krit]
plinss: another way is a lot of short cuts
06:15:07 [krit]
plinss: propdef is another one as is elementdef and attributedef
06:15:08 [TabAtkins]
<div class="propdef"><dfn>foo</dfn></div> makes "foo" a property def.
06:15:27 [krit]
plinss: Shepherd understands all IDL
06:16:06 [krit]
krit: we can auto generate many things so we can change things easily with exception for attributes
06:16:35 [shepazu]
06:16:40 [krit]
TabAtkins: since propdef is used for styling purposes, there is a new class .defintion with the same purpose now
06:17:06 [krit]
heycam: we want the big blue element definition tables
06:17:27 [krit]
heycam: with content model and a lot more information and Shepher could use that in the future
06:17:55 [krit]
plinss: they were defining elements in definition sections
06:18:07 [krit]
plinss: so you could just link to the section headings
06:18:56 [krit]
plinss: HTML spec does not have all id’s set correctly yet
06:19:21 [krit]
shepazu: we adapted in the past already and adapting confincient the CSS WG is using makes sense...
06:19:29 [krit]
shepazu: easier to maintain
06:19:53 [krit]
shepazu: does SVG WG object to use convenients Shepherd is expecting?
06:20:13 [krit]
ChrisL: depends.. on testing yes. Bikeshed? maybe not
06:20:40 [krit]
shepazu: mean we should adapt spec styling so that Shepherd can pick things up more easily
06:20:48 [krit]
ChrisL: yes, we should definitely
06:20:52 [Rossen__]
Rossen__ has joined #svg
06:21:10 [ChrisL]
bikeshed is fine if it could do a multi-doc spec like svg2
06:21:18 [krit]
plinss: yes, Shepherd picks up tests already and don’t care about the markup as long as it is explicitly
06:21:35 [krit]
shepazu: yeah, we do not care about the markup, we want things to work
06:21:45 [krit]
ChrisL: and we don’t have the maintainance
06:21:58 [TabAtkins]
SVG just splits up pages by chapter, right?
06:22:22 [krit]
ChrisL: what is the minimal set for HTML5 so that we can adapt that?
06:22:34 [krit]
plinss: I am identifying most attributes but not all elements
06:22:47 [TabAtkins]
I think HTML tries to have the pages roughly balanced.
06:22:48 [SimonSapin]
SimonSapin has joined #svg
06:22:57 [ChrisL]
ChrisL has joined #svg
06:23:02 [ChrisL]
s/adapt/auto link into/
06:23:10 [krit]
krit: you pick up attributes on HTML but not elements? what about the reference to elements from attribute?
06:23:12 [TabAtkins]
<a element>filter</a>, or <a data-link-type="element">filter</a> if you're not Bikeshedding.
06:23:18 [krit]
plinss: not sure if Shepherd does
06:23:20 [SimonSapin]
FWIW, MDN also wants to parse spec to be notified when something changes that needs doc changes
06:23:40 [krit]
shepazu: what is the best way to learn what is needed for shepherd
06:23:44 [TabAtkins]
To mark up attributes for elements, <dfn attribute for="filter">x</dfn> (or whatever).
06:24:13 [krit]
plinss: I can generate a document explaining it
06:24:24 [gcapiel]
gcapiel has joined #svg
06:24:39 [krit]
ACTION: plinss deliver document to adapt specs to Shepherd
06:24:39 [trackbot]
Error finding 'plinss'. You can review and register nicknames at <>.
06:24:47 [krit]
ACTION: Peter Linss deliver document to adapt specs to Shepherd
06:24:47 [trackbot]
Created ACTION-3540 - Linss deliver document to adapt specs to shepherd [on Peter Sorotokin - due 2013-11-21].
06:24:56 [ChrisL]
ChrisL has joined #svg
06:25:36 [krit]
plinss: so you have attribute def table, we have the same for properties but we do not analyze the table in detail
06:25:41 [krit]
plinss: plan to do it
06:26:07 [krit]
plinss: will be done soon and pick up values and relations automatically
06:26:26 [krit]
plinss: what ever format you use, it must be machnine parable
06:26:31 [krit]
06:26:49 [krit]
cyril: how do you link back from specs and attributes?
06:27:08 [krit]
plinss: in the past we have backinks from tests to the spec
06:27:53 [krit]
krit: can we add anchor detections on tests and Shepherd will pick them up and auto link?
06:28:07 [krit]
plinss: came up before, but doesn’t work right now
06:28:42 [krit]
plinss: TabAtkins will probably discuss testable assertions and how Bikeshed can help in the future
06:29:33 [krit]
plinss: one thing, the test suite and test suite generation is independent of Shepherd, but Shepherd is used to build it
06:30:38 [krit]
ChrisL: prefer to have links to TR. If we send people to ED, then TR get irrelevant
06:31:01 [krit]
plinss: Tim says we can host a TR spec somewhere else and have a link to TR form that spec
06:31:22 [krit]
ChrisL: we have a rule against external script
06:31:53 [krit]
plinss: all tools are open sourced, I do not care on which server they run on
06:32:28 [krit]
ChrisL: [discussing publish policies of W3C]
06:33:16 [krit]
topic: new SVG DOM proposal
06:33:29 [krit]
heycam: want to make SVG DOM a bit saner
06:33:40 [krit]
heycam: how could it be possible to opt in to this new DOM
06:33:49 [krit]
heycam: otherwise existing script could break
06:33:49 [heycam]
06:34:27 [krit]
heycam: to sumaries: key idea… not have SVG elements in a different NS than HTML elements
06:34:55 [krit]
heycam: so we would use the NS of the element to decide to use new SVG DOM or old SVG DOM and element defintions
06:35:24 [krit]
ChrisL: HTML parser parses a lot of staff. So what happens to this which adds elements ti SVG NS?
06:35:51 [krit]
heycam: HTML parser would need to change to switch to new NS unless there is an foreignElment or other elements
06:36:46 [krit]
s/an foreignElment or other elements/a new elements where the SVG content is used which will do the switch to the new NS/
06:36:53 [krit]
heycam: I called it graphics
06:37:13 [krit]
heycam: <graphics>HTML NS of SVG elements</graphics>
06:37:38 [krit]
heycam: problem is support for older UAs
06:37:56 [shepazu]
06:38:00 [MichaelC]
MichaelC has joined #svg
06:38:21 [krit]
heycam: a new element would not help
06:38:24 [MichaelC]
MichaelC has left #svg
06:38:52 [krit]
krit: unless you wrap the SVG content in an extra <svg> element
06:38:55 [krit]
heycam: yes
06:39:01 [ChrisL]
ChrisL has joined #svg
06:39:07 [krit]
krit: when we want backward compatibility then...
06:39:13 [krit]
heycam: not sure if we want that
06:40:12 [krit]
TAG: If I have an old school element and move it to and old school element what happens
06:40:31 [gcapiel]
gcapiel has left #svg
06:40:39 [krit]
TAG: what happens to import node, adapt node, appendChild and so on
06:40:50 [ed]
s/adapt node/adoptNode/
06:41:05 [ed]
s/import node/importNode/
06:41:07 [krit]
heycam: most functionality would still work
06:41:22 [krit]
heycam: didn’t thought about that
06:41:30 [krit]
TAG: what about createElement
06:41:50 [krit]
TAG: new SVGPath() which interface do I get?
06:42:00 [krit]
heycam: there are no Ctors for SVG element yet
06:42:20 [krit]
heycam: and createElementNS would give you old school element
06:42:50 [krit]
heycam: now that they are in HTML, are they HTML*Element
06:43:11 [krit]
heycam: but we can’t easily use the same interfaces if you have linking within the same document
06:44:28 [birtles]
krit: so can't you just use an attribute instead?
06:44:36 [heycam]
(TAG = Alex Russell)
06:44:50 [TabAtkins]
Haha, I was wondering who TAG was supposed to be.
06:44:51 [birtles]
heycam: well typically the prototype of an object is decided at creation time
06:45:20 [birtles]
... since you need to decide the interface of the object at object creation time
06:45:34 [birtles]
... I thought that if you document.createElement it, it can't start off with the old interface
06:45:45 [birtles]
... then you do .setAttribute and suddenly get the new interface
06:45:48 [slightlyoff]
slightlyoff has joined #svg
06:46:02 [slightlyoff]
06:46:13 [krit]
06:46:37 [birtles]
TabAtkins: so in Custom Elements you can say what the prototype is but only at parse time
06:46:53 [birtles]
heycam: do you agree that it would be weird to change the interface on a object after it start existing?
06:47:20 [birtles]
slightlyoff: I think you can get there using some esoteric ways (ES6 proxies etc.) but none of them are attractive
06:47:33 [birtles]
... the downside is that in the transition period is that we double the surface area
06:47:44 [birtles]
... I'd like to find ways to reduce the surface area of the SVG DOM
06:47:56 [birtles]
... the number of interfaces created by the SVG DOM is a burden on implementations
06:48:09 [birtles]
shepazu: to what extent could we trim them away from the existing DOM without harming existing content
06:48:27 [slightlyoff]
heycam, sorry I wasn't in the channel before, can you link me to the proposal again?
06:48:37 [jun]
jun has joined #svg
06:48:49 [krit]
shepazu: q-
06:48:51 [nikos]
06:48:58 [cyril]
06:48:59 [ChrisL]
ChrisL has joined #svg
06:49:06 [slightlyoff]
06:49:13 [birtles]
heycam: the section of reflecting attributes in the proposal gets rid of a lot of the interfaces (from the new world)
06:49:24 [birtles]
shepazu: what is the goal of the proposal?
06:49:41 [birtles]
... making a new root element is an outcome not a goal
06:49:48 [birtles]
heycam: right, it's not a goal, but a means to an end
06:50:07 [birtles]
shepazu: I mean is putting SVG elements into the HTML namespace a goal or a means?
06:50:16 [birtles]
heycam: it wasn't a goal per se
06:50:24 [birtles]
shepazu: I'd like to see the goals be more explicit
06:50:35 [birtles]
cyril: my experience of teaching SVG is that students gets confused by namespaces
06:50:48 [birtles]
... they are surprised that they can't create SVG elements in the same way as they can HTML elements
06:51:02 [birtles]
krit: I also think namespaces introduce an implementation burden
06:51:18 [birtles]
... we should be able to assume people are just using the new DOM or the old DOM
06:51:33 [birtles]
heycam: I'd love to drop the old DOM but unfortunately we can't given existing usage
06:51:55 [birtles]
krit: what if we keep the existing naming, interfaces etc. and remove just the namespace requirement
06:52:03 [birtles]
... i.e. SVGElement inherits from HTMLElement
06:52:23 [birtles]
heycam: my proposal includes SVGElement inheriting from HTMLElement
06:52:34 [slightlyoff]
heycam, this proposal looks very good overall
06:53:26 [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
06:53:52 [birtles]
... but Dirk, how do you propose we fix existing problems such as getting rid of animVal
06:54:02 [ChrisL]
the proposals for reflecting values and getting rid of animval and baseval is valuable
06:54:09 [birtles]
krit: I don't think we can get rid of those now
06:54:52 [birtles]
dino: but we should take the view that the future is bigger that the past so we should fix it now
06:55:19 [birtles]
slightlyoff: I also agree that these old interfaces are creating drag that stops SVG from developing
06:55:59 [birtles]
krit: but there are existing libraries like raphael and snap that rely on the current SVG DOM
06:56:04 [birtles]
ChrisL: I don't see any removal of functionality... just expressing it in a different way
06:56:23 [birtles]
krit: so what do you suggest?
06:56:32 [birtles]
heycam: the proposal doesn't remove the old DOM
06:56:50 [birtles]
... there is duplication, but I think that's the only way we can move forward without breaking other content
06:57:16 [birtles]
ChrisL: so this would double the footprint for SVG but then we hope the old footprint would fade away quickly
06:57:31 [birtles]
shepazu: in terms of footprint... you have these reflectors in there
06:58:04 [birtles]
... is it possible they reduce the footprint of the new DOM by aliasing etc.
06:58:50 [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
06:59:03 [birtles]
shepazu: I'm just wondering how we can reduce the footprint
06:59:12 [ChrisL]
ChrisL has joined #svg
06:59:27 [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
06:59:33 [ChrisL]
ChrisL has joined #svg
06:59:50 [birtles]
heycam: Doug, you don't need two implementations, you can re-use code
07:00:16 [birtles]
krit: can we remove the liveness of animVal?
07:00:25 [ChrisL]
ChrisL has joined #svg
07:00:33 [birtles]
... i.e. make it an alias for baseVal
07:00:53 [birtles]
... that would be a big saving
07:01:25 [ChrisL]
ChrisL has joined #svg
07:01:44 [birtles]
heycam: we can probably discuss that separately
07:02:25 [ChrisL]
ChrisL has joined #svg
07:02:32 [birtles]
... the basic strategy I've applied to these members is to expose attributes as strings...
07:02:43 [birtles]
... we have, for example, the polygon element that has a list of points
07:02:58 [birtles]
... in the old SVG DOM we have a live list of points you can manipulate
07:03:09 [birtles]
... in the new SVG DOM we have a pair of methods to set and get an array
07:03:21 [birtles]
... that makes it slightly more awkward to use
07:03:32 [birtles]
... if you just want to change one point, say, for animation, you have to set the whole thing
07:03:42 [birtles]
... but what do you think Alex?
07:03:51 [birtles]
slightlyoff: lists in javascript are currently particularly painful
07:04:04 [birtles]
... in the post-ES6 world things might get easier
07:04:22 [birtles]
... currently you might use a proxying approach which is basically what the old DOM does
07:04:38 [birtles]
... but my suggestion for the time being is to do whatever is closest to current javascript which is arrays
07:04:53 [birtles]
heycam: what will things look like in the distant future?
07:05:23 [birtles]
slightlyoff: it's end-of-turn... I assume you're not doing synchronous layout?
07:05:36 [birtles]
heycam: actually if you update stuff and do getBBox then I think you will get the updated result
07:05:52 [birtles]
slightlyoff: that's problematic, we should try to fix that
07:06:06 [birtles]
... we should try to avoid that
07:06:25 [birtles]
heycam: at least in SVG it's more contained since you don't have reflow, just absolutely positioned elements
07:06:37 [birtles]
krit: can we take on some parts of the proposal
07:06:45 [birtles]
... the most important part is that we don't have many namespaces
07:06:53 [birtles]
heycam: I agree, but I don't think we can do it separately
07:07:15 [birtles]
... since otherwise you'll have SVG elements in the HTML namespace with the old DOM then we could never change it
07:07:28 [birtles]
... so it would poison our ability to change things
07:07:46 [birtles]
krit: I don't think the swapping works
07:08:17 [birtles]
... it's a huge mess... you add more code and it's unlikely that you can ever remove the old code
07:09:02 [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
07:09:23 [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.
07:09:44 [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
07:10:09 [birtles]
slightlyoff, ChrisL: I don't think that gets you a lot
07:10:17 [birtles]
slightlyoff: it means you have to keep the old interfaces forever
07:10:45 [birtles]
heycam: I don't want to do things slowly, I want to add the new features at once
07:11:00 [birtles]
krit: if we switch the namespace now what can you *not* do in the future?
07:11:13 [birtles]
heycam: you can't use the namespace as the switch for opting into the new DOM
07:11:45 [birtles]
krit: everything you want to add to the new DOM, you can detect this stuff
07:12:00 [birtles]
slightlyoff: how does that work?
07:12:25 [birtles]
... this makes compatibility more difficult since you have to detect this stuff
07:12:30 [myakura]
myakura has joined #svg
07:12:49 [birtles]
... I don't think we should give weight to implementation issues here
07:12:59 [birtles]
TabAtkins: I think we could trim out a lot of stuff already
07:13:07 [ChrisL]
ChrisL has joined #svg
07:13:13 [birtles]
ChrisL: we're focussing too much on the impact on implementors
07:13:24 [birtles]
... we should focus more on authors and this proposal makes it easier for authors
07:13:44 [birtles]
... one way to introduce this is to say that all the new SVG2 stuff only works in this new method
07:13:55 [birtles]
... as an incentive to switch to this
07:14:06 [TabAtkins]
+1 to carrot
07:14:10 [birtles]
heycam: e.g. a method to get the stroke bounding box etc.
07:14:17 [shepazu]
07:14:29 [TabAtkins]
Old DOM freezes on the current set, and shrinks as metrics show we can kill things.
07:14:35 [birtles]
... krit, what do you think is the problem with this?
07:14:44 [TabAtkins]
New DOM is better, and grows with new abilities as we think of them.
07:14:45 [birtles]
krit: I think we'll never be able to get rid of the old interfaces
07:14:59 [birtles]
... it will be 10 years before we can start removing things
07:15:08 [ChrisL]
ChrisL has joined #svg
07:15:20 [birtles]
... it will take 2~3 years until it is implemented properly
07:15:29 [ChrisL]
ChrisL has joined #svg
07:15:47 [birtles]
ChrisL: but you were saying we drop animVal?
07:15:54 [birtles]
krit: it's not being used
07:16:03 [birtles]
ChrisL: it is
07:16:32 [birtles]
shepazu: there was a small but active community of SVG developers from 1999-2006
07:16:43 [TabAtkins]
shepazu: Maybe 12 or so.
07:16:48 [birtles]
... (more background)
07:18:57 [birtles]
... there is lot of content out there that may not even work due to namespace issues
07:19:26 [birtles]
... in any case, I think we need to involve the community in this decision
07:19:34 [birtles]
... people like maintainers of script libraries
07:20:15 [birtles]
krit: I don't think many people have reviewed it yet
07:20:39 [birtles]
heycam: I just want to know (a) if I should keep driving this, and (b) what sort of timeframe?
07:20:48 [birtles]
shepazu: I'm still uncomfortable about changing the root element
07:20:57 [birtles]
... it introduces confusion about what you should be doing
07:21:02 [birtles]
... there are definite risks
07:21:09 [birtles]
... but that may be ok
07:21:16 [birtles]
... I'd like to be explicit about the goals
07:21:46 [birtles]
heycam: the 1.5 goals are, 1) changing to the reflecting of attributes, 1.5) changing namespaces
07:21:59 [birtles]
... the change of namespaces just happened to be a good way of opting into the new DOM
07:22:04 [birtles]
... the new root element is not a goal, just a means
07:22:13 [birtles]
cyril: the goal to change the reflecting of attributes
07:22:29 [birtles]
... is it to make writing SVG easier? or reduce code size in implementations?
07:22:35 [birtles]
heycam: for useability for authors
07:22:53 [birtles]
krit: "is this something important enough for SVG 2?" is a good question
07:23:00 [birtles]
... is it worth delaying SVG 2 for?
07:23:27 [birtles]
dino: if we delay it, it will only make the decision harder
07:23:30 [birtles]
... there will be more content to break
07:23:36 [ChrisL]
ChrisL has joined #svg
07:23:49 [birtles]
ChrisL: and by bringing forward the namespace change you'd remove one of the drivers for switching
07:23:57 [birtles]
krit: so, should it be in SVG2?
07:24:03 [birtles]
heycam: I feel like it should
07:24:33 [birtles]
ChrisL: I don't think we could do this in SVG3
07:24:41 [birtles]
krit: in which case we should prioritize this work
07:25:17 [birtles]
... we should focus on the details at the next F2F
07:25:43 [birtles]
slightlyoff: I'd like to help set up a process for you all to talk to major library authors and get their input
07:25:46 [myakura]
myakura has joined #svg
07:26:10 [birtles]
... are these meetings to do design work or just making decisions?
07:26:17 [birtles]
heycam: we do both
07:26:30 [birtles]
... this is the first f2f where I've brought up the proposal
07:26:41 [birtles]
... so we could dedicate more time to it at the next f2f
07:26:49 [birtles]
ChrisL: I think we can get new data before then
07:26:59 [birtles]
krit: I think we should delay LC anyway
07:27:09 [birtles]
heycam: I think January was a bit optimistic anyway
07:27:12 [birtles]
... but we will discuss that later
07:27:21 [birtles]
krit: how do we reach out to developers from here
07:27:28 [birtles]
heycam: I haven't really announced it yet
07:28:09 [birtles]
shepazu: for svg developers there's the d3 list, svg-developers, we can tweet, etc.
07:29:14 [birtles]
krit: if we want people to read the proposal I think we could rework it to make it easier to follow
07:29:27 [birtles]
shepazu: does your document talk about the problems with the existing DOM?
07:29:37 [birtles]
... I think we should add that
07:31:34 [birtles]
heycam: is there anything else to cover?
07:32:37 [dholbert]
dholbert has joined #svg
07:32:46 [birtles]
topic: SVGAnimatedBoolean
07:32:54 [birtles]
ed: it's only used in one place
07:33:05 [birtles]
krit: I doubt anyone uses it
07:33:16 [birtles]
heycam: was externalResourcesRequired the only other use?
07:33:26 [birtles]
ed: yes
07:33:31 [birtles]
... so can we remove it?
07:33:41 [birtles]
ChrisL: let's remove it
07:34:19 [ChrisL]
getAttr still works
07:35:09 [birtles]
RESOLUTION: We will remove SVGAnimatedBoolean and SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
07:35:50 [birtles]
ACTION: Dirk to remove SVGAnimatedBoolean and SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM
07:35:50 [trackbot]
Created ACTION-3541 - Remove svganimatedboolean and svgfeconvolvematrixelement.preservealpha from the svg2 dom [on Dirk Schulze - due 2013-11-21].
07:36:42 [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
07:36:45 [ed]
-- break time --
07:36:48 [TabAtkins]
07:42:53 [Zakim]
07:44:24 [ChrisL]
ChrisL has joined #svg
07:45:24 [ChrisL]
ChrisL has joined #svg
07:47:54 [Zakim]
disconnecting the lone participant, TabAtkins, in Team_(svg)06:02Z
07:47:55 [Zakim]
Team_(svg)06:02Z has ended
07:47:55 [Zakim]
Attendees were Huangshan, TabAtkins
07:48:03 [ChrisL]
ChrisL has joined #svg
07:55:25 [ChrisL]
ChrisL has joined #svg
08:06:21 [nsakai]
nsakai has joined #svg
08:06:48 [heycam]
Zakim, room for 4?
08:06:49 [Zakim]
ok, heycam; conference Team_(svg)08:06Z scheduled with code 26632 (CONF2) for 60 minutes until 0906Z
08:06:58 [ed]
ed has changed the topic to: Agenda: code for today is 26632
08:06:58 [heycam]
Zakim, call Huangshan
08:06:58 [Zakim]
ok, heycam; the call is being made
08:06:59 [Zakim]
Team_(svg)08:06Z has now started
08:07:01 [Zakim]
08:07:28 [kurosawa]
kurosawa has joined #svg
08:08:01 [heycam]
Scribe: Cameron
08:08:07 [heycam]
ScribeNick: heycam
08:08:20 [heycam]
Topic: SVG DOM continued
08:08:34 [jun]
jun has joined #svg
08:08:39 [heycam]
krit: any new SVG DOM should not have any reference to x/y/width/r/rx/ry/cx/cy
08:08:43 [heycam]
ChrisL: because?
08:08:56 [heycam]
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
08:09:09 [heycam]
heycam: I really want to do rect.x = 10
08:09:22 [heycam]
ed: I'd like to be able to assign a full rectangle in one go
08:09:28 [heycam]
ChrisL: rect.xywh = ...
08:09:39 [heycam]
krit: happy if SVG WG to prioritise the DOM for SVG 2
08:09:42 [heycam]
... like heycam's proposal
08:09:45 [heycam]
... but up to the WG
08:10:16 [Zakim]
08:10:28 [heycam]
s/to prioritise the DOM/to ask the CSS WG to prioritise the CSSOM/
08:10:37 [ChrisL]
ChrisL has joined #svg
08:11:03 [heycam]
Topic: SVGElement implementing global event handlers (onfoo)
08:11:06 [heycam]
ed: should these be on Element?
08:11:07 [ed]
08:11:08 [ChrisL]
ChrisL has joined #svg
08:11:26 [heycam]
ed: I think in Blink recently there was some code reshuffling
08:11:35 [heycam]
... it was discovered that SVG elements did not have the global event handlers like HTML does
08:11:46 [heycam]
... so you couldn't do rectElement.onload = ... and have that assign a function
08:11:49 [nikos_]
nikos_ has joined #svg
08:11:52 [heycam]
... so this is something that most SVG authors would like to have
08:12:01 [heycam]
... and the way it works in browsers, even if the SVG spec doesn't require it
08:12:07 [nikos_]
nikos_ has left #svg
08:12:11 [heycam]
... I think we should have this in the spec
08:12:32 [heycam]
... 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
08:12:39 [heycam]
krit: and that would be bad?
08:12:40 [heycam]
ed: yes
08:12:44 [heycam]
... but having it on SVGElement would be fine
08:13:06 [heycam]
heycam: are all HTML event listener attributes defined on HTMLElement?
08:13:10 [heycam]
ed: yes, apart from special things with <body>
08:13:17 [heycam]
... this is the way Gecko already does it
08:13:27 [maltman]
maltman has joined #svg
08:13:28 [heycam]
ed: it does mean we have some additional events supported automatically
08:13:35 [heycam]
... things which we don't require in SVG at the moment
08:14:28 [heycam]
heycam: what if one day SVGElement inherits from HTMLElement?
08:14:35 [heycam]
ed: we could still make both implement GlobalEventHandlers
08:15:08 [heycam]
heycam: if we do have SVGElement inherit from HTMLElement one day, we can just remove the duplicated ones on SVGElement
08:15:23 [heycam]
ed: any objections to this? :
08:15:29 [heycam]
SVGElement implements GlobalEventHandlers;
08:15:46 [heycam]
... I think Cameron has an action already relating to this
08:16:01 [heycam]
heycam: does SVG have onzoom or something that isn't in HTML?
08:16:08 [heycam]
ed: a few, yes... not sure if that already works on an HTMLElement
08:16:16 [ChrisL]
ChrisL has joined #svg
08:16:38 [heycam]
heycam: if they aren't on GlobalEventHandlers, should they be?
08:16:39 [heycam]
ed: yes
08:17:24 [TabAtkins]
Ah, there's someone's voice.
08:17:39 [heycam]
birtles: on HTMLElement, you have onfocus, but SVG has onfocusin/onfocusout
08:17:42 [heycam]
... is there some mismatch?
08:17:45 [heycam]
Takagi-san noticed this
08:17:54 [heycam]
TabAtkins: in HTML the focusout event is called blur
08:18:02 [heycam]
ed: which already works in all browsers
08:18:13 [heycam]
birtles: so would we end up with onfocusin/onfocusout/onfocus/onblur?
08:18:32 [heycam]
heycam: how much do we really need to keep onfocusin/onfocusout?
08:18:41 [heycam]
ed: we have a later topic on removing some SVG-specific events, discuss it then?
08:19:15 [heycam]
heycam: is Ian alright with having any SVG specific ones on GlobalEventHandlers?
08:19:16 [heycam]
ed: yes
08:19:35 [heycam]
s/yes/I haven't asked him that/
08:19:43 [dino_]
dino_ has joined #svg
08:20:15 [TabAtkins]
But, probably, yes.
08:20:18 [heycam]
ACTION: Erik to ask in the thread about whether SVG specific event handlers should go on GlobalEventHandlers, or separately on SVGElement
08:20:18 [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].
08:20:46 [heycam]
RESOLUTION: We will have "SVGElement implements GlobalEventHandlers" in SVG2's IDL.
08:21:12 [heycam]
ACTION: Erik to make SVGElement implement GlobalEventHandlers in SVG2.
08:21:12 [trackbot]
Created ACTION-3543 - Make svgelement implement globaleventhandlers in svg2. [on Erik Dahlström - due 2013-11-21].
08:21:37 [heycam]
Topic: Is it future-proof to return SVGElement on nearestViewportElement and farthestViewportElement?
08:22:08 [krit]
08:22:17 [heycam]
krit: I have a question about these two
08:22:29 [heycam]
... farthestViewportElement, isn't that always SVGSVGElement? can we just use that?
08:22:37 [heycam]
... it's true, today at least
08:22:39 [Rossen__]
Rossen__ has joined #svg
08:22:52 [heycam]
... is is true in the future? if we should ever allow SVGCircleElement to be an HTMLElement, what should it return?
08:23:08 [heycam]
... my question is should we rather replace SVGElement with just Element?
08:23:18 [heycam]
... or in this case, should it return null as in some other cases?
08:23:22 [ChrisL]
ChrisL has joined #svg
08:23:44 [heycam]
heycam: is this when you have say a <circle> with no ancestor <svg>?
08:23:49 [heycam]
krit: I guess we return null currently
08:24:24 [heycam]
heycam: I am ok with it being Element; the spec will still say what objects get returned
08:24:34 [heycam]
... we still would return null from <circle> when there is no ancestor <svg>
08:24:52 [heycam]
RESOLUTION: We will make nearestViewportElement / furthestViewportElement be Elements, not SVGElement
08:25:27 [heycam]
ed: I've rarely seen these used, could we not just remove them?
08:25:45 [heycam]
krit: add UseCounters and see if we can remove it?
08:25:50 [heycam]
ed: sure
08:26:04 [kurosawa_]
kurosawa_ has joined #svg
08:26:12 [heycam]
ACTION: Erik to add use counters to see if nearestViewportElement/furthestViewportElement are used
08:26:12 [trackbot]
Created ACTION-3544 - Add use counters to see if nearestviewportelement/furthestviewportelement are used [on Erik Dahlström - due 2013-11-21].
08:26:36 [heycam]
ACTION: Dirk to change nearestViewportElement/furthestViewportElement to be Element
08:26:36 [trackbot]
Created ACTION-3545 - Change nearestviewportelement/furthestviewportelement to be element [on Dirk Schulze - due 2013-11-21].
08:26:56 [heycam]
Topic: Animation Elements
08:27:10 [heycam]
birtles: you all know about Web Animations, the model for animations and an API on top of that model
08:27:23 [heycam]
... the intention is to define CSS Animations/Transitions and SVG's animation features in terms of that model
08:27:43 [birtles]
08:27:44 [heycam]
... 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
08:27:56 [heycam]
... skeleton document I've made
08:28:09 [heycam]
... the only parts I've filled in are some use cases at the top, and describing how it relates to SVG 1.1
08:28:15 [heycam]
... and also some other specifications
08:28:32 [heycam]
... 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
08:28:37 [heycam]
... it's an Unofficial Draft at the moment
08:28:48 [heycam]
... if you're OK with me working on this as an Editor's Draft, I'd like to decide on that
08:29:20 [heycam]
cyril: does it cover the timing model and the animation model, or just the animation model?
08:29:31 [heycam]
birtles: the 1st requirement of this is that it's backwards compatible with SVG 1.1's animation support
08:29:36 [heycam]
... so yes, it has to cover both of those things
08:29:45 [heycam]
shepazu: to what extent is it backwards compatibel?
08:29:50 [heycam]
... you've documented the bits that aren't going to be?
08:30:09 [heycam]
birtles: there are three exceptions, marked at the start of section 1.2, regarding backwards compatibility
08:30:18 [heycam]
... crazy frozen to-animation that nobody implemented won't be in here
08:30:39 [heycam]
... second point, I want to rewrite how cycles in syncbase dependencies are resolved, as these are implemented inconsistently
08:30:57 [heycam]
... might be some minor changes as to how that works, but I don't think people rely on the details
08:31:06 [heycam]
... third is animateColor -- waiting on use counters to see whether people use this
08:31:11 [heycam]
... and drop it if not
08:31:17 [heycam]
cyril: is the shim you have already supporting this?
08:31:18 [heycam]
birtles: no
08:31:22 [heycam]
... there's no shim for this markup
08:31:30 [heycam]
... there's fakeSmil, but that's the existing featureset
08:31:36 [heycam]
... you can see there's a list of new features
08:31:47 [heycam]
... some of them are exposing things which are already in the Web Animations model as markup
08:31:59 [heycam]
... there's also the <discard> element, which was in SVG 2 but I think it belongs in this specification instead
08:32:09 [heycam]
... timelineStart="" as well
08:32:23 [heycam]
... most of the new things are requirements we had for SVG 2, and I put them in this spec
08:32:46 [heycam]
shepazu: for every feature of element-based SVG animation, there will be an equivalent API/model aspect? and possibly CSS syntax?
08:32:48 [heycam]
birtles: roughly
08:32:53 [heycam]
... there are some things which only appear in one form
08:33:01 [heycam]
... e.g. timing groups, we don't know how yet to express that with CSS syntax
08:33:14 [heycam]
... likely that will be in the model, exposed here in element markup, but not exposed in CSS syntax, at least initially
08:33:22 [heycam]
... you don't get the full feature set across both syntaxes
08:33:34 [heycam]
shepazu: one of my frustrations with SVG animation syntax was the lack of reusability
08:33:47 [heycam]
... the same animation for multiple elements, I had to repeat the animation
08:33:53 [heycam]
... is this now possible with element syntax?
08:34:00 [heycam]
birtles: yes, you can use the select="" attribute to target multiple elmeents
08:34:14 [heycam]
... 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
08:34:33 [heycam]
... 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
08:34:38 [heycam]
cyril: so you can put an animation in a defs?
08:34:42 [heycam]
birtles: yes
08:34:45 [heycam]
shepazu: that's great
08:35:15 [heycam]
... if I'm animating something with the element syntax, the CSS syntax and the script, what happens?
08:35:24 [heycam]
... I assume you have some order of priorities?
08:35:30 [heycam]
birtles: that ordering is covered in the Web Animations model
08:35:45 [heycam]
... there are priorities based firstly on start time, but also on document order, and facilities for changing the priotity too
08:35:45 [ed]
minor nit, "timelineStart" was actually called "timelineBegin" in SVG Tiny 1.2, was the change of name intentional?
08:35:47 [heycam]
... but it is well defined
08:36:07 [heycam]
birtles: that's an advantage to having a unified animation model
08:36:14 [heycam]
ChrisL: but before it was undefined
08:36:37 [heycam]
birtles: re timelineStart, that wasn't intentional
08:36:55 [heycam]
krit: can I see a WD?
08:37:03 [heycam]
birtles: I want permission to do that yes
08:37:24 [ChrisL]
ChrisL has joined #svg
08:37:59 [heycam]
dino: I enthusiastically support this
08:38:07 [heycam]
... I'm glad Brian is doing this
08:38:12 [heycam]
... wanted something like this for 18 months
08:38:26 [heycam]
... Apple is going to propose something like this in a few weeks anyway, so this is great
08:38:43 [heycam]
ChrisL: MS said they wouldn't implement either of these, before there was a consistent model explaining how it works together
08:39:22 [heycam]
dino: I have comments on the content, but i'll wait until the document exists
08:39:22 [ChrisL]
ChrisL has joined #svg
08:39:46 [heycam]
... one is one of the first things people will do with this, is still write much their animation in CSS -- their keyframes, animation parameters
08:39:55 [heycam]
... and just use this as a way to do declarative timing separate from the animation
08:40:06 [heycam]
... in most cases you won't use <animate> elements, but toggling classes at particular times, or in response to particular events
08:40:35 [heycam]
... 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
08:40:54 [heycam]
... something not covered here, should we define a MIME type for a document like this? <link rel=stylesheet>
08:41:08 [heycam]
... you will want this inline in some cases, so in the document you could have a <timesheet> element in HTML
08:41:20 [heycam]
... adding elements to the <head> is difficult, but this could be in the <body> as well
08:41:23 [ChrisL]
ChrisL has joined #svg
08:41:35 [heycam]
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
08:41:53 [heycam]
shepazu: what namespace should they be in?
08:42:05 [heycam]
birtles: I'd like to see what happens with Cameron's proposal
08:42:13 [heycam]
dino: I want these to apply to HTML too, so the namespace doesn't matter
08:42:26 [ChrisL]
ChrisL has joined #svg
08:42:30 [heycam]
dino: it should follow HTML-like parsing rules as much as possible
08:42:42 [ChrisL]
ChrisL has joined #svg
08:43:00 [heycam]
birtles: perhaps for each element, we need to define the content model so that it can be used in either parsing mode?
08:43:26 [ChrisL]
ChrisL has joined #svg
08:43:54 [heycam]
heycam: it's difficult to add new empty elements in HTML, which don't have closing tags
08:44:08 [heycam]
shepazu: we should consider how we can expose animations in an accessible way
08:44:21 [heycam]
dino: I think this is the great thing about having the model, you can get at the animations
08:44:26 [ChrisL]
ChrisL has joined #svg
08:44:27 [heycam]
shepazu: I was thinking more of having a <title> for the animation
08:44:39 [ChrisL]
ChrisL has joined #svg
08:44:55 [heycam]
krit: there might already be a document describing accessibility of SMIL
08:45:09 [heycam]
cyril: I had another comment
08:45:17 [heycam]
... one of the next steps is to synchronise animations with media elements
08:45:19 [heycam]
birtles: yes
08:45:24 [heycam]
cyril: that's something I'm trying to work on
08:45:25 [ChrisL]
ChrisL has joined #svg
08:45:31 [heycam]
... the next topic is Streaming, and it's somehow related
08:45:34 [heycam]
birtles: I think that's a common question
08:45:49 [heycam]
... just to reiterate the status there, we have left synchronisation with media out of the first level of Web Animations
08:45:54 [heycam]
... just in the interest of progressing it more quickly
08:45:59 [heycam]
... it's definitely intended to be part of that model
08:46:08 [heycam]
... we already have an idea of how it should work, and a polyfill to demonstrate that
08:46:24 [heycam]
... the current thinking is that we'll write a separate document just for that feature, to say to integrate media with the model
08:46:26 [ChrisL]
ChrisL has joined #svg
08:46:26 [heycam]
... and the markup for it
08:46:34 [heycam]
... I think Cyril and Dean have shown some interest on working on that before
08:46:42 [heycam]
ChrisL: how do you expect that to work? event based?
08:46:51 [heycam]
birtles: you'd have another kind of timed item, which is a reference to the media element
08:47:06 [heycam]
... the <video> element needs to be in a particular part of the document for layout purposes
08:47:17 [heycam]
... you would set the timing parameters on the pointer object, and it would trigger the <video> as appropriate
08:47:31 [heycam]
cyril: two aspects, controlling the media element, and using the media element to control the timing of other things
08:47:44 [heycam]
birtles: wrt Web Animations, we only support the former, where the media is slaved to the timing groups
08:48:02 [heycam]
... 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
08:48:21 [heycam]
dino: are you saying you don't intend to have animations slaved to media unless they're inline in the media?
08:48:25 [ChrisL]
ChrisL has joined #svg
08:48:40 [heycam]
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
08:48:47 [heycam]
birtles: if you need it the other way around, I suggest the Streaming approach
08:48:51 [heycam]
dino: that use case is very important to us
08:48:59 [heycam]
... if the answer is put it in a group and seek the group, we can do that
08:49:08 [heycam]
cyril: where's the right forum to work on this spec?
08:49:11 [heycam]
08:49:29 [heycam]
ChrisL: I think FX is an obvious home
08:49:43 [heycam]
ChrisL: LC or before is a good time to get other people involved in reviewing it
08:50:20 [heycam]
RESOLUTION: We will take on Animation Elements as an official WD.
08:50:37 [heycam]
cyril: we talked about this in the past, the dur="" attribute, does the model cover that?
08:50:41 [heycam]
... on an SVG document?
08:50:46 [heycam]
birtles: why on a document, not on a group?
08:50:50 [heycam]
cyril: if you want to loop the document?
08:50:57 [heycam]
birtles: you'd put it on a group
08:51:06 [heycam]
s/a group/the root/
08:51:13 [heycam]
birtles: every outermost SVG element will act as a nested timeline
08:51:17 [heycam]
... it's like a simple group
08:51:20 [heycam]
... you can't repeat it, but you can seek it
08:51:21 [ChrisL]
ChrisL has joined #svg
08:51:24 [heycam]
cyril: can you put a dur on that?
08:51:25 [heycam]
birtles: no
08:51:33 [heycam]
... just put a group around everything you want to repeat
08:51:56 [heycam]
ChrisL: could you just construct groups as you want and point them to items to repeat them?
08:51:58 [heycam]
birtles: yes
08:52:09 [heycam]
... in the use cases, typically I found it was easier to separate out the timing from the content
08:52:17 [heycam]
... only simple cases can you put them side-by-side
08:54:59 [heycam]
Topic: SVG streaming update
08:55:04 [heycam]
cyril: we have three types of animations
08:55:14 [heycam]
... [cyril reads out the slides]
08:55:37 [cyril]
08:59:51 [kurosawa]
kurosawa has left #svg
09:01:35 [heycam]
cyril: I'd like to be able to use SVG in <video> and in <track>
09:01:49 [heycam]
... I implemented this with a shim
09:02:31 [ChrisL]
ChrisL has joined #svg
09:03:55 [heycam]
krit: regarding the same origin restrictions, what do you want to reference? svg documents?
09:04:07 [heycam]
cyril: I think the same restrictions should apply as images
09:08:23 [heycam]
RRSAgent, pointer
09:08:23 [RRSAgent]
09:10:47 [Jirka]
Jirka has joined #svg
09:24:42 [heycam]
cyril: so what is needed for standardisation is:
09:24:45 [heycam]
... first, the guideline document
09:24:51 [heycam]
... support for SVG in the video and track elements
09:25:06 [heycam]
... and support for annotations either in the SVG document, or outside it, to give information about the streaming units
09:25:30 [heycam]
... we have everything else that we need from SVG, CSS, etc.
09:25:41 [heycam]
... the generation tool is open source
09:25:49 [heycam]
... the players aren't yet, but only because they're badly implemented
09:25:52 [heycam]
... I'll put them on GitHub soon
09:26:08 [heycam]
krit: I don't have anything against working on that in the WG, but we might not have the expertise here
09:26:19 [heycam]
cyril: first step is to apply it to SVG, since SVG works well, has a timeline per document
09:26:21 [heycam]
... HTML doesn't
09:26:40 [heycam]
birtles: Web Animations defines a timeline per HTML document
09:26:51 [heycam]
cyril: maybe the Guidelines for Streaming SVG is good for this WG though
09:27:12 [heycam]
krit: I don't want to push the spec out of this WG, but it sounds like you need expertise from other people
09:27:20 [heycam]
cyril: tomorrow we have a session on WebVTT, I hope to present at that
09:27:35 [heycam]
... the HTML Media TF has a lot of activity atm
09:27:49 [heycam]
shepazu: I personally like to see this work go forward
09:27:59 [masatakayakura]
masatakayakura has joined #svg
09:27:59 [heycam]
... I think Dirk raises good points about who needs to be involved
09:29:12 [myakura_]
myakura_ has joined #svg
09:29:27 [heycam]
heycam: for identifying the chunks in the document, can you just use IDs?
09:29:44 [heycam]
cyril: when the client uses an ID, someone needs to convert that to a byte range
09:29:54 [heycam]
... in my case, I didn't do any server side processing to determine the byte range
09:30:14 [heycam]
... when it's packaged in WebVTT or MP4 you don't have this problem
09:30:56 [heycam]
mohamed: what about if we want to use svgz?
09:31:06 [heycam]
... then the byte offsets changed
09:31:09 [heycam]
cyril: I'm using Content-Encoding
09:31:13 [heycam]
... so the byte offsets remain the same
09:31:19 [heycam]
... IDs would require adding them to every frame
09:31:33 [heycam]
... when you concatenate two animations, you might have to rename IDs
09:31:46 [heycam]
mohamed: how will you deal with the background that is preloaded? will you do complex like intermediate frames?
09:32:11 [heycam]
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
09:32:51 [heycam]
... you can put the common elements in the "header" of the document
09:33:13 [heycam]
dino: from the Apple part of WebKit, looking cool isn't enough to contribute impl resources
09:33:16 [heycam]
... we need demand from users
09:33:26 [heycam]
... then we have to balance that against what can you achieve currently int he platform without having to implement it
09:33:53 [heycam]
... 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
09:34:08 [heycam]
... every time you add a new declarative format to the web, there is a lot of maintenance, security, etc. overhead
09:34:12 [heycam]
... there's a good balance there
09:34:17 [heycam]
... with this proposal I am more concerned
09:34:22 [heycam]
... there's JS in there
09:34:32 [heycam]
... that's not me making a value judgement on the technology in any way
09:34:55 [heycam]
... 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
09:34:57 [heycam]
cyril: I hear that
09:35:02 [heycam]
... not asking for any browser changes
09:35:09 [heycam]
... the purpose of this was to demonstrate that with a shim you can do it
09:35:26 [heycam]
... 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
09:35:28 [heycam]
dino: yeah
09:35:40 [heycam]
dsinger: what would you need the browsers to do natively? which bits are likely?
09:35:44 [heycam]
dino: a great example of this is MSE
09:36:01 [heycam]
... 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
09:36:06 [heycam]
... the ability to generate media streams from js
09:36:13 [heycam]
... that's the way you have to ask browser vendors to do things
09:36:18 [heycam]
cyril: I'm not asking browser vendors to do things
09:36:28 [heycam]
... I'm asking agreement to publish guidelines on svg streamable content
09:36:37 [heycam]
... if authors want to stream their svg content, it would be better if they did it this way
09:36:47 [glenn]
glenn has joined #svg
09:36:50 [heycam]
... any streaming tool would need some annotations
09:37:04 [heycam]
... but from the browser point of view, there's nothing to be changed, unless users demand it because perf is not there, or ...
09:37:08 [heycam]
dsinger: where would that be?
09:37:31 [heycam]
cyril: the sync you can achieve here is best effort
09:37:36 [heycam]
... if you need frame accurate ...
09:37:52 [heycam]
dino: I think it sounds like a great CG effort
09:38:05 [heycam]
cyril: if I'm alone in the CG...
09:38:11 [heycam]
dino: if you're alone in the CG, maybe it shouldn't take WG time
09:38:15 [heycam]
... I don't think you will be though
09:38:39 [heycam]
shepazu: I think the dedicated conversations you could have there wouldn't distract this group
09:38:45 [heycam]
cyril: I think it's also relevant to this group
09:38:51 [heycam]
... not completely, but somehow
09:38:56 [heycam]
... it's related to timed elements
09:39:07 [heycam]
... if you want all these things to be synced, looped, then you could do it with web aimations
09:39:09 [heycam]
09:39:23 [heycam]
shepazu: I'd like to see SVG WG people in that CG
09:40:01 [heycam]
... speaking as a W3C person, I want to see smooth transitions from CG to Rec track stuff
09:40:21 [heycam]
cyril: having a CG sounds ok
09:41:34 [heycam]
RRSAgent, make minutes
09:41:34 [RRSAgent]
I have made the request to generate heycam
09:41:56 [Zakim]
09:42:05 [ed]
trackbot, end telcon
09:42:05 [trackbot]
Zakim, list attendees
09:42:05 [Zakim]
As of this point the attendees have been Huangshan, TabAtkins
09:42:13 [trackbot]
RRSAgent, please draft minutes
09:42:13 [RRSAgent]
I have made the request to generate trackbot
09:42:14 [trackbot]
RRSAgent, bye
09:42:14 [RRSAgent]
I see 12 open action items saved in :
09:42:14 [RRSAgent]
ACTION: heycam to look at the performance class requirements and decide whether to remove points or move them into general requirements [1]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: heycam to review Resource Priorities specification [2]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Rich to reference ARIA 1.1 in SVG 2 [3]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Doug to clarify HTML content in <desc> and <title> elements [4]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Doug to work with Gerardo and Tab to come up with haptic, tactile and 3d media queries [5]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: plinss deliver document to adapt specs to Shepherd [6]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Peter Linss deliver document to adapt specs to Shepherd [7]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Dirk to remove SVGAnimatedBoolean and SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM [8]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Erik to ask in the thread about whether SVG specific event handlers should go on GlobalEventHandlers, or separately on SVGElement [9]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Erik to make SVGElement implement GlobalEventHandlers in SVG2. [10]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Erik to add use counters to see if nearestViewportElement/furthestViewportElement are used [11]
09:42:14 [RRSAgent]
recorded in
09:42:14 [RRSAgent]
ACTION: Dirk to change nearestViewportElement/furthestViewportElement to be Element [12]
09:42:14 [RRSAgent]
recorded in
09:42:24 [Zakim]
09:42:25 [Zakim]
Team_(svg)08:06Z has ended
09:42:25 [Zakim]
Attendees were Huangshan, TabAtkins
09:43:42 [RRSAgent]
RRSAgent has joined #svg
09:43:42 [RRSAgent]
logging to
09:43:52 [heycam]
Present+ Eriik, Brian, Satoru, Fujisawa, Nikos, Doug, Chris, Dirk, Cyril, Rik, Dean, Cameron
09:43:59 [heycam]
RRSAgent, make minutes
09:43:59 [RRSAgent]
I have made the request to generate heycam
09:44:23 [heycam]
Present+ Rich
09:44:36 [heycam]
RRSAgent, make minutes
09:44:36 [RRSAgent]
I have made the request to generate heycam
10:17:20 [myakura]
myakura has joined #svg
12:02:52 [Zakim]
Zakim has left #svg
12:13:53 [myakura]
myakura has joined #svg
13:12:55 [nsakai]
nsakai has joined #svg
13:15:45 [nsakai_]
nsakai_ has joined #svg
13:46:30 [glenn]
glenn has joined #svg
14:48:55 [dino]
dino has joined #svg