07:06:53 <RRSAgent> RRSAgent has joined #svg
07:06:53 <RRSAgent> logging to http://www.w3.org/2014/04/08-svg-irc
07:06:55 <trackbot> RRSAgent, make logs public
07:06:55 <Zakim> Zakim has joined #svg
07:06:57 <trackbot> Zakim, this will be GA_SVGWG
07:06:57 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
07:06:58 <trackbot> Meeting: SVG Working Group Teleconference
07:06:58 <trackbot> Date: 08 April 2014
07:06:58 <krit> ScribeNick: krit
07:07:06 <ed> chair: ed
07:07:30 <krit> heycam: [presentation about his proposal for new SVG DOM]
07:07:43 <ed> zakim, remind us in 8 hours to go home
07:07:43 <Zakim> ok, ed
07:08:37 <krit> heycam: ...want to improve SVG DOM... secuirty bugs in old DMO
07:08:42 <krit> heycam: no one likes it
07:09:01 <krit> heycam: new features are harder to add... especially looking forward to a new API
07:09:04 <nikos> http://dev.w3.org/SVG/proposals/improving-svg-dom/
07:09:11 <krit> heycam: should a new API be consistent with SVG DOM or HTML?
07:09:21 <krit> heycam: that is why I thought about new API
07:09:30 <krit> heycam: more HTML like API without breaking content
07:09:36 <krit> heycam: but didn't really work out
07:09:48 <krit> heycam: eg SVGAnimatedLength stuff
07:09:58 <krit> heycam: svg.width = something would be great
07:10:13 <krit> heycam: but there is no way we can still keep the SVGAnimated object on there
07:10:24 <krit> heycam: and have numbers as argument at the same time
07:10:54 <krit> heycam: from there I though if we need to want a new DOM... the authors should have a way to use the new API and have a  fallback for the old API
07:11:09 <krit> heycam: to opt in to new SVG DOM should be known at element creatiion
07:11:21 <krit> heycam: NS would be a way to indicate new elements
07:11:32 <krit> heycam: SVG NS would get old API
07:11:41 <krit> heycam: no NS (HTML NS) will get new API
07:12:29 <krit> heycam: you can create elements without NS suffix
07:12:41 <krit> heycam: that puts element sin the HTML NS by default
07:12:51 <krit> heycam: null NS allows elements in XML NS
07:13:23 <krit> heycam: I hope that the fact that there are 2 NS versions of an element is not too big of a problem to implementations
07:14:13 <krit> heycam: we don't want to have inline SVG stuff to get suddenly a new API
07:14:21 <krit> heycam: we need to tag them differently
07:14:41 <krit> heycam: so that old content doesn't end up with new API while the JS code still addresses the old NS
07:14:48 <krit> s/NS/API.
07:14:50 <krit> s/NS/API/
07:15:03 <krit> heycam: the tricky part is the img element
07:15:17 <krit> heycam: "image" creates the <img> element, not <image>
07:16:06 <krit> krit: what about createElement("image")
07:16:13 <krit> heycam: hm, need to think about it
07:16:55 <krit> heycam: while <image> in HTML actually creates <img>, creareElement("image") might not
07:17:01 <krit> heycam: [does checking and confirms]
07:18:17 <krit> krit: what about innerHTML = "<image>"?
07:18:24 <krit> heycam: maybe we need another flag
07:18:37 <krit> ed: authors might not want to have 2 different image elements
07:18:42 <krit> heycam: probably
07:18:50 <krit> heycam: haven;t looked into the APIs
07:19:29 <krit> heycam: so not sure if the images are compatible
07:19:42 <krit> krit: both elements would need the attributes of the other
07:20:14 <krit> heycam: the proposal rests on having two APIs where one gets dropped over time
07:20:31 <krit> heycam: don't think it is possible to drop SVG content completely
07:20:40 <krit> s/content/API/
07:21:12 <krit> pdr: what about having both APIs on the same element
07:21:17 <krit> heycam: that is how I started
07:21:31 <krit> heycam: element.x = .... [see problem above]
07:22:24 <krit> heycam: for inline SVG we would need a new root <graphics> to get the new API
07:22:31 <krit> heycam: this would create a new viewport
07:22:59 <krit> heycam: all attributes need to be lowercase
07:23:47 <krit> heycam: same for elements
07:24:34 <krit> heycam: maybe even do dashed limitingConeAngle -> limiting-cone-angle
07:25:16 <krit> heycam: some element need to be unified like script, style, a
07:26:20 <krit> heycam: still needs to be defined what happens when you mix SVG and HTML-SVG elements
07:28:40 <krit> heycam: [explains some API specific things that do not allow to simply combine old and new SVG DOM]
07:28:50 <krit> heycam: [all in his document]
07:30:54 <krit> ed: you can not check equality of SVGAnimated objects in Blink anymore
07:31:39 <krit> pdr: we broke that intently
07:31:51 <ed> rect.x === rect.x will return false in blink
07:32:00 <krit> krit: some one from Google said that on the mailing list www-svg
07:32:17 <krit> birtles: yes, and bz was clearly against that
07:32:23 <krit> birtles: we can not do it
07:32:35 <krit> pdr: we made it and it makes the implementation much simpler
07:33:41 <krit> heycam: going HTML allows us to avoid duplication from many things that didn't move up to Element
07:33:46 <krit> heycam: like tabIndex
07:35:34 <krit> heycam: all SVGAnimated* types get basic types like SVGBoolean to boolean SVGString to DOMString
07:35:44 <krit> heycam: int -> long
07:42:21 <tbah> tbah has joined #svg
07:42:42 <krit> heycam: [explaining different lists in his proposal]
07:46:48 <krit> ed: did you measure SVG DOM usage?
07:46:55 <krit> heycam: I plan to do it
07:47:15 <krit> pdr: we coudldn't in Blink. We wanted to do the measuring
07:48:08 <ed> s/SVG DOM usage?/SVG DOM usage? particularly the pathSeg DOM
07:52:06 <krit> pdr: why do you keep normalized paths around? IIRC just Presto ever implemented normalized path with synchronization?
07:52:15 <krit> heycam: yeah, we might get rid of it.
07:52:26 <krit> pdr: not sure why we need normalized paths at all
07:52:32 <krit> pdr: canvas doesn't have it
07:52:49 <krit> krit: canvas paths are not that difficult as SVG paths
07:54:08 <krit> heycam: [goes on with aspectratio]
07:54:39 <krit> heycam: if there is a need for preserveAspcetRatio that can not be solved with CSS we may need to keep it but as string instead of enum
07:57:21 <birtles> ScribeNick: birtles
07:57:33 <birtles> pdr: I like this proposal
07:57:49 <birtles> heycam: One of my concerns is the duplication of code and the burden it would be
07:57:53 <birtles> ... I hope it wouldn't be too much
07:57:58 <birtles> ... same functionality but a different API
07:58:03 <birtles> pdr: yes, that is a concern
07:58:19 <birtles> ... what about making SVG2 be a clean break altogether?
07:58:43 <birtles> ... why not remove backwards compatibility altogether when you have <graphics> as top-level?
07:58:49 <birtles> krit: that would lead to two implementations
07:59:00 <birtles> pdr: but in the future we would hope to remove the old implementation
07:59:07 <birtles> heycam: I think this proposal does that
07:59:46 <birtles> pdr: this maintains features like SMIL for example
08:00:08 <birtles> krit: in general I like this idea of SVG inheriting from HTMLElement
08:00:22 <birtles> ... I think this is worthwhile but I see the problems with <image> and <script> and moving elements around
08:00:46 <birtles> ... what I would propose therefore is, we have a resolution to move more attributes to presentation attributes
08:00:55 <birtles> ... having that, many of the features of the SVG DOM are not necessary therefore
08:01:31 <birtles> ... if you have a look at Tab's proposal for a CSSOM
08:01:45 <birtles> http://www.xanthir.com/b4UD0
08:01:53 <birtles> ... this defines a new object model
08:02:16 <birtles> ... when we go ahead with this, the CSSOM, to then come up with another SVG API is not the way to go
08:02:27 <birtles> ... we should focus on this API which affects all elements, not just SVG
08:02:43 <birtles> ... at some point this proposal will go ahead, perhaps with some changes
08:03:09 <birtles> heycam: I agree that it wouldn't be good if we had two ways of assigning length properties
08:03:36 <birtles> ... I would be hopeful that the CSSOM stuff--which is still a few years away since it requires Javascript features that we don't have yet
08:03:43 <birtles> ... specifically value objects don't exist yet
08:03:52 <birtles> ... so it will be a while before this is possible
08:04:08 <birtles> ... so I think we should make sure the SVG2 DOM can use these value objects when they are available
08:04:11 <birtles> krit: the mapping right.
08:04:29 <birtles> ... so we want to deprecate the SVG DOM at some point anyway so we should focus on the HTML DOM stuff
08:04:39 <birtles> heycam: looking at a concrete example
08:04:52 <birtles> ... if we have rectElement.x = "10px"; (with my proposal)
08:05:02 <birtles> ... and you can also do rectElement.x + 20
08:05:21 <birtles> ... if we were to support value objects then we would also allow rectElement.x = 10px
08:05:40 <birtles> krit: I think we don't actually want that but just want strings
08:05:46 <birtles> ... I think that's a problem with Tab's proposal
08:06:02 <birtles> ... so I don't think you can just use 10px, I think you'd pass it "10px"
08:06:12 <birtles> heycam: what part of the CSSOM API do you want to use then?
08:06:29 <birtles> ... are you saying that you should just be able to do rectElement.style.x = "10px"
08:08:28 <birtles> ... if we didn't promote all these attributes to properties, is there still something from the CSSOM we could use to represent this?
08:08:37 <birtles> ... e.g. rectElement.x = CSS.px(10)
08:08:55 <birtles> krit: we should work together with the CSSWG in the FXTF to come up with an API for everything not just SVG
08:09:13 <birtles> ... it seems strange to come up with all these IDLs that are SVG specific
08:09:44 <birtles> birtles:  isn't the same for HTML elements e.g. HTMLImageElement.src
08:09:53 <birtles> krit: I want to limit the number of IDLs we have
08:09:55 <birtles> heycam: why?
08:10:02 <birtles> krit: why do you want to flood the platform with IDLs
08:10:13 <birtles> heycam: are you worried about introducing new globals?
08:10:19 <birtles> krit: just in general
08:10:28 <birtles> heycam: surely you want rectElement.x?
08:10:42 <birtles> krit: I don't think rect.x vs rect.style.x is a big deal
08:10:51 <birtles> ... it's strange to me that you have rect.width but div.style.width
08:10:56 <birtles> ... why not have the same API for both?
08:11:12 <birtles> heycam: but in HTML you have inputElement.value not inputElement.style.value?
08:11:30 <birtles> krit: yes, you cannot promote all attributes to style properties but we should promote the ones we can
08:11:46 <birtles> ... ones like width etc. can be promoted
08:11:59 <birtles> heycam: I was never 100% comfortable with what we had
08:12:02 <birtles> krit: why?
08:12:14 <birtles> heycam: the fact that all of the proposals had downsides with them
08:12:30 <birtles> ... either we had to introduce new properties names that match CSS but not the attribute names
08:12:45 <birtles> ... or we add properties named 'x' etc. that are very generic and only apply to SVG elements
08:13:07 <birtles> krit: a lot of properties can be applied to all elements even though they don't make sense
08:13:19 <birtles> pdr: krit, your point seems to be a nice-to-have
08:13:26 <birtles> ... holding up the proposal on the CSSOM is dangerous
08:13:40 <birtles> krit: yes, especially since the current CSSOM is not implemented in that manner
08:14:07 <birtles> pdr: I think tying this to CSSOM seems more risky
08:14:20 <birtles> krit: if we want to look at real examples, the SVG DOM is already rarely used
08:14:27 <birtles> ... so why introduce something that people might or might not use
08:14:46 <birtles> ... why work on something we're going to deprecate?
08:14:55 <birtles> heycam: but one reason no-one uses it today is that it's so hard to use
08:15:03 <birtles> ... if you can do rectelement.x people might actually use it
08:15:27 <birtles> davve: what about all the SVG tutorials on the Web that document the old DOM?
08:15:32 <birtles> ... it's really hard to change that
08:15:44 <birtles> heycam: if we can rely on measurements for when we can drop the old stuff
08:16:10 <birtles> ... the existence of of tutorials might lengthen the time it takes but as long as we can measure them, we can know when to drop them
08:16:31 <birtles> ... Alex Russell said, why not tie new features to the new DOM as a kind of carrot to move people over
08:17:08 <birtles> krit: I just think we can avoid this burden but not introducing a new API
08:17:51 <birtles> pdr: if we're already introducing a new top-level element, downplaying the fact that it's SVG at all, that it's <graphics> in HTML
08:18:03 <birtles> ... might help people avoid old SVG tutorials
08:18:20 <birtles> ed: if we do that we should change the SVG MIME type
08:19:14 <birtles> ... that way you could copy content from an HTML document and put it in a standalone document it would still work (without the change in MIME type the parsing differences would break it)
08:19:28 <birtles> heycam: a new MIME type / media type is an additional barrier to get things happenning
08:19:44 <birtles> ... since it requires new server configurations etc. and people can never get that right
08:20:17 <birtles> ... I'm not sure how much advantage there is to renaming the whole language to help with the mindset of "this is something new"
08:20:50 <birtles> ... I think it will be easier to convince implementors to get on board if it's not something completely new
08:21:53 <birtles> birtles: from authoring point of view I think it's nice if you can opt into the new DOM but just changing the name of the top-level element
08:22:12 <birtles> heycam: that won't work for standalone XML documents (due to attribute case sensitivity) but it will for HTML
08:22:39 <birtles> krit: don't underestimate the point of authoring tools, not only Illustrator and Inkscape, but other tools export SVG
08:23:08 <birtles> pdr: fair enough, I think a drastic overhaul is probably difficult
08:23:30 <birtles> krit: there are a lot of non-graphical technical products that export SVG
08:23:53 <birtles> ... but there are no tools that support SVG animations and SVG DOM so we could get rid of those
08:24:05 <birtles> ... for the same reasons I don't see tools using the new SVG DOM
08:24:30 <birtles> ... I don't think people will make use of the power of the new API
08:24:49 <birtles> heycam: I'm guessing differently that the simplicity of the new API will encourage people to use it
08:25:03 <birtles> ... do people want to script SVG at all? I think yes, they do
08:25:17 <birtles> ... and if they do, then I think they will want to use this
08:25:37 <birtles> krit: but I think people use libraries to do the scripting and those libraries can use the existing SVG DOM
08:26:18 <birtles> birtles:
08:26:39 <birtles> nikos: if you do this, maybe people won't feel the need to use libraries
08:26:49 <birtles> ed: I think most people will use libraries anyway
08:26:56 <birtles> krit: and you'll never get it right for everyone
08:27:28 <birtles> heycam: Tav, what do you think about the markup changes?
08:27:54 <birtles> krit: I think Inkscape doesn't need to care about the markup changes too much--just the top-level document and attribute case sensitivity
08:28:54 <birtles> krit: I think the proposal needs to be more downward compatible with regards to case sensitivity
08:28:55 <birtles> heycam: if we have to change the root-level element anyway then browsers that don't support it won't render it at all anyway
08:29:03 <birtles> ed: but it will still render the text inside
08:29:06 <birtles> heycam: yes it will
08:29:38 <birtles> krit: I'm not convinced that there is enough need for this to justify defining a new API
08:29:52 <birtles> heycam: are you saying that authors should use setAttribute/getAttribute to access these things?
08:30:25 <birtles> krit: I think in the future they can use CSSOM, who knows, maybe people won't use that either since they're so used to .style.x = DOMString
08:33:07 <ed> (15min break)
08:40:48 <heycam> old and new API: https://pastebin.mozilla.org/4776291
08:40:53 <heycam> for setting transform
08:53:10 <nikos> nikos has joined #svg
08:55:58 <nikos> scribenick: nikos
08:56:26 <nikos> heycam: Ideal outcome for me is go ahead and do my proposal
08:56:40 <nikos> ... outcome I really want is whether we are going to do something like this and I should continue work or not
08:56:46 <nikos> pdr: CSSOM will happen
08:57:04 <nikos> ... Dirk's point about this change not benefiting users so much, getting behind CSSOM would benefit users more
08:57:30 <nikos> krit: I think your proposal is very sane for CSS as well as SVG
08:57:56 <nikos> ... I think it would be good if we could base CSSOM definition on it
08:58:09 <nikos> heycam: Dirk's future relies on promoting properties to presentation attributes
08:58:16 <nikos> ... it seems like support for that is waning
08:58:39 <nikos> ed: we have a topic later on about width and height as presentation attributes
08:58:48 <nikos> heycam: one thing is, I think now is the best time to do something about this
08:59:02 <nikos> ... if we wait too much longer then our opportunity will be missed
08:59:12 <nikos> ... which is why I'd like to know now whether to push forward on it
08:59:33 <nikos> ... if we assume that we promote a bunch of things, you might be right that .style.something might be the preferred way of interacting
08:59:41 <nikos> ... but the simplicity of .x is alluring to me
08:59:48 <nikos> pdr: why can't we do that as well? .x is great
08:59:53 <nikos> heycam: don't think DIrk wants to
08:59:59 <nikos> ... if we have .style we shouldn't have .x
09:00:30 <nikos> krit: the biggest issue is that you cannot easily compare right?
09:00:31 <nikos> heycam: yes
09:00:50 <nikos> krit: can you do .x = 3 + 4 or += something?
09:01:02 <nikos> heycam: you can make it work using a valueOf method
09:01:08 <nikos> krit: it would create an object first?
09:01:19 <nikos> heycam: this is if it is an object already
09:01:28 <nikos> krit: === doesn't work for blink right?
09:01:31 <nikos> pdr: we broke it yes
09:01:36 <nikos> krit: chrome or developer channel?
09:01:41 <nikos> ed: dev channel for sure, not sure about chrome
09:01:50 <nikos> krit: that was the biggest issue with your proposal
09:02:01 <nikos> heycam: it violates javascript semantics so not possible anywhere
09:03:11 <nikos> krit: can we upgrade property to also support taking a dom string?
09:03:50 <nikos> heycam: limitations are: you can't do equality checking. equals and not don't work
09:04:10 <nikos> ... I don't think that's acceptable as it will confuse people
09:04:26 <nikos> ... is your view Dirk, that if we don't need a new API for .x then we don't have the problem of reconciling with the old API
09:04:39 <nikos> ... so therefore we don't need the proposal because you don't need to opt in to the new DOM
09:05:19 <nikos> heycam: if we do the namespace thing without hooking in a new API we have lost the opportunity
09:05:47 <nikos> heycam: I guess I disagree about the importance of the string accessors?
09:05:55 <nikos> pdr: is the reason people don't use this today that it's hard to find?
09:06:01 <nikos> heycam: I think so but it's hard to prove
09:06:50 <nikos> pdr: I use get and setAttribute because I don't want to have to remember the other methods
09:07:22 <nikos> krit: we are stuck in this situation where each of us wants a part of the proposal
09:07:26 <nikos> ed: what do we agree on?
09:07:39 <nikos> pdr: everyone agrees on namespace bit? inheriting from HTML.
09:08:20 <nikos> heycam: you may have to do the root element name change for that
09:08:27 <nikos> pdr: we looked at doing a parser change
09:08:38 <nikos> ... it broke things
09:08:55 <nikos> ... we tried parsing svg with the html parser and there were a few things that didn't work
09:09:22 <nikos> heycam: I was just talking about whether its necessary to rename the root element not whether we use a different parser for stand alone docs
09:09:39 <nikos> pdr: so you can parse a stand alone document with the xml parser in the html namespace
09:09:41 <nikos> heycam: yes
09:10:00 <nikos> heycam: the bits that Dirk doesn't want to do are the things that I think we only have the opportunity to do now
09:10:41 <nikos> ... I don't what information is going to help us make the decisions?
09:10:49 <nikos> heycam: will anyone use the new APIs?
09:11:01 <nikos> pdr: I think only a small number will
09:11:14 <nikos> ... the number of handwritten svg files is small
09:11:28 <nikos> ... think that d3 etc are mostly what is used but don't know how to prove that
09:11:48 <nikos> birtles: is one thing to do the namespace change but add .x and .y later?
09:12:23 <nikos> heycam: why would people use the new things if there's no extra functionality available?
09:13:10 <nikos> heycam: Dirk you were asking if we can do a survey?
09:13:14 <nikos> krit: don't think it would be that reliable
09:13:35 <nikos> heycam: I'm not sure how to move forward
09:14:03 <nikos> ed: you want the whole thing and not just small parts that we can agree on?
09:14:20 <nikos> heycam: we might not be able to add parts later
09:14:39 <nikos> heycam: I'm not convinced that .style.something is preferred to .something
09:14:46 <nikos> ... I think I would prefer .something
09:14:58 <nikos> pdr: I agree but don't know why an alias wouldn't work there
09:15:17 <nikos> birtles: would that be forwards compatible with CSSOM?
09:15:28 <nikos> krit: needs approval from CSS WG but they don't know what the CSSOM is going to look like
09:16:31 <heycam> if we made elt.x just forward on to elt.style.x, then I think we would want to restrict elt.x to be a string
09:16:35 <heycam> and not (float or DOMString)
09:16:47 <heycam> since we don't really know how other types are going to be handled on elt.style.x
09:17:04 <nikos> heycam: what individual bits does everyone agree on?
09:17:16 <nikos> ed: inheriting from HTML element and namespace sounds fine to me
09:17:34 <nikos> pdr: dropping crazy path API
09:18:08 <nikos> birtles: I generally like the graphics element
09:18:23 <nikos> heycam: I feel like the graphics element is a necessary evil for the opt in api
09:18:39 <nikos> krit: graphics can mean a lot of things and in the future you may not just have canvas or svg
09:19:15 <nikos> heycam: do people think it's useful to get feedback from users via svg developers list?
09:19:21 <nikos> pdr: don't think it will be accurate enough
09:19:29 <nikos> krit: you'll only get participation from those who want the API
09:19:50 <nikos> heycam: how can we decide on whether the new API stuff should be in there?
09:19:53 <nikos> ... what info do we need
09:20:13 <nikos> pdr: how do we prove more people will use it?
09:20:20 <nikos> heycam: tie in new features to the new DOM only
09:20:44 <nikos> ... although that doesn't mean they will have to use .x. could still use setAttribute
09:21:21 <nikos> ed: using the version attribute for switching makes sense for authoring tools
09:21:36 <nikos> heycam: don't think you can change the API based on the attribute
09:21:47 <nikos> ... when you do createElement the attribute isn't present yet
09:22:27 <nikos> ed: you couldn't change the namespace based on version attribute but you could select the API
09:22:36 <nikos> heycam: I don't want to have to check in every method
09:22:57 <nikos> pdr: write a polyfill. If usage gets high enough then switch
09:23:11 <nikos> krit: web animations provides a polyfill and no one uses it
09:23:20 <nikos> birtles: we have a few people using it. Have had good feedback
09:23:32 <nikos> pdr: polyfill used for shadow DOM is getting usage
09:23:49 <nikos> birtles: I agree that polyfill isn't enough of a measure
09:24:20 <nikos> nikos: might not be time to take the measurements with a polyfill without missing the opportunity to make the change
09:25:05 <nikos> ed: what about if we provide a javascript compat library?
09:25:14 <nikos> krit: how would they include the script?
09:25:26 <nikos> ... it's an interesting idea
09:25:44 <nikos> pdr: we've thrown around the idea of implementing svg with javascript
09:26:19 <nikos> ... rendering would come from backing objects
09:26:23 <nikos> ... it would be faster
09:27:03 <nikos> heycam: I like the idea in general of writing a polyfill for the new DOM API
09:27:29 <nikos> ... probably wouldn't give us the information needed to decide if we go on with the changes
09:28:50 <nikos> heycam: I can write the polyfill
09:29:16 <nikos> pdr: could be useful for pointing the CSSOM people in the right direction
09:29:24 <nikos> ... but it seems like a lot of work
09:29:28 <nikos> heycam: might not be too much work
09:29:37 <nikos> ... not sure how to do the namespace stuff. It's just about the API
09:29:48 <nikos> ... including the script opts in
09:30:03 <nikos> pdr: could use custom elements
09:30:05 <nikos> ... but couldn't be a root element
09:30:24 <nikos> ... since script exists in both namespaces maybe you could
09:30:54 <nikos> ed: so outcome is to write a polyfill?
09:30:57 <nikos> heycam: I guess so
09:31:04 <nikos> pdr: other outcome was the four things we agreed on
09:31:27 <nikos> heycam: in terms of moving forward, I still feel gated by deciding on what to do with the DOM
09:31:45 <nikos> ... if we're undecided we are basically making the decision not to go forward because the opportunity is limited
09:32:26 <nikos> birtles: we can introduce new API later easily enough. Say .x but only if we drop the old implementation
09:33:46 <nikos> heycam: so we know the things we agree on. I can write a polyfill for the DOM so we can get a feel. But I don't know how much that will help us decide whether to push forward. What's going to help us make that decision?
09:33:51 <nikos> ... the default decision is to not do it
09:34:29 <nikos> krit: why not write the polyfill then we make a decision at the next F2F
09:36:02 <nikos> ACTION: Cameron to write polyfill for his DOM proposal before next F2F (with enough time for WG to experiment)
09:36:02 <trackbot> Created ACTION-3611 - Write polyfill for his dom proposal before next f2f (with enough time for wg to experiment) [on Cameron McCormack - due 2014-04-15].
09:37:02 <nikos>  Topic: buffered-rendering and will-change
09:37:08 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/buffered_rendering_expansion
09:37:33 <nikos> Topic: buffered-rendering
09:37:49 <nikos> birtles: at TPAC we discussed buffered-rendering and having an extra value for buffered-rendering
09:38:13 <nikos> ... I think the idea was that the author can control whether content should be re-rasterised as it's being transformed
09:38:29 <nikos> ... in any case, that was before will-change had been discussed
09:38:40 <nikos> ... and it's my understanding that will-change covers most of those use cases
09:39:07 <nikos> ... so if you're going to zoom or pan around then you set will-change=transform before doing so to tell the user agent to render once
09:39:11 <nikos> heycam: but it's only a hint?
09:39:17 <nikos> birtles: yes. buffered-rendering was too
09:39:35 <nikos> ... I think perhaps we don't need buffered-rendering after all. will-change is probably enough
09:39:47 <nikos> ... Takagi-san prepared some performance test cases
09:39:48 <stakagi> http://svg2.mbsrv.net/devinfo/devstd/panZoom/
09:40:06 <nikos> birtles: there are some notes about the performance observed in each case
09:40:21 <nikos> ... one thing to note is that for the panning case, FF recently got faster
09:40:34 <nikos> ... it's my view that many of these cases can be optimised in the browser without extra hints
09:40:40 <nikos> ... some will-change would help
09:40:56 <nikos> heycam: will-change is good for the first few frames before heuristics kick in
09:41:34 <nikos> birtles: I spoke to Takagi-san before about different use cases and we wonder are there use cases where you really do prefer a crisp rendering over smooth performance?
09:41:41 <nikos> ... I wonder if we always want smooth performance
09:42:43 <nikos> pdr: there's memory concerns with buffered-rendering and will-change
09:42:54 <nikos> ... I can imagine there are cases where you don't want to use the memory
09:43:07 <nikos> heycam: I'm assuming heuristics in the browser will ensure you don't eat up all the memory
09:43:22 <nikos> birtles: it's a hint so the browser can ignore
09:46:21 <nikos> pdr: it can be jarring if you optimise for speed while transforming then switch to pixel perfect. Have had user complaints
09:47:53 <nikos> birtles: there is a proposal. This is prior to will-change but has updated
09:48:04 <nikos> ... the proposal was to add an additional keyword to buffered-rendering
09:48:19 <nikos> ... currently we're wondering if it's needed or if will-change is sufficient
09:48:31 <nikos> ... I would further propose that we don't need buffered-rendering at all in SVG
09:49:04 <nikos> heycam: if there's a use case for preferring dropping frames over smooth transitions then it could be useful
09:49:45 <nikos> pdr: does any browser other than Chrome implement buffered-rendering?
09:49:49 <nikos> ed: Presto did
09:50:32 <nikos> ... was for set top boxes that have low spec hardware. Was successful but was in environments where content was controlled
09:51:45 <nikos> heycam: I would be tempted to wait until there are stronger requests for the dynamic one, and if we're happy that will-change fulfills the smooth transition use case then stick with that
09:52:23 <nikos> birtles: I think that's fine. Takagi-san was pointing out there are some parallels with the SVG integration spec
09:52:29 <nikos> ... where we had different modes
09:52:41 <nikos> ... if we were to keep buffered-rendering there would be some alignment that would be possible
09:52:50 <nikos> ... could use a different strategy for buffering depending on the content mode
09:52:59 <nikos> ... but if we don't have buffered-rendering then it doesn't matter
09:53:13 <nikos> heycam: you might be able to detect a lot of that automatically in the implementation
09:53:45 <nikos> heycam: pdr said before he implemented buffered-rendering on Blink specifically for the image element
09:54:47 <nikos> ed: does will-change make a difference on SVG content now?
09:55:12 <nikos> pdr: I'd be supportive of changing buffered-rendering to will-change
09:56:38 <nikos> RESOLUTION: will drop buffered-rendering in favour of will-change
09:57:38 <nikos> krit: will-change is not purely a hint
09:57:48 <nikos> heycam: if you say will-change=transform you have to create a stacking context
09:59:57 <nikos> Lunch break
10:03:58 <ed> ACTION: brian to replace buffered-rendering with will-change in svg2
10:03:58 <trackbot> Created ACTION-3612 - Replace buffered-rendering with will-change in svg2 [on Brian Birtles - due 2014-04-15].
10:56:33 <nikos> nikos has joined #svg
10:59:18 <nikos> Topic: z-index
11:00:04 <nikos> heycam: I was talking to jwatt recently and he was saying it would be good if z-index made it into the spec so that we could make use of all the refactoring that was done to allow z-index to work
11:00:12 <nikos> ... is anyone planning on doing the work to put it in the spec?
11:00:16 <nikos> ... if not perhaps I can
11:01:07 <nikos> pdr: is there any relation to will-change?
11:01:17 <nikos> heycam: in the sense that they are both related to stacking contexts
11:02:02 <nikos> ... we already have lots of things in SVG 2 that will create stacking contexts
11:02:07 <nikos> ... blending, transforms, masking, etc
11:02:24 <nikos> davve: what's the relation of css stacking contexts to svg stacking contexts?
11:03:02 <nikos> heycam: in svg content it's going to be the same as css
11:03:53 <nikos> cabanier: 2d transforms don't create stacking context in svg because we do many transforms
11:04:03 <nikos> heycam: we probably need to have an overall description of the rendering
11:04:20 <nikos> ... if z-index isn't on anyone elses plate I'll have a crack before the deadline
11:05:20 <nikos> heycam: the concept of a stacking context can come from the css spec can't it ?
11:06:42 <nikos> ... the overall process will be the same as CSS, but with specific SVG rendering steps
11:09:05 <nikos> ACTION: Cameron to add z-index text to SVG 2 specification before feature cut off date
11:09:05 <trackbot> Created ACTION-3613 - Add z-index text to svg 2 specification before feature cut off date [on Cameron McCormack - due 2014-04-15].
11:09:24 <nikos> Topic: making width/height presentation attributes on foreignObject
11:09:30 <nikos> davve: this came up when I did patches for Blink
11:09:33 <nikos> ... I have some examples
11:09:42 <davve> http://jsfiddle.net/MmkYj/
11:09:51 <davve> http://jsfiddle.net/MmkYj/1/
11:10:04 <nikos> one uses height attribute and one uses property
11:10:23 <nikos> davve: in FF they are equivalent, but not in Blink
11:10:59 <nikos> ... svg and foreignObject are the two elements that interact with the CSS box model
11:11:27 <nikos> krit: I would like to avoid having width and height presentation attributes on some elements and not on others
11:12:39 <nikos> davve: don't think it's that odd. It makes sense for things that interface with the box model
11:13:34 <nikos> ed: I don't think accepting for foreignObject would preclude us from adding it for other elements later
11:13:59 <nikos> heycam: what about iframe and canvas?
11:14:21 <nikos> krit: for iframe can you override the width and height attribute with stylesheet?
11:14:32 <nikos> davve: not sure
11:14:49 <nikos> pdr: yes in Chrome
11:15:01 <pdr> Iframe example: http://jsfiddle.net/MmkYj/2/
11:15:48 <pdr> Updated with style overriding: http://jsfiddle.net/MmkYj/3
11:16:18 <nikos> pdr: so this would apply for svg as well
11:16:41 <nikos> ed: there might be an existing resolution for this
11:17:28 <nikos> heycam: so in svg foreignObject and iframe will have x and y. Should they be presentation attributes as well?
11:17:47 <nikos> ed: according to previous resolution, yes
11:17:53 <nikos> heycam: I'm happy to just do it for width and height
11:18:37 <nikos> ... the previous resolution was about mapping many to presentation attributes but we never followed through
11:18:54 <nikos> ed: I think we should do it for foreignObject
11:19:36 <nikos> heycam: I think it doesn't make sense to make rect width and height presentation attributes without the broader set being done
11:19:55 <nikos> ... we can easily do width and height for foreignObject and iframe and do the others later if we want
11:20:28 <nikos> RESOLUTION: make width and height attributes on foreignObject element presentation attributes
11:21:20 <nikos> ACTION: Erik to edit SVG 2 to make width and height presentation attributes on foreignObject
11:21:20 <trackbot> Created ACTION-3614 - Edit svg 2 to make width and height presentation attributes on foreignobject [on Erik Dahlström - due 2014-04-15].
11:21:41 <nikos> Topic: Resolving concerns with marker-segment and marker-pattern
11:23:24 <nikos> heycam: marker-start, mid and end are the existing marker properties
11:23:33 <nikos> ... I added my proposal for two additional properties
11:23:46 <nikos> ... marker-segment lets you place markers in the middle of each segment of the path
11:24:18 <nikos> ... marker-pattern is something more like a stroke-dasharray where you give a sequence of lengths and marker elements that are repeated without regard to the segments of the path
11:24:54 <nikos> ... there was some concern from Tab and Dirk that we might not need to have both marker-pattern and marker-segment
11:25:02 <nikos> ... there should be a way to do marker-segment with marker-pattern
11:25:29 <nikos> ... some of the solutions were to have instructions in the pattern pattern for advancing to the next segment
11:25:50 <nikos> ... it seemed like that might be a bit confusing
11:26:00 <nikos> ... so I prefer having separate controls
11:26:09 <nikos> ... I wanted to resolve either way
11:26:18 <nikos> krit: I don't think it was about having more or less properties
11:26:30 <nikos> ... but about control
11:27:38 <nikos> [Dirk draws example showing markers that are offset relative to the segment they are in]
11:28:53 <nikos> Tav: it's related to variable width stroke
11:30:04 <nikos> ... could add a length unit to variable width stroke so the position of the widths is dependent on the length of the segment
11:30:28 <nikos> [Brian draws example]
11:31:41 <nikos> ed: is there anything to deal with short segments that might not fit the author defined sequence of markers?
11:31:49 <nikos> ... e.g. I want those markers if the segment is > than some distance
11:32:00 <nikos> heycam: nothing in the spec at the moment to allow that
11:32:12 <nikos> ... similar to stroke-dashadjustment that I want to talk about later
11:32:25 <nikos> ... not exactly the same but you might want to disable dashing based on length
11:33:12 <nikos> heycam: I have a feeling that marker pattern where you're going by length than by segments is generally more useful
11:33:31 <nikos> ... you wouldn't come across that problem there although the whole length of the path may come in to play
11:33:49 <nikos> krit: one of the issues with marker-pattern was that you can have multiple layers of markers defined
11:34:14 <nikos> heycam: in my proposal at the moment you can only have one marker-pattern
11:34:51 <nikos> krit: how do you differ between each in the shorthand?
11:35:31 <nikos> heycam: it's defined (you'll have to look at the spec)
11:36:40 <nikos> [discussion on how the shorthands work]
11:37:42 <nikos> krit: if we don't make marker-pattern part of the short hand then there's no problem
11:39:43 <nikos> krit: shorthand must reset all marker properties but it's not necessary for marker to set marker-pattern
11:40:20 <heycam> thread http://lists.w3.org/Archives/Public/www-svg/2012Nov/0023.html
11:41:14 <nikos> heycam: so the specific issue of whether marker-segment is useful as a separate property. What do you think?
11:41:38 <nikos> Tav: I'd get rid of it and use a segment reference in marker-pattern
11:41:49 <nikos> birtles: Tab thinks adding a new type is no problem
11:43:34 <nikos> Cameron's example: 0.5 seg url(#diamond) -20px url(#dot) 40px url(#dot) -20px 0.5seg
11:45:38 <nikos> [Discussion on various syntax options]
11:46:06 <nikos> heycam: is it possible to reuse fr somehow?
11:47:12 <nikos> ... no, it's probably a bit different
11:47:17 <nikos> ... but shouldn't be a problem to add a new unit
11:48:13 <nikos> heycam: do you want to make a single property, or is the offset more the thing you want to solve?
11:48:19 <nikos> krit: the offset
11:48:42 <nikos> ... would be ok with only having one track for marker-pattern
11:48:46 <nikos> heycam: that's how the spec is currently
11:49:03 <nikos> ... maybe we could wait to see how it's solved for variable width stroke and then try to bring that across to marker-pattern
11:49:27 <nikos> ... the example seems a bit complex for the simple case
11:49:45 <nikos> birtles: calc would simplify it
11:50:36 <nikos> krit: at some point I think I argued for the same syntax for marker-segment and marker-pattern. Then you wouldn't need the segment unit. marker-segment would define a pattern but per segment
11:50:56 <nikos> ... you could then use percentages and pixels to define offsets
11:51:18 <nikos> heycam: we have the same thing with stroke-dashadjustment where you can choose between repeating dashes over the whole length of the path or per segment
11:51:48 <nikos> ... might be a bit far removed, but it's as similar problem
11:52:28 <nikos> ... would be good if we could have a consistent way of selecting path or segment based control for all three cases (marker, variable width stroke, dasharray)
11:53:15 <nikos> pdr: marker-mid when you point to a marker with position, it doesn't seem like that's used here
11:53:32 <nikos> heycam: position is new. You can put marker elements as children of a path
11:53:51 <nikos> pdr: marker-mid pointing to a marker with position of -50%... would this be the same as what you're proposing for marker-segment?
11:54:01 <nikos> krit: you'd always end up with one segment with no marker
11:54:12 <nikos> heycam: you'd have to extend marker-mid to take a pattern
11:55:20 <nikos> krit: why not go with marker-pattern first and then marker-segment later?
11:55:25 <nikos> heycam: we could
11:55:34 <nikos> ... let's see how we solve things for variable width stroke
11:57:54 <nikos> heycam: so do people thing we should forget marker-segment for now?
11:58:02 <nikos> ed: I would suggest going with only one to begin with
11:58:12 <nikos> Tav: I'd put marker-segment in marker-pattern
11:58:18 <nikos> heycam: we can do that
11:58:26 <nikos> ... it's compatible
11:58:36 <nikos> ... do you think relative values for marker-pattern?
11:58:46 <nikos> Tav: I think you want to align dasharray with markers
11:59:20 <nikos> birtles: for variable width stroke it's absolute. It makes sense for variable width stroke to do it this way. There's a potential inconsistency there
12:00:38 <nikos> ... variable width stroke doesn't have the seg unit so it's different
12:00:45 <nikos> birtles: but don't want to have subtle inconsistencies
12:00:55 <nikos> ... maybe we need to revisit variable width stroke syntax tomorrow
12:01:31 <nikos> heycam: how about we say we'll drop marker-segment and leave marker-pattern as is at the moment pending other discussions
12:02:06 <nikos> RESOLUTION: drop marker-segment in favour of marker-pattern
12:02:31 <nikos> Topic: Removing marker knockouts
12:02:45 <nikos> heycam: I had this grand idea of removing parts of the stroke around where markers are placed
12:03:17 <nikos> heycam: I was trying to find a good way of specifying the shape that you'd remove
12:03:27 <nikos> ... the classic metro map example
12:03:44 <nikos> Tav: important for arrow heads
12:04:11 <nikos> heycam: what I tried to do was not have another marker definition of a shape to remove from the stroke
12:05:51 <nikos> nikos: could you do a multi pass thing where you use the markers as a mask when drawing the path?
12:07:22 <nikos> [discussion on problems that might pop up with this technique]
12:07:48 <nikos> heycam: I don't really want a solution where you have to split up rendering of the path to ensure overlaps work
12:09:24 <nikos> pdr: you can achieve this at the moment using two paths can't you ?
12:10:14 <nikos> ... you have one path that defines the path. Where you want cut outs you place a marker. You use that as a mask when re-drawing
12:12:21 <nikos> [Tav draws arrowhead example]
12:13:05 <nikos> Tav: you have a viewport on the marker and you define a cutout as a path so the cutout can be any shape
12:13:39 <nikos> heycam: we discussed this before. One of the issues, when you have a clip path, is you need to invert that shape and union it with all the other shapes
12:13:43 <nikos> ... would be ok with a mask
12:13:55 <nikos> ... would be nice if you didn't have to define anything extra on the marker
12:14:07 <nikos> ... but this solution is more general
12:14:15 <nikos> pdr: what happens if there's a hole in the marker?
12:14:32 <nikos> Tav: it's up to you to add that hole to the clip or not
12:16:10 <nikos> ... for the subway case, the cutout is the center of the circle
12:19:23 <nikos> [discussion of the result of applying the clip to a curved/warped path]
12:19:35 <nikos> Tav: I think my suggestion fits 95% of the cases
12:20:02 <nikos> ... but if you want the cut of the path to be a particular angle then it may fail
12:22:17 <nikos> pdr: someone on irc was having issues drawing junctions on circuit markers. Seems like it's a related problem
12:22:34 <nikos> ed: so for the removal part, do we agree we want that functionality?
12:22:43 <nikos> Tav: I'd like my proposal
12:23:02 <stakagi> stakagi has joined #svg
12:23:06 <nikos> heycam: I'm happy for my stuff to be removed from the spec
12:23:14 <nikos> krit: for overlapping path segments are we ok with having artifacts?
12:23:24 <nikos> Tav: seems like a minor case
12:23:32 <nikos> krit: I think users would care
12:24:19 <ed> s/we want that functionality?/on that?
12:26:00 <nikos> Tav: most important case for us is start and end markers, but it would be good for others too
12:26:09 <nikos> heycam: if we could solve the subway map problem that would be good
12:26:55 <nikos> ACTION: Tav to write up proposal for clipping sections of path around markers
12:26:55 <trackbot> Created ACTION-3615 - Write up proposal for clipping sections of path around markers [on Tavmjong Bah - due 2014-04-15].
12:29:00 <Tav> Tav has joined #svg
12:29:28 <nikos> Topic:  'stroke-dashcorner' and 'stroke-dashadjust'
12:30:47 <nikos> heycam: a long time ago we discussed adjusting stroke-dasharrays so that
12:30:55 <nikos> ... 1) you could ensure dashes happen at corner of paths
12:31:16 <nikos> ... 2) control repetition so you could have an even number and not end in the middle of the dash pattern
12:31:40 <nikos> ... I added  'stroke-dashcorner' and 'stroke-dashadjust' to the spec
12:31:58 <nikos> ... stroke-dashcorner controls whether to put a dash at every corner of the path and what the size of that dash is
12:32:22 <nikos> heycam: it only makes sense for paths where the corners are meaningful. So probably doesn't make much sense for curves
12:33:13 <nikos> krit: Andreas had the requirement that you want stroke on corners and where lines meet
12:34:03 <nikos> heycam: my thing is on every corner, doesn't take into account the angle of the corner
12:35:24 <nikos> krit: for the curves with smooth transition (t) you probably don't want a dash
12:36:31 <nikos> https://svgwg.org/svg2-draft/painting.html#StrokeDashing
12:37:09 <nikos> ed: are dashes between the corners distributed?
12:37:13 <nikos> heycam: that's the other property that controls that
12:37:28 <nikos> ... when you have corner dashes you do the dash-array only between the corner dashes
12:38:13 <nikos> ed: I think we have a resolution to allow radius on corners, what happens there?
12:38:40 <nikos> heycam: for rounded rects you don't want corner dash at the edge of each arc, you want it throughout arc
12:38:51 <nikos> ed: or maybe you don't want a corner dash at all
12:39:37 <nikos> krit: how do you implement it ?
12:39:58 <nikos> heycam: if you can't modify the code that does dashing, you may have to expand the dasharray out and work it out
12:40:12 <nikos> krit: you can't rely on the graphic library
12:40:19 <nikos> pdr: Skia doesn't offer this today
12:40:32 <nikos> heycam: you can give an arbitrary length dash array so you can work it out yourself
12:41:52 <nikos> ... there is similarity with this and the segment stuff we were talking about before
12:42:44 <nikos> heycam: the other property is stroke-dashadjust
12:43:09 <nikos> ... and that's for doing adaptive dashing or adjusting repetitive dashes so it fits in the space as you want
12:43:17 <nikos> [shows examples]
12:43:51 <nikos> heycam: you can use this property to say either, make dashes and gaps shorter to just fit in, or longer and just fit in
12:44:00 <nikos> ... and also whether it applies to only the dashes or the gaps
12:44:05 <nikos> ... might be too much control?
12:44:11 <nikos> ... but that's how we discussed it last time
12:44:21 <nikos> Tav: it would be easiest to just do both
12:44:30 <nikos> heycam: don't think it's that hard in any case
12:45:06 <nikos> ... works well in conjunction with stroke-dashcorner where you don't want a little bit before the corner
12:45:54 <nikos> krit: in illustrator we adjust the dasharray for each segment