- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 17 Sep 2012 17:31:01 +0200
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
As html:
http://www.w3.org/2012/09/17-svg-minutes.html
as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
17 Sep 2012
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2012/09/17-svg-irc
Attendees
Present
Regrets
Chair
Cameron
Scribe
nikos, ed, birtles, TabAtkins__, heycam
Contents
* [4]Topics
1. [5]Pass Path object to SVG path
2. [6]Linking to external style sheets — should we have
<link>?
3. [7]enable-background naming in relation to compositing
and blending
4. [8]Filter Effects - keep new fe*elements that lack
description ATM?
5. [9]Filter Functions
6. [10]Removing pixelUnitToMillimeter{X,Y} and
screenPixelToMillimeter{X,Y}
7. [11]How to internationalize "title"?
8. [12]Removing pixelUnitToMillimeter{X,Y} and
screenPixelToMillimeter{X,Y}
9. [13]passing path object to svg path
10. [14]new arc command
11. [15]<image> as paint server for SVG (already resolved
to have <gradient>)
12. [16]color interpolation filters for shorthands
13. [17]Perlin noise
14. [18]Need a new filter shorthand for noise?
15. [19]Masking issues
* [20]Summary of Action Items
__________________________________________________________
<trackbot> Date: 17 September 2012
<heycam> Meeting: SVG WG Switzerland F2F Day 1
<nikos> scribenick: nikos
Pass Path object to SVG path
krit: It would be better to discuss this when Tab is here
Topic moved
Linking to external style sheets — should we have <link>?
heycam: I was wondering, in the spec at the moment (1.1), it
says if you want to reference external stylesheets you should
use xml processing instruction
... we should have another way as well
... we at least need to say @import works
... referencing css should get that for free
krit: Is it not possible currently?
heycam: You can't
... you can't use the xml stylesheet processing instruction in
html so we should decide what is the prefered way to link to
external stylesheets
... one option is to have link in svg, just like in html
birtles: yes
ed: What would happen if you copy pasted svg with link element
into html5
... link is current an html element so if you pasted svg that
is using it into html would it go back to html?
... you can create it with the dom or put it in a foreignObject
heycam: it seems to work in firefox
... I was testing whether the parser breaks out into html
<heycam>
[21]http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!
DOCTYPE%20html%3E%0A%3Csvg%3E%3Clink%3E%3Cscript%3Ew(document.g
etElementsByTagName(%27link%27)%5B0%5D.namespaceURI)%3C%2Fscrip
t%3E
[21]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Csvg%3E%3Clink%3E%3Cscript%3Ew(document.getElementsByTagName(%27link%27)%5B0%5D.namespaceURI)%3C%2Fscript%3E
shepazu: Isn't there a white listing of svg elements? or is
that just for changing case?
heycam: Yes, just changing case
krit: what happens if you move the node in the DOM?
heycam: I think the link element in the html namespace doesn't
have any effect at the moment
... if you try and reference some stylesheet would it work?
... it looks like the way it behaves is - you can have it
anywhere in the document
... if we want it to work we specify it the same way except
it's in the svg namespace
... I think we are eventually going to have a bunch of these
elements that either share or that can work in both svg and
html namespaces
krit: I'm just testing safari, if you put a link elements it's
in the svg namespace
heycam: what do you think of the idea dirk?
krit: I like it but I'm wondering what happens when you move
nodes in the DOM
... I'm a bit afraid the namespace won't change if you move it
in the DOM
heycam: nothing changes automatically when you move it
krit: and is that ok?
shepazu: henri will complain about changes to the parser - are
there any?
heycam: not for this because it's already in the svg namespace
... maybe it would be a problem if it broke out
krit: I wish to have the link element
heycam: it gets put in the html namespace
... you can't declare namespaces explicitly but the dom nodes
get created in the namespace
shepazu: I think the reason for doing it this way is to allow
authors to do it without thinking about it - they already know
how to do it in html
heycam: I think it would work nice and obviously
cabanier: it works in Chrome
shepazu: if that's true, we should match that user agent
heycam: I couldn't get it work in Chrome
cabanier: I know it loads the sheet (can see it in the
debugger) but I don't know if it applies it
... so it's like half implemented
<ed>
[22]http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!
DOCTYPE%20html%3E%0D%0A%3Csvg%3E%3Clink%20rel%3Dstylesheet%20hr
ef%3D%22data%3Atext%2Fcss%2Ccircle%20%7Bfill%3Agreen%7D%22%20ty
pe%3D%22text%2Fcss%22%20%2F%3E%3Ccircle%20cx%3D50%20cy%3D50%20r
%3D20%20fill%3Dred%20%2F%3E
[22]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Csvg%3E%3Clink%20rel%3Dstylesheet%20href%3D%22data%3Atext%2Fcss%2Ccircle%20%7Bfill%3Agreen%7D%22%20type%3D%22text%2Fcss%22%20%2F%3E%3Ccircle%20cx%3D50%20cy%3D50%20r%3D20%20fill%3Dred%20%2F%3E
heycam: anyone think it's bad idea
all: no
shepazu: we should ask the html working group
heycam: we should ask them if there is anything we haven't
thought of
Resolution: We will add a link element to SVG that behaves in
the same way as HTML
<scribe> ACTION: Cameron to email the HTML and WhatWG working
groups to ask if there any problems related to adding the HTML
link element into SVG [recorded in
[23]http://www.w3.org/2012/09/17-svg-minutes.html#action01]
<trackbot> Created ACTION-3351 - Email the HTML and WhatWG
working groups to ask if there any problems related to adding
the HTML link element into SVG [on Cameron McCormack - due
2012-09-24].
enable-background naming in relation to compositing and blending
cabanier: The name is a bit confusing
... it doesn't match what users are familiar
... in the compositing spec it was replaced with isolation
... so we have the existing enable-background keyword, we can't
get rid of it or it will break content
... we were thinking of having it shadow
... like an alias
krit: css wg tries to define shadowing properly
... they have the same problem for some text properties
nikos: we are thinking that the property should apply to
compositing and blending and filter effects
... you shouldn't be able to specify different modes for each
heycam: so there's 2 issues really, having the property apply
to both and the naming
... do you have an example of css shadowing?
krit: not yet, we don't have a specification, but the css wg
have expressed an interest in the idea
heycam: what about if you use the css om to look up property
values?
... like there's a single variable underneath but there's 2
properties
krit: the question is which takes effect if both are specified
cabanier: I think the last one wins
... what happens currently if you say 'opacity=1 opacity=0.5'?
heycam: what happens currently for prefixed and not when you
support them both?
krit: they are both in the style declaration as far as I know
heycam: with one underlying variable?
krit: I'll have to check
heycam: I assume the css working group wants to define how this
works and not us
cabanier: so are we ok combining them?
heycam: I think so - as long as enable-background works for
existing things
... so enable-background has numbers when you specify new? or
did we get rid of that
krit: we got rid of that
... looking at the source code - we treat them as different
properties
... for box-shadow and webkit-box-shadow we have two different
style declarations
... you can set box-shadow and webkit-box-shadow and they can
be different
... when rendering one will win but I'm not sure which
heycam: I think that as long as it is worked out then I'm ok
with it
cabanier: do we know who is working on the shadowing?
krit: no, we'll have to ask
Resolution: We want isolation property to shadow
enable-background and we will ask the CSS working group about
the details
<scribe> ACTION: Rik to ask CSS WG about how shadowing will
work for enable-background [recorded in
[24]http://www.w3.org/2012/09/17-svg-minutes.html#action02]
<trackbot> Created ACTION-3352 - Ask CSS WG about how shadowing
will work for enable-background [on Rik Cabanier - due
2012-09-24].
krit: I think we will put both properties in Filter Effects and
mark one as preferable
nikos: So is it ok for one property to control both
filter-effects and compositing and blending?
all: yes that's ok
Resolution: The enable-background/isolation will apply to both
Filter Effects and Compositing and Blending
Filter Effects - keep new fe*elements that lack description ATM?
<krit>
[25]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#feUnsharpMaskElement
[25]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feUnsharpMaskElement
<krit>
[26]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#feDiffuseSpecularElement
[26]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feDiffuseSpecularElement
krit: We have different filter effects that lack definition and
I would like to know if we want to keep them and add
description or is it not neccesary?
... I'm just talking about filter primitives and not the
shorthands
cabanier: does anybody implement these?
krit: no
... we are about to implement feCustom
heycam: who wanted them ?
ed: diffuse specular was meant to be an optimisation to give
better performance
... I'm not sure if it's really needed as the implementation
can analyze the filter chain and do the same optimisation
heycam: would it make it better for authors?
ed: probably not
heycam: I say get rid of them then
ed: I don't mind removing them if they don't seem to be useful
... you could do feUnsharpMaskElement with scripting and other
filter effects
... but we don't have a shorthand for it
Resolution: Remove feUnsharp and feDiffuseSpecular from Filter
Effects specification for now - may be added again in future
<krit>
[27]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#FilterFunction
[27]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction
Filter Functions
are other shorthands needed?
krit: The question is do we put in a bug report on Safari for
functions that are not implemented?
... I had suggestions for other filter functions that we could
have, but I have not had any feedback
... so I'm wondering if we can remove the issue
heycam: it doesn't hurt to keep it in, but if you're wanting to
finalise and go to last call then you can remove it
krit: there's no problem adding new shorthands in the later
version
... the question is do we freeze what we have now?
heycam: I think the set that is there currently is a reasonable
set
Resolution: Remove filter function suggestions (issue 5) from
Filter Effects spec
<scribe> ACTION: Dirk to file a bug and track filter functions
(issue 5) removed from Filter Effects spec [recorded in
[28]http://www.w3.org/2012/09/17-svg-minutes.html#action03]
<trackbot> Created ACTION-3353 - File a bug and track filter
functions (issue 5) removed from Filter Effects spec [on Dirk
Schulze - due 2012-09-24].
Removing pixelUnitToMillimeter{X,Y} and screenPixelToMillimeter{X,Y}
heycam: I didn't know this existed and I'm not sure anyone
would use these API functions
krit: Is anyone using them?
heycam: I'm not sure, I can check.
andreas: is there an alternative way to get at the pixel size?
heycam: I think not but I think it's been discussed in the CSS
WG whether you should access the real DPI and do something
based on that
cabanier: you mean the HD stuff?
heycam: I'm not sure
krit: so why do you want to remove it?
heycam: our implementation returns a constant value assuming 96
dpi.
cabanier: what does webkit do?
krit: the same thing
cabanier: it could be implemented to not be constant in the
future - for HD devices
krit: the idea is that we want to know how many mm it is on the
screen
heycam: I remember people objecting to that in some other
context
cabanier: how do you know what the screen size is?
krit: Firefox used to expose that information in an API but
removed it.
heycam: now everyone has converged on CSS units being a fixed
number of pixels
krit: the problem is that some platforms don't give you the
exact DPI, so it could not be implemented on some platforms
heycam: I think one of the problems with physical units is you
want to know it for different reasons - like touch events
(finger size) and font size (but how far away are they from the
screen)
krit: I don't know how they would be used
shepazu: you'd be surprised - some people implement for one
browser and if it's implemented in one browser it gets used
ed: Opera is hard coded also
... I think it's the same value as other implementations
krit: the css working group is looking into ways to get screen
pixels per CSS pixel.
heycam: but it doesn't tell you the physical size
cabanier: are you going to remove pixels per inch as well?
heycam: yep there's not 4 methods
cabanier: I think somebody somewhere is using them
ed: I'd be surprised to see them used
heycam: I just googled screenPixelToMillimeterX and got no hits
... with svg file types
cabanier: I wonder if they will become more useful
... in future
heycam: I would like to ask the CSS WG what they think about
units
krit: the question is how to get the physical size, but I don't
think the CSS WG is working on that
heycam: the topic about mm not being real mm anymore comes up
often and I'd like to know the details
... is it because it's probably not what authors want
krit: if I say 2cm but then project it on the wall I don't want
it to be 2 cm
heycam: I'll ask Chris
How to internationalize "title"?
Tav: This came up at SVG open. Someone was asking whether it
could be done.
heycam: My first suggestion would be to allow system language
on the title element.
ed: that's already done isn't it ?
heycam: I'll look
... The question is how to internationalise the title
shepazu: how about we use switch?
Tav: how would it work?
shepazu: you would have the switch element with different
copies of the titles
heycam: what is switch a child of ?
shepazu: how about we change switch to allow text content ( if
it doesn't already)
... I think switch only works at an element level now and not
at a text level
... I think we should change it to text
... then you would switch on the actual text content rather
than on the element
... title would be a child element
krit: can you change paragraphs in HTML to change content based
on the language?
shepazu: there is no mechanism for doing that
... since we are changing switch anyway, we could add something
like a span that is basically meaningless? We have tspan - it's
not a child of title
... we have a few options
... we can change switch to have text content, but what is the
child element of the switch
... we can change title apply to the parent of the switch
... if title is encased in a switch element it jumps up one
level - the switch is transparent in regards to the title
Tav: what about the desc element?
shepazu: or tooltip, or whatever
... they'd be the same
heycam: on switch you can have all the group attributes.
shepazu: people shouldn't use switch for that - you can but you
shouldn't
... switch should be transparent
heycam: I think you should be able to do multiple title
elements
... like <rect><title systemLanguage="..." />
... or have language tags which are subsets
... we could resolve that the first title element that matches
the conditional processing attributes is used
... if you want a fallback you have a title without conditional
attributes
<ed> just playing a bit with the systemLanguage:
[29]http://jsfiddle.net/YueKQ/
[29] http://jsfiddle.net/YueKQ/
heycam: and resolve that only one title applies to an element
shepazu: that's good. So we'd be getting rid of the switch
element for this case
... we should tell people, for legacy reasons, always put the
default first
krit: and instead of systemLanguage can we just use lang?
shepazu: it might not be the system language it might just be
the language of preference, so that sounds like a good idea
... we can change it in switch as well
... anything camel cased needs to die, die, die, die, die!
... I agree with something short but we'd be overloading lang
then
... but that's actually useful
... the problem is, what happens if you do
<text> <tspan lang="de">Hallo</tspan><tspan lang="en">he
said....
heycam: I would be fine with allowing lang on title as a
special thing
shepazu: it seems strange
krit: in general you can just display one title
shepazu: are we going to generalise this and get rid of the
switch element in other circumstances?
heycam: I don't think it would work in other cases
shepazu: ok I'm fine with it for any meta element (description
also)
... we are giving special characteristics to title with respect
to what the language is
heycam: I'm ok with that
... I think systemLanguage makes more sense with the current
functionality but lang looks nicer
shepazu: lets leave lang as a special meta data thing that is a
special case of switch
ed: for title it works not sure about desc
Tav: how is title as an attribute different from title as an
element?
... do the browsers treat it differently?
shepazu: We just hint what you should do
heycam: one of the arguments of having title as an element is
good for languages which require disambiguation of direction
... svg doesn't have the elements to control that so I think
it's a moot issue for us
... what about if we had title as a property?
shepazu: that would promote poor practice for
internationalisation
heycam: I don't know if you'd want to download a big file with
lots of languages
shepazu: I quite like using many languages in SVG. it wasn't
designed to be text heavy.
... one thing we didn't talk about is - a common workflow for
skins is to point to an external resource for the languages
... it looks up the value and inserts it. We could enable
something like that for SVG
... people could point off to their text file that contains
different languages
heycam: I think you could already do that for text other than
title
shepazu: we should define how that happens
heycam: it's defined.
shepazu: We should give examples of how it works to promote
best practices
... it could be an href like tref and if it's defined you go
and retrieve it and thats where all the switching stuff is
done.
... if it doesn't get the file then it could use the default of
what you put in the <text>
... I think it would allow people to customise these things
more easily - it's just a proposal
Tav: allowing lang on title solves the use case that was put to
be at SVG open
krit: so the first title doesn't need a lang but the rest do?
heycam: current implementations look at the first title only,
so if you are happy having that as a fallback that will always
work you need to put it first
and then you could still put lang on it if that's what you want
for the default
heycam: the issue is, I think, if you have the first title and
it has an obscure language, you don't want that to be the
default in the new system if other languages are provided
krit: I don't agree,
shepazu: for implementations that support this it will check
every language and display the first match
... so it has the behaviour you want
... it's just for legacy purposes the default is the first
krit: that's ok
heycam: the only downside is the order checking is different
from switch
shepazu: it's not switch though it's something different
Resolution: Add lang to title and desc
<TabAtkins> Ugh, I slept straight through my alarm, wow. Where
are we? Like, physically?
<TabAtkins> kk
<scribe> ACTION: Tav to add lang to tile and desc [recorded in
[30]http://www.w3.org/2012/09/17-svg-minutes.html#action04]
<trackbot> Created ACTION-3354 - Add lang to tile and desc [on
Tavmjong Bah - due 2012-09-24].
Removing pixelUnitToMillimeter{X,Y} and screenPixelToMillimeter{X,Y}
andreas: I did some reasearch
... there's a property you can create in Javascript called
window.devicePixelRatio
... Opera supports it but it has a different value than WebKit
... that's all I've really found that does that
Tab: It's a proprietary webkit thing right now
<andreas>
[31]http://www.quirksmode.org/blog/archives/2012/06/devicepixel
rati.html
[31]
http://www.quirksmode.org/blog/archives/2012/06/devicepixelrati.html
Tab: I think if they're use-less remove them but they could be
useful since we have the possibility of non-square pixels
nikos: would it be more useful to just get the ratio and not
worry about the size?
Tab: I think getting the X width is the most useful and then Y
could either be an actual height or a ratio
heycam: this seems to be a bit different since the SVG
functions relate to a specific size on the screen rather than a
ratio
<ed> scribeNick: ed
passing path object to svg path
<krit>
[32]http://www.whatwg.org/specs/web-apps/current-work/multipage
/the-canvas-element.html#path
[32]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
DS: in html canvas we have an interface to build a path object
... would be good if we could get the path and pass it to the
svgdom
... to append to the svg path
CM: can it serialize to the svg pathstring?
DS: no, there are some differences
... arcto for example
... suggest we leave it up to the browser to normalize the path
... and not specify exactly how
CM: i think it should be specified
RC: if you draw a circle it stores a bunch of bezier curves
... so if you read the path out it looks ok, but it's no longer
a circle
doug: so if I do a circle in skia and a circle in cairo i would
get the same result?
DS: might be different, but should look the same
doug: is this exposed to the user?
TA: the UA would need to remember the original commands,
doesn't do this atm
DS: i'd prefer the first version to not specify the
normalization
CM: i don't like it
TA: if you're doing it in script you're going to have to do it
anyway
BB: scripts handle one segments produces in one browser, that's
how most authors work
Doug: experienced that with freaky mouth example, didn't work
in opera due to how path normalization worked there
CM: we could require one or more beziers
... not knowing how many you get
Doug: doesn't help the author at all
CM: the predictable thing is that you'll get a number of
beziers
doug: think about animation
DS: we could specify how arc is normalized, as quadratic curves
TA: all implementations support cubic beziers
CM: why not have a configurable thing to store the original
path commands?
TA: we should specify how many beziers an arc gets turned into
BB: is there a concrete usecase for this? or is this just about
the procedural api for creating the path?
TA: i think the api is a use-case
BB: we could just support the canvas path api in svg
TA: the path is a toplevel global api, so you can create the
path object without having a canvas
... will break paper.js, but that's fine, will just shadow the
native interface
CM: there's an interface CanvasPathMethods that we could
inherit
... to have them directly on the <path> element
DS: but then you can't use this to create a canvas path, and
reuse the path object
RC: you can contruct it with an svg path string
TA: we could also make it serialize out to something that works
in svg path@d attribute
DS: like that idea
... but it doesn't make sense that it has to serialize and then
reparsed by svg
ED: agree
Doug: element.addPath(obj) to append that path
... you might want to animate and reuse and so on
CM: how would you get arcs?
... with the procedural api
DS: you can't, you'd get cubics back
Doug: everybody hates the arc syntax in svg
... with catmull-rom we thought to translate that into beziers
anyway
... you should be able to find out what it converted to
<shepazu> shepazu: and you could chain commands
CM: would like the native api to be able to create the native
path commands, like arc, catmull-rom etc
... so if I create an arc with the API and put it into an svg
<path> element that the arc is still an arc
DS: but then the mapping isn't 1:1
CM: you can't tweak everything afterwards if it's normalized
... but the arc syntax might be different betweent the api and
the svg commands
doug: there should be a way to get the non-normalized path out,
you should be able to get both that and the normalized variant
TA: we want to normalize (which needs to be specified)
lineto,moveto, cubic beziers and close path
CM: i want to be able to say .arc and have that turn into arc
command
TA: why? the syntax is different
CM: if we have the nicer path syntax in svg then we could have
a direct mapping
TA: so taking the path commands and adding it to svg, plus
extending the api?
CM: as long as it's possible procedural things and get the
actual path commands
(discussion on spec stability)
TA: the path object stringifies to a normalized path string
CM: how many beziers does an arc get turned into?
TA: needs to be specified
RESOLUTION: we want to add a stringifier on the path object
that returns a string using normalized svg path syntax
... svg path elements gains a addPath method that appends path
object to the path
CM: does canvas paths need to start with a moveto?
TA: not required, starts at 0,0
... some things start implicit subpaths
... e.g the rect command
<heycam> String(new Path("M … A …"))
<heycam> normalizes the path back to an SVG path segment list
RESOLUTION: it will be possible to normalize explicitly and
stringify the result
<TabAtkins> (new Path().addPath("M... A...")+''
<TabAtkins> (new Path()).addPath("M... A...")+''
RESOLUTION: there will be a method that normalizes any svg
shape into a path object
BB: so adding the canvas api methods to the svgpathseglist
TA: if we put it on the path element id' expect it to be
normalized
... but if we put it on the svgpathseglist then i'd expect
non-normalized
CM: where you put the interface is just baout how much you want
to help the authors
TA: so seglists could be smarter
CM: seems confusing
BB: i do want a simple api, but avoiding duplication is maybe
better
CM: e.d.arcTo(...)
... e.arcTo(...)
... think the second one is not necessary
RC: if you do addPath it works
CM: i'd like to be able to set the svg path from a string
directly
BB: think it should be on the seglist interface
CM: so adding addPath to the svgpathseglist
DS: i think it should be on the path element
CM: think it makes sense to have all path manipulations on the
svgpathseglist interface
DS: what's on the svgpathseglist api now?
TA: path manip methods
DS: doesn't quite fit tehre IMO
CM: BB thinks it'd be more useful to have retained pathseglists
... without having it attached to a path element
... so the worry is that we'll have two such path object
representations (svgpathseglist and the path object)
BB: who's going to revise the path apis in svg?
CM: i think i have an action to do that
<scribe> ... new SVGPathSegList(canvaspath)
Andreas: does addPath start a new subpath?
Doug: you can use clear to clear out the path so that you can
have a blank canvas to draw on
... addPath will add a new moveto, but what if you want to add
commands to that?
... to a existing path
CM: you could stringify and strip out the movetos
Doug: couldn't we just have addSegment to just append/continue
the path?
... could we make addSegment strip out the implicit path API
moveto?
... usecase: to append segments to an existing path
TA: you don't know if the moveto was explicit or implicit
... due to normalization
... i want addPath and extendPath
... extendPath cuts off the first moveto
RESOLUTION: add extendPath - which acts as addPath but trims
off the initial moveto
doug: so are we adding arcTo?
... and what do we do with catmull-rom?
CM: these new commands should be on the canvas path api so both
can use them?
doug: yes, sounds useful for both
RESOLUTION: add new procedural methods for catmull-rom and add
canvas-like arc commands in svg path syntax
CM: there are arc and arcto, and ellipse
TA: arc and ellipse use startangle,endangle
RESOLUTION: add a 'd' property to the svg path element for
accessing the pathseglist
BB: allow svgpathseglists to be created independent of the svg
path element
... allow assigning a pathseglist object ot the path element
(pathelm.d = seglist)
doug: should have a json serialization of the path, in addition
to the stringification
CM: someone has requested toJSON for passing objects around,
e.g for web workers
BB: to be able to set and get an array of floats
... you already have normalization for moveto, lineto,
closepath
... faster with float arrays than to use pathseglist
CM: so, stringifier, jsonifier, and pointifier?
BB: there are a number of ways you could do this
... there are libs that work on arrays of points directly
... you're really working on arrays of arrays
CM: for subpaths you could flag it somehow
TA: boolean at the end?
BB: needs to be there when you set it back again
CM: alternative is to have a function isSubpathClosed, and pass
in the subpath
BB: that's a bit less flexible
... want to just read out the point array, manipulate and set
it back
TA: so you have an array of points per subpath
BB: and you have array of subpaths, which each haven array of
points
TA: so defer until we get some feedback on this, on the list?
CM: the json thing then...
TA: not quite ready to resolve on that yet, but similar to the
array one, should probably be discussed on the list
-- 1h break for lunch --
<birtles> scribenick: birtles
new arc command
heycam: problem is the existing arc is unintuitive and you
often want to animate the angles of arc rather than the
endpoints
... it's really hard with declarative animation
... you have to do all the trig yourself
... which of the canvas arc commands let you specify the angle?
TabAtkins: arc and ellipse are basically the same...
... arc(x, y, radius, startAngle, endAngle, acw)
... coordinates are absolute
... ellipse is the same but the radius has x and y and a
rotation argument
... arcTo is a separate command that takes...
heycam: is the implicit start point on the circle?
cabanier: no, it automatically draws a line to the start of the
arc
TabAtkins: arcTo is a little more interesting...
... it does a straight line segment but it provides C1
continuity
... arcTo(x1, y2, x2, y2, radius)
... (draws a diagram explaining how arcTo works)
shepazu: I'd like to add a rounding algorithm to SVG based on
this mechanism
TabAtkins: there is no rounded rect, you just use four arcTo
commands
... there are the two arc commands in canvas
krit: but are we running over the letters in the alphabet in
the SVG path syntax?
TabAtkins: but we could allow identifiers that are more than a
single letter
shepazu: we could just say "arc"
heycam: is it useful to have both?
everyone: yes
TabAtkins: we could just have "arc" and "arcTo"?
heycam: are you sure we don't want to use single letters?
... what about "e"?
krit: that conflicts with scientific notation
(which is now in CSS by the way)
TabAtkins: I don't think we can continue with single letters
heycam: what about leading punctuation?
ChrisL: we've talked about having longhand before
shepazu: it's also better for compression
(talking about using expanded elements for path commands)
heycam: so use "arc" and "arcTo" as the commands?
TabAtkins: I'd be inclined to call them "circle", "ellipse" and
"arcTo"
... so that we can use "arc" later as a longform for the
existing arc command
heycam: it might be more important to match the command name
with the method
... rather than accommodating the existing arc command
... we could give it some other name in the future
ChrisL: do we want to deprecate the existing arc command?
TabAtkins: no, it's sometimes useful
ChrisL: ok
TabAtkins: ok, let's keep consistency with the canvas method
names for now
ChrisL: we should have a resolution about whether we want the
longhand form or not
TabAtkins: need to decide priorities (when you have both)
heycam: it seems like a lot of duplication when sometimes it's
probably easier just to separate out paths of the path string,
rather than having 10 new elements
ed: like having a fragment of the path as a separate element
ChrisL: I think we'll probably have that too
... but we've often been asked for the verbose form
... the two big advantages are (a) better compression, (b)
adding IDs / event handlers to specific parts
(discussion about whether we could stroke sections differently)
krit: what about adding length (units) to the path data
ChrisL: when we originally considered that there was feedback
that said that was really difficult
heycam: what about percentages?
krit: percentages are difficult, just lengths would be enough
heycam: percentages would be useful
TabAtkins: what measure do you resolve against for a diagonal
line
heycam: depends which coordinate of the command
... if it's the y coord it is resolved against the height
... since unit identifiers are currently more than one letter
there shouldn't be clashes with the path commands?
shepazu: using units in paths has often been requested
... sometimes this is because people don't understand how to
set units at the root
... but percentages are often valid
krit: when are percentages are resolved?
TabAtkins: if it's created in JS, what do you resolve the
percentages against?
heycam: it's similar to creating SVGLength objects
... what do they get resolved against?
... using createSVGLength
... we never really resolved how that should work
RESOLUTION: We will add arc, ellipse, and two forms of arcTo to
the SVG path syntax based on the canvas methods of the same
names
TabAtkins: the only remaining command on canvas that's not
available with the d attribute is "rect"
ChrisL: what do we need to spec out with regards to that
resolution
heycam: DOM API etc.
TabAtkins: it would be nice to make the "d" attribute of the
SVGPathElement return a sane version of SVGPathSegList
... (and not just an alias of pathSegList)
krit: does this work for repeated commands?
... since the number of arguments to arcTo varies
TabAtkins: arcTo comes in a 5 arg and a 7 arg version
ChrisL: we could solve it by giving them different names
... or just say you have to repeat the command
TabAtkins: what if we have ellipseTo
ChrisL: and just document what ellipseTo equates to in canvas
terms
... then you wouldn't have to have an exception where these
commands can't be repeated
heycam: we should look into adding ellipseTo to canvas (as an
alias to the equivalent arcTo command)
TabAtkins: I'll propose it
<scribe> ACTION: Tab to propose to the HTML WG that the 7
argument form of arcTo be replaced with an ellipseTo method
[recorded in
[33]http://www.w3.org/2012/09/17-svg-minutes.html#action05]
<trackbot> Created ACTION-3355 - Propose to the HTML WG that
the 7 argument form of arcTo be replaced with an ellipseTo
method [on Tab Atkins Jr. - due 2012-09-24].
(this is because the elliptical version of arcTo is not
implemented anywhere so we are still free to change the name)
heycam: I'll try to write this up in the spec since my name is
down next to this item in the requirements list
ChrisL: what about lengths and percentages in paths?
krit: I'm still not sure about how you resolve percentages
TabAtkins: let's defer percentages to further discussion on the
list and just stick to lengths for now
heycam: em units still need a context
TabAtkins: you can resolve against a default font size
heycam: what about calc?
TabAtkins: it's not problematic by itself
... only if one of its components is a length we can't resolve
heycam: more discussion is needed on lengths
... particularly for what to do when you don't have a context
for resolving against
... what about points on a polyline?
krit: yes, since we have that for shapes in CSS
<scribe> ACTION: Dirk to tell the CSS WG that we changed the
SVG path syntax [recorded in
[34]http://www.w3.org/2012/09/17-svg-minutes.html#action06]
<trackbot> Created ACTION-3356 - Tell the CSS WG that we
changed the SVG path syntax [on Dirk Schulze - due 2012-09-24].
<scribe> ACTION: Dirk to prepare a proposal for supporting
lengths/percentages in paths and polylines [recorded in
[35]http://www.w3.org/2012/09/17-svg-minutes.html#action07]
<trackbot> Created ACTION-3357 - Prepare a proposal for
supporting lengths/percentages in paths and polylines [on Dirk
Schulze - due 2012-09-24].
ChrisL: what about element syntax for paths?
TabAtkins: I think it's useful
<scribe> ACTION: Chris to produce a proposal for expanded
element syntax for paths (including finding the results of
testing improved compression ratios with the expanded syntax)
[recorded in
[36]http://www.w3.org/2012/09/17-svg-minutes.html#action08]
<trackbot> Created ACTION-3358 - Produce a proposal for
expanded element syntax for paths (including finding the
results of testing improved compression ratios with the
expanded syntax) [on Chris Lilley - due 2012-09-24].
cyril: I think it's good to be able to break paths into
fragments but not necessarily an element per point
ChrisL: it wouldn't be per point but per command
heycam: sometimes you don't want to go down to individual
commands but just fragments
... it would be nice to use the same mechanism for that
shepazu: it would be nice to refer to segments and include them
reversed etc.
ChrisL: if you have multiple paths and you want to combine
those to make one path you sometimes need to reverse a segment
shepazu: it would be nice to be able to get the geometry of the
reversed version
cyril: if we have elements for each command, you'd end up with
a lot of DOM nodes
... is it worth having the parse collapse them?
TabAtkins: no, you don't want the parser doing that kind of
special magic
everyone: no magic
andreas: what about polar coordinates?
heycam: we rejected the request for polar coordinates in
transforms
... in place of that we have proposed the turtle graphics which
solves many of the cases but not all
ChrisL: it reminds me of the syntax used in Raphael which
provides a SVG path-like syntax for describing transforms
krit: polar coordinates are definitely useful...
... but then the whole coordinate system should be in polar
coordinates
... otherwise you have to map them
andreas: sometimes you have a series of survey results that are
best described using polar coordinates, like a cave
... everything is relative to the last position
... it's typically a series of straight line segments and
rotations
heycam: that should be possible using the turtle graphics
command
... but polar coordinates in general are difficult and we
rejected that requirement
(description of turtle graphics proposal, the 'r' and 'R'
commands)
(now talking about Catmull-Rom curves)
shepazu: adding a segment affects the previous segment
... and you need two endpoints
... so if you start with a P command (the Catmull-Rom command)
you can't draw the curve until you get a second point
ChrisL: with regards to the issue of segments affecting the
previous segment, if you duplicate the points of the last
segment (i.e. a zero-length segment which degenerates to a
straight line segment) it won't affect the previous segment
<image> as paint server for SVG (already resolved to have <gradient>)
krit: we already allow <gradient>
... and we resolved how it applies to path elements
... and it's not limited to gradient box (as defined in CSS)
TabAtkins: in CSS gradients are infinite
... but they get chopped to their box
... but SVG can define gradients so that extend to infinity
... but other image types can't be trivially extended in the
same way
ChrisL: in SVG 2 we could also have a painted bounding box (aka
decorated bounding box)
... we could use that instead
shepazu: i.e. use that instead of the gradient bounding box
cyril: but with an image you can say that it only fills 50% of
the box
... how do you fill the rest of the object?
krit: not at all
ChrisL: transparent black
TabAtkins: CSS lets you specify repetition etc.
... if we wanted to do that in SVG we'd have to make fill etc.
a shorthand
... or we could specify those properties when specifying a
paint server (e.g. a pattern)
ChrisL: there's another consequence of this painted bounding
box
... previously if you had a gradient on a horizontal line you'd
end up with nothing unless you special case it
... but if you use the painted bounding box you can get around
that
krit: what if you have a rectangle that you stroke
... you stroke it with an image
... if you use the geometric bounding box only half the stroke
gets painted
TabAtkins: what about backwards compatibility about using the
painted bounding box
shepazu: you'd use the geometric bounding box for existing SVG
gradient elements, and the painted bounding box for CSS
gradients
(discussion about providing a new keyword like
objectBoundingBox when defining an SVG gradient so it can use
the painted bounding box)
TabAtkins: that's important since we also want to be able to
use SVG gradients in CSS
(discussion about the definition of the decorated bounding box)
TabAtkins: when using a CSS gradient function in SVG, do we
want stroke to use the painted bounding box and the fill to use
the geometric?
ChrisL: I'd like to have the flexibility to use both
TabAtkins: I think fill should default to geometric and stroke
to painted
... in summary, we want to expose the ability to switch between
geometric and painted bounding boxes
... we will add an optional keyword to the fill/stroke
properties to allow switching between the two
... with appropriate defaults for each (specifically fill =
geometric, stroke = painted)
heycam: what about markers?
... are they included in the calculation of the decorated
bounding box (as they are in the DOM method)? it might be less
useful when stroking to include markers
... it needs more thought
TabAtkins: for stroke, the default is the painted bounding box
... but when referring to an SVG gradient element it will defer
to an attribute on the gradient specifying which bounding box
to use
... and *that* will default to the geometric bounding box for
backwards compatibility
... just like we're doing with maskign
s/maskign/masking/
scribe: for the more general issue of the CSS <image> type...
... if you draw a gradient using the geometric bounding box
... it will size itself using the inner bounding box but it
still can extend beyond that box
... the gradients are defined such that they extend infinitely
... then CSS just clips that result
... but SVG might not do that
... what do we do outside the box for other CSS image types
... do we just paint them as transparent black?
(other CSS image types being all those other than gradient
functions)
scribe: if you want it to repeat, put it in a pattern and use
that
... CSS just defines that outside the box you're transparent
black unless you use background properties to repeat the image
heycam: the alternative is to introduce background-repeat etc.
into SVG
... and I'd rather not do that
TabAtkins: me too, use patterns for repeating
RESOLUTION: We will add a control to fill and stroke to
determine which bounding box (geometric or decorated) to use
for sizing paint servers
<cyril> for sizing and positioning too
RESOLUTION: We will add attribute to the existing paint servers
in SVG defaulting to the geometric bounding box (like the
maskType attribute)
... When using CSS image types that are finite in extent are
expanded to infinity by using transparent black (not by
repeating the result)
s/extent are/extent, they are/
<scribe> ACTION: Tab to amend the definition of fill,stroke in
SVG to allow the CSS <image> type [recorded in
[37]http://www.w3.org/2012/09/17-svg-minutes.html#action09]
<trackbot> Created ACTION-3359 - Amend the definition of
fill,stroke in SVG to allow the CSS <image> type [on Tab Atkins
Jr. - due 2012-09-24].
heycam: is there a clash since fill,stroke already take a URL
but so does the <image> type
... are the mechanics for how you interpret it different?
TabAtkins: it should be ok
birtles: it's the same for masks
... you have one behavior when you refer to a whole document
(a.svg) vs an element within a document (a.svg#mask)
<TabAtkins__> ScribeNick: TabAtkins__
color interpolation filters for shorthands
krit: Currently we have the color-interpolation property for
all filters.
... How do we apply it to the shorthand functions?
heycam: Would you normally want to apply it to specific filter
primitives?
chrisl: In general you want to do linear, but there are cases
where you want to stay in the sRGB as you pass values between,
to avoid loss.
krit: For shorthands, we're okay with just using the default
colorspace. If you want different shorthands, use the SVG
<filter> element.
<nikos>
[38]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#ShorthandEquivalents
[38]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#ShorthandEquivalents
<krit>
[39]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#FilterFunction
[39]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction
krit: [lists the shorthand functions]
... So, first question, are we okay with saying that the filter
shorthands just use the default colorspace?
RESOLUTION: Filter shorthands only use the default colorspace
(*not* the current value of 'color-interpolation-filters' on
the element, either).
krit: Note, obviously, that you can use an SVG <filter> (with
color-interpolation set on the <filter> element or the
subfilters) and then reference it with url().
Perlin noise
krit: Do we want to add a new type of noise function that is
easier to hardware-accelerate?
ChrisL: In addition to existing turbulence, or replacement?
TabAtkins__: Addition - too much content already relying on it.
<ChrisL> ok good
ChrisL: Is there a definition for the algorithm that's free?
krit: We need to decide on the new algorithm, with discussion
or further research.
ed: I think we discussed Simplex noise before.
<ChrisL> [40]http://www.eng.utah.edu/~cs6965/papers/noise.pdf
[40] http://www.eng.utah.edu/~cs6965/papers/noise.pdf
<ChrisL> [41]http://reality.sgiweb.org/olano/s2002c36/ch02.pdf
Noise Hardware - Ken Perlin
[41] http://reality.sgiweb.org/olano/s2002c36/ch02.pdf
RESOLUTION: Add a new type of noise algorithm to the filters
spec, for easier hardware acceleration. (Further research for
what type, possibly Simplex noise.)
Need a new filter shorthand for noise?
krit: Often the noise functions are not used standalone -
they're used with other filter primitives.
<ChrisL> [42]https://github.com/ashima/webgl-noise/wiki glsl
implementation of Perlin and simplex noise
[42] https://github.com/ashima/webgl-noise/wiki
<ed> here's an example using a bit of turbulence:
[43]http://dahlström.net/svg/presentations/svgopen2012/presenta
tion/introimage-static-grain-toothpaste.svg
[43] http://dahlstr/
TabAtkins__: The use-case I care about is usually solved by
taking an initial background-image or background-color, and
layering a "noise image" on top to give it some irregularity.
You cannot do this with the 'filter' property unless you define
a <filter> element and refer to it.
ChrisL: I've come across an impl of both classic and simplex
noise in glsl, and it says explicitly that both algorithms can
be done fine even on low-end (e.g. phone) GPUs.
... So why is this a problem that we need to solve?
krit: Based on list discussion, Simplex is a smaller O()
complexity, which is of concern with the often-large images
that will be used in CSS.
<ChrisL> ok
<ChrisL> demo
[44]http://alteredqualia.com/three/examples/webgl_shader_copper
.html
[44]
http://alteredqualia.com/three/examples/webgl_shader_copper.html
<heycam> ScribeNick: heycam
<ed> the demo chrisl pasted demos 3d-perlin noise I believe
TabAtkins__: the filter function in filter effects is of type
CSS <image>
s/TabAtkins__/krit/
<TabAtkins__> s/filter function/filter() function/
TabAtkins__: so you can introduce a noise filter shorthand and
then use it in the filter function
<TabAtkins__> s/TabAtkins__/krit/
TabAtkins__: my argument is that the filter function as written
still takes an <image> as an argument
krit: that would change
TabAtkins__: if you make that optional it's less troublesome
... I think it's weird that we have no-input filters
<cabanier> filter function:
[45]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#FilterCSSImageValue
[45]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterCSSImageValue
… I think that was a hack in the original SVG
… and instead just said "these are not paint servers but some
filter primitives"
… I am somewhat opposed to extending that confusion into the
CSS version of the syntax
… if we are producing an image, I would want to produce an
<image> directly
krit: then you can put this <image> as input to the filter
function
ed: if you want the same number of parameters that the SVG
turbulence has?
TabAtkins__: I don't know what's needed
... you would have "filter: noise(…) ..."
krit: wouldn't the parser get confused?
TabAtkins__: no
… the filter function takes the first argument is an image, the
next is filter list
s/filter: noise(…) .../background-image: filter(noise(…), …)/
krit: you could use this as an input to custom filter
primitives too
TabAtkins__: so this seems fine to me
krit: do we still want to have a shorthand noise function?
… and is that in Images or Filter Effects?
TabAtkins__: I don't think we do, because it's only a
generation
… and we can't do tree-based filter chains in the filter
property
… if we do do that, we can allow <image>s as well as inputs to
compositing filters for example
… I think making feTurbulence a filter primtiive and not a
paint server was a mistake
krit: in the end it probably doesn't matter, but yes where do
we put it logically
TabAtkins__: we should only allow pass through filters in the
filter property
krit: I agree
ed: would we have a corresponding element in SVG filters?
… we have feTurbulence
krit: deprecate but not drop it
TabAtkins__: for filters do we want to correct this historical
mistake?
… you can't just take a paint server directly, you need to
specify bounds to fill
krit: we could use feImage taking CSS <image> as well
ed: I think it would be handy to have in SVG filters too
... I don't mind if it's a new primitive or an 'image'
referenced from <feImage>
... a new in="" value?
TabAtkins__: you just need to combine a paint server with a
rect
krit: in general, we need to redefine in and in2
… to have CSS <image>s as input in there is fine
TabAtkins__: you can't use colors in there
... because "blue" might be a name of a result
… the <image> function in CSS can produce solid colors
… image(blue)
krit: feImage still has subregion clipping
… you could use media fragments for selecting the region, but
there's no way to do preserveAspectRatio
krit: a question about the noise function, how do you define
the size of it?
TabAtkins__: I would do the same as gradients
… it's sized into the box it's drawn into
… it has no intrinsic size
… in SVG's case, it can still do an extension out to infinite
case
ed: one complication is having tiling
… if you tile the noise function without stitchTiles you can
see the tile edges
TabAtkins__: any primitive tiling mechanisms will cause
discontinuities at the edges of tiling
… unless you tell the noise algorithm to stitch the edges
ChrisL: we shouldn't be padding noise out, just which region we
really want to cover
<ed>
[46]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#feTurbulenceStitchTilesAttribute
[46]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feTurbulenceStitchTilesAttribute
krit: primitives are always clipped to the filter region
… if you have feOffset you can reach the edge of the noise
function
TabAtkins__: we should just generate noise at whichever pixels
are going to be touched
<scribe> ACTION: Dirk to look into allowing CSS <image> values
in in="" and in2="" [recorded in
[47]http://www.w3.org/2012/09/17-svg-minutes.html#action10]
<trackbot> Created ACTION-3360 - Look into allowing CSS <image>
values in in="" and in2="" [on Dirk Schulze - due 2012-09-24].
<scribe> ACTION: Tab to work with Dirk to spec out a noise()
<image> value [recorded in
[48]http://www.w3.org/2012/09/17-svg-minutes.html#action11]
<trackbot> Created ACTION-3361 - Work with Dirk to spec out a
noise() <image> value [on Tab Atkins Jr. - due 2012-09-24].
TabAtkins__: some things need the size you're drawing into
… CSS gradients need to know how big their box is before
drawing
… media fragments don't apply to most CSS <image>s, just url()
images
ed: for SVG I would like to have 3D noise and to be able to
connect the time domain to the third dimension
… so you can have continuous effects
… with feTurbulence it can move things in x and y, but you
can't really have a fire/plasma effect
krit: I'd suggest using shaders for that
ed: you couldn't implement it that way
…but it would be nice to have filter primitives for that
krit: do we really want 3d noise? maybe, don't know.
… is simpled 2d or 3d?
ed: you can extend it to how many ever dimensions
… I think that would be really nice to have
… I want to allow that when we go with <image> generation, so
we can animate the timing
TabAtkins__: the CSS <image> type is now animatable, in Images
4
… there's a generic animation type that does a cross-fade
… but cross-fade and gradients animate argument-wise
… so that's fine to have animation of noise()
ed: Chris' link earlier shows the 3d noise animation
shepazu: when we're talking about stitching, does this also
apply to Tiling & Layering?
TabAtkins__: just if you're using a noise function of a certain
noise, or inside a pattern element that ends up being repeated,
you need to tell the algorithm to make sure the edges tile well
Masking issues
krit: we said we wanted to have attribute maskType for <mask>
… that says you specifically want to use this mask with alpha
or luminance
… do we want to make this a presentation attribute
ed: why would you want to?
krit: we already define mask-type for CSS masking
heycam: so this would just use the same attribute/property on
both the <mask> and the thing being masked
<krit>
[49]http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#
the-mask-type
[49]
http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-type
krit: yes
... second question is if you use maskType="" as we currently
defined it, it's camel case
… which HTML editors don't want, because they need to special
case it for the parser
… I have no problems if they need to special case it
ChrisL: the reason we had camel case was we originally had
hyphenation, and the DOM people requested camel casing
shepazu: if I'm converting from a property name to a DOM name,
removing the hyphen is trivial, adding the camel-cased letter
is kind of trivial with regex, but...
krit: still trivial
… the only problem is HTML is not case sensitive
shepazu: could we go to all lower case?
TabAtkins__: you would need to define what happens if you
accept both camel case and lower case
... I'm fine with all lower case or keeping camel case in
attributes
… updating the list isn't a big deal
… given every implementation just has a list of attribtues with
cases, it's easy to update
heycam: I'm slightly concerned that the case in the DOM changes
after the parser is updated
TabAtkins__: that's only a problem if people try to use the
feature before implementations add the feature
… you could define that with conflicting case names, just use
the last one … that's what the HTML parser does
TabAtkins__: maybe we should keep camel case, because when you
are using the property with CSS, you use camel case in the DOM
heycam: have the presentation attribute be camel case for a
hyphenated property name?
TabAtkins__: dashes are hard for the DOM, but we could accept
hyphens too
krit: it's easy in WebKit to have the dashed version of the
presentation attribute
…we just pass that to the CSS engine
heycam: if it's going to become a presentation attribute, it
should be mask-type not maskType
krit: so do we want it to become a presentation attribute /
property?
TabAtkins__: I think we do
birtles: just wondering when you'd want to set mask-type on
<mask> with a style sheet
TabAtkins__: you could set all <mask> elements to alpha with a
style rule
birtles: ok
heycam: is it confusing that mask-type means slightly different
thinks applied to <mask> and masked elements?
TabAtkins__: we could merge in the "alpha" or "luminance" back
into mask-image
… instead of the separate mask-type
… and just use mask-type to apply to <mask>
birtles: I'd rather this
TabAtkins__: and I think it's fine to think of the alpha-ness
of luminance-ness as part of the image
[discussion about changes to serizliation and computed values
for -webkit-mask]
RESOLUTION: mask-type now only applies to <mask>, and the [
alpha | luminance | auto ] goes in the mask-image value
krit: next problem is related
… mask-image has syntax like background-image
… so it clips to a region
… we have a predefined clipping regions border-box, content-box
and padding-box
… I would suggest defining for SVG that border-box means
painted rectangle
heycam: what's the default?
TabAtkins__: border-box
ed: if you ahve an SVG inline in HTML, you might want the
actual border-box of the outer <svg>
TabAtkins__: yes it should mean that on the outer <svg>
s/ahve/have/
TabAtkins__: padding-box should map to normal bounding box
krit: that's what it is currently
RESOLUTION: {border-box, content-box, padding-box} should map
to {painted bbox, normal bbox, normal bbox} for mask-clip
ed: would you ever want to have a box that includes the
filters? markers?
krit: we need to discuss this
… I'd rather no, because we would do this masking on the gpu
heycam: markers are already included in border-box
TabAtkins__: if you have a drop shadow applied to an element,
then using mask-clip will clip that away
krit: the old mask property still works the same way
… the url() references <mask> and can still have
x/y/width/height on it
<shepazu>
[50]http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON
[50] http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON
Summary of Action Items
[NEW] ACTION: Cameron to email the HTML and WhatWG working
groups to ask if there any problems related to adding the HTML
link element into SVG [recorded in
[51]http://www.w3.org/2012/09/17-svg-minutes.html#action01]
[NEW] ACTION: Chris to produce a proposal for expanded element
syntax for paths (including finding the results of testing
improved compression ratios with the expanded syntax) [recorded
in [52]http://www.w3.org/2012/09/17-svg-minutes.html#action08]
[NEW] ACTION: Dirk to file a bug and track filter functions
(issue 5) removed from Filter Effects spec [recorded in
[53]http://www.w3.org/2012/09/17-svg-minutes.html#action03]
[NEW] ACTION: Dirk to look into allowing CSS <image> values in
in="" and in2="" [recorded in
[54]http://www.w3.org/2012/09/17-svg-minutes.html#action10]
[NEW] ACTION: Dirk to prepare a proposal for supporting
lengths/percentages in paths and polylines [recorded in
[55]http://www.w3.org/2012/09/17-svg-minutes.html#action07]
[NEW] ACTION: Dirk to tell the CSS WG that we changed the SVG
path syntax [recorded in
[56]http://www.w3.org/2012/09/17-svg-minutes.html#action06]
[NEW] ACTION: Rik to ask CSS WG about how shadowing will work
for enable-background [recorded in
[57]http://www.w3.org/2012/09/17-svg-minutes.html#action02]
[NEW] ACTION: Tab to amend the definition of fill,stroke in SVG
to allow the CSS <image> type [recorded in
[58]http://www.w3.org/2012/09/17-svg-minutes.html#action09]
[NEW] ACTION: Tab to propose to the HTML WG that the 7 argument
form of arcTo be replaced with an ellipseTo method [recorded in
[59]http://www.w3.org/2012/09/17-svg-minutes.html#action05]
[NEW] ACTION: Tab to work with Dirk to spec out a noise()
<image> value [recorded in
[60]http://www.w3.org/2012/09/17-svg-minutes.html#action11]
[NEW] ACTION: Tav to add lang to tile and desc [recorded in
[61]http://www.w3.org/2012/09/17-svg-minutes.html#action04]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [62]scribe.perl version
1.136 ([63]CVS log)
$Date: 2012/09/17 15:26:55 $
__________________________________________________________
[62] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[63] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [64]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[64] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/can/can't/
Succeeded: s/foreignObejct/foreignObject/
Succeeded: s/henry/henri/
Succeeded: s/filter chain does the optimisation/implementation can analy
ze the filter chain and do the same optimisation/
Succeeded: s/differnet/differently/
Succeeded: s/I think if they're useful remove them but they could be use
ful since we have the possibility of non-square pixels/I think if they'r
e use-less remove them but they could be useful since we have the possib
ility of non-square pixels/
Succeeded: s/commandas/commands/
Succeeded: s/appends path to the path/appends path object to the path/
Succeeded: s/svgpath elements/svgpathseglist/
Succeeded: s/arc2/arcTo/
FAILED: s/maskign/masking/
FAILED: s/extent are/extent, they are/
FAILED: s/TabAtkins__/krit/
FAILED: s/filter function/filter() function/
FAILED: s/TabAtkins__/krit/
FAILED: s/filter: noise(…) .../background-image: filter(noise(…), …)/
Succeeded: s/have a/have/
FAILED: s/ahve/have/
Found ScribeNick: nikos
Found ScribeNick: ed
Found ScribeNick: birtles
Found ScribeNick: TabAtkins__
Found ScribeNick: heycam
Inferring Scribes: nikos, ed, birtles, TabAtkins__, heycam
Scribes: nikos, ed, birtles, TabAtkins__, heycam
ScribeNicks: nikos, ed, birtles, TabAtkins__, heycam
WARNING: No "Present: ... " found!
Possibly Present: Andreas BB CM ChrisL Cyril DS RC TA Tab TabAtkins TabA
tkins__ Tav all birtles cabanier doug ed everyone glenn heycam https joi
ned konno konno_ krit nikos scribenick shepazu stakagi svg trackbot vict
or
You can indicate people for the Present list like this:
<dbooth> Present: dbooth jonathan mary
<dbooth> Present+ amy
Agenda: [65]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agen
da
Found Date: 17 Sep 2012
Guessing minutes URL: [66]http://www.w3.org/2012/09/17-svg-minutes.html
People with action items: cameron chris dirk rik tab tav
[65] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda
[66] http://www.w3.org/2012/09/17-svg-minutes.html
End of [67]scribe.perl diagnostic output]
[67] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Received on Monday, 17 September 2012 15:31:59 UTC