SVG Working Group Teleconference -- 08 Apr 2014

<trackbot> Date: 08 April 2014

<krit> ScribeNick: krit

heycam: [presentation about his proposal for new SVG DOM]
... ...want to improve SVG DOM... secuirty bugs in old DMO
... no one likes it
... new features are harder to add... especially looking forward to a new API

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

heycam: should a new API be consistent with SVG DOM or HTML?
... that is why I thought about new API
... more HTML like API without breaking content
... but didn't really work out
... eg SVGAnimatedLength stuff
... svg.width = something would be great
... but there is no way we can still keep the SVGAnimated object on there
... and have numbers as argument at the same time
... 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
... to opt in to new SVG DOM should be known at element creatiion
... NS would be a way to indicate new elements
... SVG NS would get old API
... no NS (HTML NS) will get new API
... you can create elements without NS suffix
... that puts element sin the HTML NS by default
... null NS allows elements in XML NS
... I hope that the fact that there are 2 API versions of an element is not too big of a problem to implementations
... we don't want to have inline SVG stuff to get suddenly a new API
... we need to tag them differently
... so that old content doesn't end up with new API while the JS code still addresses the old API.
... the tricky part is the img element
... "image" creates the <img> element, not <image>

krit: what about createElement("image")

heycam: hm, need to think about it
... while <image> in HTML actually creates <img>, creareElement("image") might not
... [does checking and confirms]

krit: what about innerHTML = "<image>"?

heycam: maybe we need another flag

ed: authors might not want to have 2 different image elements

heycam: probably
... haven;t looked into the APIs
... so not sure if the images are compatible

krit: both elements would need the attributes of the other

heycam: the proposal rests on having two APIs where one gets dropped over time
... don't think it is possible to drop SVG API completely

pdr: what about having both APIs on the same element

heycam: that is how I started
... element.x = .... [see problem above]
... for inline SVG we would need a new root <graphics> to get the new API
... this would create a new viewport
... all attributes need to be lowercase
... same for elements
... maybe even do dashed limitingConeAngle -> limiting-cone-angle
... some element need to be unified like script, style, a
... still needs to be defined what happens when you mix SVG and HTML-SVG elements
... [explains some API specific things that do not allow to simply combine old and new SVG DOM]
... [all in his document]

ed: you can not check equality of SVGAnimated objects in Blink anymore

pdr: we broke that intently

<ed> rect.x === rect.x will return false in blink

krit: some one from Google said that on the mailing list www-svg

birtles: yes, and bz was clearly against that
... we can not do it

pdr: we made it and it makes the implementation much simpler

heycam: going HTML allows us to avoid duplication from many things that didn't move up to Element
... like tabIndex
... all SVGAnimated* types get basic types like SVGBoolean to boolean SVGString to DOMString
... int -> long
... [explaining different lists in his proposal]

ed: did you measure SVG DOM usage? particularly the pathSeg DOM

heycam: I plan to do it

pdr: we coudldn't in Blink. We wanted to do the measuring
... why do you keep normalized paths around? IIRC just Presto ever implemented normalized path with synchronization?

heycam: yeah, we might get rid of it.

pdr: not sure why we need normalized paths at all
... canvas doesn't have it

krit: canvas paths are not that difficult as SVG paths

heycam: [goes on with aspectratio]
... 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

<birtles> ScribeNick: birtles

pdr: I like this proposal

heycam: One of my concerns is the duplication of code and the burden it would be
... I hope it wouldn't be too much
... same functionality but a different API

pdr: yes, that is a concern
... what about making SVG2 be a clean break altogether?
... why not remove backwards compatibility altogether when you have <graphics> as top-level?

krit: that would lead to two implementations

pdr: but in the future we would hope to remove the old implementation

heycam: I think this proposal does that

pdr: this maintains features like SMIL for example

krit: in general I like this idea of SVG inheriting from HTMLElement
... I think this is worthwhile but I see the problems with <image> and <script> and moving elements around
... what I would propose therefore is, we have a resolution to move more attributes to presentation attributes
... having that, many of the features of the SVG DOM are not necessary therefore
... if you have a look at Tab's proposal for a CSSOM

http://www.xanthir.com/b4UD0

scribe: this defines a new object model
... when we go ahead with this, the CSSOM, to then come up with another SVG API is not the way to go
... we should focus on this API which affects all elements, not just SVG
... at some point this proposal will go ahead, perhaps with some changes

heycam: I agree that it wouldn't be good if we had two ways of assigning length properties
... 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
... specifically value objects don't exist yet
... so it will be a while before this is possible
... so I think we should make sure the SVG2 DOM can use these value objects when they are available

krit: the mapping right.
... so we want to deprecate the SVG DOM at some point anyway so we should focus on the HTML DOM stuff

