- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 8 Apr 2014 15:46:06 +0000
- To: SVG public list <www-svg@w3.org>, SVG WG <public-svg-wg@w3.org>
Here are the minutes of the SVG WG F2F meeting for the second day in Leipzig.
http://www.w3.org/2014/04/08-svg-minutes.html
Greetings,
Dirk
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
08 Apr 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/04/08-svg-irc
Attendees
Present
Regrets
Chair
ed
Scribe
krit, birtles, nikos, ed
Contents
* [3]Topics
1. [4]buffered-rendering and will-change
2. [5]buffered-rendering
3. [6]z-index
4. [7]making width/height presentation attributes on
foreignObject
5. [8]Resolving concerns with marker-segment and
marker-pattern
6. [9]Removing marker knockouts
7. [10]'stroke-dashcorner' and 'stroke-dashadjust'
8. [11]stroke bounding box
9. [12]Canvas Path2D update
10. [13]F2F
11. [14]version number
12. [15]Symbol with refX/refY
13. [16]svg implementation status
* [17]Summary of Action Items
__________________________________________________________
<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> [18]http://dev.w3.org/SVG/proposals/improving-svg-dom/
[18] 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
[19]http://www.xanthir.com/b4UD0
[19] 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:
[20]https://pastebin.mozilla.org/4776291
[20] 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
[21]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>
[22]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/buffered_
rendering_expansion
[22] 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> [23]http://svg2.mbsrv.net/devinfo/devstd/panZoom/
[23] 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
[24]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
[25]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> [26]http://jsfiddle.net/MmkYj/
[26] http://jsfiddle.net/MmkYj/
<davve> [27]http://jsfiddle.net/MmkYj/1/
[27] 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: [28]http://jsfiddle.net/MmkYj/2/
[28] http://jsfiddle.net/MmkYj/2/
<pdr> Updated with style overriding:
[29]http://jsfiddle.net/MmkYj/3
[29] 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
[30]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
[31]http://lists.w3.org/Archives/Public/www-svg/2012Nov/0023.ht
ml
[31] 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
[32]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
[33]https://svgwg.org/svg2-draft/painting.html#StrokeDashing
[33] 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
[34]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> [35]http://tavmjong.free.fr/blog/?p=472
[35] 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>
[36]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014
[36] 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
[37]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> [38]http://tavmjong.free.fr/SVG/SYMBOL/symbol.html
[38] 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
<stakagi> <defs><circle cx="0" cy="0" r="10" id="poi1"/></defs>
<use href="#poi1" x="X" y="Y"/>
pdr: icon thing
RESOLUTION: Add refX/refY to symbol element
<scribe> ACTION: Tav to add refX/refY to symbol [recorded in
[39]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
<[40]http://www.w3.org/2005/06/tracker/irc> for help.
[40] http://www.w3.org/2005/06/tracker/irc%3E
Summary of Action Items
[NEW] ACTION: brian to replace buffered-rendering with
will-change in svg2 [recorded in
[41]http://www.w3.org/2014/04/08-svg-minutes.html#action02]
[NEW] ACTION: Cameron to add z-index text to SVG 2
specification before feature cut off date [recorded in
[42]http://www.w3.org/2014/04/08-svg-minutes.html#action03]
[NEW] ACTION: Cameron to write polyfill for his DOM proposal
before next F2F (with enough time for WG to experiment)
[recorded in
[43]http://www.w3.org/2014/04/08-svg-minutes.html#action01]
[NEW] ACTION: Dirk to write specification text for approximate
bounding box that is used with stroke-box keyword [recorded in
[44]http://www.w3.org/2014/04/08-svg-minutes.html#action06]
[NEW] ACTION: Erik to edit SVG 2 to make width and height
presentation attributes on foreignObject [recorded in
[45]http://www.w3.org/2014/04/08-svg-minutes.html#action04]
[NEW] ACTION: heycam to check office space for London F2F
[recorded in
[46]http://www.w3.org/2014/04/08-svg-minutes.html#action07]
[NEW] ACTION: Tav to add refX/refY to symbol [recorded in
[47]http://www.w3.org/2014/04/08-svg-minutes.html#action08]
[NEW] ACTION: Tav to write up proposal for clipping sections of
path around markers [recorded in
[48]http://www.w3.org/2014/04/08-svg-minutes.html#action05]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [49]scribe.perl version
1.138 ([50]CVS log)
$Date: 2014-04-08 15:43:44 $
__________________________________________________________
[49] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[50] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [51]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/NS/API./
Succeeded: s/NS/API/
Succeeded: s/content/API/
Succeeded: s/SVG DOM usage?/SVG DOM usage? particularly the pathSeg DOM/
Succeeded: s/we want that functionality?/on that?/
Succeeded: s/visible?/visible/
Succeeded: s/heycam/krit/
Succeeded: s/refs/defs/
Succeeded: s/allow/specify/
Succeeded: s/refs/defs/
Found ScribeNick: krit
Found ScribeNick: birtles
Found ScribeNick: nikos
Found ScribeNick: ed
Found ScribeNick: krit
Inferring Scribes: krit, birtles, nikos, ed
Scribes: krit, birtles, nikos, ed
ScribeNicks: krit, birtles, nikos, ed
WARNING: No "Present: ... " found!
Possibly Present: Tav birtles cabanier davve dirk ed heycam https joined
krit left nikos pdr rik scribenick shepazu stakagi svg tbah trackbot
You can indicate people for the Present list like this:
<dbooth> Present: dbooth jonathan mary
<dbooth> Present+ amy
Found Date: 08 Apr 2014
Guessing minutes URL: [52]http://www.w3.org/2014/04/08-svg-minutes.html
People with action items: brian cameron dirk erik heycam tav
[52] http://www.w3.org/2014/04/08-svg-minutes.html
[End of [53]scribe.perl diagnostic output]
[53] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 8 April 2014 15:46:51 UTC