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