heycam: looking at a concrete example
... if we have rectElement.x = "10px"; (with my proposal)
... and you can also do rectElement.x + 20
... if we were to support value objects then we would also allow rectElement.x = 10px

krit: I think we don't actually want that but just want strings
... I think that's a problem with Tab's proposal
... so I don't think you can just use 10px, I think you'd pass it "10px"

heycam: what part of the CSSOM API do you want to use then?
... are you saying that you should just be able to do rectElement.style.x = "10px"
... if we didn't promote all these attributes to properties, is there still something from the CSSOM we could use to represent this?
... e.g. rectElement.x = CSS.px(10)

krit: we should work together with the CSSWG in the FXTF to come up with an API for everything not just SVG
... it seems strange to come up with all these IDLs that are SVG specific

birtles: isn't the same for HTML elements e.g. HTMLImageElement.src

krit: I want to limit the number of IDLs we have

heycam: why?

krit: why do you want to flood the platform with IDLs

heycam: are you worried about introducing new globals?

krit: just in general

heycam: surely you want rectElement.x?

krit: I don't think rect.x vs rect.style.x is a big deal
... it's strange to me that you have rect.width but div.style.width
... why not have the same API for both?

heycam: but in HTML you have inputElement.value not inputElement.style.value?

krit: yes, you cannot promote all attributes to style properties but we should promote the ones we can
... ones like width etc. can be promoted

heycam: I was never 100% comfortable with what we had

krit: why?

heycam: the fact that all of the proposals had downsides with them
... either we had to introduce new properties names that match CSS but not the attribute names
... or we add properties named 'x' etc. that are very generic and only apply to SVG elements

krit: a lot of properties can be applied to all elements even though they don't make sense

pdr: krit, your point seems to be a nice-to-have
... holding up the proposal on the CSSOM is dangerous

krit: yes, especially since the current CSSOM is not implemented in that manner

pdr: I think tying this to CSSOM seems more risky

krit: if we want to look at real examples, the SVG DOM is already rarely used
... so why introduce something that people might or might not use
... why work on something we're going to deprecate?

heycam: but one reason no-one uses it today is that it's so hard to use
... if you can do rectelement.x people might actually use it

davve: what about all the SVG tutorials on the Web that document the old DOM?
... it's really hard to change that

heycam: if we can rely on measurements for when we can drop the old stuff
... 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
... Alex Russell said, why not tie new features to the new DOM as a kind of carrot to move people over

krit: I just think we can avoid this burden but not introducing a new API

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
... might help people avoid old SVG tutorials

ed: if we do that we should change the SVG MIME type
... 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)

heycam: a new MIME type / media type is an additional barrier to get things happenning
... since it requires new server configurations etc. and people can never get that right
... I'm not sure how much advantage there is to renaming the whole language to help with the mindset of "this is something new"
... I think it will be easier to convince implementors to get on board if it's not something completely new

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

heycam: that won't work for standalone XML documents (due to attribute case sensitivity) but it will for HTML

krit: don't underestimate the point of authoring tools, not only Illustrator and Inkscape, but other tools export SVG

pdr: fair enough, I think a drastic overhaul is probably difficult

krit: there are a lot of non-graphical technical products that export SVG
... but there are no tools that support SVG animations and SVG DOM so we could get rid of those
... for the same reasons I don't see tools using the new SVG DOM
... I don't think people will make use of the power of the new API

heycam: I'm guessing differently that the simplicity of the new API will encourage people to use it
... do people want to script SVG at all? I think yes, they do
... and if they do, then I think they will want to use this

krit: but I think people use libraries to do the scripting and those libraries can use the existing SVG DOM

birtles:

nikos: if you do this, maybe people won't feel the need to use libraries

ed: I think most people will use libraries anyway

krit: and you'll never get it right for everyone

heycam: Tav, what do you think about the markup changes?

krit: I think Inkscape doesn't need to care about the markup changes too much--just the top-level document and attribute case sensitivity
... I think the proposal needs to be more downward compatible with regards to case sensitivity

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

ed: but it will still render the text inside

heycam: yes it will

krit: I'm not convinced that there is enough need for this to justify defining a new API

heycam: are you saying that authors should use setAttribute/getAttribute to access these things?

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

<ed> (15min break)

<heycam> old and new API: https://pastebin.mozilla.org/4776291

<heycam> for setting transform

<nikos> scribenick: nikos

heycam: Ideal outcome for me is go ahead and do my proposal
... outcome I really want is whether we are going to do something like this and I should continue work or not

pdr: CSSOM will happen
... Dirk's point about this change not benefiting users so much, getting behind CSSOM would benefit users more

krit: I think your proposal is very sane for CSS as well as SVG
... I think it would be good if we could base CSSOM definition on it

heycam: Dirk's future relies on promoting properties to presentation attributes
... it seems like support for that is waning

ed: we have a topic later on about width and height as presentation attributes

