IRC log of svg on 2014-08-22

Timestamps are in UTC.

08:32:56 [RRSAgent]
RRSAgent has joined #svg
08:32:56 [RRSAgent]
logging to http://www.w3.org/2014/08/22-svg-irc
08:32:58 [birtles]
topic: Agenda review
08:32:59 [ed]
Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
08:33:02 [birtles]
scribenick: birtles
08:33:04 [ed]
chair: ed
08:33:05 [birtles]
scribe: birtles
08:33:20 [jwatt]
jwatt has joined #svg
08:33:26 [birtles]
ed: one suggestion was to split up the spec editing over all the days
08:33:34 [birtles]
... e.g. one hour per day for editing instead of a full day
08:33:47 [birtles]
shepazu: just a suggestion, e.g. 4-5pm
08:33:53 [birtles]
heycam: maybe not the end of the day
08:34:02 [birtles]
... just after/before lunch?
08:34:08 [birtles]
shepazu: after lunch is fine
08:34:47 [birtles]
(shuffling of PM agenda to put spec editing after lunch)
08:35:27 [Tav]
Tav has joined #svg
08:35:41 [birtles]
ed: any other topics missing from agenda?
08:35:50 [birtles]
krit: I'd like to give a progress report about CSS layout properties
08:35:54 [birtles]
... and discuss fill/stroke properties
08:36:01 [birtles]
... any day other than today is fine
08:36:53 [birtles]
Tav: I'd like to get some review on my talk for the conference if there's time at the end
08:37:00 [birtles]
(conference = graphical web conference)
08:37:04 [birtles]
ed: no one calling in?
08:37:07 [birtles]
heycam: I don't think so
08:37:52 [birtles]
topic: The topic index
08:37:54 [birtles]
https://www.w3.org/Graphics/SVG/WG/wiki/Topics
08:38:12 [birtles]
heycam: one problem we seem to have is that we easily lose track of previous discussion about topics
08:38:30 [birtles]
... we type up our minutes, send them to the ml, tracker picks up issues/actions but apart from that there's no indexing/tracking of topics
08:38:40 [birtles]
... often you want to find out the latest on an issue and you have to trawl through the ml
08:38:51 [birtles]
... so I wrote a couple of scripts to manage links to discussions on particular topics
08:39:00 [birtles]
... they harvest mails sent to the mailing list
08:39:13 [birtles]
... the above link, links to pages from telcon minutes etc.
08:39:14 [heycam]
https://www.w3.org/Graphics/SVG/WG/wiki/Topic_database
08:39:19 [birtles]
... if you follow the first link ^
08:39:25 [birtles]
... that's where it's getting its information from
08:39:41 [birtles]
... I've only added a couple of topic lists just to give you an idea of the kind of format
08:39:51 [birtles]
... new ones will automatically get added as we send out more minutes to the list
08:40:02 [birtles]
... it extracts out the names of topics and resolutions
08:40:02 [jet]
jet has joined #svg
08:40:08 [birtles]
... since tracker doesn't do that for us
08:40:23 [birtles]
krit: are resolutions also tracked?
08:40:34 [birtles]
heycam: they're automatically added but they're not automatically copied to the topic page
08:41:00 [birtles]
shepazu: is this a tool that you can make available to other WGs?
08:41:15 [birtles]
heycam: it's on my github but there may be some SVG-specific code
08:41:24 [birtles]
krit: so we have to use the same topic every time?
08:41:36 [birtles]
heycam: that is a problem but you can go back and edit the topic names
08:42:07 [birtles]
... the new minutes will get added automatically and then myself or someone else will adjust the titles so they coalesce
08:42:38 [birtles]
nikos: I've got a similar record on our wiki if you want to use that data for historical records
08:42:48 [birtles]
heycam: I could also run the script on old mails
08:42:58 [birtles]
... hopefully that's useful
08:43:04 [birtles]
... let me know if you have problems/suggestions
08:43:25 [birtles]
shepazu: w3c is looking now at exposing group/spec data through an API
08:43:38 [birtles]
... so this might be another tool
08:43:58 [birtles]
... we're finally abandoning the RDF structures we use internally
08:44:16 [birtles]
... it's quite likely that this information would be useful.. to be able to drill down into topics that a WG discussed
08:44:27 [birtles]
... for example we manually maintain a list of our specifications
08:44:31 [cyril]
cyril has joined #svg
08:44:37 [birtles]
... there's no way for us right now to get all our specifications and their statuses
08:44:40 [birtles]
krit: what
08:44:51 [birtles]
... what's the problem with that?
08:45:15 [birtles]
shepazu: it's not nicely maintained, e.g. what WG is producing what specs etc.
08:45:22 [birtles]
... which revision each spec is etc.
08:45:40 [birtles]
... if there's any data you feel you want from w3c then let us know
08:45:45 [birtles]
krit: resolutions are really important
08:45:55 [birtles]
shepazu: I think this is good, and if it's in a wiki that good too
08:46:00 [birtles]
... can we edit to add notes?
08:46:12 [birtles]
heycam: it expects a precise format the moment but I can adjust that
08:46:26 [birtles]
shepazu: we use various bots
08:46:37 [cyril]
RRSAgent, pointer
08:46:37 [RRSAgent]
See http://www.w3.org/2014/08/22-svg-irc#T08-46-37
08:46:37 [birtles]
... I've never been very happy with the way we handle minutes
08:47:00 [birtles]
... it might be worth fixing those bots
08:47:10 [birtles]
heycam: that's something I've often wanted to do, have links to etherpads etc.
08:47:23 [birtles]
krit: can we add it to svgwg.org as well?
08:47:26 [cyril]
RRSAgent, draft minutes
08:47:26 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/08/22-svg-minutes.html cyril
08:47:27 [birtles]
heycam: yes, of course
08:47:53 [birtles]
nikos: it might be good to highlight which telcons have resolutions
08:48:22 [birtles]
heycam: I have this infrastructure to munch emails from the list now
08:48:37 [birtles]
topic: Putting SVG 2 spec on GitHub
08:49:03 [birtles]
heycam: so Dirk asked about this recently...
08:49:08 [birtles]
krit: other WGs are experimenting with this
08:49:14 [birtles]
... HTML is one of them
08:49:20 [birtles]
... it's helping others to contribute to the specification
08:49:34 [heycam]
RRSAgent, make minutes public
08:49:34 [RRSAgent]
I'm logging. I don't understand 'make minutes public', heycam. Try /msg RRSAgent help
08:49:38 [heycam]
RRSAgent, make logs public
08:49:40 [heycam]
RRSAgent, make minutes
08:49:40 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/08/22-svg-minutes.html heycam
08:51:03 [birtles]
krit: some developers would be interested in submitting PRs for specs
08:51:13 [birtles]
... I think we could accept PRs under the W3C license
08:51:34 [birtles]
heycam: I put the WebIDL spec on github and have accepted a few PRs
08:51:50 [birtles]
... but it was a bit unclear if PRs from non-w3c members was ok
08:51:59 [birtles]
krit: you could put a license on the repo
08:52:47 [birtles]
(discussion about how hard it is/isn't to learn GitHub)
08:53:29 [birtles]
heycam: one thing is that the mercurial repo does automatic building of the spec when you push changes
08:53:36 [birtles]
... would that work with github?
08:53:47 [birtles]
ed: you can do that with git
08:53:54 [birtles]
ChrisL: with git or github?
08:54:11 [birtles]
ed: because we have our own server, we can use that
08:54:31 [birtles]
(discussion about how we could set up automatic building with github)
08:54:46 [birtles]
krit: the CSS testsuite runs some scripts on every push
08:55:02 [ed]
http://stackoverflow.com/questions/19041220/how-to-run-post-receive-hook-on-github
08:55:05 [birtles]
ed: using webhooks we can trigger actions from github
08:55:27 [birtles]
heycam: if someone's willing to do the work for that I don't see a problem
08:55:36 [birtles]
krit: I don't have the experience yet to do that
08:55:59 [birtles]
ChrisL: who was pushing for that?
08:56:10 [birtles]
heycam: I think Anne was looking to make some changes
08:56:26 [birtles]
ChrisL: is he ok to pushes changes under W3C license?
08:56:53 [birtles]
shepazu: it's not just about him, a lot of people are doing this and seeing good results
08:58:20 [birtles]
ed: would we also push to the w3c mercurial repo?
08:58:27 [birtles]
shepazu: I'd prefer to just push to the github
08:58:32 [birtles]
(general agreement)
08:58:40 [birtles]
jwatt: so we'd dump the w3c repo?
08:58:47 [birtles]
shepazu: MikeSmith has some experience with doing this
08:59:29 [birtles]
ChrisL: are we moving all the specs for this WG?
08:59:34 [birtles]
shepazu: yes, I think so
09:00:12 [birtles]
ed: on a related note, I noticed that web-platform-tests is on github and I suggest we drop the svg2-test repository and switch to web-platform-tests
09:00:57 [birtles]
RESOLUTION: We will move SVG WG's specs from the W3C mercurial server to Github
09:01:21 [birtles]
Tav: are we going to use github exclusively or if we still need our own server
09:01:39 [birtles]
ed: we'll still need our own server to run the build scripts since we can't run arbitrary scripts on github
09:01:56 [birtles]
jwatt: but as for the WG members, they'd just be using github
09:02:06 [birtles]
Tav: and I'd still be able to build it locally
09:02:09 [birtles]
ed: yes, sure
09:02:13 [birtles]
Tav: so all the tools are included too
09:02:41 [birtles]
ACTION: Doug to talk to Mike Smith about migrating the SVG WG repository to Github
09:02:41 [trackbot]
Created ACTION-3638 - Talk to mike smith about migrating the svg wg repository to github [on Doug Schepers - due 2014-08-29].
09:03:09 [birtles]
ed: who's going to look at webhooks from github to get a ping when someone pushes
09:03:14 [birtles]
... so we can tell svgwg.org to rebuild the spec
09:04:53 [birtles]
ACTION: Dirk to actually perform the migration of SVG specs to Github in cooperation with Mike Smith
09:04:53 [trackbot]
Created ACTION-3639 - Actually perform the migration of svg specs to github in cooperation with mike smith [on Dirk Schulze - due 2014-08-29].
09:05:28 [birtles]
jwatt: we need to decide where it lives in github
09:05:45 [birtles]
shepazu: Mike says he's happy to help and it all looks do-able
09:06:14 [ed]
https://github.com/w3c/csswg-drafts
09:07:20 [birtles]
ed: regarding tests, there's web-platform-tests
09:07:24 [ed]
https://github.com/w3c/web-platform-tests
09:07:52 [birtles]
ChrisL: regarding that, we previously decided we want to work with CSS WG's test infrastructure
09:08:09 [birtles]
... and their tools do lots of linking between specs
09:08:18 [birtles]
... but none of that's going to be on web-platform-tests
09:08:34 [ed]
there's also https://github.com/w3c/csswg-test
09:08:36 [birtles]
... so we should choose wisely
09:08:56 [birtles]
shepazu: the way that CSS has done things is idiosyncratic to the rest of the consortium
09:09:10 [birtles]
... I think we're probably better off aligning with the rest of the consortium
09:09:21 [birtles]
... I think there will be other tools built around web-platform-tests
09:09:46 [birtles]
heycam: the advantage of doing things in the CSS repository is that Peter Linss is very active, and works very hard to get things going right
09:10:03 [birtles]
ChrisL: he is very active and we do do a lot of work together with the CSSWG
09:10:27 [birtles]
heycam: it seems like the CSS tests are primarily reftests, where do their scripted tests run?
09:10:34 [birtles]
ChrisL, krit: same repo
09:10:51 [birtles]
krit: the JS tests can still have metadata
09:11:30 [birtles]
birtles: the web-platform-tests can have a fair bit of metadata
09:11:58 [birtles]
shepazu: from the perspective of web-platform org is that we're looking for something like icanuse.com
09:12:10 [birtles]
... MDN's equivalent is just a table that someone inputs
09:12:41 [birtles]
... but for webplatform.org we have scripts that do that automatically now
09:13:09 [birtles]
... caniuse is good but it's based on very few tests and we want to be more rigorous than that
09:13:21 [birtles]
... and have a clickable field where you can drill down to individual tests
09:13:30 [birtles]
... so you have a confidence score about how well a feature is supported
09:14:06 [birtles]
ed: do we still want the svg2-tests repository or use one of the others?
09:14:22 [birtles]
... do we want a separate one?
09:14:29 [birtles]
krit: shepherd doesn't care
09:15:10 [birtles]
ChrisL: what you (shepazu) described about drilling down to individual tests sounds great
09:15:13 [birtles]
... but how far away is that
09:15:21 [birtles]
shepazu: what we have now is a JSON structure that generates the tables
09:15:30 [birtles]
... so we can plug anything into those tables we want
09:15:41 [birtles]
... going from there to drilling down is probably a couple of weeks work
09:15:56 [birtles]
... it hasn't been a priority until now but it will be in the coming few months
09:16:18 [birtles]
ChrisL: that's good for developers, but what about the WG who are looking for "how far are we from CR?" etc
09:16:27 [birtles]
Tav: how can I put Inkscape's test results in?
09:16:43 [birtles]
shepazu: I guess you would have to do it manually
09:16:58 [birtles]
heycam: are you referring to the boxes in the CSS spec?
09:17:17 [birtles]
krit: you'd have to ask Peter
09:17:32 [birtles]
ChrisL: I think you'd have to fill in this data and pass a pointer... it's been asked before
09:18:12 [birtles]
... I think the answer is to mail Peter and ask
09:18:32 [birtles]
shepazu: it sounds to me like people are leaning towards shepherd
09:18:57 [birtles]
... for webplatform.org we'd rather the data be all in one place and rather the CSS WG joined in what everyone else did
09:19:29 [birtles]
krit: we can join these test repositories later
09:20:05 [birtles]
... i.e. go to CSS repo first and then merge to web platform later
09:20:24 [birtles]
birtles: can we go the other way?
09:20:27 [birtles]
ChrisL: no
09:20:50 [birtles]
Rozvan: what about tests which are only supported behind a flag?
09:21:46 [birtles]
... we had this problem for crowdsourcing tests for CSS shapes
09:22:06 [birtles]
... users wouldn't know that they had to enable these flags so they'd report incorrect results
09:22:52 [birtles]
shepazu: for webplatform.org we just want to get the results of tests (not create them or run them)
09:24:02 [birtles]
birtles: I know we're doing some work to better integrate web-platform-tests into the Mozilla build system
09:24:36 [birtles]
krit: we have that for the CSS repo as well
09:24:48 [birtles]
heycam: we have some scripts for the CSS repo too
09:25:20 [birtles]
shepazu: I'd like to avoid going to the mercurial of tests systems
09:25:44 [birtles]
ed: what about user-submitted tests?
09:25:56 [birtles]
... do we want to decide a structure for that
09:26:08 [birtles]
birtles: so TTWF normally submits tests to web-platform-tests?
09:26:12 [birtles]
ed: yes
09:26:23 [birtles]
ChrisL: but there are some tests in shepherd from TTWF
09:27:15 [birtles]
heycam: at some point we need to convert our SVG 1.1 test suite to reftests etc. (i.e. automated tests)
09:27:34 [birtles]
shepazu: that might be a good topic for TTWF
09:28:15 [birtles]
(discussion about how to write reftests for things like paths)
09:29:04 [birtles]
ed: another thing to consider about dropping svg2-tests is that it's not being pulled into blink's repo
09:29:34 [birtles]
shepazu: at some point I'd like to add to the agenda discussion about using annotations in the SVG spec
09:30:09 [birtles]
... we should decide between the CSS test repo or web-platform-tests
09:31:15 [birtles]
heycam: I'd like to know if web-platform-tests supports reftests
09:31:50 [birtles]
https://github.com/w3c/web-platform-tests/
09:33:00 [birtles]
... it would be good to use the structure from CSS for reftests and the boxes with test results
09:33:09 [birtles]
shepazu: that's why I'd like to talk about annotations
09:33:24 [birtles]
... since we're planning on building that functionality
09:33:51 [birtles]
... if that kind of feature is useful, it will get added to web-platform-tests
09:34:54 [birtles]
ed: it doesn't seem like we're arriving at consensus over which repo to use
09:35:06 [birtles]
ChrisL: I feel like I don't have enough information to decide
09:35:14 [birtles]
Tav: I'd like to see a demonstration of both
09:36:38 [birtles]
RESOLUTION: We will migrate tests from svg2-tests to either the CSS test repository or web-platform-tests (or both)
09:38:08 [birtles]
(discussion about who to demonstrate the test repositories)
09:39:08 [birtles]
(break 15mins)
09:39:55 [ChrisL]
ChrisL has joined #svg
09:40:55 [jwatt_]
jwatt_ has joined #svg
09:42:38 [oslego]
oslego has joined #svg
10:05:44 [heycam]
ScribeNick: heycam
10:08:01 [nikos]
nikos has joined #svg
10:09:50 [heycam]
Topic: marker, symbol: refX and refY shorthand anchor points: 'top left' 'center center', etc.
10:10:09 [heycam]
Tav: if you remember we decided to extend refX and refY to apply to symbols, like markers
10:10:14 [heycam]
... Andreas Neumann had requested that
10:10:24 [heycam]
... he's also now requested for us to consider adding shorthands: top, left, center
10:10:31 [heycam]
... because this is typically what people doing mapping stuff use
10:10:44 [heycam]
krit: center would be the bbox center?
10:10:46 [heycam]
Tav: yes
10:10:52 [heycam]
krit: do we support % on these attributes?
10:10:54 [heycam]
Tav: don't know
10:11:28 [heycam]
ed: they are length in SVG 1.1
10:11:31 [heycam]
krit: which means it includes percentages
10:11:35 [heycam]
... what's it resolved against?
10:11:53 [heycam]
ChrisL: so we could make left,center,right mean 0%,50%,100%
10:12:07 [heycam]
... that's the point of having a symbol rather than g, it has its own viewport
10:12:14 [heycam]
krit: but no viewBox?
10:12:18 [heycam]
ChrisL: yes
10:12:36 [heycam]
Tav: right now it's the viewport that's being used
10:12:49 [heycam]
krit: of the marker or the path?
10:13:04 [heycam]
... for refX and refY, is this % resolved against the viewport of the marker?
10:13:06 [heycam]
Tav: yes
10:13:16 [heycam]
... I wasn't aware that % was already supported there
10:13:32 [ChrisL]
actually it does have a viewBox attribute http://www.w3.org/TR/SVG/struct.html#SymbolElement
10:13:38 [heycam]
heycam: if the %s mean what Andreas is requesting, then I would say just use the %s
10:14:20 [heycam]
shepazu: this is what I wanted to roll these all up in one
10:14:24 [heycam]
Tav: I was looking at that...
10:14:44 [heycam]
Tav: these different elements differ enough in their uses that I think it would be hard?
10:15:04 [heycam]
ChrisL: I think there is an advantage to having separate names for these things
10:15:11 [heycam]
Tav: e.g. markers change depending on stroke-width, or not
10:15:22 [heycam]
shepazu: that's sort of like a use? you can change some aspect of it, or not
10:15:30 [heycam]
Tav: there's an attribute that controls whether it scales according to stroke width
10:15:33 [ChrisL]
advantage is you can optimise based on typical use eg caching patterns
10:15:56 [heycam]
shepazu: if they haven't different behaviours, that's one thing, but if they have additional behaviours, I think we should try to do this
10:16:06 [heycam]
... consistency of the model, understandability
10:16:20 [heycam]
... bugs, etc. if you only have to do one different thing for this other use...
10:16:26 [heycam]
Tav: I can try to find the work I did looking at this
10:16:36 [heycam]
shepazu: maybe it doesn't make much sense for Inkscape but it does for the spec
10:16:48 [heycam]
ChrisL: if we had a new DOM we could make all of these inherit from the one interface
10:17:03 [heycam]
ed: your question is whether to allow the keywords?
10:17:10 [heycam]
Tav: I didn't know percentages were already allowed
10:17:38 [heycam]
ChrisL: so if we did support 'top left' it would be a shorthand for '0% 0%' etc.?
10:17:39 [heycam]
Tav: it would be
10:17:56 [heycam]
... I'll ask what Andreas thinks about using the percentages
10:18:14 [heycam]
ChrisL: one advantage to the shorthands is that CSS does that for thing like boxes, tiling of background images it has this center top syntax
10:18:17 [heycam]
... but it's just syntactic sugar
10:18:25 [heycam]
... the one thing to remember is to switch off the clipping
10:18:33 [heycam]
... otherwise you only get the first quadrant of your symbol
10:18:48 [heycam]
... don't understand why overflow isn't visible by default
10:19:43 [heycam]
krit: so this is overflow: visible for symbol?
10:19:44 [heycam]
shepazu: by default
10:20:02 [heycam]
ChrisL: the only downside I can think of is if they have hidden things in the other quadrants
10:21:13 [heycam]
... I suggest we do that and have authoring guideliness to define symbol around (0,0) to make your life easier
10:21:27 [heycam]
Tav: Andreas pointed out that in mapping you often have different anchor points
10:21:34 [heycam]
... a tower would be aligned to the center bottom, for example
10:22:24 [heycam]
RESOLUTION: symbol will be overflow:visible by default by the UA style sheet in SVG 2
10:22:55 [heycam]
ACTION: Chris to add |symbol { overflow: visible; }| to the UA style sheet and add authoring suggestion to say to design symbols around (0,0)
10:22:56 [trackbot]
Created ACTION-3640 - Add |symbol { overflow: visible; }| to the ua style sheet and add authoring suggestion to say to design symbols around (0,0) [on Chris Lilley - due 2014-08-29].
10:23:16 [heycam]
ed: what about the keywords?
10:23:23 [heycam]
... transform-origin has these
10:23:26 [heycam]
Tav: that's where I got the names frmo
10:23:33 [heycam]
... it might be useful if that's how it's done in CSS already
10:23:41 [heycam]
ed: I think it's fine to add that
10:24:21 [heycam]
heycam: I would prefer not adding the keywords
10:24:56 [heycam]
ed: do you see refX/refY becoming presentation attribtues in the future?
10:25:00 [heycam]
krit: to x and y maybe
10:26:12 [heycam]
Tav: I don't think they need to be presentation attributes
10:26:27 [heycam]
krit: I think for authors it's more important to have the basic shape geometry attribtues as properties
10:26:52 [heycam]
nikos: I don't see any need to add the keywords; I think the meaning of the percentages are clear
10:26:56 [heycam]
shepazu: no strong feeling
10:27:02 [heycam]
krit: I don't think we should add the keywords
10:27:07 [heycam]
Tav: ok I'll get back to Andreas with that
10:27:55 [heycam]
ACTION: Tav to get back to Andreas about refX/refY top/left/etc.
10:27:55 [trackbot]
Created ACTION-3641 - Get back to andreas about refx/refy top/left/etc. [on Tavmjong Bah - due 2014-08-29].
10:28:40 [jwatt_]
jwatt_ has joined #svg
10:29:36 [heycam]
krit: for overflow:visible I thought we were talking about marker, not symbol
10:29:39 [heycam]
ChrisL: I think we should do it for both
10:30:47 [heycam]
ACTION-3640: Actually this should remove the existing UA style rule to set |overflow: hidden|
10:30:47 [trackbot]
Notes added to ACTION-3640 Add |symbol { overflow: visible; }| to the ua style sheet and add authoring suggestion to say to design symbols around (0,0).
10:31:42 [heycam]
krit: did IE make overflow:visible by default on root <svg> of inline SVG?
10:31:58 [heycam]
Rossen_: it made the most sense
10:32:03 [heycam]
ed: it's what people would expect
10:32:35 [heycam]
Rossen_: I'd expect it to be visible for foreignObject too
10:32:43 [heycam]
ed: per spec that would be hidden since it's a viewport-establishing element
10:35:17 [ed]
https://svgwg.org/svg2-draft/masking.html#OverflowProperty
10:35:22 [heycam]
ed: so I would prefer to drop the last bullet point in that section
10:35:41 [heycam]
krit: I would worry about the inner SVG becoming overflow:visible
10:35:51 [heycam]
krit: otoh I'm surprised that inline root SVG is not breaking anything for IE
10:36:02 [heycam]
ed: I think people are told to workaround it by putting overflow:hidden
10:36:21 [heycam]
ed: the less special handling for overflow in SVG the better
10:36:35 [heycam]
krit: that's a benefit, but I'm just noting that people are using inline SVG and I'm not sure if that new behaviour would be better
10:36:45 [heycam]
... maybe we can make this change and see implementation feedback?
10:37:07 [heycam]
ed: pattern too?
10:37:11 [heycam]
heycam: no I think that would break things
10:37:36 [ed]
The initial value for ‘overflow’ as defined in [CSS21-overflow] is 'visible', and this applies also to the rootmost ‘svg’ element; however, for child elements of an SVG document, SVG's user agent style sheet overrides this initial value and sets the ‘overflow’ property on elements that establish new viewports (e.g., ‘svg’ elements), ‘pattern’ elements and ‘marker’ elements to the value hidden.
10:37:53 [ed]
(this is the last bulletpoint in the link I pasted above)
10:38:08 [heycam]
ed: so pattern would remain
10:38:29 [heycam]
... but viewport establishing elements would all go to overflow:visible
10:38:38 [heycam]
ed: overflow doesn't apply to mask
10:38:52 [heycam]
krit: mask default has this 10% margin region
10:38:59 [heycam]
... this has changed in the masking specification to be auto
10:39:08 [heycam]
... so it's effectively overflow:visible
10:41:46 [heycam]
RESOLUTION: All viewport-establishing elements will be overflow:visible by default, except for root <svg> of SVG whole documents.
10:42:01 [heycam]
ACTION-3640: Plus more, check the minutes here.
10:42:01 [trackbot]
Notes added to ACTION-3640 Add |symbol { overflow: visible; }| to the ua style sheet and add authoring suggestion to say to design symbols around (0,0).
10:42:52 [heycam]
Topic: variable stroke width
10:43:27 [heycam]
birtles: last time I put forward the proposals for syntax
10:43:27 [birtles]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke
10:43:44 [heycam]
... the next action coming out was to make a polyfill
10:43:55 [heycam]
... I did the part that does the parsing, but I didn't do the part which actually draws the stroke
10:44:04 [heycam]
... I don't have the time to do that
10:44:13 [heycam]
... so if anyone wants to see the feature progress, it needs your help to do that
10:44:24 [heycam]
shepazu: I've done a lot of that stuff in the past
10:44:33 [heycam]
ChrisL: did you try and it was complicated? or that's just where you stopped
10:44:49 [birtles]
https://rawgit.com/birtles/curvy/master/index.html
10:45:26 [heycam]
birtles: I haven't updated the syntax for what we discussed in Germany
10:45:36 [heycam]
... if you look at the wiki page, the property is now called stroke-profile
10:45:41 [heycam]
... but in the prototype here it's called stroke-widths
10:45:48 [heycam]
... so it's not up to date with the proposal
10:46:17 [heycam]
shepazu: I see it supports inner and outer
10:46:21 [heycam]
birtles: asymmetric stroke yes
10:46:43 [heycam]
shepazu: how does it interpolate between the points?
10:46:51 [heycam]
birtles: we were going to try different ways with the prototype
10:47:03 [heycam]
ChrisL: would be a good option for Catmull-Rom
10:47:42 [heycam]
... the wikipedia page mentions a few different forms of Catmull-Rom, some of which are more well behaved than others
10:47:52 [heycam]
... i.e. doesn't produce cusps/loops
10:47:56 [heycam]
Tav: inkscape has something similar implemented
10:49:58 [heycam]
ACTION: Tav to ask Inkscape vsw implementor to add Catmull-Rom interpolation to see what it's like
10:49:58 [trackbot]
Created ACTION-3642 - Ask inkscape vsw implementor to add catmull-rom interpolation to see what it's like [on Tavmjong Bah - due 2014-08-29].
10:53:51 [heycam]
cabanier: there's an Adobe guy who probably would be eager to help with the prototype
10:54:33 [heycam]
ACTION: Rik to ask the Adobe guy about working on the vsw prototype
10:54:34 [trackbot]
Created ACTION-3643 - Ask the adobe guy about working on the vsw prototype [on Rik Cabanier - due 2014-08-29].
10:54:47 [heycam]
Tav: we have cubic bezier, linear, and spiro as interpolations in Inkscape
10:54:53 [heycam]
... shouldn't be that hard to add Catmull-Rom
10:55:41 [heycam]
Tav: I think this isn't the harder part of the problem
10:55:49 [heycam]
... joins are harder
10:55:52 [heycam]
krit: dashes too
10:58:38 [heycam]
[discussion about various corner cases]
11:00:27 [ChrisL]
http://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline Centripetal Catmull–Rom spline
11:00:48 [jet]
jet has joined #svg
12:13:17 [jet]
jet has joined #svg
12:23:22 [jwatt]
jwatt has joined #svg
12:39:28 [jwatt_]
jwatt_ has joined #svg
12:49:09 [nikos]
nikos has joined #svg
12:58:59 [nikos_]
nikos_ has joined #svg
13:02:45 [ed]
[work on actions until 3.15pm]
13:07:16 [nikos]
trackbot, close ACTION-3599
13:07:16 [trackbot]
Closed ACTION-3599.
13:15:35 [jwatt]
jwatt has joined #svg
13:18:46 [nikos]
trackbot, close ACTION-3168
13:18:46 [trackbot]
Closed ACTION-3168.
13:18:54 [nikos]
trackbot, close ACTION-3170
13:18:54 [trackbot]
Closed ACTION-3170.
13:46:53 [jwatt_]
jwatt_ has joined #svg
13:48:16 [heycam]
trackbot, close ACTION-3634
13:48:16 [trackbot]
Closed ACTION-3634.
14:05:38 [ChrisL]
action-3640?
14:05:38 [trackbot]
action-3640 -- Chris Lilley to Add |symbol { overflow: visible; }| to the ua style sheet and add authoring suggestion to say to design symbols around (0,0) -- due 2014-08-29 -- OPEN
14:05:38 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/actions/3640
14:06:53 [glenn]
glenn has joined #svg
14:08:02 [ChrisL]
<svg><star><star><star><star><star><description>OMG its full of stars</description></svg>
14:10:55 [ChrisL]
s/star>/star\//g
14:26:33 [nikos_]
nikos_ has joined #svg
14:29:35 [richardschwerdtfeger]
richardschwerdtfeger has joined #svg
14:48:48 [nikos]
Scribe: Nikos
14:48:55 [nikos]
scribenick: nikos
14:49:11 [nikos]
Topic: New SVG DOM
14:51:37 [nikos]
heycam: last time we discussed the DOM stuff, the discussion ended on the point where a couple of people weren't sure about going ahead in this direction
14:51:48 [nikos]
... so we decided to write a polyfill for experimentation
14:52:15 [nikos]
... the polyfill only works in recent FF with a certain pref on
14:52:27 [nikos]
... relies on web components, shadow trees, mutation events, and some other features
14:52:55 [nikos]
... I'll take you through some of the examples that are in the repo
14:53:12 [nikos]
... graphics element causes the new DOM interfaces to be put on elements
14:53:28 [nikos]
... I realised that to avoid breaking the pages that use the old one, we need some syntactic way to opt into the new stuff
14:53:36 [nikos]
... the best way seemed to be to have a different element name for the root
14:53:43 [nikos]
... so that existing content gets the old interfaces
14:53:51 [nikos]
... and new elements can go in html namespace
14:54:10 [nikos]
krit: does polyfill create elements in the html namespace?
14:54:27 [nikos]
heycam: the root graphics element gets a shadow tree. The whole tree gets cloned in the shadow tree with updated names and cases and so on
14:54:32 [nikos]
... and it watches for updates
14:54:55 [nikos]
... there are limitations - events, etc
14:55:09 [nikos]
ed: if you were to have nested graphics elements this wouldn't work right?
14:55:20 [nikos]
heycam: no. inner things are called viewport and outer are graphics
14:55:29 [nikos]
ed: foreignObject?
14:55:33 [nikos]
heycam: I didn't do it
14:56:04 [nikos]
... I rely on html parsing and these elements go in html namespace. there are some tricky bits that require parser changes
14:56:18 [nikos]
... if we had foreignObject it would probably be a good chance to use a different name
14:56:43 [nikos]
birtles: we are going to look at using svg elements in html without foreignObject on Monday
14:57:12 [nikos]
shepazu: rather than be a new element, couldn't the flag be svg element without the ns?
14:57:21 [nikos]
heycam: you don't put the ns already in inline svg in html
14:57:32 [nikos]
shepazu: the key is that things are going in the html ns
14:57:34 [nikos]
heycam: yep
14:57:59 [nikos]
heycam shows some demos
14:58:24 [nikos]
heycam: there are some options for lengths. There are some modes you can set to try different options
14:59:03 [nikos]
... I'm not sure which would be best
14:59:33 [nikos]
... in terms of the namespace. Because we're in html ns. If I want to create a new rectangle I can just use createElement("rect")
15:00:01 [nikos]
... certain things get a lot shorter - interaction with attributes, creation of element
15:00:43 [nikos]
shepazu: why can't we expose these methods on existing svg elements?
15:00:52 [nikos]
heycam: the names are already taken
15:01:14 [nikos]
... currently if you're interacting with a rect you use rect.x.baseVal.value = 100
15:01:21 [nikos]
... if you wanted rect.x = 100, that would work
15:01:28 [nikos]
... but rect.x == 100 wouldn't work
15:01:33 [nikos]
... it doesn't know you want x to be a number
15:02:12 [nikos]
... I have an example showing the different ways of exposing svg lengths - moving-rects-0.html
15:02:30 [nikos]
... this is using the existing dom
15:02:58 [nikos]
... creates 10 rectangles, initially diagonally down the page at 0em, 1em, etc
15:03:14 [nikos]
... then does an animation where a random amount is added each update
15:03:26 [nikos]
... most concise way to set is via setAttribute
15:03:50 [nikos]
... jittering rectangles around means you need .x.baseVal.value to get to a number
15:04:58 [nikos]
... same example using strings. Creating the object and setting initial values is more concise and more familiar for html authors
15:05:30 [nikos]
... doing the numeric stuff is a problem because you need to convert to numeric values
15:05:40 [nikos]
... this is a limitation of reflecting lengths only as strings
15:05:49 [nikos]
ChrisL: could it be reflected multiple ways?
15:06:12 [nikos]
birtles: you can't overload the getter but you can for the setter
15:06:44 [nikos]
heycam: reflecting as strings is one option, but there are a few other options
15:07:04 [nikos]
... next example the properties on assignment can take number or string, but when you get them out you always get the user unit out
15:07:30 [nikos]
ChrisL: so when getting values all numbers are converted to a canonical unit?
15:07:42 [nikos]
heycam: yes
15:08:03 [nikos]
... this is nicer than string only, but you can't use .x to get the string value
15:08:13 [nikos]
... final way you could do it is to have parallel accessors
15:08:28 [nikos]
... e.g. rect.x_px
15:08:56 [nikos]
ChrisL: I don't like that as much as .x.px
15:10:04 [nikos]
shepazu: chaining is a common pattern, I don't know if it's only with methods or if it would also be useful for properties
15:10:05 [ChrisL]
no, I was unclear. I don't like either x.px or x_px; prefer just .x returning a number
15:10:19 [nikos]
heycam: not really relevant for properties
15:10:39 [nikos]
krit: I was talking with Dmitry. He doesn't like this kind of magic
15:11:05 [nikos]
... where you set with one value and getter returns a different value because it's in a different unit
15:11:17 [nikos]
heycam: I think that's a valid point and might be reason to pick another proposal over this one
15:11:29 [nikos]
... might be an author expectation that returned value is the same as the set value
15:11:43 [nikos]
krit: Dmitry suggested something like x.getPixel()
15:11:48 [nikos]
shepazu: that's also magical
15:12:01 [nikos]
ChrisL: problem with returning strings is you have to parse them or have utility functions for dealing with them
15:12:18 [nikos]
... I think there's something in css where you can assign but the returned value is a canonical type
15:12:22 [nikos]
... why can't it be the same here?
15:12:27 [nikos]
krit: not the same in css
15:12:36 [nikos]
... internally css uses a canonical type
15:12:51 [nikos]
ChrisL: I think it will align down the road with css
15:13:04 [nikos]
heycam: depends if css goes down the road where you assign one type and get another out
15:13:09 [nikos]
... but they might not go in that direction
15:13:21 [nikos]
... whatever they do, it would be good to follow the same pattern
15:13:27 [nikos]
birtles: I thought the long term plan was to use value objects
15:13:32 [nikos]
heycam: don't think it's going to happen soon
15:13:54 [nikos]
birtles: I don't want us to paint ourselves into a corner where we can't align
15:14:20 [nikos]
krit: I'm not sure if it's magic, as far as I read the proposal from Tab it's pretty straight forward
15:14:26 [nikos]
heycam: I don't see that happening soon
15:14:31 [nikos]
krit: could svg wg push that forward?
15:15:04 [nikos]
... I added new section in SVG 2 with x, y presentation attributes. We could start working on om for css
15:15:59 [nikos]
krit: I have a fear with any new OM. it's svg specific
15:16:03 [jwatt]
jwatt has joined #svg
15:16:12 [nikos]
heycam: it's not svg specific in terms of the pattern of interacting with objects
15:16:31 [nikos]
... the pattern of exposing all properties as types appropriate to the property
15:16:39 [nikos]
ChrisL: people like that sort of thing
15:17:01 [nikos]
heycam: think there's a lot of antipathy wrt to getAttribute and setAttribute
15:17:09 [nikos]
krit: I support the part of making everything in html namespace
15:17:13 [nikos]
... don't support new graphics element
15:17:31 [nikos]
... it took 12 years for svg to be adopted. Now they have to learn something new
15:17:41 [nikos]
ChrisL: we can't break all the existing scripts
15:17:51 [nikos]
krit: if we decide to use new dom we can't
15:18:02 [nikos]
ChrisL: only way to move forward is to introduce a new element with the new dom
15:18:14 [nikos]
... so you're arguing for breaking all scripting in svg with new dom?
15:18:31 [nikos]
krit: I'm arguing that we shouldn't introduce new dom because we won't do it right this time
15:18:35 [nikos]
... like last two times
15:18:46 [nikos]
... i prefer to follow pattern of new CSS OM
15:18:52 [nikos]
... rather than creating new SVG model
15:19:21 [nikos]
... implementations won't support elements in two namespaces
15:19:31 [nikos]
... it's duplication of maintenance effort
15:19:36 [nikos]
heycam: I don't think it'll be too much work
15:19:49 [nikos]
... will just be an extra line in tables
15:19:58 [nikos]
... I think this DOM thing is actually rather small
15:20:02 [nikos]
... mostly it's accessor things
15:20:11 [nikos]
... which html elements already have code for reflection of attributes
15:20:24 [nikos]
... if we have string or length then that's a bit different than html but it's not too much extra
15:20:32 [nikos]
... plus a couple of methods for dealing with list type things
15:20:40 [nikos]
... so total code to support new DOM is not that big
15:20:52 [nikos]
krit: for webkit it would be a major change because svg animation uses old dom
15:20:58 [nikos]
... and needs to be mapped to new dom as well
15:21:16 [nikos]
ChrisL: I see your point that we need to consider implementer feedback
15:21:24 [nikos]
... if we allow opting in and promote the new dom
15:21:31 [nikos]
... in a few years we can drop the old method
15:21:41 [nikos]
... and break content that hasn't updated
15:22:02 [nikos]
krit: my point is that supporting new svg dom in the meantime with long term plan to go to css om
15:22:11 [nikos]
... means three things we have to maintain at once
15:22:22 [nikos]
ChrisL: css om is 5-10 years away
15:22:34 [nikos]
krit: new svg dom will be same time frame before it is in mainstream use
15:22:38 [nikos]
ChrisL: don't agree
15:23:02 [nikos]
krit: in this case you said we'd break a lot of content with svg dom, but the adoption of the new dom will be lower than you expect
15:23:25 [nikos]
ChrisL: I think as soon as this is implemented people will want to use it - it's simpler, probably more performant, etc
15:23:30 [nikos]
... everyone hates the existing dom
15:23:39 [nikos]
... number one thing people want is the dom fixed
15:23:52 [nikos]
krit: we are seeing most content comes from tools or scripts
15:24:09 [nikos]
... people aren't using svg dom
15:24:13 [nikos]
shepazu: possibly because it's so crap
15:25:40 [nikos]
shepazu: the performance hit for marshalling is bad, this might fix it right?
15:25:58 [nikos]
heycam: for lists it should
15:26:18 [nikos]
... I can show an example - transform-changes-1.html
15:26:51 [nikos]
... graphics element, 3 shapes, each has an initial transform and we're doing some script animations
15:26:59 [nikos]
... instead of having svg transform list and all the items in the list
15:27:40 [nikos]
... we have getTransformItems() which returns an array of objects
15:27:51 [nikos]
... each item in the array is a plain javascript object with dictionary
15:27:58 [nikos]
... it's not a live reflection of the thing
15:28:29 [nikos]
... you can push some new object onto the end of the array and it takes effect
15:28:32 [nikos]
krit: that's pretty neat
15:28:36 [nikos]
... but it would just work on svg elements?
15:28:58 [nikos]
heycam: the model I'm thinking of, for elements that have attributes, for each attribute there's some accessor method
15:29:02 [nikos]
... why couldn't we use that on a div
15:29:05 [nikos]
... ?
15:29:22 [nikos]
... if cssom had some nice list method like this (which it doesn't) then you could
15:29:38 [nikos]
shepazu: why do you think it's important that it's a generic one rather than one that works with svg elements
15:29:43 [nikos]
krit: it's important to have a unified model
15:29:57 [nikos]
shepazu: in what way is this not similar to getting the href of an a element in html?
15:30:06 [Rossen_]
Rossen_ has joined #svg
15:30:14 [nikos]
... I think there's a core difference between svg and html content
15:30:26 [nikos]
... html is light on attributes and attributes don't have complex values
15:30:42 [nikos]
... I think this is about as close as you can get with how a html dom would work
15:30:58 [nikos]
ed: looking at an attribute with a complex structure - say path - there's talk of adding path to css
15:31:06 [nikos]
... would this work similarly on path in css?
15:31:12 [nikos]
heycam: I would want the same dictionary values to be used
15:31:34 [nikos]
krit: with css the attribute has the least priority in the cascade, you would constantly override the values
15:31:46 [nikos]
heycam: maybe that's an argument for not having accessors on divs
15:31:51 [nikos]
krit: it's the same with svg attributes
15:31:53 [nikos]
heycam: that's true
15:32:02 [nikos]
krit: I do like this api more than what we have on svg currently
15:32:09 [nikos]
... but it should apply to everything that's transformable
15:32:18 [nikos]
shepazu: for transform you have a point
15:33:14 [nikos]
heycam: maybe it would have been better to show an example on path
15:33:23 [nikos]
jet: I was hoping to see the sprite model on svg
15:33:33 [nikos]
... what I'm seeing is svg is more machine generated
15:33:44 [nikos]
... lists would have many elements and iterating over isn't pratical
15:34:05 [nikos]
... what I'm seeing is that you can't pick out a particular object
15:34:45 [nikos]
heycam: one step in making it faster is the 'willchange' property
15:35:11 [nikos]
... in terms of the dom memory size issue, if you're not going to make modifications, it's been suggested to take a snapshot of the tree as a raster and throw away the tree
15:35:20 [nikos]
... it's kind of possible now with some work using Canvas
15:35:48 [nikos]
shepazu: there's a problem with that technique because you lose quality if someone zooms or does anything similar
15:35:56 [nikos]
... though perhaps you could just reconstruct
15:36:09 [nikos]
heycam: depends if you've thrown away the subtree
15:37:03 [krit]
s/ css the attribute/ the SVG attribute/
15:37:49 [nikos]
birtles: you could use an image element with a data uri to generate a sprite and throw away the dom tree
15:38:20 [nikos]
heycam: it's a bit like the original promise of use
15:38:31 [nikos]
shepazu: and by having params you could optimise on what would change and what would not
15:38:38 [nikos]
... so you could decide what bits to throw away and what to retain
15:39:07 [nikos]
... I hadn't considered that aspect, but params along with variables could be used as an optimisation hint
15:39:22 [nikos]
... one of the interesting things about svg is that you don't just have a static image - you have something you can change
15:39:30 [nikos]
... that is an advantage over rasters
15:39:42 [nikos]
jet: I'm not just talking about performance, but usage
15:39:48 [nikos]
... vast majority of svg isn't programmed
15:39:57 [nikos]
... so I'd like to be able to opt in to enabling programming on svg content
15:40:13 [nikos]
shepazu: you could specify that on the graphics element
15:40:27 [nikos]
jwatt: you could probably determine that programatically
15:40:42 [nikos]
... you'd need to take note of percentages and layout
15:40:54 [nikos]
... it's kind of the thing that you don't want an author to decide
15:41:11 [nikos]
heycam: if it's inline svg markup you need to have the dom because changes could come from outside
15:41:41 [nikos]
jet: programmable graphics is useful, but we're making assumptions about the dom that come from html
15:41:51 [nikos]
... which is mostly hand written, but svg is generated
15:42:09 [nikos]
... author just wants a scalable image, but it's slow because all the stuff going on under the hood to support the dom
15:42:24 [nikos]
heycam: you can already make that decision as an author by placing the image in line or not
15:42:59 [nikos]
... if you're doing inline svg you've made the decision that the dom needs to stick around
15:43:33 [nikos]
krit: if you scale the webpage, is there a performance difference between scaling an inline svg or an image svg?
15:44:00 [nikos]
Rossen_: you will see differences if you use percentages
15:44:25 [nikos]
krit: if percentages aren't use will images always be faster in IE?
15:44:27 [nikos]
Rossen_: yes
15:44:46 [nikos]
... which goes back to the point before about using the svg as an image
15:44:54 [nikos]
krit: I'm not sure about WebKit, what's FF like?
15:45:57 [nikos]
birtles: we have optimisations on img that will make it faster
15:46:28 [nikos]
birtles: I think we've worked out a way to reduce the cost of the DOM if that's what you want
15:46:38 [nikos]
krit: is there a cost on the dom other than memory?
15:47:06 [nikos]
jwatt: for us there would be - e.g. hit testing on elements
15:47:25 [nikos]
krit: for re-rendering only the render tree would be used (in WebKit)
15:47:47 [nikos]
heycam: back to the polyfill
15:48:29 [nikos]
Rossen_: there was a css value proposal that Tab had - I liked that he hid all the properties behind a CSS object
15:48:31 [nikos]
krit: that's the css om
15:48:41 [nikos]
Rossen_: have you thought of applying the same approach here?
15:49:01 [nikos]
heycam: I think we considered at one point doing something like giving different united access
15:49:12 [nikos]
... e.g. element.px.width
15:50:05 [nikos]
Rossen_: I liked it all being behind css
15:50:26 [nikos]
... related to dirk talking about transform, it's clear which you're working with
15:50:58 [jet]
jet has joined #svg
15:51:11 [Rossen_]
link to Tab's proposal http://www.xanthir.com/b4UD0
15:51:45 [nikos]
ed: we are moving more svg properties to css om, there's less unique svg elements in the dom
15:52:03 [ed]
s/elements/attributes (or objects)
15:52:40 [nikos]
heycam: for everything that has an attribute on an element, there's a dot something that lets you access it
15:52:49 [nikos]
... for consistency with html there should be some way of doing that
15:52:51 [jwatt_]
jwatt_ has joined #svg
15:52:58 [nikos]
krit: not sure if we need to be consistent with html at that point
15:53:08 [nikos]
heycam: I think that's a consistency that hasn't been broken in html
15:53:16 [nikos]
... an author can always guess how to interact with an object
15:53:46 [nikos]
ed: rather than breaking existing dom, phase it out and upgrade what we have
15:54:01 [nikos]
heycam: to achieve that new objects shouldn't have access to the old dom
15:54:29 [ed]
s/rather than breaking existing dom/I'd rather break the existing dom
15:54:40 [nikos]
shepazu: I'm don't think there's too much content using the current dom
15:54:46 [nikos]
heycam: we get bugs filed all the time when things change
15:55:20 [nikos]
krit: there's lots of differences now between Blink and WebKit and we don't get many bugs filed on it
15:56:21 [nikos]
shepazu: I'm skeptical that there's content using the specific part of the dom that we would break
15:56:43 [nikos]
... some content would break obviously, but is there a significant amount?
15:56:54 [nikos]
heycam: didn't we do a search last time and we found that d3 uses some
15:56:59 [nikos]
krit: just transform, with a fallback
15:57:20 [nikos]
shepazu: I think we talked last time about reaching out to those library authors and seeing how they feel
15:57:31 [nikos]
birtles: it's all the sites that have installed it and aren't updating it
15:57:45 [nikos]
ChrisL: I'd like to take up your point, get Dmitry's input for example
15:58:05 [nikos]
shepazu: that's not what I'm talking about. I'm talking about the proposal not having this new graphics element
15:58:14 [nikos]
ed: are there any other ways of opting in?
15:58:19 [nikos]
heycam: I couldn't think of any that are reasonable
15:58:27 [nikos]
shepazu: I'm suggesting that we break backwards compatibility
15:58:43 [nikos]
... just say rather than maintain these two paths, just break it
15:58:53 [nikos]
krit: speaking for WebKit and Apple, we would do it
15:59:01 [nikos]
jwatt: if you do it and get away with it I'd be happy to do it
15:59:18 [nikos]
shepazu: put out a build and see if people complain
15:59:36 [nikos]
krit: we can't break getPathLength, but we can break animval stuff
15:59:51 [nikos]
heycam: I agree that if it's possible to completely replace things then that's the best solution
15:59:55 [nikos]
... but I'm cautious about doing that
16:00:14 [nikos]
shepazu: there will be content that breaks, old documentation that will no longer be applicable
16:00:23 [nikos]
... but I suspect most of that content is not content that is being used
16:00:55 [nikos]
... a lot of the content would be from the old days
16:01:10 [nikos]
... FF broke almost all SVG content when it insisted we include the ns in the svg root
16:02:04 [nikos]
shepazu: I think we should be aggressive and try to change it and see what people say
16:02:32 [nikos]
ed: as long as there's an alternative to the functionality
16:02:35 [nikos]
shepazu: you can do it with a shim
16:02:39 [nikos]
ed: that would be difficult with animval
16:03:25 [nikos]
heycam: 1. whether or not new accessors are what we want
16:03:48 [nikos]
2. is backwards compat what we want?
16:04:51 [nikos]
heycam: I still think we should have the nice accessors, but it means we can do it in stages
16:05:08 [nikos]
shepazu: I would be happy with any of the suggestions rather than what we have now
16:05:18 [nikos]
... I couldn't decide on which one we want now
16:05:35 [nikos]
ed: it should be possible to drop parts of the old svg
16:05:44 [nikos]
heycam: what do you think about the dictionary things?
16:05:52 [nikos]
krit: everything using dictionaries is more like coding today
16:06:18 [ed]
s/drop parts of the old svg/drop parts of the old svg e.g the SVGPathSeg* API
16:07:09 [nikos]
krit: could we map svg namespace to html namespace?
16:07:14 [nikos]
heycam: that's a big dom core change but ....
16:07:33 [nikos]
ed: we had some hacks in presto to let you do that
16:07:48 [nikos]
heycam: could hack html parser now to put svg elements into html namespace
16:07:55 [nikos]
... and rely on not inspecting the namespace
16:08:16 [nikos]
krit: we got bug reports on that - about inheritance of objects
16:08:28 [ed]
s/presto to let you do that/presto to let you do that (document.createElement("rect") got you an SVGRectElement if the document had an <svg> root)
16:08:41 [nikos]
krit: right now is the best time to change svg this way
16:08:59 [jwatt]
Some modern HTML5 elements that have added numerical DOM properties:
16:09:01 [jwatt]
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-meter-element
16:09:03 [jwatt]
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-progress-element
16:09:04 [jwatt]
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content.html#media-elements
16:09:05 [nikos]
shepazu: right now people are using svg like an image, in the next few years people will be using it more like something you can program
16:09:17 [jwatt]
(so precedent for heycam's proposal)
16:09:41 [nikos]
heycam: I think we have to provide a nice scripted interface. Don't think it's good to require people to use libraries
16:10:10 [nikos]
jwatt: dirk was saying he didn't like having numerical properties - there's precedent for doing that in html5
16:11:49 [nikos]
heycam: I think we have a path to the next step now
16:11:54 [nikos]
... if we can rip the band aid off then that's good
16:12:02 [nikos]
... we would still need to work out the details regarding namespace stuff
16:12:09 [nikos]
... if we're not using a new root element name
16:12:54 [nikos]
shepazu: I wonder if this is something we should talk about at graphical web?
16:12:58 [nikos]
... on the panel thing
16:14:56 [nikos]
heycam: for a couple of the changes here, can you change href and classname to a string?
16:15:19 [nikos]
shepazu: you should also allow href without the xlink
16:15:26 [nikos]
krit: we also need to talk about image vs img
16:15:38 [nikos]
heycam: that was one of the wrinkles with this
16:15:48 [nikos]
... any way we go about it it's going to require changes to parsing
16:15:55 [nikos]
... maybe we should allow img
16:16:37 [nikos]
... we are already switching to object-fit and object-position
16:17:59 [nikos]
heycam: so to summarise the plan:
16:18:10 [nikos]
... 1. can we just remove the existing svg dom? dirk will try
16:18:26 [nikos]
... 2. if so, various parts of this proposal don't need to be done because we don't need to opt in
16:18:42 [nikos]
... we should give people whatever nicer options we can as soon as possible, but it doesn't have to be all at the same time
16:18:50 [nikos]
... 3. if it fails then we re-evaluate
16:19:01 [nikos]
krit: WebKit only releases every year
16:19:12 [nikos]
... need to talk to someone else for Blink
16:19:34 [nikos]
ed: I think as long as there's use counter data then it might be possible
16:19:39 [nikos]
krit: introduce a compile or runtime flag
16:19:49 [nikos]
heycam: decision about switching that flag?
16:20:29 [nikos]
krit: easy on nightly
16:20:39 [nikos]
ed: we can do it in parallel
16:20:59 [nikos]
heycam: dirk, how close are you to being convinced to doing something like this if the plan fails?
16:21:15 [nikos]
krit: my main concern was having a new graphics element that forces people to the new svg
16:21:27 [nikos]
heycam: we didn't talk about lower casing all attributes
16:22:45 [nikos]
shepazu: it might be advantageous for Blink and WebKit if you could point to this conversation and say this is what the svg wg is interested in doing to gather data
16:23:13 [nikos]
jwatt: we should clarify that we're not removing the entire svg dom
16:23:20 [nikos]
... someone should come up with a list
16:23:36 [nikos]
shepazu: we could give an example - say everything that is reflecting something
16:25:22 [nikos]
RESOLUTION: We will remove SVG DOM attribute accessors pending web compatibility checks
16:25:57 [jwatt]
all IDL attributes of type SVGAnimated*
16:26:00 [nikos]
ACTIONS: Erik to add run time flag to disable parts of SVG DOM in Blink
16:26:17 [nikos]
ACTION: Dirk to add compile time flag to disable parts of SVG DOM in WebKit
16:26:18 [trackbot]
Created ACTION-3644 - Add compile time flag to disable parts of svg dom in webkit [on Dirk Schulze - due 2014-08-29].
16:26:59 [nikos]
krit: I'd be interested in whether MS would remove the DOM if others did?
16:27:04 [nikos]
Rossen_: likely would
16:27:26 [nikos]
... would be in favour of better accessors
16:27:35 [nikos]
heycam: dirk your biggest concern is graphics element?
16:27:40 [nikos]
krit: yes, duplicating code paths
16:27:57 [nikos]
heycam: if we can't do removing and I can come up with another method of opting in without root graphics element would you be happier?
16:27:59 [nikos]
krit: yes
16:28:12 [nikos]
heycam: I'm not sure there is another way but I could think about it
16:28:28 [nikos]
ed: the point is to make existing svg elements inherit from HTMLElement
16:28:30 [nikos]
heycam: yes
16:28:54 [nikos]
shepazu: image element isn't as big a worry as a element as far as conflicts go
16:28:59 [nikos]
krit: it's not used very much
16:29:05 [nikos]
... we'd have to discuss with html community
16:29:17 [nikos]
krit: most of html community would be happy if we move to html namespace
16:29:21 [nikos]
... not sure they realise the cost though
16:29:47 [nikos]
heycam: I wonder if we're at a point where we decide that we want to put things in the html namespace?
16:30:12 [nikos]
krit: I think we should
16:30:27 [nikos]
shepazu: I'm in favour of it
16:30:30 [nikos]
ed: I'd like it if possible
16:31:10 [nikos]
heycam: I propose that we work towards having all svg elements in the html namespace
16:31:22 [nikos]
krit: do we need changes to the content model if we do that?
16:31:30 [nikos]
... e.g. circle having nested elements?
16:31:47 [nikos]
heycam: don't think changes would be needed
16:31:55 [nikos]
shepazu: think it would lead to changes but they're not required
16:32:03 [nikos]
heycam: I don't want to change the structure of elements
16:33:04 [nikos]
krit: if we decide this is the direction we want to go. we can devote next f2f to resolving the issues
16:33:41 [nikos]
Rossen_: moving to a namespace free world would be awesome
16:37:50 [nikos]
RESOLUTION: We want better accessor methods for list type things. e.g. return array of plain javascript values
16:39:43 [nikos]
RESOLUTION: All SVG elements should be moved to html namespace pending further discussion about details of doing that
16:40:59 [nikos]
heycam: in my proposal I said that you can put things in html namespace or no namespace
16:41:10 [nikos]
... with the aim that if you're writing xml by hand you can leave off the xmlns
16:41:18 [nikos]
... seemed like the nicest thing to do
16:44:28 [ed]
RRSAgent, make minutes
16:44:28 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/08/22-svg-minutes.html ed
16:45:26 [glenn]
glenn has joined #svg
16:47:02 [ed]
Meeting: SVG WG London F2F 2014
16:47:49 [ed]
present: Chris, Erik, Cameron, Doug, Nikos, Jet, Jonathan, Brian, Razvan, Dirk, Rossen, Rik, Tav
16:47:52 [ed]
RRSAgent, make minutes
16:47:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/08/22-svg-minutes.html ed
17:18:44 [glenn]
glenn has joined #svg
17:48:06 [glenn]
glenn has joined #svg
18:04:17 [thorton]
thorton has joined #svg
19:02:35 [thorton]
thorton has joined #svg
19:23:18 [glenn]
glenn has joined #svg
20:07:21 [jwatt]
jwatt has joined #svg
21:06:11 [jwatt]
jwatt has joined #svg
21:43:26 [krit]
ed: s/Leipzig/London ….many similarities