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