heycam: one thing is, I think now is the best time to do something about this
... if we wait too much longer then our opportunity will be missed
... which is why I'd like to know now whether to push forward on it
... if we assume that we promote a bunch of things, you might be right that .style.something might be the preferred way of interacting
... but the simplicity of .x is alluring to me

pdr: why can't we do that as well? .x is great

heycam: don't think DIrk wants to
... if we have .style we shouldn't have .x

krit: the biggest issue is that you cannot easily compare right?

heycam: yes

krit: can you do .x = 3 + 4 or += something?

heycam: you can make it work using a valueOf method

krit: it would create an object first?

heycam: this is if it is an object already

krit: === doesn't work for blink right?

pdr: we broke it yes

krit: chrome or developer channel?

ed: dev channel for sure, not sure about chrome

krit: that was the biggest issue with your proposal

heycam: it violates javascript semantics so not possible anywhere

krit: can we upgrade property to also support taking a dom string?

heycam: limitations are: you can't do equality checking. equals and not don't work
... I don't think that's acceptable as it will confuse people
... 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
... so therefore we don't need the proposal because you don't need to opt in to the new DOM
... if we do the namespace thing without hooking in a new API we have lost the opportunity
... I guess I disagree about the importance of the string accessors?

pdr: is the reason people don't use this today that it's hard to find?

heycam: I think so but it's hard to prove

pdr: I use get and setAttribute because I don't want to have to remember the other methods

krit: we are stuck in this situation where each of us wants a part of the proposal

ed: what do we agree on?

pdr: everyone agrees on namespace bit? inheriting from HTML.

heycam: you may have to do the root element name change for that

pdr: we looked at doing a parser change
... it broke things
... we tried parsing svg with the html parser and there were a few things that didn't work

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

pdr: so you can parse a stand alone document with the xml parser in the html namespace

heycam: yes
... the bits that Dirk doesn't want to do are the things that I think we only have the opportunity to do now
... I don't what information is going to help us make the decisions?
... will anyone use the new APIs?

pdr: I think only a small number will
... the number of handwritten svg files is small
... think that d3 etc are mostly what is used but don't know how to prove that

birtles: is one thing to do the namespace change but add .x and .y later?

heycam: why would people use the new things if there's no extra functionality available?
... Dirk you were asking if we can do a survey?

krit: don't think it would be that reliable

heycam: I'm not sure how to move forward

ed: you want the whole thing and not just small parts that we can agree on?

heycam: we might not be able to add parts later
... I'm not convinced that .style.something is preferred to .something
... I think I would prefer .something

pdr: I agree but don't know why an alias wouldn't work there

birtles: would that be forwards compatible with CSSOM?

krit: needs approval from CSS WG but they don't know what the CSSOM is going to look like

<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

<heycam> and not (float or DOMString)

<heycam> since we don't really know how other types are going to be handled on elt.style.x

heycam: what individual bits does everyone agree on?

ed: inheriting from HTML element and namespace sounds fine to me

pdr: dropping crazy path API

birtles: I generally like the graphics element

heycam: I feel like the graphics element is a necessary evil for the opt in api

krit: graphics can mean a lot of things and in the future you may not just have canvas or svg

heycam: do people think it's useful to get feedback from users via svg developers list?

pdr: don't think it will be accurate enough

krit: you'll only get participation from those who want the API

heycam: how can we decide on whether the new API stuff should be in there?
... what info do we need

pdr: how do we prove more people will use it?

heycam: tie in new features to the new DOM only
... although that doesn't mean they will have to use .x. could still use setAttribute

ed: using the version attribute for switching makes sense for authoring tools

heycam: don't think you can change the API based on the attribute
... when you do createElement the attribute isn't present yet

ed: you couldn't change the namespace based on version attribute but you could select the API

heycam: I don't want to have to check in every method

pdr: write a polyfill. If usage gets high enough then switch

krit: web animations provides a polyfill and no one uses it

birtles: we have a few people using it. Have had good feedback

pdr: polyfill used for shadow DOM is getting usage

birtles: I agree that polyfill isn't enough of a measure

nikos: might not be time to take the measurements with a polyfill without missing the opportunity to make the change

ed: what about if we provide a javascript compat library?

krit: how would they include the script?
... it's an interesting idea

pdr: we've thrown around the idea of implementing svg with javascript
... rendering would come from backing objects
... it would be faster

heycam: I like the idea in general of writing a polyfill for the new DOM API
... probably wouldn't give us the information needed to decide if we go on with the changes
... I can write the polyfill

pdr: could be useful for pointing the CSSOM people in the right direction
... but it seems like a lot of work

heycam: might not be too much work
... not sure how to do the namespace stuff. It's just about the API
... including the script opts in

pdr: could use custom elements
... but couldn't be a root element
... since script exists in both namespaces maybe you could

ed: so outcome is to write a polyfill?

