IRC log of svg on 2009-03-16

Timestamps are in UTC.

19:33:04 [RRSAgent]
RRSAgent has joined #svg
19:33:04 [RRSAgent]
logging to http://www.w3.org/2009/03/16-svg-irc
19:33:06 [trackbot]
RRSAgent, make logs public
19:33:06 [Zakim]
Zakim has joined #svg
19:33:08 [trackbot]
Zakim, this will be GA_SVGWG
19:33:08 [Zakim]
ok, trackbot, I see GA_SVGWG()2:30PM already started
19:33:09 [trackbot]
Meeting: SVG Working Group Teleconference
19:33:09 [trackbot]
Date: 16 March 2009
19:33:52 [Zakim]
+??P1
19:33:56 [heycam]
Zakim, ??P1 is me
19:33:56 [Zakim]
+heycam; got it
19:34:03 [heycam]
Zakim, who is here?
19:34:03 [Zakim]
On the phone I see ??P0, heycam
19:34:04 [Zakim]
On IRC I see RRSAgent, ed_, heycam, jwatt, anthony, shepazu, trackbot, ed_work
19:34:08 [Zakim]
+Shepazu
19:34:31 [jwatt]
Zakim: ??P0 is me
19:34:51 [Zakim]
+??P2
19:35:00 [anthony]
Zakim, ??P2 is me
19:35:00 [Zakim]
+anthony; got it
19:35:02 [jwatt]
Zakim, ??P0 is me
19:35:02 [Zakim]
+jwatt; got it
19:36:00 [Zakim]
+??P3
19:36:04 [ChrisL]
ChrisL has joined #svg
19:36:05 [ed_]
Zakim, ??P3 is me
19:36:05 [Zakim]
+ed_; got it
19:36:35 [jwatt]
heycam: nope
19:36:41 [jwatt]
heycam: not a peep
19:37:00 [Zakim]
+ChrisL
19:38:18 [jwatt]
yeah
19:38:32 [ChrisL]
http://discussions.apple.com/message.jspa?messageID=6235454
19:38:36 [jwatt]
System Preferences > Sound
19:38:58 [jwatt]
heycam: Input Volume there
19:39:41 [ChrisL]
try saying "is this thing on?"
19:42:09 [heycam]
Chair: Erik
19:42:15 [heycam]
Scribe: Cameron
19:42:19 [heycam]
ScribeNick: heycam
19:42:29 [ed_]
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0241.html
19:45:18 [heycam]
Topic: Transforms
19:45:45 [heycam]
DS: css wg has resolved to publish 2d transforms
19:45:55 [heycam]
... is there anything that we should comment that we haven't already?
19:46:03 [heycam]
ED: it's possible that some of our comments apply to 2d transforms as well
19:46:14 [heycam]
... wondering if those have been taken into account already
19:46:23 [heycam]
DS: i don't think it's critical that they're taking into account before fpwd
19:46:26 [heycam]
ED: probably not
19:47:39 [heycam]
DS: dean asked for changes to be made to our spec, we should be sure to make them
19:49:57 [heycam]
Topic: SVGSVGElement inheriting from ViewCSS
19:50:00 [heycam]
ISSUE-2232?
19:50:00 [trackbot]
ISSUE-2232 -- SVGSVGElement should not inherit from ViewCSS -- RAISED
19:50:00 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2232
19:50:18 [heycam]
CL: is that an error?
19:50:21 [heycam]
CM: i believe so
19:50:51 [heycam]
DS: i suspect it's an error that wasn't caught early enough
19:50:58 [heycam]
CL: anyone implemented it that way?
19:51:02 [heycam]
JW: mozilla has
19:51:05 [heycam]
CM: batik has
19:51:18 [jwatt]
s/has/has not/
19:51:38 [jwatt]
oh
19:51:40 [jwatt]
mine
19:51:43 [heycam]
[to be clear: mozilla hasn't implemented it, batik has]
19:51:44 [jwatt]
oops
19:51:59 [heycam]
CL: will peoples content behave differently?
19:52:00 [jwatt]
s/mozilla has/mozilla has not/
19:52:04 [heycam]
DS: my guess would be no
19:52:13 [heycam]
CM: it's the only way to get computed css style in batik
19:52:22 [heycam]
... so any document that relies on that, in batik, would break
19:52:34 [heycam]
DS: it's esoteric, so it's probably not hard for content to be updated
19:53:03 [heycam]
CM: batik can keep around the getComputedStyle() method on SVGSVGElement anyway, for compat, if necessary
19:53:08 [heycam]
... but i think it should move to the Window object
19:53:17 [heycam]
ED: what does ViewCSS give you?
19:53:24 [heycam]
JW: it gives you computed style information
19:53:48 [jwatt]
JW: it resolves the cascade
19:53:57 [heycam]
JW: is there a window object in batik?
19:54:01 [heycam]
... can you implemented it there?
19:54:05 [heycam]
CM: yes there is, and it should
19:55:26 [heycam]
DS: an implementation could expose it both ways so that older content would still work
19:55:26 [heycam]
JW: because batik has a way of saying that some code that's called has been deprecated, right?
19:55:26 [heycam]
CM: no
19:55:26 [heycam]
... that'd be a neat feature :)
19:56:03 [heycam]
ED: so according to the cssom spec, which is being worked on, it'd be on the Window object and nothing else
19:56:13 [heycam]
... i don't really think it has a place on the SVGSVGElement interface
19:56:15 [heycam]
CM: me neither
19:56:16 [heycam]
JW: no
19:57:04 [heycam]
ACTION: Cameron to create an erratum for ISSUE-2232
19:57:04 [trackbot]
Created ACTION-2493 - Create an erratum for ISSUE-2232 [on Cameron McCormack - due 2009-03-23].
19:57:46 [heycam]
Topic: Circular references and error processing
19:57:50 [heycam]
http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F9DE@mailkeeper.mdigitalm.com
19:57:57 [heycam]
ED: this is for 1.2T
19:58:18 [heycam]
... i thought we did fix this for tiny
19:58:32 [heycam]
DS: I thought so too
19:58:58 [heycam]
CM: where is the recursion bit defined in 1.2T?
19:59:04 [ed_]
"A circular IRI reference is an error. Because SVG user agents may vary on when they first detect and abort a circular reference, conforming SVG document fragments must not rely upon circular references. Examples of circular references include:"
19:59:26 [ed_]
http://www.w3.org/TR/SVGMobile12/linking.html#IRIandURI
19:59:30 [ed_]
under the table
20:00:13 [heycam]
CM: ah, so it's an error, and then lee is taking exception to the fact that that requires highly visible indications
20:00:58 [heycam]
ED: i'm wondering if this sentence was something rather new, or not
20:01:02 [heycam]
CM: i think it was added in nuremberg?
20:01:31 [ed_]
http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/linking.html.diff?r1=1.105&r2=1.106&f=h
20:02:04 [ed_]
http://www.w3.org/Graphics/SVG/WG/track/actions/2024
20:02:18 [heycam]
... i remember discussing it then at least
20:03:21 [heycam]
CM: but then we also have those test slides that allow some level of recursion
20:03:21 [heycam]
... i'm not sure i'm completely comfortable with allowing an impl to choose an arbitrary depth to process it with
20:03:22 [heycam]
ED: is this incorrect and we should add an erratum?
20:04:37 [heycam]
CL: the only difference it says that content must not rely on it since the place the recursion is detected could be inconsistent
20:04:37 [heycam]
CM: i can see the intention of that
20:04:39 [heycam]
... since you might find the cycle at a different link somewhere in that cycle
20:04:54 [heycam]
ED: ACTION-2023 says to make the circular reference an unsupported value
20:05:00 [ed_]
http://www.w3.org/Graphics/SVG/WG/track/actions/2023
20:06:17 [heycam]
CM: so an arbitrary link in the cycle will use the lacuna value?
20:06:23 [heycam]
... maybe we can say that explicitly
20:07:05 [heycam]
... that, or i would be happier with prescribing exactly which link gets dropped and replaced with the lacuna value
20:07:10 [heycam]
... but that's more work
20:07:13 [heycam]
... (for us)
20:07:18 [heycam]
DS: i don't think this is a problem
20:07:33 [heycam]
... lee says that we should soften the language
20:07:36 [heycam]
CL: soften it to what?
20:07:49 [heycam]
DS: "a highly perceivable indication of error", softer than that
20:07:56 [heycam]
... the way they normally handle an error is that they don't render the file
20:08:11 [heycam]
... i suspect they're saying that they don't want to not handle the file if it's a fairly minor example of circular referencing
20:08:21 [heycam]
CL: didn't erik find that this is an unsupported value and not an error?
20:08:39 [heycam]
ED: i found discussion previiously in the minutes, which resulting in ACTION-2023
20:08:49 [heycam]
... but that action was closed saying "superseded by something else"
20:08:57 [heycam]
DS: i recall us saying that it was going to be an error
20:09:10 [heycam]
... but since we softened up what errors were in svg, that it was more appropriate that it be an error
20:09:30 [heycam]
... my interpretation is that they're saying "we don't want to not render content jsut because it has a circular reference"
20:09:38 [heycam]
... according to the spec, it's fine
20:09:56 [heycam]
CL: yes, the spec says that authors can't rely on content that relies on the impl catching the recursion at a particular point
20:10:06 [heycam]
DS: we should reply to ask exactly what it should be softened to
20:10:20 [heycam]
ACTION: Doug to reply to Lee asking what the recursion detection softening should actually be
20:10:20 [trackbot]
Created ACTION-2494 - Reply to Lee asking what the recursion detection softening should actually be [on Doug Schepers - due 2009-03-23].
20:11:00 [heycam]
Topic: objectBoundingBox and absolute lengths
20:11:12 [heycam]
http://www.w3.org/mid/49BA6295.1040001@jwatt.org
20:12:05 [heycam]
JW: in the linked email i have a link to a blog, where some mozilla guy is talking about using this in non-SVG content
20:12:10 [heycam]
... but it also applies to within SVG
20:12:42 [heycam]
... lengths with units on them other than percentages become completely useless when you have clipPathUnits="objectBoundingBox"
20:12:54 [heycam]
... beacuse the spec says that objectBoundingBox should be implemneted by appending an implicit transform
20:13:03 [heycam]
... so that basically the left side of the object is at 0 and the right side is at 1
20:14:08 [heycam]
... it would seem like units are useless here
20:14:31 [heycam]
... it'd be useful to change the spec to say that objectBoundingBox to modify what percentages are resolved against
20:14:46 [heycam]
... and remove the bit of the text that talks about the implicit transform, which makes the other units useless
20:15:01 [heycam]
DS: they probably meant more "conceptual" than "implicit", at a guess
20:15:10 [heycam]
... i think what you're saying makes a lot of sense
20:15:15 [heycam]
CM: would we have "1" be different from "1px"?
20:15:47 [heycam]
ED: if you had a clipPath that you wanted relative to the viewport, then those percentages would now be resolved against the bbox of what you're using it on
20:15:57 [heycam]
... you could mix viewport percentages and bbox percentages
20:16:26 [heycam]
... currently, %s are resolved against the viewport
20:16:32 [heycam]
JW: but not in objectBoundingBox
20:16:51 [heycam]
ED: really? we should test it.
20:17:18 [heycam]
... i've heard the same complaints several times, though
20:17:22 [heycam]
... so changing it might be a good idea still
20:17:34 [heycam]
JW: i thought %s were resolved against the bbox when objectBoundingBox is in use
20:18:08 [heycam]
ACTION: Jonathan to test how percentages resolve with objectBoundingBox
20:18:08 [trackbot]
Created ACTION-2495 - Test how percentages resolve with objectBoundingBox [on Jonathan Watt - due 2009-03-23].
20:18:40 [heycam]
JW: if it does not cause a problem, should i just propose wording?
20:18:46 [heycam]
DS: yes, propose wording anyway
20:18:58 [heycam]
JW: if it does conflict, we'll bring it up at the next telcon
20:19:18 [heycam]
Topic: errors in the SVG 1.1 implementation notes
20:20:14 [heycam]
http://www.w3.org/mid/49BA1959.6080503@mindspring.com
20:20:14 [heycam]
ED: do we have the same wording in 1.2T?
20:20:14 [heycam]
... we don't have arcs, i guess
20:21:26 [heycam]
luckily each symbol in the "task to find" is a separate image
20:21:29 [heycam]
so should be easy to move
20:22:47 [heycam]
CL: it's just phi that's in the wrong place
20:23:17 [heycam]
I think F.6.5 also needs changing.
20:23:47 [heycam]
s/5/4/
20:24:40 [heycam]
ACTION: Chris to add an erratum for SVG 1.1 F.6.5 to move the variables around
20:24:40 [trackbot]
Created ACTION-2496 - Add an erratum for SVG 1.1 F.6.5 to move the variables around [on Chris Lilley - due 2009-03-23].
20:25:07 [heycam]
Topic: 'image-fit" vs preserveAspectRatio
20:25:20 [heycam]
ED: this came up in css discussion
20:25:31 [heycam]
... people seem to be looking for a way to fit images into some viewport
20:26:14 [heycam]
... making sure they can control how it's positioned and fills the viewport
20:26:14 [heycam]
... so quite similar to SVG's pAR
20:26:14 [heycam]
... but image-fit also allows positioning to a finer degree than we support
20:26:14 [heycam]
... also it's a CSS property, which this attribute isn't
20:26:20 [heycam]
... i haven't followed the discussion, if there has been any
20:26:24 [heycam]
CM: i don't think there has been any
20:26:29 [heycam]
... apart from what was crossposted
20:27:33 [heycam]
DS: i'm inclined to say that this is an area that we should ask them to align to us, and when they have things that could work in SVG, we could co-align with them
20:27:38 [heycam]
... so if they're allowing something that we can't do in SVG, but there's no reason we can't, even if it comes with a slight change of syntax, i think we should allow it
20:27:46 [heycam]
ED: there are some problems with choosing pAR as a name of a property
20:27:52 [heycam]
... esp the camel casing
20:28:08 [heycam]
... i guess it could still be mapped into something that worked
20:28:51 [heycam]
... it'd only be an issue in svg content anyway
20:28:51 [heycam]
... we can't remove the attribute
20:28:51 [heycam]
DS: we needn't remove pAR
20:28:52 [heycam]
... what's their proposed property name?
20:28:54 [heycam]
ED: image-fit
20:28:56 [heycam]
... according to simon, they called it pAR first, not sure what's the reason for changing it
20:28:58 [heycam]
DS: they might've been concerned with it conflicting with SVG
20:29:00 [heycam]
... also it's long
20:29:17 [heycam]
... i wonder if there's a name that would better fit our and their use case
20:29:32 [heycam]
... for us, preserveAspectRatio is honestly not particularly clear, or if that's the best way of phrasing it
20:29:42 [heycam]
... we could just make a new aspect-ratio attribute that aligns with their
20:29:55 [heycam]
... and we could both add a property/attribute of the same name
20:31:00 [heycam]
... we define how it works wrt pAR
20:31:00 [heycam]
... e.g. this overrides pAR when both are supplied
20:31:00 [heycam]
... seems the easiest way, with the most gain for everyone
20:31:00 [heycam]
CM: i'd agree with that
20:31:01 [heycam]
DS: or we could ask them to use pAR, but then we'd need to define what happens when people use it without camel casing, etc.
20:32:00 [heycam]
... is the name image-fit intuitive for SVG?
20:32:00 [heycam]
ED: it's not always about image fitting in SVG
20:32:00 [heycam]
DS: maybe aspect-ratio
20:32:00 [heycam]
ED: for things like symbols, any viewport establishing element
20:32:16 [heycam]
DS: will css people confuse this with screen aspect ratio?
20:32:19 [heycam]
... or svg people?
20:32:23 [heycam]
CL: they might think that
20:32:35 [heycam]
DS: aspect-ratio seems to get it
20:32:41 [heycam]
CL: the name we have is much more precise, i think
20:33:19 [heycam]
DS: image-fit is not particularly good for the SVG case
20:33:20 [ChrisL]
aspect ratio preservation strategy
20:33:26 [heycam]
ED: so what do we want to suggest to them
20:33:34 [heycam]
DS: don't want to get into a shed painting discussion
20:33:46 [heycam]
... be more producting if we did come up with something that did fit ours and theirs, though, and propose that to them
20:33:59 [heycam]
... and say we'd like to adopt this, it overrides pAR like this, etc.
20:37:20 [heycam]
http://www.w3.org/mid/op.uqqgwlqxidj3kv@zcorpandell.linkoping.osa
20:37:20 [heycam]
ACTION: Doug to reply to Simon about image-fit
20:37:20 [heycam]
trackbot, hello?
20:37:20 [trackbot]
Created ACTION-2497 - Reply to Simon about image-fit [on Doug Schepers - due 2009-03-23].
20:37:20 [trackbot]
Sorry, heycam, I don't understand 'trackbot, hello?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
20:39:20 [heycam]
Topic: SVG in text/html
20:40:39 [heycam]
ED: two new files have been checked in to CVS
20:40:44 [heycam]
... starting point for proposals
20:40:46 [heycam]
DS: right
20:41:05 [heycam]
ED: have there been any edits so far?
20:41:11 [heycam]
DS: i haven't made any so far
20:41:19 [heycam]
ED: the edited one is -mod?
20:41:20 [heycam]
DS: yes
20:42:44 [heycam]
... the idea i had would be that it's easiest to work in the raw file, instead of in the wiki
20:42:55 [heycam]
... it'd allow easier diffs between the two
20:43:19 [heycam]
ED: so this modified document has everything that was commented out in the html 5 spec?
20:43:28 [heycam]
DS: yes, there was some other stuff that i stripped out
20:43:42 [heycam]
... this is the part i thought we wanted to the most modifications to
20:44:00 [heycam]
... svg is mentioned in other places in html 5, but it mostly all references this section
20:45:42 [heycam]
... he makes a difference between tag name and element name
20:46:42 [heycam]
... this might be terminology specifically for this foreign content handling
20:46:56 [heycam]
... i mentioned in the email what i think we should do
20:47:17 [heycam]
... there's one section that talks about attributes, that's one place where i would say we would add parse errors for the foreign content mode
20:48:34 [heycam]
... liam quin (xml guy) liked the idea of reporting when/where missing attribute quotes, e.g., is reported
20:48:44 [heycam]
ED: looking at some of the feedback jwatt sent recently
20:49:00 [heycam]
... there are things we want to change based on feedback so far
20:49:05 [heycam]
... and on jonathan's suggestions
20:49:07 [ed_]
http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0222.html
20:49:12 [ed_]
http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0223.html
20:50:10 [heycam]
... how much of the feedback/agreements we have will we incorporate into the document?
20:50:24 [heycam]
maybe someone needs to collate the agreed-upon points
20:50:54 [heycam]
ED: what we agreed on might have changed based on comments we got back
20:51:17 [heycam]
... not sure if we should use the wiki page again, or just start working on the document directly
20:52:35 [heycam]
... it would be more efficient to just work on the modified document, and take any disagreements back to the list
20:52:36 [heycam]
DS: we should propose some wording for the upcoming HTML meeting
20:52:40 [heycam]
ED: I could allocate some time for that
20:53:52 [heycam]
CL: so hopefully we won't have any whitelisting, and will definitely allow current syntax?
20:54:42 [ChrisL]
allow, but not require
20:56:18 [heycam]
CL: e.g. it'd be fine for namespaces to be omitted, but shouldn't require removing them
20:56:38 [heycam]
CL: similarly for casing; it shouldn't require element names to be specified in lowercase
20:56:48 [heycam]
... so you should be able to take content and paste it in svg
20:57:06 [heycam]
... taking content out of html into an svg authoring tool would be ok
20:57:53 [heycam]
... don't want to see tools that only export "new svg"
20:57:53 [heycam]
DS: our proposal wouldn't violate those requirements
20:59:27 [Zakim]
-ChrisL
20:59:29 [Zakim]
-ed_
20:59:29 [Zakim]
-anthony
20:59:31 [Zakim]
-heycam
20:59:42 [Zakim]
-Shepazu
20:59:55 [heycam]
RRSAgent, make minutes
20:59:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/16-svg-minutes.html heycam
21:00:22 [shepazu]
ed_: I'm going to add ids to those sections
21:00:36 [shepazu]
let me know which ones you want to edit
21:01:13 [ed_]
ChrisL: btw, will you be attending the thursday call? (do you want to have vector-effects on the agenda?)
21:01:38 [Zakim]
-jwatt
21:01:39 [Zakim]
GA_SVGWG()2:30PM has ended
21:01:40 [Zakim]
Attendees were heycam, Shepazu, anthony, jwatt, ed_, ChrisL
21:02:52 [jwatt]
okay
21:03:07 [jwatt]
percentages are completely useless in the face of objectBoundingBox
21:03:28 [jwatt]
we so need to fix this
21:05:52 [jwatt]
we should try and register a non-xml mime type for svg though
21:06:05 [jwatt]
as well as image/svg+xml
21:06:11 [jwatt]
shepazu
21:06:44 [ed_]
yes
21:06:48 [shepazu]
on phone, brb
21:54:36 [shepazu]
ed_: any thoughts on which parts you want to do?
22:24:37 [Zakim]
Zakim has left #svg