- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 14 Feb 2015 12:33:23 +1100
- To: www-svg@w3.org
http://www.w3.org/2015/02/12-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG WG Sydney F2F 2015, day 2
12 Feb 2015
[2]Agenda
[2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
See also: [3]IRC log
[3] http://www.w3.org/2015/02/12-svg-irc
Attendees
Present
+61.2.933.6.aaaa, Doug_Schepers
Regrets
Chair
ed
Scribe
Cameron, Nikos, tav, BogdanBrinza
Contents
* [4]Topics
1. [5]superpath
2. [6]optimizing for machine generation
3. [7]Miter line join
4. [8]auto closing path closing
5. [9]Text on a shape
6. [10]x/y/width/height on <symbol>
7. [11]svg2 issues
8. [12]Text bounding box
9. [13]Open SVG 2 issues
10. [14]svg2 issues in the color chapter
11. [15]Remove above two interfaces.
12. [16]Painting chapter issues
13. [17]Issue: stroke-dashcorner doesn't work well for
rounded rects
14. [18]SVG Markers
15. [19]Timeline for SVG2 and modules
16. [20]SVG2 WD publication
17. [21]Next F2F meetings
18. [22]Smoothing in mesh gradients
19. [23]outermost svg element definition
20. [24]motion path
* [25]Summary of Action Items
__________________________________________________________
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
superpath
<cyril> [26]http://moissinac.github.io/SuperPath/
[26] http://moissinac.github.io/SuperPath/
cyril: my colleague has been working on this superpath
prototype
... the idea is that in many graphics, you need to share paths
or pieces of paths among bigger paths
... for example you need to share them if you have regions in a
map, share them sometimes in direct order, sometimes in reverse
order
... so the idea is to reuse a piece of a path in another path
... benefits in reducing file size, but also more semantically
correct content. not duplicating information when not needed.
... viewers could do better antialiasing on that path, it's
only present once
... it could be rendered seamless
... last time we talked about it, I exposed the fact that we
wanted to have a path with an ID attribute, then another path
referencing that initial path
... after some investigation we realised that it's very hard to
extract a piece of a path and make it a separate path alone
... because what command would you put at the front
... the geometry of the path often depends on the point before
or the point after
... so we changed our idea here ab it
... nikos suggested instead of having the reusable path a
separate path, define it while using it in the first place
... so you have the full context
... you have the previous point if you want to reuse it in
reverse order, or the next point if you are reusing in direct
order
Tav: that's clear, but not sure if it's necessary
cyril: you can see some examples on this page
... don't pay much attention to the syntax yet
... my colleague is happy to change the syntax, it's just a
prototype
<cyril> d="M 90,190 220,90 330,150 (p1|L330,150 280,230
L330,310 280,400)L120,375 z"
cyril: this is an example of syntax; the path you will be
reusing is between parens
... the ID is the thing after the open paren, and it ends with
the bar
... when you want to reuse it
<cyril> d="M 500,385 390,460 280,400!p1|L450,50 565,81 z"
cyril: that's a reverse use
... and I think the prototype uses # for forward use
<cyril>
[27]http://moissinac.github.io/SuperPath/Samples/piece01withExt
ernalScript.svg
[27] http://moissinac.github.io/SuperPath/Samples/piece01withExternalScript.svg
cyril: there's a more complex example with a map
<cyril>
[28]http://moissinac.github.io/SuperPath/Samples/bretagneSuperP
ath.svg
[28] http://moissinac.github.io/SuperPath/Samples/bretagneSuperPath.svg
cyril: this is a region of france with three subregions
... the blue path for the sea
... as I said, the syntax is probably not the best
... but the big change is the path is defined inline
... when it's first used
... to have the full context
... what is preserved is the geometry
... what he does is any path used is converted to a path that
has relative commands, so it's easier to reverse
... then the reversed relative commands are applied
... the next step for us is to fix the syntax, then have it run
on many examples
... JC is writing a program to analyse existing content and
replace duplicated paths with this
... when the content has been authored and the paths don't
exactly match, e.g. with slightly different floating point
values
Tav: in inkscape you can output in relative or absolute
... I want to talk about auto closing a path
... with a rounded segment
... so you'd leave out the first point, then put the first
point in the path
nikos: it wasn't to do with smooth curve final segments was it?
Tav: it helps with positioning the marker
heycam: so that's a mid marker
Tav: and makes the orientation expected
cyril: what does the group think of defining the reusable path
name in the path data?
krit: how do we handle compatibility?
cyril: for the path that defines the reusable path, it you
could skip the ID then it could render
... the path that reuses it you couldn't really do anything
Tav: now you define a country, as one path, and a region in
that would be the path that you share?
cyril: the country would be a single path element, but the d
attribute would be divided into many subpaths, each having an
ID for example
... then you define a region with an external border with the
country, when you define the path data for that region you
reuse the subpath defines in the country border
Tav: I find that conceptually more complicated than defining
each subpath separately
nikos: you could define all the subpaths in defs
... and then you only need to reference it because you want to
fill it
cyril: if you don't care that the path segment between the
previous point and the first point of the reused path, then
doing what you suggest is good
ed: can you get a continuous curve with reused subpaths?
cyril: yes
ed: it's a similar problem to the autoclosing command
... also wondering with this proposed syntax, is it possible to
have nested reusable subpaths?
cyril: I haven't tested that, I guess the prototype doesn't
accept that
... but in theory it could work
... one of the difficult things in the current impl is that the
path is converted to relative, and if the path you are defining
is at the end of a big path, and the big path uses another
path, you need to resolve that one first
... there's a possibiltiy you need to process the whole file
before doing anything
... there's also the possibility of doing loops
Tav: don't we have some rules for dealing with that already
ed: yes for ID cycles
cyril: so that would need to be specified
heycam: bit uneasy about defining the names in the path data
... seems odd
birtles: if I add the get-path-data-as-floats API, how would
this work?
cyril: it would return the expanded path
... animation is also an open issue
... I don't know how it can be implemented in browsers
... polyfilling is easy
heycam: we wouldn't do the seamless rendering first, that would
need lots of graphics library rewriting
cyril: I don't think I need a resolution or an action, but if
anyone is willing to help/test
... e.g. prototype in inkscape
Tav: I'd like to but have enough other prototypes to work on
for now
<scribe> ACTION: jean-claude to further develop the protoype
including with animation support [recorded in
[29]http://www.w3.org/2015/02/12-svg-minutes.html#action01]
<trackbot> Created ACTION-3734 - Further develop the protoype
including with animation support [on Jean-Claude Moissinac -
due 2015-02-19].
optimizing for machine generation
jet: I wanted to talk to the group about some implementation
experience that I've had
... recently and in the past
... at Mozilla we recently implemented a flash player in JS
... and just deployed it in nightly Firefox builds
... previously I worked at Adobe on the flash player
... before that at Macromedia on the flash authoring tool
... at Macromedia, Adobe was building their LiveMotion
authoring tool
... I wanted to share with the group some of why flash got the
ubiquity it did and Adobe's SVG didn't
... it wasn't so much that the technology was better, but that
we did things at Macromedia so that it would defeat SVG at the
time
... I think there's an opportunity to get past that after all
this years
... and move interactive animations on the web in a way that
SVG could not at the time
... the things that made it get over that hump at the time,
weren't the things you'd expect
... Adobe's authoring tool was good, had a reputation for
quality software, plugin worked in many places
... but when we would evanglize Flash over SVG, we'd demo with
the worst browsers with SVG, and the best browser with Flash
... one company in particular the Flash developers went to at
the time was Disney
... experts in animation, decided to use Flash on the front
page of their site
... at the time, if you wanted to use animation you'd use
GIF89, and there wasn't really anything else
... this is the era of 9600 baud modems and 386 computers
... today, the hardware is better, but similar network issues
... the things that made Flash successful was bug compatibility
across browsers, and performance characteristics that were
consistent across browsers
... for example Flash had retained mode API, binary file format
... small, fast, compiled
... after a while, the workflow would be that you'd take the
authoring file format, .fla (which is a zip with xml resources,
not quite svg)
... what I'm getting at is that SVG is an excellent authoring
format, but a poor runtime format
... not because of XML vs binary is better or worse, but that
we're unable to offer the consistent runtime/rendering
experience because of what the format offers
... an example: coons patches, flash doesn't support that; nor
gradient meshes
... but you can build a gradient mesh in the authoring tool and
it spits out a bitmap under the covers
... there are things like that which make SVG very expressive,
but which on a phone rendering a coons patch for your logo is
less practical
... so what I'd like to get from the SVG group to see if
there's an appetite to fix that
... is there a way for the implementors here to think about
using SVG in a way that we can start with a subset that is
normative for a runtime implementation
... not enough that we'd say you have to implement a coons
patch for SVG, but that you could render a subset of SVG and
have bug compatibility if possible
krit: it sounds a bit like the Basic SVG Profile
jet: SVG is one facet of it
... vector art and animation, and interactivity
... the part that made Flash also be ubiquitous is that its OM
was very contained and strict
... you wouldn't expect that the HTML hosting your Flash file
could mess with the Flash OM
... so maybe a basic profile of SVG?
... today, we implemented flash in /canvas
... something similar to the React Canvas
... implementing flash in JS/canvas
... SVG is so rich and powerful that I think it's better suited
as an authoring format than a runtime one
... if we could design a subset that is a subset that has clear
DOM semantics
... that the runtime can then make decisions about rasterising
etc.
... that's the spiel, don't have concrete ideas
heycam: are you coming from the perspective of trying to
implement Flash in SVG, and the performance wasn't there?
jet: not all performance, but also different rendering model
... we also have an ad use case
... flash can bundle things up in a package neatly
ChrisL: sounds like you're asking for a package format
... which travels in one unit
... or can play without being unpacked
jet: yes, that's one way. maybe it is a zip container.
... there are things that made flash as a tagged binary file
format, in the order of use
... you know before you use an element that you would've pushed
it through the network
... the packaged file fromat like jar files, you have to get
the whole blob before you can start
cyril: the work I presented yesterday uses mp4 container rather
than zip
... which can be used for streaming
... to come back to the earlier statement, I agree that design
of Flash was very different
... authoring format, and publication format
... SVG is completely different in that the authoring format is
the publication format
... so the tradeoffs are different
... performance and compact model is not the same
... that's a benefit but also a problem for optimisation
... looking at converting cartoons to SVG, there are thousands
of ways of doing it
... so it's hard to optimise
... there are so many ways to do the same thing
jet: for an authoring format, that's great
... flash was an authoring tool before it was a runtime format
... the compile-to-runtime was an artifact of having to send
things over slow networks
... the answer I get to asking people why they're still writing
flash, games/ads/etc., is both (a) these issues and (b) tooling
... so this is a problem we could solve, if we agree that we
can start with a subset today that is available across all
implementations
Rossen: I heard you mention a few times offering a subset
... and also guaranteeing interop
... I think we can all agree on how to spec a subset
... I don't know about guaranteeing interop
... it's what we all try to do
... but how do you guarantee it?
jet: I think that opens us up to the same disadvantages
Rossen: here's one way to go
... if this is something that we expose a number of APIs to the
web platform, that you can implement SVG as one library, and
that library is circulated and used
... that's the only way I can see that it's interoperable
always
... going back for a second, you're mentioning a subset
... do you have an idea?
jet: I say subset just so it would be surmountable problem
... if we say basic shapes are required and then pixel perfect
requirements
... because that's a simple problem
ChrisL: last meeting we tried to decide "is a geometry
coordinate at the top/left of a pixel, or middle of a pixel"
... and we couldn't agree, because different graphics libraries
are different
... one reason Flash was successul was that there was one
implementation (that mattered)
... and that the implementation is basically the spec
jet: so we implemented Flash using JS/canvas
... that it was possible is somethign taht got me thinking
... if we can render it today, why couldn't we all do the same
thing? why can we not do it for a format other than swf?
... firefox is going to pre-ship with the JS flash
implementation, but it's not feasible to make all cartoon
authors have to ship this library
... couldn't we polyfill a format other than flash, perhaps a
subset of svg?
... I'd like to build on things already in the web platform
cyril: there is history to that. SVG Tiny 1.2 was that; an
attempt to make a subset of SVG that was more efficient for
mobile devices
krit: we could do that right now with specifications that
exist. you could use web components to make your own vector
format, if you have the right primitives
cyril: I doubt you'd have good performance there though
Rossen: I'm still thinking you're talking about two different
things here
... one is packaging, plus maybe additional step of
standardising extension API where a platform piece can be
delivered or hosted on CDNs and have lifetimes/updates and
implementations will download them periodically
... so that they become part of the native packaged platform
ChrisL: [tooling]
... the other reason I have Flash installed on my machine is
that I like to watch video
krit: content protection
jet: we're solving the video problems another way, I think
we'll get there
... the use cases are the ones I'd like to cover are ads, 2D
games
... the people who makes those games/ads in Flash, is that SVG
implementations are fragile
... can we make it so that it's less fragile across
implementaitons, by saying that there's a subset that has to be
normative across the board
Rossen: I think everything that we publish is normative
... in order to get interop you either have to converge on a
single implementation, or just pray
cyril: if you subset SVG, in some sense you don't have 10 ways
to do the same thing
... you can optimise that
Rossen: example?
krit: asm.js
cyril: how do you frame based animation in SVG?
Rossen: what is it today?
cyril: you can use display, visibility, opacity
... Brian just exposed yesterday all the challenges if you want
to optimise your animation
... there are several ways, will-change, transfromZ
Rossen: let's go back to SVG
... from the SVG spec, tell me what is exposed is ambiguous and
can be implemented in many ways
... if we're saying we're going to converge on one single
technology that covers the entire web platform, I don't think
this is the right forum
... I'd still like to figure out the problem for SVG
ChrisL: I'd like to see detail on what they find is fragile
roc: do people demand exact rasterisation consistency on all
targets? or are they more concerned about performance
consistency?
... or other things?
jet: it was consistency across targets
roc: rasterisation consistency?
jet: that, performance, ...
... we built a Flash renderer in JS, could this be a SVG
renderer
Rossen: what does versioning look like in this case?
... I think we are falling down to some basic software
engineering problems where the answer is either scaling down to
one implementation, or you pray
... there's always a first to market, and others following
... are you going to hold everything back so that nobody jumps
the gun and releases a feature?
... I think we build new features so that you have graceful
progression
... and that comes back to the single implementation
roc: are you implicitly saying that you find that canvas has
sufficient rastiersation consistency to satisfy these people,
and that builindg something on canvas would help these people?
cyril: I can't speak for Google, talking to the people who work
on swiffy, they said exactly that. they started with SVG, and
moved to canvas
roc: they're finding canvas more consistent then
... you could have authoring tools produce canvas and JS
... and compile down to that level
... if you do that I think everyone gets what they want
jet: there's something amiss there, then you have to implement
the playback engine
roc: you can customise that engine right down to exactly what
the ad needs
... you won't need most of the features that Shumway has
... I don't know how small we can make that, but I think for a
lot of ads we can make it pretty small
jet: is that something we could standardise?
roc: we wouldn't need to, which is why it'd be a great solution
... in standards, we could look at making canvas rendering
consistent
... as canvas is more focused than svg is
cyril: what's the scalability of canvas?
ChrisL: well it's immediate mode
roc: that's a problem that canvas-using apps already have
... there's a couple of pieces to solving that
... we have consensus on solving that; there's an event that
first when canvas needs to be re-rendered
... and an application listens for that event and rerender
... and we need a way for the app to size the backing store to
device pixels
... which is a renderedWidth/Height property on the canvas
jet: then maybe all we have missing is the packaging side
roc: you might be able to design your ad such that --- well you
have image assets etc.
... there have been several proposals for zip-like but
streamable bundles
... (you can make zip streamable if you format it correctly
iirc)
... I'm not sure why they didn't go anyway
... maybe the use cases weren't compelling enough?
... some people were trying to do it as a performance thing in
a single HTTP transaction
... but then SPDY came along
... so for speeding up website loading that solved it
... but for this problem of content traversing multiple
networks was not really thought of as a use case
... technically it's not a mysterious problem
cyril: you should look at the SVG streaming spec; it's still a
draft, but it might help you
heycam: marcos will know about packaging
roc: if we could re-use this new app packaging format that
might be a solution
cyril: my recollection is that it wasn't streamable
<Tav> [30]http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html
[30] http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html
Miter line join
<cyril> [31]https://github.com/w3ctag/packaging-on-the-web
[31] https://github.com/w3ctag/packaging-on-the-web
jet ^ (packaging)
Tav: people were asking for a different type of miter
... instead of clipping at a certain point, when you reach the
limit, you get a uniform clipping
ChrisL: the existing one is discontinuous
krit: in canvas, what do we do there?
... do we do the second one?
Tav: the guy from nvidia (not neil) said that half graphics
engines do it one way, half do the other
... the lower one is existing behaviour in some engines?
roc: we just use the underlying graphics libraries
... so I'm sure it would be different on different platforms
<krit>
[32]https://developer.mozilla.org/samples/canvas-tutorial/4_8_c
anvas_miterlimit.html
[32] https://developer.mozilla.org/samples/canvas-tutorial/4_8_canvas_miterlimit.html
krit: I think different platforms do align
Tav the proposal is to have a fourth (well, we have 'arcs')
Tav so if you're already doing something to implement arcs
(i.e. not solely relying on existing libraries), then
implementing this proposal is trivial
ChrisL: a new value would be good
Tav: I've played with the cairo line join code
... and doing this is trivial
krit: does it work cross platform? cairo uses CoreGraphics on
OS X.
roc: so the image rasteriser, not the other backends
<roc> cyril: in what way is
[33]http://w3ctag.github.io/packaging-on-the-web/#streamable-pa
ckage-format not streamable?
[33] http://w3ctag.github.io/packaging-on-the-web/#streamable-package-format
<roc> shepazu: can you hear us?
ed: the proposal is?
krit: a new value that has this behaviour
Rossen: are you proposing an interpolation function that goes
between these things?
<cyril> roc: it depends on the definition of streamable. My
definition includes timing/synchronization. This packaging
format is progressively processable, not streamable. Not
seekable for instance.
Tav: no just clip the miter rather than fall back to the other
point
<roc> ah
<roc> cyril: OK. When Jet was talking about the Flash format
being streamable, for the purposes of ad delivery, I think he
meant "progressively processable"
<cyril> roc: there are use cases for adaptive streaming of ads
as well
ChrisL: so you're using a line cap which never triggers
miter-limit
... the numerical value for miter-limit wouldn't affect it?
Tav: it would
ChrisL: you're looking for a line-join keyword?
<cyril> roc: mp4 being ubiquitous in all browser, I think it's
a candidate that shouldn't be dropped without investigation
<roc> cyril: maybe, but I think you can't have adaptive
streaming and a single inviolable package.
ChrisL: miter-clip
<cyril> cyril: still controlled/timed delivery of big packages
is interesting too
<cyril> roc: still controlled/timed delivery of big packages is
interesting too
RESOLUTION: We will add line-join:miter-clip in SVG 2.
<scribe> ACTION: Tav to add line-join:miter-clip to SVG 2.
[recorded in
[34]http://www.w3.org/2015/02/12-svg-minutes.html#action02]
<trackbot> Created ACTION-3735 - Add line-join:miter-clip to
svg 2. [on Tavmjong Bah - due 2015-02-19].
-- 15 min break --
auto closing path closing
<Tav>
[35]http://tavmjong.free.fr/SVG/AUTO_PATH_CLOSING/index.html
[35] http://tavmjong.free.fr/SVG/AUTO_PATH_CLOSING/index.html
Tav: there are problems when you have a curved segment at the
begin/end of a path
... in that in order to close the path you have to have a
0-length z
... that causes problems with how markers are rendered
... there are inconsistencies with how browsers handle them
... if you paste that link in 2 different browsers, compare the
rendering, you'll see that they're inconsistent
... due to rounding errors, if you use relative path segments
by the time you get to the end your last point may not match up
with the first point
... would be nice to have a way that specifies they should
match up
... some possible solutions on how to do that
... one possibility is new commands
... the Z command is essentially an L command, where the point
is the first point
... so you could extend that, but I don't think it's good to
extend Z_a or whatever
... you could use a non-numerical parameter
... which means "use the first point"
... you could use a Z to indicate that you should replace a
missing point with the first point in the path
... so either the second or third solution would be a way of
doing it
heycam: would you accept this special symbol anywhere in the
path?
Tav: maybe but it wouldn't be as useful
heycam: makes me wonder if you would want to go back to any
point, not just the first point
Tav: it reminds me of a different problem, if 2 points are on
top of each other, say a handle is on top of the start, how is
direction determined for markers?
heycam: I think we covered the marker direction issue a couple
of weeks ago
cyril: the whole problem comes from rounding errors, right?
Tav: yes
nikos: even ignoring precision issues, having a Z command that
closes a bezier is useful anyway
... you could expand the meaning of Z to mean "close a path and
create a segment if it needs to"
heycam: that's the third option
nikos: what if in an arc command you omitted the flag values
and put a z there
heycam: I think just make that invalid
RESOLUTION: We will allow a Z to fill in any final coordinate
pairs missing from the previous command.
<scribe> ACTION: Tav to add the new Z behaviour. [recorded in
[36]http://www.w3.org/2015/02/12-svg-minutes.html#action03]
<trackbot> Created ACTION-3736 - Add the new z behaviour. [on
Tavmjong Bah - due 2015-02-20].
<Tav>
[37]http://tavmjong.free.fr/SVG/TEXT_ON_A_SHAPE/index.html
[37] http://tavmjong.free.fr/SVG/TEXT_ON_A_SHAPE/index.html
Text on a shape
Tav: inkscape originally drew ellipses/circles with paths
... some people noticed they could no longer put text along a
circle
... because it's a common thing to do, it was proposed that we
allow text on shapes
... in inkscape this is easy to do, because at the time we
disply we've already converted the shape to a path
... the major issues have already been solved, such as the
start point on a circle, because we had to define that using
markers
heycam: and dashing
Tav: there are a couple of challenges
... if you put text on a circle it might make sense to use a
negative startOffset
... how do you put text on the other side
... we could have a flag to say which way the text goes
heycam: sounds fine
... what about the flag?
ChrisL: what would the names be? inside/outside? left/right?
Tav: left/right
ChrisL: as long as you have a good definition
roc: clockwise/anticlockwise?
... mapping people use "true left" of a river, left when moving
downstream
Tav: how about negative startOffset?
heycam: negative startOffset is already allowed, but we
probably don't define what happens with closed subpaths
RESOLUTION: We will allow <textPath> to reference shapes and a
flag to say which side of the path the text is put.
<scribe> ACTION: Tav to update textPath for text on a shape.
[recorded in
[38]http://www.w3.org/2015/02/12-svg-minutes.html#action04]
<trackbot> Created ACTION-3737 - Update textpath for text on a
shape. [on Tavmjong Bah - due 2015-02-20].
x/y/width/height on <symbol>
Tav: this is an issue I came across
<Tav> [39]http://tavmjong.free.fr/SVG/viewport.svg
[39] http://tavmjong.free.fr/SVG/viewport.svg
Tav: Opera Presto and Inkscape you see no red boxes
ChrisL: and red is bad right?
Tav: it means x/y/width/height are being interpreted when the
spec says they shouldn't be
cyril: Firefox/Chrome behave the same
<ChrisL> IE11 is correct
Tav: Batik does it wrong, and probably everyone assumed Batik
does it right
... so I don't think following those attributes is useful
... I think the spec should be followed in this case
roc: I suspect those attributes got cloned onto the <svg> and
they're being interpreted in place
... so maybe we should add them for consistency with
referencing <svg>?
ChrisL: is it fully defined what it means, if we removed that
rule from the spec?
... given that nested <svg>s already allow this
Rossen: I don't want to change
ChrisL: the reason I changed was that we added x/y to <svg>,
and now referencing it is different from referencing <symbol>
roc: if the issue is what I think it is, I think it would be
easy to fix. but consistency between <svg> and <symbol> would
be good.
krit: does <symbol> have viewBox?
Tav: yes
krit: then I'm starting to agree with roc
<shepazu> +1 to roc's proposal... we should do the same for
<marker>, etc.
ed: if you have width/height on the <use> it will override the
ones on the cloned tree
Rossen: and that makes sense
roc: this is not an argument for making symbol behave
differently though
Tav: it's only used by a <use> element
ed: I think you'll still get the same behaviour if you default
width/height on <symbol> to 100%
... so if we did that I'd be fine with it
krit: what happens now that x/y are properties?
Rossen: what is the main use case here that would be broken if
we don't do this?
Tav: if someone has incorrectly put x/y/width/height
... some browsers have ignored it, others have not
Rossen: what would be the expected behaviour or use that comes
out from tooling?
... what would be more natual for tooling to output for this?
... when you're using <use>, I would expect tooling would
probably define x/y/width/height on the <use>
heycam: so I agree that x/y on <symbol> is not useful
... but the argument would be consistency with referencing
<svg>
krit: it's an edge case, I don't think content would be relying
on this behaviour
Rossen: what would be the most natural thing from the author's
point of view?
... in either case the code change would be straightfowrard
... I want to know what the effect for users would be
krit: <symbol width height> and <use x y> without width/height,
that would be useful to avoid duplicating width/height all the
time
... I think there is an argument to simplify the code
... by treating these the same
... the user could live with specifying width/height on <use>
dmitry: it looks more to be a bug in the spec rather than the
browsers
... as an author, I would expect x/y/width/height to be
available on <symbol>
... it's not a big deal
ChrisL: the underlying model when this was designed is that
<use> positions a new thing, and that referenced thing has its
centre of its coord system would pin it
... it does mean sometimes you need to display all four
quadrants
... and there are some issues with clipping
... some people would rather specify the middle rather than 0,0
Tav: well we now have refX/refY on symbol, to match marker
Rossen: what would users want/say
roc: I don't think users are necessarily going to use this
... do we change the spec to make things things more consistent
<pdr__> cyril asked me to confirm that swiffy has indeed
switched to canvas
ed: send a mail to www-svg asking for feedback, wait two weeks,
decide then?
Rossen: sounds reasonable
<scribe> ACTION: Tav to mail www-svg about the symbol
x/y/width/height issue and report back in two weeks [recorded
in [40]http://www.w3.org/2015/02/12-svg-minutes.html#action05]
<trackbot> Created ACTION-3738 - Mail www-svg about the symbol
x/y/width/height issue and report back in two weeks [on
Tavmjong Bah - due 2015-02-20].
<ed> scribeNick: ed
svg2 issues
<heycam> [41]https://svgwg.org/svg2-draft/layout.html
[41] https://svgwg.org/svg2-draft/layout.html
heycam: this is the chapter for x,y,cx,cy and so on properties
<ChrisL> botie, tell cyril he was mean to zakim
<botie> ChrisL: excuse me?
heycam: issue 1: need to check the initial values for all of
them
krit: r has different initial values for gradients and circle
... propose to make it 'auto'
... to make it work out the correct value depending on element
heycam: is this done with UA styles?
TabAtkins: auto is more for when auto is going to affect the
results
... if you're just doing based on the element you should use UA
styleaheets
krit: next issue, rx and ry should use zero as initial value
... something that's not there is fx and fy
... on radial gradient
... the descirption is complicated, by default uses values from
cx and cy...
... we could set them to auto and make them do the same thing
heycam: it's a strange feature
krit: it doesn't define specialcasing for fx,fy
heycam: we did decide to make fx and fy properties, right?
krit: yes
heycam: did we only do this because we did the other gradient
attributes?
krit: I think so
heycam: we should focus on the basic shapes
... don't do this for the gradient elements, even with cx, cy
on gradients
ChrisL: but you can put presentation attributes on any element
ed: can't we just make them presentation attributes on
particular elements?
heycam: if it's easier since presentation attributes work on
any element (?)
krit: in webkit we didn't turn cx cy to properties on
radialgradient
heycam: i'd prefer not making them presattrs in this case
RESOLUTION: don't make the layout properties into presentation
attributes on the gradient elements
heycam: issue 2, what to do about x and y on text elements?
Tav: we also have them on tspan right?
heycam: yes
... the issue is that they're list of values
... either we could allow list of values in the property, but
only use the first value
... or the attribute has some special processing
... one option is to not make x y presentation attributes on
any of the text elements
krit: I like that, or alternatively make xy presattr on text,
but map them to other properties
... don't quite like the second idea though
heycam: we already decided that the x,y lists are bad due to
font issues
... so don't think we should allow the second one
krit: another way might be to apply the xy property to text
elements, but also apply the positoning fromthe xy attributes
also
... that would allow positioning from css
heycam: that'd be a little bit confusing
... but might be the best solution
Tav: so discourage use of the x,y,dx,dy?
heycam: I think we should try it out
krit: ok, so spec that and await feedback from implementations?
Tav: ok
RESOLUTION: add a new keyword value to the x and y properties
that means use-the-list-of-lengths in the attributes, and set
that with the UA stylesheet
<scribe> ACTION: krit to add a new keyword value to the x and y
properties that means use-the-list-of-lengths in the
attributes, and set that with the UA stylesheet and add a note
to say that it's still an open issue [recorded in
[42]http://www.w3.org/2015/02/12-svg-minutes.html#action06]
<trackbot> Created ACTION-3739 - Add a new keyword value to the
x and y properties that means use-the-list-of-lengths in the
attributes, and set that with the ua stylesheet and add a note
to say that it's still an open issue [on Dirk Schulze - due
2015-02-20].
<heycam> [43]https://svgwg.org/svg2-draft/coords.html
[43] https://svgwg.org/svg2-draft/coords.html
heycam: next chapter, coordinates
... issue 2, are there any more up-to-date defs for sizing? (i
haven't checked)
... prob needs some closer review by somebody
... someone should take an action to look at this?
<scribe> ACTION: krit to review the svg2 coordinate chapter
[recorded in
[44]http://www.w3.org/2015/02/12-svg-minutes.html#action07]
<trackbot> Created ACTION-3740 - Review the svg2 coordinate
chapter [on Dirk Schulze - due 2015-02-20].
heycam: issue 9, about pAR
<heycam>
[45]https://svgwg.org/svg2-draft/coords.html#PreserveAspectRati
oAttribute
[45] https://svgwg.org/svg2-draft/coords.html#PreserveAspectRatioAttribute
heycam: do ppl use 'defer' or can we drop it?
ChrisL: is this somehting new?
heycam: I think it's from the original 1.0 spec
krit: don't think webkit implements this
heycam: we have some tests for defer, but doesn't mean that ppl
are using it
... would be happy to try removing it
ed: I'm fine with removing it
heycam: firefox at least supports parsing it
Tav: inkscape doesn't support it
krit: webkit parses it but ignores it
ed: so does that imply that we should allow it but say in the
spec that it must be ignored?
heycam: would prefer just to remove it (don't think there's
much content using it)
krit: think we should parse it but ignore it
heycam: I'd prefer removing it
RESOLUTION: make defer do nothing (and investigate removing it
later)
<scribe> ACTION: krit to make defer be ignored in pAR [recorded
in [46]http://www.w3.org/2015/02/12-svg-minutes.html#action08]
<trackbot> Created ACTION-3741 - Make defer be ignored in par
[on Dirk Schulze - due 2015-02-20].
heycam: next, issue 15
<heycam>
[47]https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
[47] https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
heycam: in the bbox section
... bbox of text with the widht/height set on it
... should it be the box that it's laid out in, or the union of
the glyph cells?
Tav: the text would just be the content area, can be reduced
due to padding/margin
krit: we should handle it like normal block elements in html
heycam: so what should getBbox return?
Tav: there are different bboxes in css
<text x=10 y=10 width=100>A</text>
heycam: sometimes you have content that can't wrap
Rossen: inline elements don't have width in css
... this is closer to block
... the blockrelated properties is what should apply to svg
here
heycam: we don't need to make getbbox does like
getboundingclientrect
... if we ignore the width feature
... we might return the size of A
Rossen: with the width today if you specify it
<shepazu> (SVG also has different bboxes... geometric bbox,
decorated bbox, etc.)
Rossen: you can say it's the bbox or that it's the union of the
two, or just the text inside
Tav: depends on how much text you put in
heycam: it's a run of glyphs
... we can do pre-formatted text
... we can union the bboxes
... i think we shouldn't return the rect area defined by
width/height for text
Tav: if you've wrapped text, some text sticks out further than
the others, you should make that affect the bbox
... you'd have to look at all the lines to figure out the exact
bbox
nikos: if we say width(height is always returned from getbbox
you could just check the attribute
Rossen: the information for size of each line is available
internally
... you might want each line separately
ed: multiline text is new in svg2, do we want to allow fetching
the size of each line?
krit: cssom defines that getclientrects maps to getbbox (?)
roc: maybe think of it as shrinkwrapped
... the intrinsic preferred width
heycam: problem is tht dx dy influences the bbox
krit: we could disable them for the case of having width/height
heycam: the options
... 1) look just a the glyphs, take bbox of each and then union
the bboxes
... 2) if you have width attribute then bbox has that exact
width and height be multiple of lineheight
... 3) union of option 1 and 2
TabAtkins: option 2 is closest to what css is doing today
Rossen: what do we do for negative margin on inline boxes?
TabAtkins: doesn't count
Rossen: not sure it translates well to svg
(draws on whiteboard)
Rossen: think that we want two ways, if you want getclientrects
(the content) you get only the text - you can do union,
intersection or whatever you want
heycam: if we want options we have a param for getBBox that we
can use
Rossen: so list of text content boxes, or the parent box that's
the union essentially
heycam: we can always add a way to get the other one
Rossen: right, because we don't have any way to get the
lineboxes
heycam: the only downside is that it's inconsistent with
non-areabased text
... where we're using css to layout the text
... but shrinkwrapping the text
Rossen: that's fine though, the bbox is defined by the text
content in that case
Tav: think we should not consider dx, dy and rotate in the
textarea case
... for the bbox
heycam: I think the block level element in css should provide
the bbox (positioned)
Rossen: when width is auto one of the three possible ways to
size the box
... one is dependency on parent, in percentage
... other is that it's fixed
... third is that it's attached to the text content
-- break for lunch --
<nikos> scribe: Nikos
<scribe> scribenick: nikos
Text bounding box
heycam: we discussed over lunch
... when you call getBBox on a text element that has % or px or
specified width then bounding box is the specified width
... and height is the height of the CSS box that gets created
... and if you leave off the width, then you take the union of
all the bounding boxes for the text
... to handle cases where things are positioned
... if you don't have positions then it's like the other two
cases where you're looking at the box and returning the
bounding box anyway
... think that makes it a consistent model
... probably don't need to describe in terms of those three
things
Tav: looks like a good solution to me
RESOLUTION: for text bounding boxes with specified width, % or
px, then the bounding box is the specified width with height
being the height of CSS box that is created - otherwise
bounding box is union of all child text bounding boxes
<scribe> ACTION: heycam to spec behaviour of getBBox on text
[recorded in
[48]http://www.w3.org/2015/02/12-svg-minutes.html#action09]
<trackbot> Created ACTION-3742 - Spec behaviour of getbbox on
text [on Cameron McCormack - due 2015-02-20].
<heycam>
[49]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Ope
n_issues
[49] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
heycam: bogdan suggested we gather up open issues on this page
- we might not have a chance to resolve them all this meeting
... so I summarised which I thought were substantive issues
that need discussing
ed: back to text, if you have text element without width or
height and you have white space property set to pre wrap
... you have some return characters to specify text as multiple
lines
... you get three lines of text
... behaviour of bounding box should be as auto
Open SVG 2 issues
<heycam>
[50]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Ope
n_issues
[50] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
heycam: this list is based just on the red issues that are
noted in the spec
... may be a few more things in tracker
<scribe> ... new ones may also pop up as we continue reviewing
the existing text
UNKNOWN_SPEAKER: Erik and I have reviewed some chapters
... neither of us are through the whole spec yet
... so probably later chapters need a closer look than the
earlier ones
... bearing that in mind, this wiki lists the substantive
issues that are noted in the spec
cyril: some chapters start at issue number > 1?
heycam: we've already discussed some and some don't need
discussing
... we may or may not get through this list
... how would you like to prioritise?
BogdanBrinza: normally for us we take a first pass at the list
and find highest priority items
Rossen: hope we're in agreement we want to ship the spec?
... so we can tackle a couple of ways
... we can look at the spec as a whole - if we agree we want to
close all issues and ship the spec
... then move to a modular way of advancing svg
... then first pass should be to decide the must unstable and
non core things
... that we can live without
... and make those modules right now
... that will reduce the amount of work we need to do as a
group to discuss issues
... so as a first pass lets find big areas we can remove
... then from remaining we can assess what is in most dire need
of group discussion time
heycam: I like the idea of creating modules immediately for
things we're removing
cyril: maybe not the case for all chapters - but some seem to
be very close to modules
<BogdanBrinza>
[51]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_asses
sment
[51] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment
Rossen: is your list an extraction of this table?
heycam: has some correlation probably but this is just my
judgement of the issues
... and which are not editorial
BogdanBrinza: think we agree on chapters that have most issues
Rossen: do we think we can go through the first step and move
things to modules?
krit: I'm in favour of that - do you have features that you
want to move
Tav: Think we'd spend more time arguing over which stuff to
move than how to solve the issues
BogdanBrinza: Chapters 15, mesh gradients has a lot of issues
heycam: don't think we should be looking at the chapter level -
but at features
... if we look at my list of open issues - do you agree that if
we've solved open issues for a feature should it stay?
Rossen: not sure - if we can move something to the next level
why spend time talking about it?
heycam: sounds like you have ideas about features you don't
want to see in the spec - even though there are no open issues
Rossen: I wouldn't oppose a stable feature staying
BogdanBrinza: generally not about features we want in the spec
- but everyone wants to see a stable spec
heycam: do you think stability is not solely determined by open
issues?
BogdanBrinza: I'd say that's the most important thing - but
severity matters too
heycam: I was going to suggest looking at features that
correspond to open issues
... so if we've resolved issues on a feature it can stay
Rossen: do we consider features complete?
... or just enough stuff there so we think it's complete but
not sure
... are we going to find issues when we review?
... ok lets go through each issue then
heycam: let's finish co-ords chapter then we can talk about
features in other chapters
<scribe> ACTION: heycam to make stable issue identifiers in the
spec [recorded in
[52]http://www.w3.org/2015/02/12-svg-minutes.html#action10]
<trackbot> Created ACTION-3743 - Make stable issue identifiers
in the spec [on Cameron McCormack - due 2015-02-20].
issue 17, co-ords chapter
heycam: issue 17, co-ords chapter
... should fill correspond to the main area of that element?
... so fill:false should exclude that rectangular region?
<ed> for ACTION-3743 make sure that the template has fields for
assigned actions, wg discussion and resolution
heycam: if it's not an svg element you can't call getBBox, but
you can call it on the parent
... so iframe or canvas should contribute to the bbox
Rossen: if it's not exposed how can you get the bbox?
... should define getBBox on these elements
krit: if you put HTML in an svg document, how does CSS box
model contribute to the bounding box computations - it's a
general problem
Rossen: we define getBBox on foriegnObejct? Behaviour should be
the same
krit: but on fo you have a whole html doc
heycam: fo and iframe and canvas just return the rectangle -
but issue is whether fill dictionary parameter controls whether
that contained element contributes or not
Tav: To me fill:false is not a sensible option
... as a control
heycam: sounds like we agree on that
RESOLUTION: The fill dictionary parameter doesn't affect
bounding box of iframe, canvas, etc
<scribe> ACTION: heycam to update spec for fill dictionary
parameter when called on iframe, canvas, etc [recorded in
[53]http://www.w3.org/2015/02/12-svg-minutes.html#action11]
<trackbot> Created ACTION-3744 - Update spec for fill
dictionary parameter when called on iframe, canvas, etc [on
Cameron McCormack - due 2015-02-20].
heycam: proposing to remove svg:transform’ attribute
krit: already done
ChrisL: where is it being moved to ?
heycam: no one uses it
ChrisL: mapping people use it
... my understanding is we changed behaviour for this to match
what implementations do
krit: the removed text was mostly pointless
cyril: it's not the same as the transform attribute - same name
but in a different namespace
heycam: if you think it's being used by people it can stay
... just worried wording is outdated
ChrisL: this was standardised through JIS
krit: I'll put it in integration spec
ChrisL: that's ok - just don't want it removed
AlexD: isn't this what Takagi-san is using for tiling?
ChrisL: yes
cyril: don't think it should be in integration spec - should be
module on it's own
... I see integration spec as between svg, html, css
ChrisL: it's larger - how css uses things
Tav: I'd like to see it moved before it's taken out
krit: I'm doing it right now
... into a new module right/
ChrisL: section above it as well?
heycam: there was going to be a mapping spec?
ChrisL: yes but mapping spec by itself wasn't useful
... by itself
... so dispersed these features into svg 2 spec
Tav: that's why it's good having annotations describing why
things are moved
RESOLUTION: svg:transform attribute will be moved to a new
module
heycam: let's look at remaining issues in terms of the features
they encompass
... all path issues are for Catmull-Rom
Rossen: who is implementing it?
Tav: it's Doug's baby
Rossen: can we have a Catmull-Rom module?
<shepazu> why?
ChrisL: tricky because it's in the path element
shane: we did that in CSS
ChrisL: was going to bring that up as a bad example
shepazu: there's a not great way - which would still be good
enough
... supersede description in new spec
... good way is define what path commands look like
... and say future specs may define new path commands
ChrisL: agree, not sure how much work it is making it properly
extensible
shane: could put all stuff in path extension spec
ChrisL: so in core svg 2 path syntax is the same as svg 1.1?
heycam: we have bearing and stuff
... that's an example of a feature that is complete in the
spec, but people have reservations about it being in core svg 2
Tav: it's not something I care too much about having - but feel
it will be ignored once it's in another spec
Rossen: that's how css works
... survival of the fittest - good features progress faster
... I think it's a good way to do things
TabAtkins: don't be afraid of modules
heycam: Doing things in modules is the right thing- but I'm
concerned if we move features to modules then svg 2 won't be
much different to svg 1.1
ChrisL: that's a problem because we've then spent 10 years
producing a spec that doesn't have new features
Rossen: if you have 5 other specs in the pipeline then you have
a good story
ChrisL: we've already gone from modules to one monolithic spec
... now we're going back
Tav: how much work to fix Catmull Rom?
heycam: need to add math to the spec
... issues could be summarily decided
Rossen: this is a good example of a feature that could move imo
... it's a good feature
... some designers have questioned it's use
Tav: there's a good use when connecting points in a graph
heycam: I would have to do investigation of the math
Tav: it's pretty simple
Rossen: if it was such a hot feature I'd expect Adobe,
InkScape, etc to be pushing it
krit: Adobe already stated we don't care
heycam: so if you want a sense of it staying in svg 2 or being
split ... ?
krit: not necessary for svg 2
Rossen: can we resolve to move it to it's own module
heycam: as long as we create a new spec immediately
... don't want to lose the work we have done
ed: do you have same concern about bearing?
Rossen: I haven't read the bearing stuff
heycam: I'll be less excited about shipping svg 2 with all the
features removed
shane: I think we'll fairly readily be able to find features
that have no issues or trivial and those that have substantive
issues
... why not appoint champion or owner for features with
substantive issues
... if issues aren't resolved by wg within a certain time frame
we move it out
Rossen: features without issues shouldn't necessarily remain
part of the core
... if features have expensive implementation cost then they
should maybe moved out
heycam: we could mark them at risk
Jet: is there a list of at risk features/
... that's probably the first step
heycam: table in your wiki page isn't at feature granularity,
which is what we need to discuss
Rossen: it's easy to decide on some - basic types for example
krit: svg 1.1 isn't going to disappear - it can still be
referenced
stakagi: not using transform at the moment - it is ok to remove
it from this level
... you can put me as editor of the svg:transform spec
heycam: Catmull-Rom - what are we doing?
... put with superpath as svg path level 1?
shane: it's a really nice target for modularisation
... doesn't mean it won't be published at the same time as svg
2
heycam: let's publish first draft of these things when we
publish CR of svg 2
RESOLUTION: Will create SVG path module
heycam: should svg 2 path only be what is supported by 1.1?
... so move all new things (e.g. bearing) into the module?
shane: there is work involved in moving stuff - if a feature
has no issues then leave it
heycam: I'm ok either way
Rossen: i'm ok with either too
heycam: minimum work is leave it where it is
all: let's do that
<scribe> ACTION: heycam to move Catmull-Rom to SVG path module
[recorded in
[54]http://www.w3.org/2015/02/12-svg-minutes.html#action12]
<trackbot> Created ACTION-3745 - Move catmull-rom to svg path
module [on Cameron McCormack - due 2015-02-20].
heycam: Editors will be Cam, Doug, and Cyril
TabAtkins: do we want to use CSS naming where everything that
builds off SVG 2 is next level?
... then we'd start at 2
all: that's confusing, let's start at
... 1
heycam: next bunch of issues are to do with text
... either shape text or rectangular ref text
Rossen: are your issues in an order?
heycam: just numeric
Rossen: can we do things with only 1 issue?
heycam: Let's do animate.html, Issue 2
birtles: basically new features we'll defer to a separate spec
... then there's one or two edits I should make with regards to
correctness
... not sure about allowing animatemotion to use a basic shape
... not sure if we want to include those slight improvements
... or defer everything
Rossen: what would it look like after your change?
ed: we resolved to allow basic shapes for text on path
birtles: so for consistency we should leave it
... major features will be deferred
... I can take care of the issues that are there
... and get rid of references to features which we'll put in a
different module
heycam: can we discuss attributeType="auto"?
ed: I came across issue with SMIL elements and attributeType
... default is auto which means check if it's a property first
... if so that's what your'e animated, otherwise attribute
... since we made x and y properties
... it's a problem on text element
... which takes a list of values
... I'm wondering if we should try to be smarter here selecting
the right thing
heycam: why wouldn't that content work now?
... auto means when both property and presentation attribute,
choose the property right?
ed: if we make x a property, we'll try to animate x as a css
property
... and that might not give the same result as previously
heycam: outcome of previous discussion was that it would work
... property is the primary thing that determines the value
ed: if you have a list of values (e.g. "10 20 30") it's not
valid for the property, so animation will stop working when it
used to work
... one suggestion is to make auto pick the xml version if it's
a text element
... that will preserve old behaviour
... and pick css property for any other element
Rossen: and when number of values is one?
AlexD: I don't like behaviour of attribute depending on what
it's parent is
birtles: you have to look up parent or target anywhere when
animating
AlexD: but not when binding
birtles: yes you need to look to see if there's an attribute of
that name that can be animated
AlexD: seems like strange behaviour to me
... choose one or the other and whatever it breaks it breaks
Rossen: doesn't sound like much will break
ed: expect most would use one value
birtles: I think there'd be some breakage
... you see people moving characters around like that
Rossen: I'd be more concerned about tools and tool makers
birtles: that suggests keep backwards compat
AlexD: don't know if there's any tool that generates this
birtles: I was hoping to deprecate attributeType altogether
ChrisL: attributeType was introduced to disambiguate a name
class between width and height attributes and properties
<birtles> Mozilla bug:
[55]https://bugzilla.mozilla.org/show_bug.cgi?id=1062106
[55] https://bugzilla.mozilla.org/show_bug.cgi?id=1062106
ChrisL: so most of the time you didn't need to specify it
... in some was we have more of a clash now
... we've promoted lots of things that were attribtues into
properties
... so I don't think it serves much purpose at the moment
... think people tended to guess as to which value to set
... and it usually didn't matter
... so you'd probably find uses - but removing attributeType
would probably render just the same
birtles: but how do we make text case work?
Rossen: state it's deprecated
birtles: if we get rid of attributeType how do you animate x
attribute on text element?
Rossen: so what are options we have?
... option a) remove attributeType altogether because pretty
much all properties are attributes and only x is problematic
... we'll deprecate multiple x/y value animate for text
... as a consequence
ed: do we want to consider deprecating having multiple x/y
values on text element
cyril: it's heavily used isn't it ?
krit: yes but not for animation
<scribe> ACTION: ed to add use counter for multiple x/y values
on text element [recorded in
[56]http://www.w3.org/2015/02/12-svg-minutes.html#action13]
<trackbot> Created ACTION-3746 - Add use counter for multiple
x/y values on text element [on Erik Dahlström - due
2015-02-20].
Rossen: let's wait for more data then
ed: don't think we need to make both decisions at the same time
Rossen: option b) get rid of attributeType and in this case
have a fall back mechanism for the property that gives a list
of values
... e.g. we can take last or first valid attribute from the
list
... and animate with that
... which will again break animation, but not as badly (maybe)
... in one case you have no animations at all - second you have
animations of one frame
... not perfect, but less invasive
... option c) get rid of attributeType and add special handling
for x on text
... make it context aware
... is there another option where we extend the attributeType
to specify instead of doing context aware
heycam: it already has values to select attribute or property
ed: we could make auto on text elements, pick xml as the
default
Rossen: option d) attributeType for animate inside of text is
always xml - there is no auto
... would reduce options in future
cyril: detect number of values?
Rossen: that would be hacky
birtles: I think we could drop attributeType and leave a note
in the spec with the context aware behaviour as an open issue
... see what data we get on the use counter
... if there's not sufficient usage of multiple values for x we
drop, otherwise we do context aware
Rossen: what about if we deprecate it now and see who fights
for it?
birtles: I know there's a lot of opposition to multiple values
for x anyway
ed: difference between static text with multiple values and
animated multiple values - there will be a lot less animated
cyril: removing attributeType is ok - but the consequence in
option a is not acceptable
birtles: the consequence only applies to animation
cyril: ahh ok
birtles: there is a work around for jittering text
... using dx/dy
RESOLUTION: remove attributeType and deprecate animation of
multiple values in x/y
Rossen: that was the big issue with animation - so this chapter
is mostly clear
birtles: I need to do some more tidy up but yes
heycam: interact.html ISSUE 1: should we remove duplicate
events like SVGLoad? is already resolved
... lacuna value for pservers.html ISSUE 3: linearGradient y2
lacuna value is already resolved
... the value should really be zero
RESOLUTION: lacuna value of y2 on linearGreadient should be
zero
Rossen: what about masking.html ISSUE 2: define how
overflow-x,y work ?
krit: being moved
... ISSUE 3: should overflow:auto really be equivalent to
visible
... we changed behaviour based on ie
Rossen: thought we discussed in London?
nikos: from London - All viewport-establishing elements will be
overflow:visible by default, except for root <svg> of SVG whole
documents.
[57]http://www.w3.org/2014/08/22-svg-minutes.html#item04
[57] http://www.w3.org/2014/08/22-svg-minutes.html#item04
Rossen: seems like a perfect fit for integration spec
krit: do we move overflow to integration spec?
heycam: why is it in our spec?
ed: we have lots of special rules
heycam: remove that section, add relevant UA rule and that
should be enough
... krit can we really remove it all?
... I need to think about it - give me the action
<scribe> ACTION: Cameron to take care of overflow section in
the masking chapter [recorded in
[58]http://www.w3.org/2015/02/12-svg-minutes.html#action14]
<trackbot> Created ACTION-3747 - Take care of overflow section
in the masking chapter [on Cameron McCormack - due 2015-02-20].
nikos: a lot of the stuff in Clipping, Masking and compositing
will move to rendering chapter or be removed so this chapter
will probably go
RESOLUTION: masking.html, issue 2 - Drop overflow-x,y issue and
don't do anything specific in SVG
krit: so all these changes are going to integration spec and
are being removed from svg 2?
Rossen: yes
heycam: i'm concerned that it's not valid to state that auto on
a particular element computes to a different value
Rossen: we do that all the time
RESOLUTION: masking.html ISSUE 3: should overflow:auto really
be equivalent to visible? Should be moved to integration spec
and removed from SVG 2
krit: can we remove 15.3 and 15.4 totally?
heycam: think in rendering chapter we need to describe how
these things fit into the scheme of things
nikos: I think rendering chapter should say at what point these
things occur and that's all
<ed> -- 15 min break --
<Tav> scribe: tav
<scribe> scribenick: Tav
Rossen: , Let's cover issue in color chapter.
svg2 issues in the color chapter
<cyril> s/Rossen,/Rossen:/
<ed>
[59]https://svgwg.org/svg2-draft/color.html#color-managed-image
s
[59] https://svgwg.org/svg2-draft/color.html#color-managed-images
Rossen: Issue 1:
... should this be here?
TabAtkins, : Should be in colors4.
scribe: not in yet, will be soon.
krit: What do we need to keep?
Rossen: Tab, what do we need to keep?
TabAtkins: Nothing.
Rossen: Motion: move everything in this chapter to color4.
<Rossen>
[60]https://svgwg.org/svg2-draft/color.html#InterfaceSVGColorPr
ofileRule
[60] https://svgwg.org/svg2-draft/color.html#InterfaceSVGColorProfileRule
krit: SVG Interface rule should disappear.
ed: will icc-color be part of the <color> grammar in css?
Rossen: Yes, should be in colors4.
RESOLUTION: Drop SVG color profile rule interface.
... Remove color chapter from SVG 2. Refer to CSS Color 3 and
4.
<scribe> ACTION: TabAtkins Finish CSS Color 4 (with stuff from
SVG). [recorded in
[61]http://www.w3.org/2015/02/12-svg-minutes.html#action15]
<trackbot> Created ACTION-3748 - Finish css color 4 (with stuff
from svg). [on Tab Atkins Jr. - due 2015-02-20].
<krit>
[62]https://svgwg.org/svg2-draft/types.html#InterfaceSVGCSSRule
[62] https://svgwg.org/svg2-draft/types.html#InterfaceSVGCSSRule
<krit>
[63]https://svgwg.org/svg2-draft/types.html#InterfaceSVGRenderi
ngIntent
[63] https://svgwg.org/svg2-draft/types.html#InterfaceSVGRenderingIntent
Remove above two interfaces.
ed: Should go.
<ed> (to be clear, the entire room says that, not just me ;)
RESOLVE: Remove InterfaceSVGCSSRule and
InterfaceSVGRenderingIntent.
Rossen: Only two chapters to go from heycam's list: painting &
text.
Painting chapter issues
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
<Rossen>
[64]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Ope
n_issues
[64] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
heycam: first two issues are to do with arcs line-join
Tav: first issue is the name
... nobody suggested a different name
... so let's just leave it as is
... second one is what do you so with miter-limit
... now that we have this clipping option, ...
... it's possible to get a very long arc
... I would suggest that taking the mid point of the end of the
stroke before the cap, then measure along the mid-arc the miter
limit
RESOLUTION: arc line caps are affected by miter-limit by
measuring along the middle arc and clipping a straight line
perpendicular at that point
<scribe> ACTION: Tav to make miter-limit work on arc line caps
in this way [recorded in
[65]http://www.w3.org/2015/02/12-svg-minutes.html#action16]
<trackbot> Created ACTION-3749 - Make miter-limit work on arc
line caps in this way [on Tavmjong Bah - due 2015-02-20].
<Tav> Scribe: Tav
<scribe> ScribeNick: Tav
Issue: stroke-dashcorner doesn't work well for rounded rects
heycam: New feature in SVG 2. It's nice.
... look at pictures in section.
<heycam>
[66]https://svgwg.org/svg2-draft/painting.html#StrokeDashcorner
Property
[66] https://svgwg.org/svg2-draft/painting.html#StrokeDashcornerProperty
heycam: Illustrator supports.
krit: Illustator dashing different.
heycam: Not the most important issue.
krit: Could we have a stroking enhancement spec?
... would like to have a core with what is supported today.
heycam: Not happy with pulling out stroking.
ed, Rossen stroking should be well defined.
krit: doesn't include stroke-alignment...
Rossen: The fact that stroking will be well defined in SVG 2 we
could still have a stroking spec.. What would be in it?
heycam: I can summarize the new things:
... stroke-dashadjust
... stroke-dashcorner
... arcs line join
... stroke-alignment
krit, tav: stroke-alignment often requested.
tav: would like to have %
Rossen: stroke-dashcorner: our (IE) implementation for stroking
is pretty complicated, could be hard to do.
krit: Used in illustrator.
heycam: Can just stretch dash array.
Rossen: We still don't have interopability with normal dashing
today.
roc: SVG stroking is actually rather simple.
<ed> (in comparison to css border dashing)
roc: We need an extensible stroking task force. Lots of neat
things you can do.
Rossen: Should there be a new module?
... What would be in the new SVG stroking module:
ed: Variable width stroking.
Rossen: That's a really cool feature.
krit/Rossen Dashing and Variable width.
Rossen: We extend in CSS specs with just one new value of a
property.
... New specs should only add stuff that's not in already in
SVG 2.
krit: But what should we ship here for SVG 2?
heycam: I think there are some things already implemented that
should remain.
Rossen: Should we start with stroke-dashcorner? (Moving to new
spec)
heycam: Question at approach: we've been telling authors about
these new things. How can we maintain the message that things
will be coming at the same pace.
Rossen: I think that moving things into modules sends the
message that we can move faster than with a big SVG2 spec.
krit: I'm happy to move out new marker stuff to new spec.
heycam: There would be some overlap in text between specs.
Rossen: there are modules that we would ship ahead of SVG2.
... Interlude: explains IE/Microsoft philosophy towards
choosing what to ship.
krit: Can we have a resolution having a painting module?
... put in paint-order
ed: Don't think that's a good idea.
tav: Would you (Rossen) implement 'paint-order' if it was in a
separate spec?
Rossen: Yes.
ed: We could say that this section is stable.
Rossen: It's not in a stable spec.
Discussion of where things should go....
Rossen: Should we start an SVG marker spec?
heycam: I'm more concerned about public impression of SVG 2 if
things get moved out.
<shepazu> modularization is time consuming and confuses
developers
<ed> +1
BogdanBrinza: What the SVG working group thinks is more
important than public perception.
<ed> (the time consuming part)
heycam: Things in the past that have been split out tend to
mean that we don't want to work on it.
... One advantage of splitting out is that we would have a well
defined owner for the spec.
Tav: A markers spec would be a good trial of this.
ed: Not clear that a marker spec could move faster. There is a
lot of stuff tied to SVG core.
Rossen: having something in PR is much better than having some
text in the bigger spec.
... saying this is stable.
krit: marker knockout should be moved to a separate markers
spec.
heycam: ignoring the marker knockout, the rest is pretty
stable.
Proposal: Start a new marker spec.
ed: Not so sure about this but won't object.
tav: with eric
heycam: Is willing to try it.
RESOLUTION: Move new marker features to a separate marker spec.
Rossen: We won't be discussing the following issues:
<Rossen> ISSUE 23: what to do with marker knockouts
<Rossen> ISSUE 18: name these vertex or segment markers?
<Rossen> ISSUE 30: should paint-order be able to select the
different types of markers?
<Rossen> ISSUE 32: should SVGMarkerInstance objects be live?
(or should we remove those interfaces?)
Rossen: Let's get back to stroke-dashcorner for rounded rects.
heycam: Dashing will move slower than markers. Dashing should
move into a stroking spec.
Moving on to text issues.
Tav: Meta issue: how do we treat all the various text
properties?
General discussion...
Rossen: It would be reasonable to expect that paragraph level
things would work. (text-indent, etc.)
heycam: Properties that apply to inline elements should work.
roc: some aren't appropriate perhaps.
Rossen: overflow:scroll?
ChrisL: Don't want a white list.
krit: Text handled by normal code path.
Rossen: So do we.
... In trident we have the concept of paragraphs that are like
blocks with out the blocky stuff (padding, etc.)
... text alignment, writing mode, etc. are supported.
... underline, bold are handled in one level down.
heycam: We should have a paragraph guiding our intentions so
when new things come along they can be automatically included
or excluded.
Rossen: We could ask the CSS working group to add a term that
defines paragraph level properties.
roc: CSS does have the concept of anonymous blocks. We want
everything that effects these blocks. But there is no name.
krit: We should ask CSS for an "official" name.
RESOLUTION: 'text-indent' applies to <text> as it is part of
the CSS paragraph level properties.
... CSS Paragraph level properties are assume to apply to SVG
<text> element with wrapping context.
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
Rossen: so that resolves issues 37 and 38
... shape-inside, shape-outside
Tav: I think I know what to do with these now after discussing
with CSS folks
Rossen: I am the editor of that spec, too
... so the rest of the issues are shapes related
... issue 2, are dx/dy/rotate ignored for auto-wrapped text
ChrisL: when would you want to do that
heycam: never
Tav: I would be fine with that
ed: I agree
ChrisL: those things were because we didn't have wrapping text
... and some people wanted to do "better" text on a path
heycam: you could argue from consistency with single line text
... you could apply the positioning attributes to content area
text just as easily
... but it won't be useful
RESOLUTION: dx/dy/rotate are ignored for text with a wrapping
context
Rossen: last, issue 4; should x/y specify the corner of the
content area or the origin of the first glyph
[Tav draws and shows the two options]
Rossen: I suggest using extent rather than width/height
... then authors won't think you should be able to put both
width and height
RESOLUTION: Change width/height on <text> to extent
<scribe> ACTION: Tav to make the text changes from today's
meeting [recorded in
[67]http://www.w3.org/2015/02/12-svg-minutes.html#action17]
<trackbot> Created ACTION-3750 - Make the text changes from
today's meeting [on Tavmjong Bah - due 2015-02-20].
RRSAgent: make minutes
<pdr__> svgwg is rocking it for sticking with the pathseg
removal.
<krit> commit 7d2ff7e2f7a1fd55f152f6b308f695915a814408
<krit> Author: Cameron McCormack <cam@mcc.id.au>
<krit> Date: Fri Feb 13 22:13:02 2015 +1100
<krit> Markers module.
<krit> commit ce33635151342971e99b63c2cf63db8cb82a9e7e
<krit> Author: cconcolato
<cyril.concolato@telecom-paristech.fr>
<krit> Date: Fri Feb 13 11:39:52 2015 +0100
<krit> fix broken markup
<krit> commit 74e23360c8d7460facb61ef92f7b5919e7518cc3
<krit> Author: Dirk Schulze <dschulze@chromium.org>
<krit> Date: Fri Feb 13 21:27:37 2015 +1100
<krit> Initial marker spec
<krit> heycam|away: I was ~1h earlier ;)
trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 13 February 2015
<scribe> Chair: Cameron
<scribe> Agenda:
[68]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agen
da_proposals
[68] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
<BogdanBrinza> scribe: BogdanBrinza
<scribe> scribeNick: BogdanBrinza
topic is SVG Markers
SVG Markers
<heycam> [69]https://svgwg.org/specs/markers/
[69] https://svgwg.org/specs/markers/
<heycam> [70]https://svgwg.org/specs/marker/
[70] https://svgwg.org/specs/marker/
heycam: Both Dirk and I took first step o producing first spec
version for SVG Marker Level 1
... The question is - is this ready for first publish working
draft
Rossen: In CSS WG the rule is you have a short name - which is
stated on the module
... so that in mailing list you reference this and a page with
issues
heycam: So in the end we should combine two versions
krit: We should decide on short name
shane: so markers would work nice and align with CSS
Tav: should we have a Level 2 already?
heycam: does everybody agree that knockout should be in L2?
Rossen: in FPWD we can have it and then split if needed. no
reason to push this off
cyril: What about section 9? how markers are rendered?
heycam: I just missed copied that initially - will add this
soon
... so the current approach is to copy all stuff we had in old
spec at the moment
shane: it should be fine to use either
Rossen: again, the rule we follow in CSS is simple - if you're
extending 2.1 you copy whole section and start extending
... if we're extending from SVG 1.1 this is something we can
do, if we're extending from 2 (that is not ready) we can just
get the deltas
birtles: As an author I don't like the deltas
<birtles> (because I have to look up two specs)
heycam: so what are we doing? deltas / no deltas?
Rossen: let's agree on consistency
cyril: is there a pointer in CSS that goes from L2 to L3?
Rossen: not really
cyril: this might be confusing if you want to find the latest
version - google will give you not the latest
Rossen: CSS snapshots address this and everything that is up to
date at certain moment
Tav: pointer up might be useful
cyril: pointer to a stable URL might be useful
RESOLUTION: Publish SVG Markers Level 1 as FPWD
... All specs would have a pointer to a stable SVG summary spec
(snapshot) that lists the status of all modles
heycam: Because I took a text from SVG2 for this section - if
SVG2 doesn't progress fast enough we might need to change links
to SVG 1.1
Rossen: and you're going to move the section about rounding the
markers?
heycam: knockouts?
Rossen: no details about the rendering
heycam: yes, I'll move this in
... So remaining on the agenda is next F2F meeting, motion path
animation and couple of Tav topics
shane: didn't we decide we won't talke about motion path?
krit: yes
Rossen: where we left on remaining issues is
... we need to sync with Tav on remaining shapes issues
<heycam>
[71]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Ope
n_issues
[71] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
Rossen: next pat is painting where we took issues related to
markers
we decided miter limits, arcs and remaining are stroking issues
Rossen: so the discussion was should we keep strokes in SVG2 or
move to a new spec and fix the issues on fixed timelines
heycam: strokes are pretty much the same level of readiness as
markers - so it should be also splittable if we want to
Rossen: this is great sign that SVG2 spec moved as set of
modules
ed: so how do you want to do split? move jsut new things or
everything?
Rossen: we should still move stroke the same way we moved
markers
... so when we clean SVG2 strokes sections we should add
extensions since 1
... when we ship SVG2 we'll have a section about stroking and
new behavior goes to a separate spec
... and we can move or keep the new wording
heycam: it might be easier to take the whole section
Rossen: so who would be editor beside you?
heycam: there are stroke-dashcorner, miter-limit, arcs
someone: what about variable stroke width?
<birtles> birtles: that got deferred because I don't have time
to work on it at the moment
Rossen: yesterday we decided we shouldn't move good ready
modules - so from previously noted list of stoking features
which are stable or ready to move
heycam: there are number of issues and discussions those
features need
... so it would be useful to have implementors to try those
features to provide feedback
Tav: Inkscape has prototype for arcs, not yet implementing
dashing
Rossen: does anybody has implementation for stroke-dashing?
all: there are no current implementations of dashing
Rossen: so it would be good candidate to separate
... so arcs can live in current spec
heycam: we can have features at risk in the spec
... so we're moving this decision a bit earlier
Tav: so why would be pain-order at risk?
heycam: it's not - it's example of feature not at risk
Tav: so what about multiple stroke width?
heycam: it's a new and can be moved
krit: so multiple stroke width can go with multiple stroke
layers
heycam: unless we want to decide how we want to ship with /
without multiple stroke width
nikos: agree
Rossen: so in that case who is going to be the editor of SVG
stroking
heycam: it's currently all features I've added
Rossen: so Cameron and Dirk?
cyril: I have a question regarding naming
... so we went with SVG Markers Level 1
Rossen: every module starts with Level 1 unless you're
extending existing one
Tav: so what is extending in this case?
someone: so there was a initial confusion with CSS3 because it
became a buzz word
krit: but we can start with Level 1 here
heycam: Let's stick with Level 1
cyril: so you have SVG 2 and Markers Level 1
... wouldn't they assume it's based on SVG 1?
shane: people who you're talking about wouldn't read the spec
... and the target audience already understands that state and
what is based on what
Rossen: for now let's not give them many levels
birtles: that's wonderful
Rossen: so SVG strokes / stroking / else?
all: SVG Strokes
RESOLUTION: Create new spec SVG Strokes with heycam and krit as
editors
Rossen: can we move to FPWD?
heycam: I'd like to check the text and we can review after that
all: we would be happy to resolve to publish
RESOLUTION: Publish FPWD of SVG Strokes
Rossen: that is pretty much all issues Cameron brought up
... so we currently have two new modules and remaining issues.
What else is blocking?
heycam: existing issues and editoral changes
... so in order to move forward we might need to understand
amount of editorial work and assign
[72]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_asse
ssment
[72] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment
Rossen: so let's take a look at the sections in red currently
krit: so document structure?
Rossen: give me one second to log and put owners names to
chapters
... ed you mentioned you can use help from somebody?
ed: Rich send a mail that there might be changes to better
align with HTML and provide better accessibility
... there shouldn't be major issues, but need to go through all
... the major one - <use> alignment with web components
TabAtkins
... the rest are DOM interfaces, mostly clarifications
Rossen: API design is not somethign to blaze through
ed: this is not API design - this is clarifications
heycam: I'd like to have each chapter to have a single point of
contact
Rossen: there is still decent number of issues on Document
structure
ed: we did resolve some issues on F2F
Rossen: suggestion - can you take a first pass at issues and
editorials and bring this back to WG discussion
... on Document structure, Erik is primary owner, TabAtkins
would help with <use> and rest is mostly editorial changes
... next one is Text and has a clear owner - Tav
Tav: yes, rest of the issues can be addressed pretty soon
Rossen: looking through the spec - we knocked most of them
yesterday and at this point it's mostly cleaning up
Tav: for first pass I can take a look and get back with any
outstanding issues
Rossen: Paining, etc - most of the issues have been moved to
seprate specs, so cleaning out would give us a clean state
... the owner was still heycam?
heycam: yes
Rossen: next Paint Servers. There were issues on mesh gradients
not in heycam's list?
Tav: those are minor issues. Inkscape has mesh gradients
implementation for 3 years
Rossen: so in that case - after cleanup driven by Tav we can
take another look and get help
... Basic Data Types - owner heycam and he has a good handle on
this one
... next Styling
heycam: this might be in poor state and would need rewrite
... I think what this chapter should become is description on
which CSS modules are required
... and description of presentation attributes
Rossen: why this is not part of integration chapter?
heycam: this chapter currently is describing how other things
are used in SVG
Rossen: this is an inverse of integration chapter
krit: we also write what specifications we rely on CSS
heycam: we should put specifications SVG relies on
Rossen: so can we assign the owner to clean this and decide the
struecture of this one?
heycam: I would like to do that
Rossen: we're having to much on heycam, but let's try this and
on next telcons learn what we can do to help
BogdanBrinza: I can take remaining yellow ones
... so Paths, Embedded content are on me with help from WG
Rossen: next introduction section - cyril
nikos: Rendering model - that should be me
Rossen: next SVG Layout properties
krit: that's me
Rossen: Basic shapes - Rossen
krit: Color section would go entirely with additional work from
TabAtkins
Rossen: Clipping and masking - krit, nikos
all: Filter effects are gone
cyril: Linking makes sense to keep with Embedded content
BogdanBrinza: so Linking goes to BogdanBrinza as well
Rossen: Animations - birtles
... Scripting might be close to Animations
birtles: might not be able to take it before April
Rossen: ok, BogdanBrinza and Rossen will take it
... Metadata - owner ed pending merge with document
ACTION ed to merge Metadata chapter with Document structure
<trackbot> Created ACTION-3751 - Merge metadata chapter with
document structure [on Erik Dahlström - due 2015-02-20].
ACTION krit to remove Backwards Compatibility
<trackbot> Created ACTION-3752 - Remove backwards compatibility
[on Dirk Schulze - due 2015-02-20].
Rossen: Extensibility - I can take this
ACTION BogdanBrinza to add Addendums to the SVG readiness table
<trackbot> Created ACTION-3753 - Add addendums to the svg
readiness table [on Bogdan Brinza - due 2015-02-20].
<heycam> -- 15 min break --
ACTION BogdanBrinza summarize owners for chapters in
[73]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_asse
ssment
[73] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment
<trackbot> Created ACTION-3754 - Summarize owners for chapters
in
[74]https://www.w3.org/graphics/svg/wg/wiki/svg2_readiness_asse
ssment [on Bogdan Brinza - due 2015-02-20].
[74] https://www.w3.org/graphics/svg/wg/wiki/svg2_readiness_assessment
Timeline for SVG2 and modules
Rossen: how about we put timelines/cap on chapters
... next telcon is not goign to happen in next two weeks
... so owners of the chapter need to put items on the agenda
and highlight most critical issues
heycam: we might not cover all things we have on the next call
Rossen: is there anyone who believes we won't meet 3 weeks for
having all of the assessments and starting actual work?
heycam: by March 5th we should have those things listed in
actionable state
... there are couple Appendicies I would propose to remove
... Internatialization support appendix
<heycam> [75]https://svgwg.org/svg2-draft/i18n.html
[75] https://svgwg.org/svg2-draft/i18n.html
cyril: I can add things in Introduction chapter?
RESOLUTION: Remove the Appendix F: Internationalization Support
<heycam> [76]https://svgwg.org/svg2-draft/minimize.html
[76] https://svgwg.org/svg2-draft/minimize.html
ed: next one Appendix G
RESOLUTION: Remove Appendix G: Minimizing SVG File Sizes
heycam: Next one Appendix N: Media Type Registration for
image/svg+xml
... Chris would check where that links to
ed: this might point to latest TR version of it
<cyril> iana link: [[77]http://www.w3.org/TR/SVG/mimereg.html]
[77] http://www.w3.org/TR/SVG/mimereg.html]
<cyril> check this page:
[78]http://www.iana.org/assignments/media-types/media-types.xht
ml#image
[78] http://www.iana.org/assignments/media-types/media-types.xhtml#image
ACTION ChrisL to check and remove Appendix N: Media Type
Registration for image/svg+xml
<trackbot> Created ACTION-3755 - Check and remove appendix n:
media type registration for image/svg+xml [on Chris Lilley -
due 2015-02-21].
ed: Appendix L: IDL Index - do we need this?
krit: this is just an index
heycam: IDL definitions would include all, maybe we don't need
them in two places?
... so let's leave that in place
<heycam> [79]https://svgwg.org/svg2-draft/access.html
[79] https://svgwg.org/svg2-draft/access.html
heycam: next one Appendix E: Accessibility Support
<Rossen> ping
<Rossen> ping
<BogdanBrinz> ACTION Rich to define the further steps for
Appendix E: Accessibility Support
<trackbot> Created ACTION-3756 - Define the further steps for
appendix e: accessibility support [on Richard Schwerdtfeger -
due 2015-02-21].
SVG2 WD publication
<BogdanBrinz> RESOLUTION: SVG WG to publish SVG2 WD
Next F2F meetings
<ed>
[80]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015
[80] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015
<ed>
[81]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015
[81] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015
<ed> [82]https://www.w3.org/2002/09/wbs/19480/Linkoping2015
[82] https://www.w3.org/2002/09/wbs/19480/Linkoping2015
<ed> please sign up
<BogdanBrinz> ed: What is our next after Linkoping?
<BogdanBrinz> Tav: what are the options?
<BogdanBrinz> Rossen: Paris with CSS WG
<BogdanBrinz> all: also SVG Open
<BogdanBrinz> RESOLUTION: Next SVG F2F after June would be TPAC
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
Smoothing in mesh gradients
<Tav> [83]http://tavmjong.free.fr/SVG/MESH_SMOOTHING/index.html
[83] http://tavmjong.free.fr/SVG/MESH_SMOOTHING/index.html
Tav: coons patch meshes suffer from a flaw
... the derivative of the colour profile can have jumps at
patch boundaries
... leading to visible artifacts, bright lines, etc. at patch
corners
... this is enhanced by mach banding, where your eye is caught
by changes in the color profile
... you can see that the color distribution is continuous, but
appears to your eyes that it has bright white bands
... the way illustrator and coreldraw handle this is they
smooth their meshes
... for adobe, when you export the mesh, it subdivides a patch
into an 8x8 array of patches
nikos: I think it might be adaptive
Tav: at least in one example I've seen 8x8
nikos: certainly a lot of patches
Tav: you can see it on the screen
... you can see the little patches
... it'd be nice to be able to do that smoothing in SVG, then
you can reduce the number of patches in the file
nikos: and it means you don't lose the information in the
editor
Tav: so I did some experiments with various smoothing
algorithms
... I show them in 1D
... the top one on that page above is what you get out of a
coons patch mesh now
... you can see the discontinuity
... the first thing to try is a hermite, a simple smoothing
algorithm where the deriviative across the boundary is zero
... it makes the profile within the patch not to be linear
... looks wavy
... next is to try Catmull-Rom interpolation
... that gives you the hermite function, but what you need is
the tangent across the boundaries
... the next three examples on the page does that
... the difference between them is the end treatment
... one doubles the first/last points, one reflects them (the
n+1 point is a reflection of the n-1 point)
... the third is insisting that the polynomial is a quadratic
... so you have the magnitude of two points on one side, and
you have a tangent. you can fit a quadratic to that.
... that seems to be what's happening in illustrator
cyril: I remember reading a paper explaining what adobe was
doing
nikos: by Sun
Tav: the next problem is that Catmull-Rom curves can produce
minimum and maximum values within a patch
... you can avoid that by restricting the tangent to a value
that's 3 times the value of the tangent you get when looking
across the whole patch
... it gives you a monotonic profile
... so you adjust the tangents to get that
... now, looking at 2D
... there is a bicubic-interpolation you can do, which I've
implemented in inkscape
[shows a demo]
scribe: my proposal is to have a patch have a type, default
would be coons patch, second type would be smooth
nikos: this doesn't let you control the gradient across the
boundary
... if you want a sharp boundary you couldn't achieve it
Tav: you could by adding an extra row in
nikos: it'd be nice to have a control
Tav: that complicates things quite a bit
... this is just one flag
... the algorithm is here, fairly easy to implement
nikos: in Illustrator, can you control the gradient?
cyril: no
Tav: this matches Illustrator's behaviour
cyril: calling it "smooth".... "bicubic" would be clearer
Tav: I'm fine with that
... my proposal is to add this and spec it all out
... I've got the formulas and prototype implementation
cyril: you'll turn off all the other modes in inkscape?
Tav: yes that was just for demonstration
cyril: now that the mode does not say "smooth", it'd be good to
ensure we don't preclude adding additional controls in the
future
nikos: the reason we were talking about having different
elements was that otherwise you'd have different attributes
depending on the value of type=""
... if we had smoothing and we wanted to add control points for
the smoothing...
Tav: I don't see it ever happening
... you'd need control points for the three different colours?
... that's an order of magnitude more complicated in editing
nikos: if you give them the raw control, yes it's a lot of work
... but I think you an simplify that through UI for authors
... having a handle to control how far out something is spread
would be useful I think
... I just don't want to not have the option to do that later,
or for it to be a confusing syntax later
Tav: do you have an idea what syntax you would use?
nikos: not at the moment
... even if you controlled the channels separately for the
handles, it's not nice for authors, but could be for converted
content
... vectorised photographs for example
Tav: I'm worried that that will delay meshes
nikos: I don't want to do that
... I really like this proposal
... we should go with it
... I just want to keep the door open to extending without
running into nasty syntax in the ftureu
Tav: you'd have to add a new thing to the patch
... dx/dy for each of the colours
cyril: derivativecontrol="coords"
nikos: would rather have a different element when you have a
different mode
cyril: is this part of the SVG 2 spec?
Tav: it's all worked out, I'd just add it to SVG 2
nikos: I'm OK with having a type="" I think
... if you have something with extra handles you could have a
new element later
... ok
RESOLUTION: We will have a type="smooth-bicubic" or similar on
<patch>
<scribe> ACTION: Tav to add <patch type="smooth-bicubic"> to
the spec. [recorded in
[84]http://www.w3.org/2015/02/12-svg-minutes.html#action18]
<trackbot> Created ACTION-3757 - Add <patch
type="smooth-bicubic"> to the spec. [on Tavmjong Bah - due
2015-02-21].
nikos: because the control is on the patch, you can have a mesh
made of smooth and coons patches
heycam: is that useful?
Tav: no the type="" goes on the <mesh>
ACTION-3757: Actually type="" is on the <mesh> element.
<trackbot> Notes added to ACTION-3757 Add <patch
type="smooth-bicubic"> to the spec..
<cyril>
[85]http://en.wikipedia.org/wiki/Monotone_cubic_interpolation
[85] http://en.wikipedia.org/wiki/Monotone_cubic_interpolation
<scribe> ACTION: Cyril to investigate web-platform-tests for
SVG test suite and write up a wiki page [recorded in
[86]http://www.w3.org/2015/02/12-svg-minutes.html#action19]
<trackbot> Created ACTION-3758 - Investigate web-platform-tests
for svg test suite and write up a wiki page [on Cyril Concolato
- due 2015-02-21].
<stakagi>
[87]https://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview
[87] https://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview
<stakagi> last update : June 2012
stakagi, :)
stakagi, that would be a good page to update
<cyril> [88]http://testthewebforward.org/docs/
[88] http://testthewebforward.org/docs/
<cyril> [89]https://github.com/w3c/web-platform-tests
[89] https://github.com/w3c/web-platform-tests
<cyril> [90]https://github.com/w3c/test-results/
[90] https://github.com/w3c/test-results/
outermost svg element definition
<birtles>
[91]https://svgwg.org/svg2-draft/struct.html#TermCurrentInnermo
stSVGDocumentFragment
[91] https://svgwg.org/svg2-draft/struct.html#TermCurrentInnermostSVGDocumentFragment
<html> <svg><foreignObject><html><svg><svg>
[reads out definitions of "current innermost" and friends]
birtles: I think we can drop half of these definitions
krit: depends where they're used
ed: perhaps this chapter is not where they're used first
<scribe> ACTION: Brian to fix outermost/innermost svg element
definitions, checking where they're used currently [recorded in
[92]http://www.w3.org/2015/02/12-svg-minutes.html#action20]
<trackbot> Created ACTION-3759 - Fix outermost/innermost svg
element definitions, checking where they're used currently [on
Brian Birtles - due 2015-02-21].
-- adjourned --
but first...
motion path
shane: couple of minor issues
<krit> [93]http://dev.w3.org/fxtf/motion-1/
[93] http://dev.w3.org/fxtf/motion-1/
shane: some of these are adding more details/examples
... another is what happens if the position is negative or
exceeds the motion path length
... we've decidd that if it's a closed path it wraps, if it's
an open path it clamps
... we have one about "more natual names" for auto and reverse
... an issue about how to get the position in more detail
... an issue about path transform computation needing to be
more explicit
... and finally do we need to specify an origin of an element
in motion so it can be positioned appropriately
... I think of all of those, the only ones we don't have a good
answer for is the origin one
... I think we should just use transform-origin in this case
... it says in the issue we probably shouldn't, but we should!
... the motion is going to end up in the transform list anyway
cyril: a problem is that the motion animation is an additional
transform
... you could combine those two; if you think they have the
same origin...
shane: the motion path spec isn't a clean drop in replacement
for animateMotion
... you need to be careful about order of application
... and origin setting
... so this is more what the origin should be for a specified
motion path use should be
... I think the simplest thing to do is make it the same as
transform-origin
... if you're generating equivalent behaviour for
<animateMotion>, you might need to fiddle with some
translations
krit: I think we will state this usse on the mailing list again
... but here we just want to note all the open issues
shane: in the absence of significant discussion, I would say
transform-origin we should proceed with
... given this is the only substantive issue, I am asking
whether we should we can have a FPWD of motion animation
RESOLUTION: We agree on a FPWD of Motion Path Module Level 1.
-- adjourn for real --
RRSAgent: make minutes
Summary of Action Items
[NEW] ACTION: Brian to fix outermost/innermost svg element
definitions, checking where they're used currently [recorded in
[94]http://www.w3.org/2015/02/12-svg-minutes.html#action20]
[NEW] ACTION: Cameron to take care of overflow section in the
masking chapter [recorded in
[95]http://www.w3.org/2015/02/12-svg-minutes.html#action14]
[NEW] ACTION: Cyril to investigate web-platform-tests for SVG
test suite and write up a wiki page [recorded in
[96]http://www.w3.org/2015/02/12-svg-minutes.html#action19]
[NEW] ACTION: ed to add use counter for multiple x/y values on
text element [recorded in
[97]http://www.w3.org/2015/02/12-svg-minutes.html#action13]
[NEW] ACTION: heycam to make stable issue identifiers in the
spec [recorded in
[98]http://www.w3.org/2015/02/12-svg-minutes.html#action10]
[NEW] ACTION: heycam to move Catmull-Rom to SVG path module
[recorded in
[99]http://www.w3.org/2015/02/12-svg-minutes.html#action12]
[NEW] ACTION: heycam to spec behaviour of getBBox on text
[recorded in
[100]http://www.w3.org/2015/02/12-svg-minutes.html#action09]
[NEW] ACTION: heycam to update spec for fill dictionary
parameter when called on iframe, canvas, etc [recorded in
[101]http://www.w3.org/2015/02/12-svg-minutes.html#action11]
[NEW] ACTION: jean-claude to further develop the protoype
including with animation support [recorded in
[102]http://www.w3.org/2015/02/12-svg-minutes.html#action01]
[NEW] ACTION: krit to add a new keyword value to the x and y
properties that means use-the-list-of-lengths in the
attributes, and set that with the UA stylesheet and add a note
to say that it's still an open issue [recorded in
[103]http://www.w3.org/2015/02/12-svg-minutes.html#action06]
[NEW] ACTION: krit to make defer be ignored in pAR [recorded in
[104]http://www.w3.org/2015/02/12-svg-minutes.html#action08]
[NEW] ACTION: krit to review the svg2 coordinate chapter
[recorded in
[105]http://www.w3.org/2015/02/12-svg-minutes.html#action07]
[NEW] ACTION: TabAtkins Finish CSS Color 4 (with stuff from
SVG). [recorded in
[106]http://www.w3.org/2015/02/12-svg-minutes.html#action15]
[NEW] ACTION: Tav to add <patch type="smooth-bicubic"> to the
spec. [recorded in
[107]http://www.w3.org/2015/02/12-svg-minutes.html#action18]
[NEW] ACTION: Tav to add line-join:miter-clip to SVG 2.
[recorded in
[108]http://www.w3.org/2015/02/12-svg-minutes.html#action02]
[NEW] ACTION: Tav to add the new Z behaviour. [recorded in
[109]http://www.w3.org/2015/02/12-svg-minutes.html#action03]
[NEW] ACTION: Tav to mail www-svg about the symbol
x/y/width/height issue and report back in two weeks [recorded
in [110]http://www.w3.org/2015/02/12-svg-minutes.html#action05]
[NEW] ACTION: Tav to make miter-limit work on arc line caps in
this way [recorded in
[111]http://www.w3.org/2015/02/12-svg-minutes.html#action16]
[NEW] ACTION: Tav to make the text changes from today's meeting
[recorded in
[112]http://www.w3.org/2015/02/12-svg-minutes.html#action17]
[NEW] ACTION: Tav to update textPath for text on a shape.
[recorded in
[113]http://www.w3.org/2015/02/12-svg-minutes.html#action04]
[End of minutes]
__________________________________________________________
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Saturday, 14 February 2015 01:33:56 UTC