heycam: I guess so

pdr: other outcome was the four things we agreed on

heycam: in terms of moving forward, I still feel gated by deciding on what to do with the DOM
... if we're undecided we are basically making the decision not to go forward because the opportunity is limited

birtles: we can introduce new API later easily enough. Say .x but only if we drop the old implementation

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?
... the default decision is to not do it

krit: why not write the polyfill then we make a decision at the next F2F

<scribe> ACTION: Cameron to write polyfill for his DOM proposal before next F2F (with enough time for WG to experiment) [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action01]

<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].

buffered-rendering and will-change

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/buffered_rendering_expansion

buffered-rendering

birtles: at TPAC we discussed buffered-rendering and having an extra value for buffered-rendering
... I think the idea was that the author can control whether content should be re-rasterised as it's being transformed
... in any case, that was before will-change had been discussed
... and it's my understanding that will-change covers most of those use cases
... 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

heycam: but it's only a hint?

birtles: yes. buffered-rendering was too
... I think perhaps we don't need buffered-rendering after all. will-change is probably enough
... Takagi-san prepared some performance test cases

<stakagi> http://svg2.mbsrv.net/devinfo/devstd/panZoom/

birtles: there are some notes about the performance observed in each case
... one thing to note is that for the panning case, FF recently got faster
... it's my view that many of these cases can be optimised in the browser without extra hints
... some will-change would help

heycam: will-change is good for the first few frames before heuristics kick in

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?
... I wonder if we always want smooth performance

pdr: there's memory concerns with buffered-rendering and will-change
... I can imagine there are cases where you don't want to use the memory

heycam: I'm assuming heuristics in the browser will ensure you don't eat up all the memory

birtles: it's a hint so the browser can ignore

pdr: it can be jarring if you optimise for speed while transforming then switch to pixel perfect. Have had user complaints

birtles: there is a proposal. This is prior to will-change but has updated
... the proposal was to add an additional keyword to buffered-rendering
... currently we're wondering if it's needed or if will-change is sufficient
... I would further propose that we don't need buffered-rendering at all in SVG

heycam: if there's a use case for preferring dropping frames over smooth transitions then it could be useful

pdr: does any browser other than Chrome implement buffered-rendering?

ed: Presto did
... was for set top boxes that have low spec hardware. Was successful but was in environments where content was controlled

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

birtles: I think that's fine. Takagi-san was pointing out there are some parallels with the SVG integration spec
... where we had different modes
... if we were to keep buffered-rendering there would be some alignment that would be possible
... could use a different strategy for buffering depending on the content mode
... but if we don't have buffered-rendering then it doesn't matter

heycam: you might be able to detect a lot of that automatically in the implementation
... pdr said before he implemented buffered-rendering on Blink specifically for the image element

ed: does will-change make a difference on SVG content now?

pdr: I'd be supportive of changing buffered-rendering to will-change

RESOLUTION: will drop buffered-rendering in favour of will-change

krit: will-change is not purely a hint

heycam: if you say will-change=transform you have to create a stacking context

Lunch break

<ed> ACTION: brian to replace buffered-rendering with will-change in svg2 [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action02]

<trackbot> Created ACTION-3612 - Replace buffered-rendering with will-change in svg2 [on Brian Birtles - due 2014-04-15].

z-index

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
... is anyone planning on doing the work to put it in the spec?
... if not perhaps I can

pdr: is there any relation to will-change?

heycam: in the sense that they are both related to stacking contexts
... we already have lots of things in SVG 2 that will create stacking contexts
... blending, transforms, masking, etc

davve: what's the relation of css stacking contexts to svg stacking contexts?

heycam: in svg content it's going to be the same as css

cabanier: 2d transforms don't create stacking context in svg because we do many transforms

heycam: we probably need to have an overall description of the rendering
... if z-index isn't on anyone elses plate I'll have a crack before the deadline
... the concept of a stacking context can come from the css spec can't it ?
... the overall process will be the same as CSS, but with specific SVG rendering steps

<scribe> ACTION: Cameron to add z-index text to SVG 2 specification before feature cut off date [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action03]

<trackbot> Created ACTION-3613 - Add z-index text to svg 2 specification before feature cut off date [on Cameron McCormack - due 2014-04-15].

making width/height presentation attributes on foreignObject

davve: this came up when I did patches for Blink
... I have some examples

<davve> http://jsfiddle.net/MmkYj/

<davve> http://jsfiddle.net/MmkYj/1/

one uses height attribute and one uses property

davve: in FF they are equivalent, but not in Blink
... svg and foreignObject are the two elements that interact with the CSS box model

krit: I would like to avoid having width and height presentation attributes on some elements and not on others

davve: don't think it's that odd. It makes sense for things that interface with the box model

ed: I don't think accepting for foreignObject would preclude us from adding it for other elements later

