- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 07 Feb 2013 17:16:50 +1100
- To: "www-svg@w3.org" <www-svg@w3.org>
http://www.w3.org/2013/02/06-svg-minutes.html
And text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
06 Feb 2013
See also: [2]IRC log
[2] http://www.w3.org/2013/02/06-svg-irc
Attendees
Present
Regrets
Chair
Erik
Scribe
birtles, heycam, cabanier
Contents
* [3]Topics
1. [4]border brushes
2. [5]variable width stroke
3. [6]Media fragments and SVG stacks
4. [7]SVG/CSS Matrix harmonisation
5. [8]Changes to Filter Effects and Custom Filters
6. [9]CSS OM and SVG DOM improvements; exposing calc
values
7. [10]Web Animations
8. [11]Web Animations continued
9. [12]Requirements reevaluation continued
* [13]Summary of Action Items
__________________________________________________________
<trackbot> Date: 06 February 2013
<heycam> Meeting: SVG WG F2F Sydney 2013 Day 4
<birtles> scribenick: birtles
border brushes
cabanier: in CSS you have the border-image property
... where you can slice up an image
... and tile the sides
... you can stretch them and after a point they start
duplicating themselves
<cabanier> link:
[15]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agen
da/border_brushes
[15]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/border_brushes
cabanier: we have the same features in Illustrator
... and you can define a side and a corner and it does the
stacking for you
... instead of just a png
... if you do a google search you can see many places where
people use this
... on the wiki there are several examples
krit: you could use svg
cabanier: but that's kind of hard because you have to define
where the border is
dino: do the two images orient along the edge
cabanier: yes
... when there's a curve the artwork needs to bend along the
curve
... so you might need to add some limitations
... e.g. if there was a gradient then you'd need to morph the
gradient
birtles: so is this for just SVG
cabanier: this is the SVG counterpart to what's in CSS
AlexD: this would have to be an adaptive dashing style thing
... so you have an exact integer number of repeats
... like we talked about for dashing where you try to make the
dash array end on exact integers
cabanier: you'd use this brush like a stroke
... so it also is effected by the stroke-width
... e.g. a stroke width of 2 would make it scale by two
... there's an e.g. with dashes
... so each dash would be one of the images
heycam: so, theses dashes here, some of them are squashed when
they're small
... but in the non-dashing examples they maintain their aspect
ratio
cabanier: I think in dashing examples they either squash or
duplicate
... when you apply the corners...
... I think for now we only want this on polygons
... because how do you work out the corner of a path?
... even for rects you know where the corners are
heycam: but you have examples of using this on a path
cabanier: yes, I just drew these in Illustrator
... in the star it uses the corner on the outside but not in
the inside
... I think it is a special case for stars
<shepazu> (this corners question applies to the "rounded
corners" proposal from Rigi-Kaltbad, too)
dino: are you sure?
cabanier: oh, I think you're right
krit: it looks like the engine looks for the smallest angle
... and orients to that angle
cabanier: I think the syntax for this would be fairly easy
... for rounded corners it doesn't use the corner piece
... that's just how Illustrator implemented it
heycam: is it warping the corner pieces?
cabanier: yes
ed: so if you had a sharp corner in the last example with the
squiggly line
... would it get the corner piece?
cabanier: no
dino: so you'd only use it for basic shapes?
cabanier: right
dino: even if you drew the star as a path you wouldn't get the
corner piece?
cabanier: yes
... otherwise you have to define what is a corner
dino: seems like there would be a lot of work in describing how
you walk a rectangular object...
cabanier: it would be a lot of implementation work but not so
much spec work
... I don't think the warping would be defined in the spec
dino: I think how the control points are warped should be
defined in the spec
... if you want it to be interoperable
heycam: I think you could have a high-level description
regarding how points along the bezier are mapped
cabanier: I'm not saying we don't have to do it.. but do we do
that elsewhere in the spec?
ed: yes, we do
<ed> [16]http://www.w3.org/TR/SVG11/text.html#TextPathElement
[16] http://www.w3.org/TR/SVG11/text.html#TextPathElement
ed: the method attribute
... when you set that to stretch
... it says something about how its done but it's not very
precise
dmitry: I checked and Illustrator does apply the corner pieces
to custom paths with sharp corners
cabanier: so it does, you're right
ed: if you make a star with a path you probably want it
krit: there's more calculation to determine if the corner
between two curves is a sharp corner or not
ed: where is the cut-off point
krit: maybe it does it on all sharp corners?
... these are fairly detailed discussions...
<heycam>
[17]https://svgwg.org/svg2-draft/painting.html#TermLineJoinShap
e
[17] https://svgwg.org/svg2-draft/painting.html#TermLineJoinShape
heycam: the new wording about computing the shape of a stroke
has the kinds of descriptions you would want for the warping
here
... it's a high-level description of taking points on a path
and turning them into shapes or different points
<dmitry> Screenshot of the corner processing in Illustrator:
[18]http://cl.ly/image/0h3l0u0D3r1B
[18] http://cl.ly/image/0h3l0u0D3r1B
cabanier: so this would effect getStrokeBBox too right?
heycam: if some of the tiling pattern didn't fill out the whole
tiling space or overflow it, would that effect the stroke bbox?
cabanier: there was some discussion of this in the mailing list
... at least it's easier than other brushes like the bristle
brush
... I think this is pretty easy and would be nice to have in
CSS too
... in CSS you would just use it like border-image
... and if you applied it to a CSS box you wouldn't have the
deformed beziers
... do you think this is useful?
krit: I think this should not go into SVG2
birtles: I agree
krit: so should we continue at all, and if so how should we
continue?
dmitry: Illustrator lets you define two different corner pieces
(inside and outside corner)
heycam and cabanier: agree it should not be in SVG2
<dmitry> Screenshot of two types of corners:
[19]http://cl.ly/image/1S3B3i1l0E0e
[19] http://cl.ly/image/1S3B3i1l0E0e
krit: so do we want the feature?
heycam: I think we want the feature
krit: do we want to have a module for this or in SVG.next?
heycam: I think it could be a separate spec
ed: sure
<heycam> dino,
[20]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Co
mmitments
[20]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
RESOLUTION: We will continue developing border brushes in a
separate specification
<scribe> ACTION: Rik to create a module to define SVG border
brushes [recorded in
[21]http://www.w3.org/2013/02/06-svg-minutes.html#action01]
<trackbot> Created ACTION-3440 - Create a module to define SVG
border brushes [on Rik Cabanier - due 2013-02-13].
variable width stroke
[22]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agen
da/discuss_vw_stroke
[22]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/discuss_vw_stroke
cabanier: so this is not going to be for SVG2
heycam: but we had the requirement to represent InkML traces in
SVG
... we said we'd enable InkML to be rendered
... so we *could* consider it for SVG2
cabanier: defining it is pretty easy
... not sure how hard it is to do in the graphic libraries
heycam: can't be harder than these border brushes
cabanier: at any rate, defining it should be very easy
... you just say that along these paths we have these points
and at each point you say, e.g. the stroke should be 200%
... and then you draw a catmull-rom curve along the points
AlexD: why would you do that, when it involves tension
heycam: I'm thinking we could just extend stroke-width itself
... e.g. stroke-width="10px 15px"
cabanier: I think you want to use percentages
... e.g. to represent pressure on the pen
... or if you pick up a bigger pen you want to just say 200%
heycam: (e.g. on the board)
... stroke-width="10px" stroke-width-variation="0px 100%, 100px
100%, 150px 50%"
birtles: (use case from previous discussion) I want this
feature to be able to do finger-drawing on a tablet where the
stroke width varies with touch pressure
cabanier: I think I prefer stroke-width-varation="0% 100%, 66%
100%, 10% 50%"
krit: do you want to be able to specify different widths for
each side (left/right)
cabanier: I think that might get complicated because it might
not always be obvious which side is which
heycam: I think it is ok
dmitry: I think if you really want that you can just change the
path
heycam: if the widths could be a repeating pattern you could do
spaghetti lines
... I don't think it's much more work
cabanier: yes, I agree
heycam: I think you could automatically tile it, especially if
your offsets are absolute lengths
... I would actually be ok with different left-right sides
... since I think the implementation difficulty would be the
same
... but what if the two intersected?
cabanier: they can't since the percentage is always positive
birtles: is it worth adding the features in stages?
... I think the primary use cases would be data from tablets
and calligraphy
... where you probably don't need repeating patterns or
asymmetric variations
ed: I think it would be nice to have a spread-method like
approach
... where it just repeats
... I think you might want to use variable-stroke width for
custom line cap
... where the end tapers off
dmitry: you could use markers for that
... but it doesn't always work
cabanier: like if you have a gradient on the stroke
... the marker would have a separate gradient
dino: who do we expect to use this?
... hand authors? tools to export?
... I think this kind of feature is complex to hand author
cabanier: I think it's not so hard
krit: of course, you can already export this from Illsutrator
cabanier: but strokes become a series of paths
AlexD: cartographers have been asking for this
dmitry: and if the export from Illustrator loses the original
path then you can't modify it in script
birtles: and I think there are many uses cases where you
create/modify paths from script
Cyril: does this affect markers
heycam: yes
... because markers can be scaled in size depending on the
stroke width
... but that's probably what you want
ed: I think there are cases where you don't
cabanier: I think you want the original stroke-width
Cyril: in d3 examples, where you have flows of data
... and you have arrows where you want the arrow to grow or
shrink
ed: so how should we proceed?
heycam: if someone is keen to do the work, someone could
specify the minimum set of features
... symmetric stroke width variation with no repeating
krit: can stroke-width-variation be a shorthand
heycam: not sure about the naming
cabanier: it could be
Cyril: this would be a presentation attribute?
heycam: as I've written it, yes
cabanier: can you define a URI somewhere
heycam: so you can re-use the definition?
... inheritance works so that might be enough
... at first I'd like to avoid element syntax and just have the
property
... if we need a pre-defined thing we can add it later
... it's currently assigned to Doug in the requirements
commitments
(item 20)
cabanier: I can talk to Doug about it
<shepazu> (I'm happy to defer to someone else for this,
cabanier)
<scribe> ACTION: Rik to specify variable width stroking in SVG2
[recorded in
[23]http://www.w3.org/2013/02/06-svg-minutes.html#action02]
<trackbot> Created ACTION-3441 - Specify variable width
stroking in SVG2 [on Rik Cabanier - due 2013-02-13].
<shepazu> (also happy to discuss it and give feedback)
<ed> -- 15min break --
-- break, 15min --
<heycam> ScribeNick: heycam
Media fragments and SVG stacks
krit: I'm not sure on the status of media fragments on the
<image> element
especially for xlink:href
I don't think it's specified in SVG
should it be combined together with media fragments? allow
#xywh there as well? seems to be useful, but it's not specified
currently.
how would that affect our SVG Stacks hack?
ed: I don't think it would affect it that much
unless you pick that particular ID
krit: there are more fragments that SVG supports that aren't
supported in Media Fragments
choosing the viewport e.g.
should we talk to the Media Fragments WG people?
<silvia> [24]http://www.w3.org/TR/media-frags/
[24] http://www.w3.org/TR/media-frags/
silvia: what are the other things you're missing?
<silvia> spatial dimensions:
[25]http://www.w3.org/TR/media-frags/#naming-space
[25] http://www.w3.org/TR/media-frags/#naming-space
[26]https://svgwg.org/svg2-draft/linking.html#LinksIntoSVG
[26] https://svgwg.org/svg2-draft/linking.html#LinksIntoSVG
ed: you can pass transforms, a viewBox
Cyril: I don't understand how this depends on xlink:href=""
spec
krit: Media Fragments conflicts with SVG in some cases
Cyril: I don't see the problem with XLink href
media fragments are defined by the MIME type
if you use it in xlink:href="" or src="", it shouldn't matter
krit: we need to reference Media Fragments
ed: I don't think they're in very much conflict with each other
we should reference Media Fragments
silvia: are you using Media Fragments with SVG resources yet?
ed: no
silvia: SVG resources define how their ID fragments get
interpreted, if you don't adopted the Media Fragment spec for
that resource type then there's no conflict
Cyril: but it makes sense to support Media Fragments, xywh, or
timing as well
silvia: you just need to extend the fragment specification for
SVG
Cyril: so t and xywh should be reserved?
heycam: just reserve "t=" and "xywh="
Cyril: in Media Fragments you have four dimensions. how does ID
work?
silvia: nobody has implemented that
the way we envision it is that some containers define names
for sections, it's like imagine having a WebVTT chapter file in
a webm file, and you have names for sections of the video file
and you can use the chapter name to address the chapter
Cyril: what's the syntax?
silvia: id=string
Cyril: so it's not "#<string>" it's "#id=<string>"
silvia: yes
krit: for SVG would it be a difference to support #<element>
compared to #id=<element>?
Cyril: the question is how to combine them
once you start using a freeform name, you can't use an "&"
and follow it with another dimension
silvia: we wanted to be able to support multiple dimensions;
choose this one video segment (temporal), and then choose a
spatial area
that's why we defined the parsing for these media fragments
if you don't do that from the start it's difficult to
post-fit it
your selectors are functions?
you could do something like "#mediafrag(xywh=
)" to be
compatible
Cyril: you'd have to treat SVG differently then
sometimes you don't know what the type of the resource is
krit: do all media fragments require an equals sign?
silvia: yes
krit: then it's probably fine
we shouldn't need to have #mediafrag
Cyril: we could disallow ampersand in SVG IDs, then it combines
well here
krit: media fragments in HTML, if you have <img
src="blah#xywh=
"> you would have the same problem yes?
silvia: on HTML pages it's difficult, since HTML has specified
the way a fragment is interpreted
often you have a custom web site, e.g. in YouTube you can
have similar time offsets with fragments
but that's not what we've standardised for
we've done this only for media files
HTML is a different media type
krit: depends on the MIME type of the document you reference?
silvia: yes
that's how the URL specification has defined fragments to
work
krit: so we need to specify how SVG's fragments are interpreted
... the timing fragments are useful in SVG too yes/
ed: we should define how that works
birtles: we've said for Web Animations we want this to work
would be good if this worked for HTML containing documents
with animations as well as SVG
Cyril, [27]http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name
[27] http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name
dino: Cyril is asking how you distinguish #t=
from normal ID
references in HTML
Cyril: if HTML doesn't use the same solution as us, disallowing
"&" and "=", it wouldn't be good
krit: same problem with SVG in HTML, the MIME type is
text/html, and the fragments would work differently
silvia: the HTML MIME type does not support media fragments
Cyril: yet?
silvia: I think it's unlikely
ed: but if we have Web Animations it might be useful
silvia: we discussed xywh for HTML, it might be an interesting
feature, but the HTML WG should discuss that
Cyril: so should we aim for alignining with other media-like
resources, or what HTML supports?
silvia: I'd go with both strategies
I would want to be as much compatible with that spec as
possible, and when SVG goes forward have its MIME type define
how media fragments work, it's a bigger argument for HTML to
support it
I don't think this will break SVG documents, but with HTML it
could well break pages
people might have used #t= to mean something different on
HTML pages
I would orient myself towards that problem, but rather being
compatible with other media files
krit: so Media Fragments defines how xywh are parsed, why do we
need to define that in SVG?
Cyril: we just need to say image/svg+xml follows media
fragments
silvia: right
the Media Fragments working group was bound by the URL
specification
fragments are defined interpreted based on the mime type
we didn't want to have to deal with all of the mime types
around, just video
krit: SVG is still based on IRI, which should allow more
characters
silvia: it's not a problem; we wrote the spec to be based on
UTF-8
the only place where it really mattered was the chapter
names, named references
heycam: I think the URL Standard is meant to supersede IRIs
Cyril: I think I'm fine with the group saying we adopt media
fragments, and we restrict our IDs not to include xywh=,
ampersands, etc.
and then later can coordinate with HTML WG to see if it's
possible for them to support this too
silvia: one part of the Media Fragments spec has been included
in HTML; it defines how time offsets in videos are interpreted
Cyril: if you put t=15 does the document timeline start at 0?
birtles: it does a seek
then we need to add automatic pausing
RESOLUTION: SVG 2 will use Media Fragments.
<scribe> ACTION: Cyril to add Media Fragments support to SVG 2.
[recorded in
[28]http://www.w3.org/2013/02/06-svg-minutes.html#action03]
<trackbot> Created ACTION-3442 - Add Media Fragments support to
SVG 2. [on Cyril Concolato - due 2013-02-14].
Cyril: is #svgView(viewBox()) the same thing as #xywh?
ed: not quite
<scribe> ACTION: Brian to define how #t= is interpeted in Web
Animations. [recorded in
[29]http://www.w3.org/2013/02/06-svg-minutes.html#action04]
<trackbot> Created ACTION-3443 - Define how #t= is interpeted
in Web Animations. [on Brian Birtles - due 2013-02-14].
percentages will be different
krit: for #xywh these reference the original viewport
SVG/CSS Matrix harmonisation
krit: we have a new function that gets the transform between
two elements
I think this will be harder with CSS transforms
since they have 3d transforms
and it's not really possible to get a transformation matrix
over this flattening
the question is how do we want to solve this
and second, it returns an SVGMatrix which is 2D
it's not applicable for this
it should return something that can represent 3D matrices
I spoke with Dean about flattening
we think that it should either give you an exception, a null
matrix back...
somethign that indicates it's not possible to get the
transformation
something to be resolved is the return type
we would need to specify a new matrix
CSS Transforms had a spec for it
which needed to be removed, since it uses CSS OM
Dean proposed Matrix4x4
we didn't know at this time where it should live -- maybe in
ECMAScript?
on the window object
what does it look like?
<krit>
[30]http://lists.w3.org/Archives/Public/public-fx/2012JanMar/00
07.html
[30]
http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0007.html
krit: there were some discusisons about whether it should work
with Euler coordinates
dino: there was some discussion that day in the SVG meeting
about this
which I never followed up on
I think it was about whether to use radians or degrees
we have methods on here for both modifying the matrix and
returning a new one
the other big discussion was someone suggested it should
really be an ECMAScript type
someone else discussing whether it shouldn't have all those
exposed as attributes, it should be a typed array with a
wrapper of some sort
krit: they wanted to use it with WebGL as well
which needs to be fast
dino: that's why I have copyIntoFloat32Array
but you might not want to call this function each time
heycam: I don't think there's a concept of live typed arrays is
there?
dino: I think the suggestion was to have the typed array
backing the matrix
there would be an attribute to access that matrix backing
data directly
in WebGL it would just be a matter of getting that out,
instead of constantly creating new typed arrays
we didn't really have strong drive to get this happening
quickly
but I think we do now, now that the spec is closer to
completion
heycam: makes you think well then why not about Points, etc.
dino: I think that's why it wouldn't make sense to send it to
ECMA
if we just have Matrix
dino: there is still more work to do with improving SVG DOM
interfaces
should we add something now to expose 4x4 matrices
or have conversion functions separate from the SVG DOM
heycam: could we not replace SVGMatrix with Matrix4x4?
dino: that was the idea
krit: we got everything from SVGMatrix on Matrix4x4, then we
make SVGMatrix inherit from this one
there are some things that need to be in SVGMatrix
[31]http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix
[31] http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix
krit: there are SVGExceptions being thrown
heycam: that's gone in SVG2
dmitry: nobody uses skews
cabanier: why does this issue keep coming up then?
krit: Mozilla found some pages that did use skew
dino: people use it for horrible fake 3d, isometric
dmitry: we should encourage them to not do this by not having
it in the specification
cabanier: I know people use skew a lot in animations for fake
3d
krit: we could strongly ask people not to use it...
dmitry: it should be easier to make beautiful things, not just
easier to make ugly things too
krit: we could have them be deprecated but browsers still
implement it
dino: I don't think we can remove skews from transform syntax
any more
do we need to expose them in this interface?
krit: yes
dino: sounds like we do if we want to replace SVGMatrix with
Matrix4x4
ed: so do we need to fix this in SVG2?
krit: do we want to go with this new interface? I think yes
if it should live in ECMA we can worry about that later
whether it should go on window I asked the CSS group for
approval
heycam: I think just leave it not [NoInterfaceObject]
krit: which spec should it live in? a new one?
cabanier: Canvas references SVGMatrix, would be nice to
reference this instead
krit: what happens if you have a 3D transform on canvas?
heycam: who should write this Matrix4x4 spec?
krit: have to ask first, but I will probably do it
dino: what about the name Matrix4x4?
heycam: eh...
dino: GL calls them matrix4, vec3, etc.
krit: i prefer Matrix to Matrix4x4
heycam: should Matrix replace SVGMatrix, or SVGMatrix inherit?
ed: I don't think it's common for people to rely on "[object
SVGMatrix]" being the actual object type
krit: ok, just replace SVGMatrix with the new Matrix then
ed: as long as we have the same method names I think it should
be fine
RESOLUTION: SVG 2 will reference the new Matrix specification
and replace SVGMatrix with Matrix, once that spec is ready.
<scribe> ACTION: krit to write up a spec for Matrix [recorded
in [32]http://www.w3.org/2013/02/06-svg-minutes.html#action05]
<trackbot> Error finding 'krit'. You can review and register
nicknames at
<[33]http://www.w3.org/Graphics/SVG/WG/track/users>.
[33] http://www.w3.org/Graphics/SVG/WG/track/users%3E.
<scribe> ACTION: dirk to write up a spec for Matrix [recorded
in [34]http://www.w3.org/2013/02/06-svg-minutes.html#action06]
<trackbot> Created ACTION-3444 - Write up a spec for Matrix [on
Dirk Schulze - due 2013-02-14].
ACTION-3444: Also update SVG 2 to reference the spec when it's
ready.
<trackbot> Notes added to ACTION-3444 Write up a spec for
Matrix.
Changes to Filter Effects and Custom Filters
<krit>
[35]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#custom-filter
[35]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#custom-filter
krit: custom filters are used with CSS shaders
so that you can apply some distortion/modification to the
graphics
in the old specification, the syntax was
"custom(url('vertexshader') mix(url('fragmentshader') multiply
src-over), 4 4 attached, param1 value1, param2 value2)"
it's very long, hard to read, and only supports GLSL
MS asked us to make it more generic to support other shader
languages
one idea is "custom()" references an at-rule
@filter f1 {
}
but this does not support animations
dino: you could have @filter f2 {
} and animate between f1
and f2
krit: we wanted to try to keep it simple
the @filter rule tries to emulate @font-face
so it has a 'src' attribute, and you can provide a type
src: url(
) format("x-shader/x-vertex")
heycam: these are just hints not to download, like @font-face?
krit: no it's different from font-face
you need all of these resources
there's also "geometry: grid(4,4);"
and "margin:
;" like a filter primitive margin
and "parameters:
;" for the parameters to the shader
programs
so what happens with different shader formats.
the @filter defines a generic primitive, so this is not
limited to CSS Shaders
if you don't support GLSL, we'd suggest a new media query
@media (filter: glsl) {
}
so other browser could define new properties on the at rule
ed: what is the point of the format() yet?
krit: in case there is a new shader type under GLSL
dino: WebGL defines a restricted version of GLSL
it's not strictly GLSL
krit: maybe this keyword could be "WebGL" then
we can think about that later
ed: so you have src with format()s in case you support more
shader types later?
krit: also you could reference an SVG filter here
<filter id="f2">
<feOffset dx="var(x1)" dy="var(x2)"/>
</filter>
something like SVG Parameters or CSS Variables
the custom() function would then reference a filter at-rule
that references the SVG filter
@filter g2 { src: url(#f2) format('svg'); parameters: x1 30, x2
30; }
filter: custom(g2, x1 20, x2 20);
ed: what is the var() syntax there? is that defined somewhere?
krit: we're not going to put that in the first version of the
spec
since it's not clear how Parameters / CSS Variables is
working in SVG yet
but this is how custom SVG filters can be animated in the
future
ed: it might be useful to be able to pass in the document time
into the filter
krit: we can think about that for v2
heycam: I find it a bit strange that format() in src works
differently from in @font-face
krit: what if we rename "src" to "filter-src"?
heycam: maybe
it might be the combination of "src" and
"format()" that looks to me like formats are hints to avoid
downloading
why require format() at all given you can look at the actual
served Content-Type?
krit: servers might not set that correctly
dino: there's not even a standardised extension for these files
what if you reference from the local file system
heycam: what is the advantage of 'src' having the same format
across different shading language @filter rules?
dino: the source language format is the thing most likely to
change
geometric, margin, parameters make sense with other shader
languages too
krit: so are people happy with @filter rule?
heycam: I like it more than stuffing everything in to the
property
what about the src descriptor, people want a different name?
Cyril: you plan to have different mime types for vertex vs
fragment shaders?
krit: it's the case already
that's defined by WebGL
Cyril: is the mime type registered?
dino: x-shader/* is not registered, but someone would have
written something down somewhere
heycam: for me, you don't need to rename src for now
RESOLUTION: Filter Effects changes to use @filter.
-- lunch break one hour --
<cabanier> scribenick: cabanier
heycam: filter media query feels different from other media
queries
since those are properties of the device
ed: maybe @supports?
heycam: so you could write '@support filter(glsl)'
the syntax is extended but not implement
krit: yes, that seems better
... I'm OK with that
heycam: at some point there will be @supports for @-rules
krit: inside the rule?
heycam: you could then have:
atrule(filter, src:
format('x-shader')
the normal properties just check if they parse correctly
so maybe it's not quite right, but I'd be happy
Maybe email www-style
<scribe> ACTION: Dirk to email www-style about at-supports
filter function [recorded in
[36]http://www.w3.org/2013/02/06-svg-minutes.html#action07]
<trackbot> Created ACTION-3445 - Email www-style about
at-supports filter function [on Dirk Schulze - due 2013-02-14].
krit: is @filter-rule fine?
ed: are there other possibilities
is everything of the previous syntax possible
krit: yes
cabanier: even animations:
heycam: that's for the @media part not the rule
krit: do we need a new RESOLUTION?
heycam: can you do the same as before?
krit: yes
RESOLUTION: accept proposed descriptors for at-filter rule
CSS OM and SVG DOM improvements; exposing calc values
heycam: the question is if we support css lenght and how we
reflect that in svg
Dirk, did you add it already?
krit: yes. as unknown because we don't want to extend SVG DOM
at this time
heycam: so, there are a few new unit types such as rem, vw, vh,
ch, etc
.rem is default font size
shanestephens_: it's to do layout based on the font
heycam: for instance to do margins
shanestephens_: MDN has a good description
heycam: we want to support all of those
my question was that we want to add accessors for all of
those
krit: should make it so that it becomes more extensible
heycam: you could use named properties
that makes it open ended. But you'd have to update the spec
ed: that makes it more clear that the spec is going to be
extended
having a group of names makes that more clear
the spec refer to the group of supported unit types in CSS
heycam: named properties would require slightly different
implementation
but I like them to be visible in IDL
ed: as long as the spec is clear that they can be updated, it's
fine by me
heycam: I think we want an accessor so you can set it by string
.x.? to get the string value
to write or read the string
.value ?
shanestephens_: I like that
value would be a strange name for a unit
RESOLUTION: add a 'value' attribute to read or write the CSS
serialization of a unit length
heycam: there are values like 'calc' and 'attr'
krit: x = attr('x')
heycam: that would work
krit: that depends on the css syntax so it would not fail
parsing
heycam: no. that would not be a problem.
you can have a property to looks at attr(style) and that
would fail to parse
do we want calc and attr and var to work in SVG?
krit: yes
heycam: and have them work on x and y to work on CSS
shanestephens_: if something is a calc?
heycam: you can still look at 'px'
should there be an accessor to get the calc value?
shanestephens_: we have a lot of experience with polyfill and
we spend a lot of javascript mimicing value parsing
web animations has a calc in javascript parser
heycam: the other half is how this is reflect in SVG length
and follow Dirk's example to reflect them as unknown values
ed: yes, that is the only reasonable value
<scribe> ACTION: heycam add a string accessor on SVG animated
length and to make 'calc', 'attr' and 'var' work [recorded in
[37]http://www.w3.org/2013/02/06-svg-minutes.html#action08]
<trackbot> Created ACTION-3446 - Add a string accessor on SVG
animated length and to make 'calc', 'attr' and 'var' work [on
Cameron McCormack - due 2013-02-14].
heycam: I changed the spec that if there is a list, you just
set the first value
if there is no value, we add one
ed: sounds reasonable
heycam: I didn't add anything to SVGAnimatedAngle
since noone is really using that one
everyone uses the length one
cabanier: maybe better to be consistent
heycam: OK
<scribe> ACTION: heycam to update SVGAnimatedAngle as well
[recorded in
[38]http://www.w3.org/2013/02/06-svg-minutes.html#action09]
<trackbot> Created ACTION-3447 - Update SVGAnimatedAngle as
well [on Cameron McCormack - due 2013-02-14].
Web Animations
<birtles>
[39]https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index
.html
[39] https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html
birtles: there are 3 documents
the link is the core spec and the intent is to have 2 more
document to map SVG and CSS features
Is Tab's work available yet?
shanestephens_: it's not quite ready, but I'll provide a link
<shanestephens_> This is a copy of the CSS integration
document, but it does rely on features that are not yet firmed
up in the core specification:
[40]https://docs.google.com/document/d/1CrfospthGnMg3tXmYYnZmRD
E8Re-uL4mGkuSB0VPcTA/edit
[40]
https://docs.google.com/document/d/1CrfospthGnMg3tXmYYnZmRDE8Re-uL4mGkuSB0VPcTA/edit
birtles: we have f2f next week
shanestephens_: there's a few reasons that the spec is so big
we need to provide IDLs and Brian added a lot of diagrams
and complete descriptions of processes
Also we have a fairly complete polyfill that is only using
1700 lines of code
krit: does the polyfill do synchronisation?
shanestephens_: yes, but it doesn't integrate with CSS and SVG
but it works with other libraries
<shanestephens_> here is the polyfill:
[41]https://github.com/web-animations/web-animations-js
[41] https://github.com/web-animations/web-animations-js
birtles: there's a skeleton for the SVG integration
but don't even look at that
I want to talk about scheduling
<shanestephens_> (actually it's now about 2200 lines)
next week we have a f2f to fix remaining issues
and then request FPWD
there are 3 contentious features
shanestephens_: except for video, the main thrust of the doc is
correct
birtles: the FX taskforce will be asked to review so we can
publish it
and we hope to do that at the end of next week
shanestephens_: the review will be 2 ways. People will either
like it or there will be a lot of contentious issues
cabanier: probably have to ask each group for resolution
birtles: yes
dino: It would like to know what changed since I provided
feedback
a declarative form is more important and it's not in the
document
I notice that the template is taken so that's good
shanestephens_: for declarative, we would like to CSS
animation, transition and SVG all work the same under the hood
dino: yes
shanestephens_: so that in future version we can push more
declarative markup in the spec
dino: OK. Then I have no problem with the model and it does a
good job of describing what an animation engine does in a
browser
my concern is with the really big javascript API
CSS transitions became popular because they're powerful
without being complex
people are hesitant for massive APIs
Cyril: authoring tools are missing
shanestephens_: it's a lot smaller than SMIL
the shim that we built is really quite small
another things is that it provides a declarative view
It's really very similar to CSS
I understand that that doesn't address your concerns
the polyfill is mostly for testing
s/poylfill/API/
krit: in theory SVG and CSS animations should have the same
model under the hood
the most important part is that this provides an animation
model that is currently lacking in CSS
birtles: there's an appendix
[42]https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index
.html#webidl-ref
[42]
https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html#webidl-ref
dino: that's still really big
birtles: we can talk about things that shouldn't be exposed
dino: A lot of this stuff is needed
an author wants to provide timing to a document
he wants things to happen at certain times
for example, read long books
where we want something to happen at a certain time
just that alone, is requested a lot more than low level
access to an animation
scrubbing animation, querying animations, etc
but we get almost no request for something like this
shanestephens_: In Google we could use this a lot
dino: but most people want simple features
shanestephens_: chaining animations is low level?
dino: it would be great to have that.
We're on the fence about that one
I'm not saying not to provide this
having such a massive API as step 1 seems too much
shanestephens_: Are you suggesting not to provide a JS API?
dino: no, put more emphasis on the integration specs
step 1, describe the timing mode and the next step is to
provide the integration spec
shanestephens_: we think that the most important thing is CSS
and SVG animations use the same model
so we agree with you
dino: I would like to solve of an author that want to make an
animated page
and this API is not a solution for that
birtles: yes, this is not for authors
dino: that is why I want those specs at the same time
shanestephens_: should we have the spec ready at FPWD time?
dino: yes, but not have such an extensive API
krit: CSS animations and transitions need a model now
AlexD: maybe we need to split the APIs into a separate document
dino: ???
birtles: there is a way to split things up in 2 parts
dino: yes, the timing object would allow you to write your
animations
birtles: that concept is already there
shanestephens_: that sounds exciting
do you think the CSS WG would go for that
dino: if you have a class '::timeactive'
and have a CSS animation in there
that would be very powerful
birtles: we can do a timesheet
and I would love to do that
shanestephens_: so we should split the IDL off and into 2
pieces
Cyril: yes, the size is an issue
maybe splitting the spec in separate documents
birtles: I don't know how that would help
Cyril: setting time in a document is useful by itself with no
animations
media elements could be hooked to that
birtles: those use cases are already met
you can have a media element
Cyril: you can't have frame accuracy today
so maybe one step is solve this problem
birtles: it's hard to prioritize
I'm happy to split the API up
with regards to the size, we can work on that
but our problem is that we want to harmonize CSS and SVG
and we're cutting out a bunch from SMIL already
so, it will always be big
Cyril: how can you integrate inconsistent models?
if you map the models, will it break anything?
birtles: no
shanestephens_: CSS is underspecified
birtles: and inconsistently implemented
<birtles> (that is, some details of SVG are inconsistently
implemented)
shanestephens_: would it be OK to delay ::timeactive?
or should we do that now
dino: I would like to have that now and can write something up
it would be very useful to a lot of people without exposing a
large API
I would like to reimplement CSS animations in WebKit with
your spec
take canvas for instance that took 8 years and only 2 classes
<Cyril> ack
silvia: introducing a big new feature using CSS, SVG and even
HTML, how much overlap is there with HTML?
also when you're introducing this big thing, it's not enough
and too much. Since people come with their own angles
for an HTML person it's not enough but the spec is too big
splitting it into more document will help
also providing examples and summaries is very helpful since
it's too hard to digest
birtles: there are no changes to HTML
just additions to document and element interfaces
silvia: how about animateColor. That is in the spec
birtles: that's surprising
shanestephens_: it's tricky
people say it's too much but want more features
we should stick to the brief that we want to unify CSS and
SVG animation model
silvia: the minute you introduce the API you can animate an
HMTL page
Cyril: I want to make sure that we can integrate with media
elements
silvia: you can touch the HTML spec if it's needed
there's an interface that will be needed
dino: <par> and <seq> would be nice to have in the document
and it's simpler than javascript
I would like to style animation
shanestephens_: what is the next step?
we're working on this full time
and a lot of engineering time to make this happen
dino: where do we want to be in order to make a first draft
I think the integration document is the most useful
birtles: how can you have that without a model?
ed: yes, I would like the integration specs first
silvia: I would like to see the markup to see what you're
trying to do
shanestephens_: this doesn't really apply here
providing examples in markup will not do
krit1: it seems like we're going in circles
Cyril: everyone agrees that there should be a unified model
at a minimum we should have the model and integration with
CSS
krit1: are timesheets important?
dino: I would like to
I think those are more important
birtles: I think we can already do that
Cyril: I would like to integrate with media elements
<ed> -- 15min break --
<heycam> ScribeNick: heycam
Web Animations continued
shanestephens_: I had a suggestion that we could keep the parts
of the IDL that expose the behaviour of animations generated by
CSS and SVG, and remove parts of the IDL that let you create
content through js
so we can test the CSS and SVG are in the same model and are
the same thing
and then cyril can go forward with animations in HTML
and dean can go forward with timesheets
and we can look at completing the js api
I think Brian is interested in adding functionality to SVG
birtles: I'll work on SVG integration
shanestephens_: v1 of the document can be the model, CSS
integration, SVG integration, and just enough IDL to confirm
that all of the timing parameters of the model are working
correctly
Cyril: a browser will be compliant to the standard if it
exposes the right objects with the right values at the right
time
shanestephens_: that's pretty much all we care about.
functionally that the two specs are aligned.
birtles: I don't really like exposing a read only model like
that. I think we should split the API into a separate spec.
shanestephens_: it wouldn't have to be read only, but you'd
need to leave out things like play()
... the only problem I have with splitting out the API is that
it leaves nothing testable
and if it's not testable, it can't be a spec
birtles: maybe that's OK
and we publish the API later and test that
dino: a NOTE can go onto the REC track
birtles: I think we can still work on the API spec, it's not
sidelined
I think we're going to implement it anyway, just pref it off
just having a read only API doesn't meet those use cases
shanestephens_: why do we want to get it to FPWD?
birtles: I think we want to get rid of the animations stuff
from SVG and point to this thing
that's where this whole discussion is going in terms of FPWD
is this going to be a problem for SVG?
SVG is moving along, and this one is slowing down
we've got to work out how to solve that
shanestephens_: if we make it a NOTE would that work?
birtles: we still have the SVG integration document and that
will be referenced by SVG 2
shanestephens_: the CSS integration document will only allow
you to test that CSS transitions
birtles: what's the whole point of having a unified model, to
think out loud?
silvia: from what I'm hearing, you can't have a unified model
without the JS API?
shanestephens_: you can't test that it exists without a handle
on it
another way forward would be as part of the spec, specify
some interoperability primitives between SVG and CSS
so have some SVG animations using CSS key frames for example,
and vv
but that's getting in to new features
heycam: you could test how CSS and SVG animations interact
shanestephens_: so a model document that says how CSS and SVG
animations exist in the model and how they interact
then you can test the results of that
birtles: this is not testing much of the animation model
shanestephens_: can we just expose TimedItem?
birtles: it's almost more meaningful to allow CSS animations to
have an absolute start time
in terms of unifying the two
then at least you know they're working off the same clock
shanestephens_: that doesn't make them interoperable at all
though
... exposing TimedItem as a r/w object...
birtles: we could think about that next week
if you do that I think you might draw in the rest pretty
quickly
Cyril: you might want to see if people agree with the model by
implementing something
heycam: I think it would be fine to go along the REC track,
perhaps with conformance classes on other specifications using
the model spec
you don't need a test suite to pass CR
though you could just wait until you have feedback from
implementors that they are happy with re-jigging their
animation implementations in terms of the model
shanestephens_: you could point to the API spec and suggest
that as a way for them to test it internally
silvia: people won't be excited about a model spec
shanestephens_: I think we're pushing the model faster so that
it can be normatively referenced
the API can still stay as an ED next to it and publicise it
brian, dean and I are the people likely to implement in 3/5
browsers, so it's not like the people who need to see this
aren't seeing it
Cyril: will MS start implementing this now that there's a
unified model?
dino: wonder if a polyfill running in IE is enough to count as
an implementation
Requirements reevaluation continued
[$1\47] Have unknown elements treated as <g> for the purpose of
rendering
AlexD: useful for globalCoordinateSystem
heycam: I've never been entirely comfortable with changing the
behaviour here
ed: I don't like it at all
shanestephens_: Web Components is like a subset of unknown
elements
is that going to end up in SVG as well?
heycam: they rely on unknown elements being rendered?
shanestephens_: we'd need to look at exactly what they rely on
it's only a subset of unknown elements <x-blah>
<dmitry>
*[43]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_C
ommitments*
[43]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments*
heycam: it would be nice to have explicit wording about exactly
what is required of unknown elements
ed: I don't know if it makes sense to separate elements found
outside of <text> from text content elements
that's what you typically get from unknown/fallback
Cyril: in previous minutes we said it could be a fallback for
connectors
a new implementation will implement connectors, and a
previous one would ignore it
krit: do we have something in mind that we want to add new
graphical elements in the future?
if we wanted introduce a <brush> element as a new resource,
this wouldn't work as expected
for browsers who implement this unknown element, they would
render the <brush> contents
but those who do implement it would not render it
ed: I think it makes more sense to ignore / not draw unknown
content
krit: I think it will harm more than solve problems
RESOLUTION: We will drop the unknown-elements-are-rendered
requirement from SVG 2.
<scribe> ACTION: Cameron to clarify the behaviour of unknown
elements in SVG 2. [recorded in
[44]http://www.w3.org/2013/02/06-svg-minutes.html#action10]
<trackbot> Created ACTION-3448 - Clarify the behaviour of
unknown elements in SVG 2. [on Cameron McCormack - due
2013-02-14].
[$1\47] Remove the requirement to have @width and @height on
foreignObject
<shepazu> (I think this was a mischaracterization of the
"unknown elements" proposal)
heycam: this was to make foreignObject sized by shrink wrapping
based on its contents
dino: the width will be based on the viewport in HTML
doesn't make sense for it to be wider than that
krit: once width and height are properties, we have the auto
value
but we should keep the 0 width/height defaults
heycam: it's not something I feel strongly about
ed: I'm fine with not doing anything for this one
RESOLUTION: We will drop the "foreignObject can be
automatically sized" requirement for SVG 2.
[$1\47] Improve the fallback mechanism using switch
Cyril: is this similar to allowReorder?
ed: this is how you treat unknown elements
if you want to switch on something that is a new element,
then you won't check the conditional processing attributes
that's the issue
let's say we introduce a new <foo> element in SVG, in old
user agents you'd still like to see if the new feature string
is there, and do something special
<foo requiredFeatures="blah">
heycam: you could just wrap it in a <g>
ed: that's the workaround
maybe in some cases you don't want to have some wrapper
element
krit: if unknown elements are ignored, then you cannot
reference it
ed: render it
heycam: I say just look at those conditional processing
attributes if the element is in the SVG namespace
ed: currently a <switch> would always pick an unknown element,
since it is considered not to have any conditional processing
attributes, and therefore passes the tests
Cyril: you should never pick the element you don't know, what's
the sense in that?
ed: either you check the attributes you already know on SVG
elements, or you just ignore them
Cyril: so just remove it for the purpose of switch processing
ed: the only way you can get what you want is to wrap it in a
known SVG element
<scribe> ACTION: Erik to do the "Improve the fallback mechanism
using switch" requirement. [recorded in
[45]http://www.w3.org/2013/02/06-svg-minutes.html#action11]
<trackbot> Created ACTION-3449 - Do the "Improve the fallback
mechanism using switch" requirement. [on Erik Dahlstrφm - due
2013-02-14].
RESOLUTION: Keep the "Improve the fallback mechanism using
switch" requirement in SVG 2.
[$1\47] Provide a way to control audio level and playback
heycam: sounds like we should get this behaviour from the
HTMLAudioElement interface
so I don't think SVG needs anything specific
ed: the previous discussions didn't include <audio>, but I
think they should be
ACTION-3432: Should also add <audio>.
<trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the
iframe, canvas, video elements.
RESOLUTION: The "Provide a way to control audio level and
playback" SVG 2 requirement does not need any action, as we
will get this functionality from HTMLAudioElement.
[$1\47] Provide positioning information in MouseEvents
AlexD: returning a user space position
heycam: I thought I had a proposal on SVGPoint to get the
UIEvent's position in a given element's coordinate space
krit: I'd like to not encourage SVGPoint but rather a more
general Point that's being discussed in CSS
heycam: the problem is UIEvent is not really defined by us
... I'll take the requirement
RESOLUTION: We will keep the "Provide positioning information
in MouseEvents" requirement in SVG 2.
<scribe> ACTION: Cameron to do the "Provide positioning
information in MouseEvents" SVG 2 requirement. [recorded in
[46]http://www.w3.org/2013/02/06-svg-minutes.html#action12]
<trackbot> Created ACTION-3450 - Do the "Provide positioning
information in MouseEvents" SVG 2 requirement. [on Cameron
McCormack - due 2013-02-14].
[$1\47] Support CSS3 Color syntax
ed: this one already done
[$1\47] Support CSS3 image-fit
ed: got renamed to object-fit
... I'll keep that, if I have the time to do it
<scribe> ACTION: Erik to do the "Support CSS3 image-fit" SVG 2
requirement. [recorded in
[47]http://www.w3.org/2013/02/06-svg-minutes.html#action13]
<trackbot> Created ACTION-3451 - Do the "Support CSS3
image-fit" SVG 2 requirement. [on Erik Dahlstrφm - due
2013-02-14].
RESOLUTION: We will keep the "Support CSS3 image-fit" SVG 2
requirement.
[$1\47] Make it easier to write a zoom/pan widget, possibly by
adding convenience method to get scale/transfer
heycam: so we discussed in zurich possibly extending CSS
overflow and tying zoom/pan to that
Tab was interested in this
but it does not exist as a proposal yet
and needs more thought
I say defer unless there is a concrete proposal
ed: yep
RESOLUTION: We will defer the "Make it easier to write a
zoom/pan widget" SVG 2 requirement unless a concrete proposal
is forthcoming.
[$1\47] Align with CSS Value and Units
heycam: I'd like to take that one
<scribe> ACTION: Cameron to align SVG 2 with css3-values.
[recorded in
[48]http://www.w3.org/2013/02/06-svg-minutes.html#action14]
<trackbot> Created ACTION-3452 - Align SVG 2 with css3-values.
[on Cameron McCormack - due 2013-02-14].
RESOLUTION: We will keep the "Align with CSS Value and Units"
SVG 2 requirement.
[$1\47] Deprecate baseline-shift and use vertical-align
heycam: contingent on me rewriting the whole Text chapter
I will keep it
RESOLUTION: We will keep the "Deprecate baseline-shift and use
vertical-align" SVG 2 requirement.
[$1\47] Allow video elements to have captions, tracks, etc
krit: I don't know why I put my name there
heycam: should be part of Takagi-san's action, given he is
adding <video>
krit: so <track> and <source> would both be SVG elements as
well
ACTION-3432: Should also add <track> and <source>.
<trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the
iframe, canvas, video elements.
RESOLUTION: We will keep the "Allow video elements to have
captions, tracks, etc" SVG 2 requirement.
[$1\47] Allow clip to reference any element
heycam: Chris' name is on that currently
krit: the problem is you have a <g> with a <rect>, why should
that not clip while a plain <rect> would clip?
I don't think this would be a huge problem for anyone to
implement
heycam: if you have an existing shape, you don't want to
duplicate it to put it in a <clipPath>
krit: I'm not against it but I am not interested in doing the
spec work
cabanier: I will take it
birtles: we already have a resolution to allow a <g> in a
<clipPath>
<scribe> ACTION: Rik to allow the clip-path property to
reference non-<clipPath> elements in SVG 2, and to allow <g> in
a <clipPath>. [recorded in
[49]http://www.w3.org/2013/02/06-svg-minutes.html#action15]
<trackbot> Created ACTION-3453 - Allow the clip-path property
to reference non-<clipPath> elements in SVG 2, and to allow <g>
in a <clipPath>. [on Rik Cabanier - due 2013-02-14].
<birtles> [50]http://www.w3.org/2012/01/13-svg-irc#T03-58-11
[50] http://www.w3.org/2012/01/13-svg-irc#T03-58-11
RESOLUTION: We will keep the "Allow clip to reference any
element" SVG 2 requirement.
[$1\47] Promote some attributes to properties
krit: so this is just allowing auto for lengths etc.?
heycam: this is the whole property promotion change
unless somebody puts their hand up, defer
krit: leave it in the list and see if we have time for it later
... I just know I won't have the time in the next few months to
look at this, maybe after it
heycam: how about I put your name next to it
krit: ok
<scribe> ACTION: Dirk to do the "Promote some attributes to
properties" SVG 2 requirement. [recorded in
[51]http://www.w3.org/2013/02/06-svg-minutes.html#action16]
<trackbot> Created ACTION-3454 - Do the "Promote some
attributes to properties" SVG 2 requirement. [on Dirk Schulze -
due 2013-02-14].
RESOLUTION: We will keep the "Promote some attributes to
properties" SVG 2 requirement for now, and hope Dirk gets time
to do it.
[$1\47] Have an advance font metrics interface
heycam: seems deferable to me
dino: what does this mean? isn't there a measureText API in
canvas?
ed: that's usable for SVG as well
... if we don't have to do anything that's good too
cabanier: I'm not sure if people are happy with that API
dino: if you can defer something to another group, and they're
actually going to do it...
ed: what kind of things does it give you?
dino: the descender lengths, ...
cabanier: font bounding boxes, widths
RESOLUTION: We will defer the "Have an advance font metrics
interface" to the canvas spec.
<scribe> ACTION: Rik to investgate making the canvas font
metrics interface without needing a <canvas> element. [recorded
in [52]http://www.w3.org/2013/02/06-svg-minutes.html#action17]
<trackbot> Created ACTION-3455 - Investgate making the canvas
font metrics interface without needing a <canvas> element. [on
Rik Cabanier - due 2013-02-14].
ACTION-3455: Maybe by making TextMetrics take a constructor
with a text string, element context for style.
<trackbot> Notes added to ACTION-3455 Investgate making the
canvas font metrics interface without needing a <canvas>
element..
-- finish --
Summary of Action Items
[NEW] ACTION: Brian to define how #t= is interpeted in Web
Animations. [recorded in
[53]http://www.w3.org/2013/02/06-svg-minutes.html#action04]
[NEW] ACTION: Cameron to align SVG 2 with css3-values.
[recorded in
[54]http://www.w3.org/2013/02/06-svg-minutes.html#action14]
[NEW] ACTION: Cameron to clarify the behaviour of unknown
elements in SVG 2. [recorded in
[55]http://www.w3.org/2013/02/06-svg-minutes.html#action10]
[NEW] ACTION: Cameron to do the "Provide positioning
information in MouseEvents" SVG 2 requirement. [recorded in
[56]http://www.w3.org/2013/02/06-svg-minutes.html#action12]
[NEW] ACTION: Cyril to add Media Fragments support to SVG 2.
[recorded in
[57]http://www.w3.org/2013/02/06-svg-minutes.html#action03]
[NEW] ACTION: Dirk to do the "Promote some attributes to
properties" SVG 2 requirement. [recorded in
[58]http://www.w3.org/2013/02/06-svg-minutes.html#action16]
[NEW] ACTION: Dirk to email www-style about at-supports filter
function [recorded in
[59]http://www.w3.org/2013/02/06-svg-minutes.html#action07]
[NEW] ACTION: dirk to write up a spec for Matrix [recorded in
[60]http://www.w3.org/2013/02/06-svg-minutes.html#action06]
[NEW] ACTION: Erik to do the "Improve the fallback mechanism
using switch" requirement. [recorded in
[61]http://www.w3.org/2013/02/06-svg-minutes.html#action11]
[NEW] ACTION: Erik to do the "Support CSS3 image-fit" SVG 2
requirement. [recorded in
[62]http://www.w3.org/2013/02/06-svg-minutes.html#action13]
[NEW] ACTION: heycam add a string accessor on SVG animated
length and to make 'calc', 'attr' and 'var' work [recorded in
[63]http://www.w3.org/2013/02/06-svg-minutes.html#action08]
[NEW] ACTION: heycam to update SVGAnimatedAngle as well
[recorded in
[64]http://www.w3.org/2013/02/06-svg-minutes.html#action09]
[NEW] ACTION: krit to write up a spec for Matrix [recorded in
[65]http://www.w3.org/2013/02/06-svg-minutes.html#action05]
[NEW] ACTION: Rik to allow the clip-path property to reference
non-<clipPath> elements in SVG 2, and to allow <g> in a
<clipPath>. [recorded in
[66]http://www.w3.org/2013/02/06-svg-minutes.html#action15]
[NEW] ACTION: Rik to create a module to define SVG border
brushes [recorded in
[67]http://www.w3.org/2013/02/06-svg-minutes.html#action01]
[NEW] ACTION: Rik to investgate making the canvas font metrics
interface without needing a <canvas> element. [recorded in
[68]http://www.w3.org/2013/02/06-svg-minutes.html#action17]
[NEW] ACTION: Rik to specify variable width stroking in SVG2
[recorded in
[69]http://www.w3.org/2013/02/06-svg-minutes.html#action02]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [70]scribe.perl version
1.137 ([71]CVS log)
$Date: 2013-02-07 06:14:08 $
__________________________________________________________
Received on Thursday, 7 February 2013 06:17:28 UTC