IRC log of svg on 2012-04-26

Timestamps are in UTC.

20:58:51 [RRSAgent]
RRSAgent has joined #svg
20:58:51 [RRSAgent]
logging to
20:58:53 [trackbot]
RRSAgent, make logs public
20:58:53 [Zakim]
Zakim has joined #svg
20:58:55 [trackbot]
Zakim, this will be GA_SVGWG
20:58:55 [Zakim]
ok, trackbot, I see GA_SVGWG(SVG1)5:00PM already started
20:58:56 [trackbot]
Meeting: SVG Working Group Teleconference
20:58:56 [trackbot]
Date: 26 April 2012
20:59:26 [Zakim]
20:59:29 [Zakim]
20:59:31 [Zakim]
20:59:55 [krit]
zakim, vhardy_ is me
20:59:55 [Zakim]
+krit; got it
21:00:29 [Zakim]
21:00:40 [ed]
Zakim, ??P15 is me
21:00:40 [Zakim]
+ed; got it
21:01:19 [Zakim]
21:01:21 [heycam]
Zakim, ??P4 is me
21:01:21 [Zakim]
+heycam; got it
21:02:05 [ed]
21:02:08 [ed]
chair: ed
21:03:08 [heycam]
Scribe: Cameron
21:03:12 [heycam]
ScribeNick: heycam
21:03:28 [heycam]
Topic: progress update for SVG2
21:03:35 [ed]
21:03:48 [heycam]
ED: there have been a couple of placeholders added
21:03:59 [heycam]
… I was wondering about how to deal with proposals
21:04:16 [heycam]
… everything in the table that needs a proposal, is it fine to put something in the spec, or should we go through the mailing list first?
21:05:18 [heycam]
CM: could just add it to the spec
21:05:32 [heycam]
… bring it up on the list before, if you think it will be controversial
21:05:49 [heycam]
DS: I couldn't find the canvas topic on the list of requirements
21:06:20 [Zakim]
+ +
21:06:36 [Tav]
zakim, +33 is me
21:06:36 [Zakim]
+Tav; got it
21:06:55 [krit]
21:07:30 [heycam]
TB: I've taken where people have made committments, where it's easy to do so, I've added a note/annotation in the spec
21:07:48 [heycam]
… I've listed the requirement, resolution, when the resolution was made, why, and who is committed to doing it
21:08:00 [heycam]
… there are some things I don't know where they're supposed to go
21:08:18 [heycam]
ED: the next step is just to start editing those sections
21:08:21 [heycam]
Topic: canvas in SVG
21:08:34 [ed]
21:08:55 [heycam]
DS: I think it's necessary that we support this
21:09:05 [heycam]
… this will be an SVG canvas element and not an HTML one
21:09:21 [heycam]
TB: would it work just like any other image?
21:09:28 [heycam]
DS: I don't think there's anything special to handle
21:09:35 [heycam]
… in HTML, it has width/height attributes and properties
21:10:03 [ChrisL]
ChrisL has joined #svg
21:10:17 [heycam]
… referencing the HTML spec might be a tricky part
21:10:50 [Zakim]
21:11:12 [heycam]
CM: alex's mail suggests other features for canvas that aren't in the HTML one, automatically calling a function to repaint for example
21:11:32 [heycam]
DS: I am happy to take on that requirement if nobody else wants to
21:11:43 [ChrisL]
21:12:09 [heycam]
RESOLUTION: SVG2 will have a canvas element, the exact details TBD.
21:12:18 [ChrisL]
good to resolve this, thought we already did but I don't have a link
21:12:55 [heycam]
ACTION: Dirk to add an entry to the requirements and commitments page for canvas in SVG
21:12:56 [trackbot]
Created ACTION-3263 - Add an entry to the requirements and commitments page for canvas in SVG [on Dirk Schulze - due 2012-05-03].
21:13:45 [heycam]
Topic: replacing SVGException with new Web IDL exceptions
21:13:54 [heycam]
CL: no objections, sounds like a good thing to do
21:13:58 [heycam]
ED: I think that's fine
21:14:42 [heycam]
CM: I think it's unlikely people are relying on the exact details of SVGException
21:15:50 [Zakim]
21:15:51 [heycam]
RESOLUTION: SVG2 will use Web IDL style exceptions in place of SVGException
21:16:25 [jen]
jen has joined #svg
21:16:49 [heycam]
ACTION: Cameron to make SVG2 use Web IDL exceptions instead of SVGException
21:16:49 [trackbot]
Created ACTION-3264 - Make SVG2 use Web IDL exceptions instead of SVGException [on Cameron McCormack - due 2012-05-03].
21:17:02 [heycam]
ACTION: Cameron to rewrite SVG2's IDL to use Web IDL
21:17:02 [trackbot]
Created ACTION-3265 - Rewrite SVG2's IDL to use Web IDL [on Cameron McCormack - due 2012-05-03].
21:17:23 [heycam]
Topic: Hamburg F2F agenda
21:17:25 [ed]
21:17:30 [heycam]
ED: a reminder to put agenda proposals on the page
21:18:20 [heycam]
CL: we decided to meet in zurich already I think
21:18:22 [heycam]
CM: yes
21:19:10 [heycam]
Topic: masks and filters being children of what they apply to
21:19:22 [heycam]
21:19:45 [heycam]
ED: Brian is asking to add this to the requirements list
21:20:13 [heycam]
CM: is the idea to have <mask>, <filter>, etc. to apply to their parents?
21:20:21 [heycam]
CL: it's not clear
21:21:08 [heycam]
… in existing SVG, how would you tell the difference between a mask masking its parent, a <g> or an <svg>, and this new way?
21:21:44 [heycam]
CM: I think automatically having them apply to their parent would break content
21:22:12 [heycam]
CL: we would need a switch to turn that behaviour on
21:22:18 [heycam]
… does mask point to something?
21:22:23 [heycam]
ED: the mask property points to the mask element
21:22:28 [heycam]
… I don't think the mask element points to anything
21:22:58 [heycam]
CL: can we use the absence of this url() value to indicate this new behaviour?
21:23:23 [heycam]
NA: I think the pointer is around the way
21:23:45 [heycam]
ED: one way is to introduce a keyword the mask property, mask="child" for example
21:23:55 [heycam]
… we already have url() or none
21:24:09 [ChrisL]
ok so the filter property value is FuncIRI | none | parent
21:24:33 [heycam]
DS: we should take into account that an FX spec will want to specify the mask property
21:24:43 [heycam]
CL: all properties can be expressed as presentation attributes
21:24:59 [heycam]
… are you worried about the webkit mask property?
21:25:01 [heycam]
DS: yes
21:25:08 [heycam]
CL: there, they want to point to an image
21:25:31 [heycam]
… they can still use url() to point to an image, we'd just need to relax the wording of the property definition to say it can point to images as well as a mask element
21:26:26 [ChrisL]
s/to an image/to a raster image/
21:27:47 [heycam]
[discussion of whether to allow "child" as a value for the property, vs just the presentation attribute, vs on the mask element itself]
21:28:02 [heycam]
CM: so you would rather an attribute on the <mask> element that says "apply to parent"
21:28:07 [ChrisL]
21:28:15 [heycam]
ED: it might be more intuitive that way
21:28:17 [ChrisL]
like animation elements do
21:29:05 [heycam]
CL: current implementations would ignore any new <mask applytoparent> elements
21:30:20 [heycam]
ED: one advantage of having it on the property, the element that uses the mask you know directly there that it is going to be masked
21:30:30 [heycam]
… otherwise you need to traverse the subtree and find the mask element
21:30:37 [heycam]
CM: same for animation though
21:30:58 [heycam]
DS: clip path, gradient, patterns
21:31:22 [heycam]
… would the pattern apply to fill or stroke?
21:31:25 [heycam]
CL: same question for gradients
21:32:09 [heycam]
DS: what about two mask elements?
21:32:19 [ChrisL]
mask and clip are unambiguous when applying to the parent. gradient and pattern could apply to the stroke or the fill ...
21:32:40 [heycam]
CM: I wonder if it's more useful for clip path, mask, filters than gradients/patterns
21:33:08 [ChrisL]
who proposed the requirement?
21:33:37 [heycam]
Brian Birtles
21:33:39 [ChrisL]
action: brian to propose in detail how mask and clip work on parents
21:33:39 [trackbot]
Created ACTION-3266 - Propose in detail how mask and clip work on parents [on Brian Birtles - due 2012-05-03].
21:34:01 [heycam]
ACTION: Cameron to follow up with Brian about ACTION-3266
21:34:01 [trackbot]
Created ACTION-3267 - Follow up with Brian about ACTION-3266 [on Cameron McCormack - due 2012-05-03].
21:34:07 [heycam]
Topic: July F2F dates
21:34:16 [ed]
21:35:16 [heycam]
CM: if we could move it to the start of the week, that would be convenient to have at the start of the week
21:35:26 [heycam]
21:35:37 [heycam]
CL: we need to find out if the Seattle site and the Paris site can do it
21:35:59 [heycam]
… I also proposed in the email that the Seattle side start a couple of hours earlier, 7am-3pm say, that would make it 4pm-midnight in France
21:37:54 [krit]
Seattle F2F 23 to 25 of July
21:38:01 [ChrisL]
Ok so its Mon 23 to Weds 25 July
21:39:40 [heycam]
Topic: transforms on svg:svg elements
21:39:48 [heycam]
DS: we already have viewBox on <svg:svg>, when does transform apply?
21:40:13 [heycam]
… I propose, transform then viewBox then preserveAspectRatio then width/height/etc.
21:40:46 [heycam]
CM: so like wrapping the <svg> element with a <g transform>
21:40:50 [heycam]
… I think that makes sense
21:40:54 [krit]
<g transform=""><svg></svg><g> == <svg transform ...>
21:41:21 [heycam]
ED: is this only for nested elements?
21:41:25 [heycam]
DS: also for top level
21:41:51 [heycam]
CL: I think it's important for the behaviour of referencing this top level element, and just rendering it, to be the same
21:41:57 [heycam]
… so it should also apply to the top level
21:42:30 [heycam]
… people who are doing mapping, where you want to zoom in and move around, it's easier to have a transform and modify it on the root
21:42:33 [heycam]
DS: and keep the viewBox
21:42:57 [heycam]
CM: where does the currentTranslate, currentScale fit in?
21:43:00 [heycam]
ED: I think they would come in first
21:43:10 [heycam]
CL: we did define this precisely in TIny 1.2
21:43:15 [heycam]
… we decided to copy that across to SVG2
21:43:59 [ed]
21:45:16 [heycam]
ED: would we want to integrate the currentTranslate, currentScale into the transform?
21:45:20 [heycam]
21:45:41 [ChrisL]
no, I was thinking more of
21:46:09 [ed]
21:47:22 [heycam]
ED: the UA translations/scales might be modified by browser chrome, menu items
21:47:30 [heycam]
… I think it makes sense to keep separate
21:48:36 [heycam]
CM: I'm happy to keep them separate
21:49:08 [heycam]
DS: does this also mean we make SVGSVGElement be SVGTransformable?
21:49:11 [heycam]
CL: yes I think we would
21:49:55 [heycam]
ACTION: Dirk to investigate currentTranslate etc. and how they fit with <svg:svg transform="">
21:49:55 [trackbot]
Created ACTION-3268 - Investigate currentTranslate etc. and how they fit with <svg:svg transform=""> [on Dirk Schulze - due 2012-05-03].
21:50:24 [heycam]
Topic: text decorations and rotated glyphs
21:50:25 [heycam]
21:50:59 [heycam]
CM: do text decorations rotate along with rotated glyphs?
21:51:15 [heycam]
CL: what the content author expects is "it depends"
21:51:31 [heycam]
… if they're rotating a few glyphs 10 degrees left and right, they probably want the underline to be continuous underneath
21:51:45 [heycam]
… if they're doing shifts and things, they probably want the decoration to shift with the glyphs
21:51:53 [heycam]
… that argues to me to have both behaviours, and a way to switch between them
21:53:11 [heycam]
CL: sometimes the underline is just drawn as a stroke, but sometimes it's a feature of the font
21:53:39 [heycam]
… also CSS has some odd rules for colouring of decorations
21:53:49 [heycam]
CM: I hope we can have the same behaviour as CSS for decoration colours
21:53:55 [heycam]
CL: I think we made a good effort to align with CSS
21:54:08 [heycam]
ED: CSS doesn't have paints for fill/stroke
21:54:26 [ChrisL]
css color property is effectively text-fill-color
21:54:59 [heycam]
CL: would this be a separate property or a new value for text-decoration?
21:55:04 [heycam]
CM: I think a separate property would be better
21:55:30 [ChrisL]
text-decoration-transform : track | ignore
21:56:28 [heycam]
ACTION: Cameron to propose a property for making text decorations rotate or not
21:56:28 [trackbot]
Created ACTION-3269 - Propose a property for making text decorations rotate or not [on Cameron McCormack - due 2012-05-03].
21:56:53 [heycam]
Topic: mail from EXI regarding path syntax
21:56:57 [ed]
21:57:19 [heycam]
CL: I thought we had decided anyway to have an element syntax for paths
21:57:21 [Zakim]
21:57:28 [heycam]
… and an API that works on both syntaxes
21:57:59 [heycam]
… an EXI pre-processor could also use the API to decompose the path out into the verbose notation
21:58:00 [Zakim]
21:58:47 [ed]
22:01:49 [heycam]
ACTION: Chris to the mail from EXI WG on the current status of the verbose path notation
22:01:50 [trackbot]
Created ACTION-3270 - The mail from EXI WG on the current status of the verbose path notation [on Chris Lilley - due 2012-05-03].
22:03:18 [Zakim]
22:03:19 [Zakim]
22:03:20 [Zakim]
22:03:21 [Zakim]
22:03:23 [Zakim]
22:03:23 [Zakim]
22:03:23 [Zakim]
GA_SVGWG(SVG1)5:00PM has ended
22:03:23 [Zakim]
Attendees were nikos, krit, ed, heycam, +, Tav, ChrisL, [Microsoft]
22:03:28 [heycam]
RRSAgent, make minutes
22:03:28 [RRSAgent]
I have made the request to generate heycam
22:06:41 [heycam]
Zakim, who is on the call?
22:06:41 [Zakim]
apparently GA_SVGWG(SVG1)5:00PM has ended, heycam
22:06:50 [heycam]
RRSAgent, make minutes
22:06:50 [RRSAgent]
I have made the request to generate heycam
22:07:23 [heycam]
Present: Erik, Dirk, Nikos, Cameron, Tav, Chris, Jen
22:07:27 [heycam]
RRSAgent, make minutes
22:07:27 [RRSAgent]
I have made the request to generate heycam
22:07:46 [heycam]
Regrets: Doug, Rik
22:07:49 [heycam]
Chair: Erik
22:07:51 [heycam]
RRSAgent, make minutes
22:07:51 [RRSAgent]
I have made the request to generate heycam
23:00:20 [birtles]
birtles has joined #svg
23:13:40 [birtles]
man, I really have to dial into these telcons. I got given the same action I already completed :(
23:17:35 [heycam]
23:17:56 [heycam]
I guess we didn't read your mail closely enough :(
23:18:02 [krit]
birtles: IIRC there was no paper that descibes how an element should interact with different gradient s, pattern or mask applied to it, was there?
23:18:12 [krit]
heycam: might be
23:18:30 [krit]
birtles: link again please?
23:18:38 [heycam]
23:18:41 [birtles]
23:18:46 [birtles]
thanks heycam
23:18:57 [birtles]
yeah, there are still details that need to be hammered out
23:19:07 [birtles]
like considering Cyril's proposal for reversing the direction of the link
23:19:19 [birtles]
all I was requesting though was for the feature to be added to the requirements list
23:19:28 [birtles]
we can work out the specifics later
23:20:22 [heycam]
yeah we got distracted by the specifics and didn't come back to the "adding to the requirements" part. sorry about that!
23:20:55 [heycam]
people were in favour of the idea modulo the specifics, though, it seemed
23:21:10 [krit]
birtles: should sth. like that work as well? <rect><pattern><pattern></rect>? Or is it just for mask, filter, clipPath?
23:21:26 [birtles]
right, I thought we already had that discussion on the list and people were in favour in principle
23:21:58 [birtles]
krit: yes, I listed pattern in the mail as a candidate
23:22:20 [birtles]
(see the Scope section)
23:22:23 [krit]
birtles: so fill and stroke must be extended to use child as value?
23:22:37 [birtles]
krit: I'm suggesting we consider it
23:22:57 [birtles]
the motivation is to reduce dependence on ID spaghetti
23:23:23 [krit]
birtles: I understand that
23:24:20 [krit]
birtles: I had concerns about the ussage of 'child', since e.g 'mask' might be used in HTML as well
23:24:31 [birtles]
so anywhere we're relying on IDs we should be offering an alternative mechanism, child / parent seems an obvious approach
23:24:41 [krit]
birtles: I don't like the idea to introduce a new keyword that just works on SVG
23:25:05 [birtles]
krit, I'm open to other suggestions, I just want to see something in the requirements list to track this
23:25:09 [krit]
birtles: so we should continue the discussion on www-svg
23:25:19 [krit]
birtles: have to run for now
23:25:21 [birtles]
krit, right, that would be good
23:25:24 [birtles]
krit, ok, thanks!
23:28:13 [birtles_]
birtles_ has joined #svg
23:42:11 [thorton]
thorton has joined #svg
23:53:52 [krit]
krit has joined #svg