heycam: what about iframe and canvas?

krit: for iframe can you override the width and height attribute with stylesheet?

davve: not sure

pdr: yes in Chrome

<pdr> Iframe example: http://jsfiddle.net/MmkYj/2/

<pdr> Updated with style overriding: http://jsfiddle.net/MmkYj/3

pdr: so this would apply for svg as well

ed: there might be an existing resolution for this

heycam: so in svg foreignObject and iframe will have x and y. Should they be presentation attributes as well?

ed: according to previous resolution, yes

heycam: I'm happy to just do it for width and height
... the previous resolution was about mapping many to presentation attributes but we never followed through

ed: I think we should do it for foreignObject

heycam: I think it doesn't make sense to make rect width and height presentation attributes without the broader set being done
... we can easily do width and height for foreignObject and iframe and do the others later if we want

RESOLUTION: make width and height attributes on foreignObject element presentation attributes

<scribe> ACTION: Erik to edit SVG 2 to make width and height presentation attributes on foreignObject [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action04]

<trackbot> Created ACTION-3614 - Edit svg 2 to make width and height presentation attributes on foreignobject [on Erik Dahlström - due 2014-04-15].

Resolving concerns with marker-segment and marker-pattern

heycam: marker-start, mid and end are the existing marker properties
... I added my proposal for two additional properties
... marker-segment lets you place markers in the middle of each segment of the path
... 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
... there was some concern from Tab and Dirk that we might not need to have both marker-pattern and marker-segment
... there should be a way to do marker-segment with marker-pattern
... some of the solutions were to have instructions in the pattern pattern for advancing to the next segment
... it seemed like that might be a bit confusing
... so I prefer having separate controls
... I wanted to resolve either way

krit: I don't think it was about having more or less properties
... but about control

[Dirk draws example showing markers that are offset relative to the segment they are in]

Tav: it's related to variable width stroke
... could add a length unit to variable width stroke so the position of the widths is dependent on the length of the segment

[Brian draws example]

ed: is there anything to deal with short segments that might not fit the author defined sequence of markers?
... e.g. I want those markers if the segment is > than some distance

heycam: nothing in the spec at the moment to allow that
... similar to stroke-dashadjustment that I want to talk about later
... not exactly the same but you might want to disable dashing based on length
... I have a feeling that marker pattern where you're going by length than by segments is generally more useful
... you wouldn't come across that problem there although the whole length of the path may come in to play

krit: one of the issues with marker-pattern was that you can have multiple layers of markers defined

heycam: in my proposal at the moment you can only have one marker-pattern

krit: how do you differ between each in the shorthand?

heycam: it's defined (you'll have to look at the spec)

[discussion on how the shorthands work]

krit: if we don't make marker-pattern part of the short hand then there's no problem
... shorthand must reset all marker properties but it's not necessary for marker to set marker-pattern

<heycam> thread http://lists.w3.org/Archives/Public/www-svg/2012Nov/0023.html

heycam: so the specific issue of whether marker-segment is useful as a separate property. What do you think?

Tav: I'd get rid of it and use a segment reference in marker-pattern

birtles: Tab thinks adding a new type is no problem

Cameron's example: 0.5 seg url(#diamond) -20px url(#dot) 40px url(#dot) -20px 0.5seg

[Discussion on various syntax options]

heycam: is it possible to reuse fr somehow?
... no, it's probably a bit different
... but shouldn't be a problem to add a new unit
... do you want to make a single property, or is the offset more the thing you want to solve?

krit: the offset
... would be ok with only having one track for marker-pattern

heycam: that's how the spec is currently
... maybe we could wait to see how it's solved for variable width stroke and then try to bring that across to marker-pattern
... the example seems a bit complex for the simple case

birtles: calc would simplify it

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
... you could then use percentages and pixels to define offsets

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
... might be a bit far removed, but it's as similar problem
... 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)

pdr: marker-mid when you point to a marker with position, it doesn't seem like that's used here

heycam: position is new. You can put marker elements as children of a path

pdr: marker-mid pointing to a marker with position of -50%... would this be the same as what you're proposing for marker-segment?

krit: you'd always end up with one segment with no marker

heycam: you'd have to extend marker-mid to take a pattern

krit: why not go with marker-pattern first and then marker-segment later?

heycam: we could
... let's see how we solve things for variable width stroke
... so do people thing we should forget marker-segment for now?

ed: I would suggest going with only one to begin with

Tav: I'd put marker-segment in marker-pattern

heycam: we can do that
... it's compatible
... do you think relative values for marker-pattern?

Tav: I think you want to align dasharray with markers

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
... variable width stroke doesn't have the seg unit so it's different
... but don't want to have subtle inconsistencies
... maybe we need to revisit variable width stroke syntax tomorrow

heycam: how about we say we'll drop marker-segment and leave marker-pattern as is at the moment pending other discussions

RESOLUTION: drop marker-segment in favour of marker-pattern

Removing marker knockouts

heycam: I had this grand idea of removing parts of the stroke around where markers are placed
... I was trying to find a good way of specifying the shape that you'd remove
... the classic metro map example

Tav: important for arrow heads

heycam: what I tried to do was not have another marker definition of a shape to remove from the stroke

nikos: could you do a multi pass thing where you use the markers as a mask when drawing the path?

[discussion on problems that might pop up with this technique]

heycam: I don't really want a solution where you have to split up rendering of the path to ensure overlaps work

pdr: you can achieve this at the moment using two paths can't you ?
... 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

[Tav draws arrowhead example]

Tav: you have a viewport on the marker and you define a cutout as a path so the cutout can be any shape

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
... would be ok with a mask
... would be nice if you didn't have to define anything extra on the marker
... but this solution is more general

pdr: what happens if there's a hole in the marker?

Tav: it's up to you to add that hole to the clip or not
... for the subway case, the cutout is the center of the circle

[discussion of the result of applying the clip to a curved/warped path]

Tav: I think my suggestion fits 95% of the cases
... but if you want the cut of the path to be a particular angle then it may fail

pdr: someone on irc was having issues drawing junctions on circuit markers. Seems like it's a related problem

ed: so for the removal part, do we agree on that?

Tav: I'd like my proposal

heycam: I'm happy for my stuff to be removed from the spec

krit: for overlapping path segments are we ok with having artifacts?

Tav: seems like a minor case

krit: I think users would care

Tav: most important case for us is start and end markers, but it would be good for others too

heycam: if we could solve the subway map problem that would be good

<scribe> ACTION: Tav to write up proposal for clipping sections of path around markers [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action05]

<trackbot> Created ACTION-3615 - Write up proposal for clipping sections of path around markers [on Tavmjong Bah - due 2014-04-15].

'stroke-dashcorner' and 'stroke-dashadjust'

heycam: a long time ago we discussed adjusting stroke-dasharrays so that
... 1) you could ensure dashes happen at corner of paths
... 2) control repetition so you could have an even number and not end in the middle of the dash pattern
... I added 'stroke-dashcorner' and 'stroke-dashadjust' to the spec
... stroke-dashcorner controls whether to put a dash at every corner of the path and what the size of that dash is
... it only makes sense for paths where the corners are meaningful. So probably doesn't make much sense for curves

krit: Andreas had the requirement that you want stroke on corners and where lines meet

heycam: my thing is on every corner, doesn't take into account the angle of the corner

krit: for the curves with smooth transition (t) you probably don't want a dash

https://svgwg.org/svg2-draft/painting.html#StrokeDashing

ed: are dashes between the corners distributed?

heycam: that's the other property that controls that
... when you have corner dashes you do the dash-array only between the corner dashes

ed: I think we have a resolution to allow radius on corners, what happens there?

heycam: for rounded rects you don't want corner dash at the edge of each arc, you want it throughout arc

ed: or maybe you don't want a corner dash at all

krit: how do you implement it ?

heycam: if you can't modify the code that does dashing, you may have to expand the dasharray out and work it out

krit: you can't rely on the graphic library

pdr: Skia doesn't offer this today

heycam: you can give an arbitrary length dash array so you can work it out yourself
... there is similarity with this and the segment stuff we were talking about before
... the other property is stroke-dashadjust
... and that's for doing adaptive dashing or adjusting repetitive dashes so it fits in the space as you want

[shows examples]

heycam: you can use this property to say either, make dashes and gaps shorter to just fit in, or longer and just fit in
... and also whether it applies to only the dashes or the gaps
... might be too much control?
... but that's how we discussed it last time

Tav: it would be easiest to just do both

heycam: don't think it's that hard in any case
... works well in conjunction with stroke-dashcorner where you don't want a little bit before the corner

krit: in illustrator we adjust the dasharray for each segment

ed: so what feedback did you want?

heycam: do we still want these features?
... and opinions on the issues in the spec

Tav: I like this stuff, but I'm not sure you're meeting the maps use case of nice intersections

heycam: I neglected to mention that when you turn dash corners on, dasharray gets repeated per segment rather than along the whole path
... so is it ok to leave this stuff in the spec?
... Tav do you want to solve the T intersection problem?

Tav: not sure how we would solve it

pdr: could you have something like a distribute property where you say dashes are two units long but you have wiggle room of 2 to make it look nice?

heycam: you'd have to know where the intersections are
... I'll leave these in the spec for the moment and if you have opinions on the issues let me know or we can discuss in a telcon

stroke bounding box

krit: masking is the first spec that makes use of certain keywords such as view box and stroke bounding box
... we have an issue
... should we use the real bounding box or an approximation?
... looked at canvas code and it looks like it's much faster to do an abstraction
... so I'd like to get an approximation for a number of reasons
... is it ok if I come up with some spec text that uses an approximation?

Tav: i'd like to avoid bounding box changing on walking dash

pdr: there are use cases where it would be useful to use the exact bound
... if you're drawing the dashes yourself

krit: I'm talking about the masking spec where you want something reliable
... we wouldn't take dashing into account

heycam: think it's much more likely that you'd want to ignore the dash or you don't care about the dash

pdr: does this approximation take into account markers?

krit: don't think we would

heycam: think about it in terms of getBBox and the keywords we added there
... when you say marker=true it means include all of the fill and stroke and markers

pdr: what would you do for variable width stroke?

cabanier: take the widest width?

krit: we use object bounding box so control points of beziers are not what's used
... approximation is on the stroke, not on the shape
... so would people be unhappy if we use an approximation?

heycam: don't think so

krit: would you be unhappy if I put the definition in masking and not reference SVG 2?

heycam: think it should go in SVG 2

krit: can't reference SVG 2 unless it's CR

heycam: think that was being relaxed

krit: I'll put it in the masking spec and we'll see how SVG 2 goes

<ed> ed: I think this should be in svg2

RESOLUTION: Will use an approximate bounding box for stroke-box keyword

<scribe> ACTION: Dirk to write specification text for approximate bounding box that is used with stroke-box keyword [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action06]

<trackbot> Created ACTION-3616 - Write specification text for approximate bounding box that is used with stroke-box keyword [on Dirk Schulze - due 2014-04-15].

<ed> (15min break)

BREAK

<Tav> http://tavmjong.free.fr/blog/?p=472

<ed> scribeNick: ed

Canvas Path2D update

dirk: in karlsbad we argued that it's expensive to keep path data live and synchronized
... one proposal was to use Path2D from canvas
... the graphic engine does optimization behind the scenes
... idea was to get this normalized data back
... and to use this for animations or whatever
... Path evolved to Path2D
... is now designed to be a library that is readable, but not writable
... the use-case the SVG WG hoped for is not there

rik: you could turn the data back into a string if you wanted

dirk: some graphic libs experiment with doing everything on the gpu
... so you'd jjust have a reference to the path on the gpu

rik: is chrome working on this?

pdr: the way is just to send the data over
... don't know when the normailzation happens, not sure it matches the format you're asking for

heycam: the svg spec says how the noramlization works there
... but not how many segments you get and such

dirk: the Path2D is just an opaque pointer to the path, you cannot inspect/read it

rik: we could add a Path2D accessor on the svgpathelement

dirk: path2D has no way of asking for its bbox
... chrome and firefox do have accessor for that

pdr: when you end up drawing you cannot read it back
... so getting a bbox isn't going to be quite "real"

dirk: for the Path2D yes, but implementation-wise it's not the case
... I'm not sure at this point how we could make use of it in svg

ed: the use-case I see is assigning the Path2D to a path element
... e.g for boolean operations

rik: right, unioning circles and such
... I think it's still useful in svg

dirk: if you assign Path2D to a path element you might not be able to get a bbox from the path element

rik: right now path2d is mostly for caching the path
... for canvas
... all graphic libs let you read the path data back
... so if we want to allow for getting the bbox it's possible

pdr: why do we want this?

rik: we want this for svg, doesn't make sense to have a separate api for svg and another for canvas
... path2d has nothing to do with canvas really
... we want to be able to use it everywhere

pdr: not clear why pathlength and bbox isn't available on the path2d interface

heycam: you could cache the rectangle while the path is being created
... something about boolean path operations, part of the reason for not exposing path data and bbox
... that you'd implement the intersections and such on the gpu
... so if we avoid exposing the path data then we can do that

pdr: we know companies spent a lot of money on developing this

dirk: if we don't flatten we cannot export it

rik: think we do strokinig on the gpu

heycam: when you say there are ananlytic solutions, what do you mean?

pdr: intersection of quadratics
... the math behind it was quite hard

<krit> ScribeNick: krit

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014

F2F

ed: when do we want to meet?

krit: when is conference?

heycam: august 27 - 30
... wed - sat

krit: 2 days is not enough for us?
... what about splitting the meeting?

cabanier: not sur eif I go to the conference

heycam: can not assume that everyone is going to the conference
... we could do it the weekend before

birtles: not sure if I am coming

Tav: I go to both

nikos: going to both as well

Tav: have preference going before

cabanier: me too

heycam: I too because TPAC is close

krit: would be in favor for before as well
... sat, mon, tue?

heycam: ok

ed: cabanier: yeah

nikos: where do we have the meeting?
... london? Winchestor?

krit: didn't someone check for university?

heycam: we should ask

ed: would be in favor for London

heycam: we try Mozilla office first

ed: 23-26th it will be without sunday

RESOLUTION: 23-26th August next F2F

<scribe> ACTION: heycam to check office space for London F2F [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action07]

<trackbot> Created ACTION-3617 - Check office space for london f2f [on Cameron McCormack - due 2014-04-15].

version number

Tav: we decided to get rid of version numbers
... but for authoring tools it might be useful to have it

krit: you can always do that

Tav: might think will continue to use it

krit: we have data-* attributes in HTML which can be used for scripting. Can you use that?

Tav: yeah
... there are documents from elsewhere we want to target

krit: there are tools removing unnecessary data

Tav: yes

krit: want to say you can not rely on the version number

Tav: that is true

heycam: what are HTML authoring tools doing for HTML5 and incrementally added features?
... lets say we have mesh gradients in SVG
... how do authoring tools handling that?

Tav: you may want to have a backup for that

heycam: do HTML tools have similar things?

Tav: they probably have something like that

krit: usually they don't use features that are not widely apployed

cabanier: we have tools that create browser specific things

krit: you have things like modernizer that check for that

cabanier: the question was about authoring tools

heycam: so they get along without versioning, so we might as well

Tav: as an example paint-order... Iwant to make sure that older browsers can use it, but inkscape can read it back

heycam: there is so much boiler plate and i would like to avoid that

pdr: there is so much history about that

Tav: ppl are using SVG
... want to convert for the future

heycam: don't think that data-* attributes are meant for that

pdr: what about base-rprofile, xlink NS and so on... still required?

heycam: base-profile was removed
... you have modeled specs... so what would be the version number be?

ed: how do you detect what you want to read back from the preserved data?

Tav: when people write the code, we read it back in

heycam: as an author wants to export with a set of features that can be displayed

pdr: does someone do something different with versioning? Illustrator? InkScape?

Tav: krit: no

cabanier: we might for output

krit: not for input

heycam: there is so many stuff that is new and changes of the time
... so it is per feature rather then version attribute

Tav: batik lets you enable certain things based on the version string

ed: so are we adding it again?

general no

Symbol with refX/refY

Tav: Andreas asked for that
... it is nice to position symbols based on a bottom center and so on
... so you like to have some point
... markers have that already
... symbols are essential like markers
... chris mentioned that he positions at center center
... and positions realtive to viewport
... and Andreas asks if we can have something like refX/refY for that

birtles: you can do it with transform-origin as well

Tav: it would be nice not to worry about sliding things over
... could be stored in the symbol

heycam: markers and symbol loosk symbol

krit don't think so

heycam: what are the differences

krit: symbol is basically an SVG element which is not visible

pdr: you mean like defs?

<Tav> http://tavmjong.free.fr/SVG/SYMBOL/symbol.html

krit: no, don't think so, it has width, height and creates a viewport like svg

pdr: can't you implement everything with symbol?

heycam: it is a little bit more complicated
... what if we allow markers to be reference able by use?

Tav: markers are different because they set width and height

krit: symbols do as well

Tav: when you look how use interacts with symbol, then this is different than a marker does with path

heycam: it would be nice to measure if people use symbol

krit: Illustrator uses symbol

pdr: do not have use counters in Blink for symbol

krit: to understand it, so refX and refY is used as some kind of offset/delta to the position it gets placed to?

pdr: do you use symbol always with use?

Tav: yes

pdr: why doesn't g with translate in the symbol doesn't work?

Tav: they clip by defautl

ed: you can specify overflow=visible

heycam: makes sense to avoid duplication but having this kind of feature is useful

Tav: for maps it is useful

ed: would be ok with it

davve: what about using netagvie x and y on symbol?

heycam: this would move it even more in the clipping region

stakagi: I always use defs on symbols
... and overflow visible
... for non scaling feature, the symbol is not scaled

heycam: it feels more natural to have overflow visible and the content is centered around center

krit: maybe you want to have it clipped

pdr: icon thing

RESOLUTION: Add refX/refY to symbol element

<scribe> ACTION: Tav to add refX/refY to symbol [recorded in http://www.w3.org/2014/04/08-svg-minutes.html#action08]

<trackbot> Created ACTION-3618 - Add refx/refy to symbol [on Tavmjong Bah - due 2014-04-15].

svg implementation status

pdr: there is a danger that things that are documented are out of date
... otherwise blink-dev
... but maybe you want to search in the list
... there are things that are added or taken away

ed: what about using shepherd system to indicate implementation status?

krit: it is basically relying on manual tests run by users and then the results get displayed in the spec
... webkit has WebExposed flag for new features in WebKit

pdr: heycam we have one bug for SVG2

heycam: we do not have a status page

pdr: I think we can get links for the status
... I would not like to create another source for authors

[general discussions about features so far in SVG2]

trackbot, make minutes

<trackbot> Sorry, krit, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

- DRAFT -

SVG Working Group Teleconference

08 Apr 2014

Attendees

Contents