SVG Working Group Teleconference -- 16 Mar 2009

<trackbot> Date: 16 March 2009

<jwatt> Zakim: ??P0 is me

<jwatt> heycam: nope

<jwatt> heycam: not a peep

<jwatt> yeah

<ChrisL> http://discussions.apple.com/message.jspa?messageID=6235454

<jwatt> System Preferences > Sound

<jwatt> heycam: Input Volume there

<ChrisL> try saying "is this thing on?"

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Transforms

DS: css wg has resolved to publish 2d transforms
... is there anything that we should comment that we haven't already?

ED: it's possible that some of our comments apply to 2d transforms as well
... wondering if those have been taken into account already

DS: i don't think it's critical that they're taking into account before fpwd

ED: probably not

DS: dean asked for changes to be made to our spec, we should be sure to make them

SVGSVGElement inheriting from ViewCSS

ISSUE-2232?

<trackbot> ISSUE-2232 -- SVGSVGElement should not inherit from ViewCSS -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2232

CL: is that an error?

CM: i believe so

DS: i suspect it's an error that wasn't caught early enough

CL: anyone implemented it that way?

JW: mozilla has

CM: batik has not

<jwatt> oh

<jwatt> mine

[to be clear: mozilla has notn't implemented it, batik has]

<jwatt> oops

CL: will peoples content behave differently?

DS: my guess would be no

CM: it's the only way to get computed css style in batik
... so any document that relies on that, in batik, would break

DS: it's esoteric, so it's probably not hard for content to be updated

CM: batik can keep around the getComputedStyle() method on SVGSVGElement anyway, for compat, if necessary
... but i think it should move to the Window object

ED: what does ViewCSS give you?

JW: it gives you computed style information

<jwatt> JW: it resolves the cascade

JW: is there a window object in batik?
... can you implemented it there?

CM: yes there is, and it should

DS: an implementation could expose it both ways so that older content would still work

JW: because batik has a way of saying that some code that's called has been deprecated, right?

CM: no
... that'd be a neat feature :)

ED: so according to the cssom spec, which is being worked on, it'd be on the Window object and nothing else
... i don't really think it has a place on the SVGSVGElement interface

CM: me neither

JW: no

<scribe> ACTION: Cameron to create an erratum for ISSUE-2232 [recorded in http://www.w3.org/2009/03/16-svg-minutes.html#action01]

<trackbot> Created ACTION-2493 - Create an erratum for ISSUE-2232 [on Cameron McCormack - due 2009-03-23].

Circular references and error processing

http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F9DE@mailkeeper.mdigitalm.com

ED: this is for 1.2T
... i thought we did fix this for tiny

DS: I thought so too

CM: where is the recursion bit defined in 1.2T?

<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:"

<ed_> http://www.w3.org/TR/SVGMobile12/linking.html#IRIandURI

<ed_> under the table

CM: ah, so it's an error, and then lee is taking exception to the fact that that requires highly visible indications

ED: i'm wondering if this sentence was something rather new, or not

CM: i think it was added in nuremberg?

<ed_> http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/linking.html.diff?r1=1.105&r2=1.106&f=h

<ed_> http://www.w3.org/Graphics/SVG/WG/track/actions/2024

CM: i remember discussing it then at least
... but then we also have those test slides that allow some level of recursion
... i'm not sure i'm completely comfortable with allowing an impl to choose an arbitrary depth to process it with

ED: is this incorrect and we should add an erratum?

CL: the only difference it says that content must not rely on it since the place the recursion is detected could be inconsistent

CM: i can see the intention of that
... since you might find the cycle at a different link somewhere in that cycle

ED: ACTION-2023 says to make the circular reference an unsupported value

<ed_> http://www.w3.org/Graphics/SVG/WG/track/actions/2023

CM: so an arbitrary link in the cycle will use the lacuna value?
... maybe we can say that explicitly
... that, or i would be happier with prescribing exactly which link gets dropped and replaced with the lacuna value
... but that's more work
... (for us)

DS: i don't think this is a problem
... lee says that we should soften the language

CL: soften it to what?

DS: "a highly perceivable indication of error", softer than that
... the way they normally handle an error is that they don't render the file
... 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

CL: didn't erik find that this is an unsupported value and not an error?

ED: i found discussion previiously in the minutes, which resulting in ACTION-2023
... but that action was closed saying "superseded by something else"

DS: i recall us saying that it was going to be an error
... but since we softened up what errors were in svg, that it was more appropriate that it be an error
... my interpretation is that they're saying "we don't want to not render content jsut because it has a circular reference"
... according to the spec, it's fine

CL: yes, the spec says that authors can't rely on content that relies on the impl catching the recursion at a particular point

DS: we should reply to ask exactly what it should be softened to

<scribe> ACTION: Doug to reply to Lee asking what the recursion detection softening should actually be [recorded in http://www.w3.org/2009/03/16-svg-minutes.html#action02]

<trackbot> Created ACTION-2494 - Reply to Lee asking what the recursion detection softening should actually be [on Doug Schepers - due 2009-03-23].

objectBoundingBox and absolute lengths

http://www.w3.org/mid/49BA6295.1040001@jwatt.org

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
... but it also applies to within SVG
... lengths with units on them other than percentages become completely useless when you have clipPathUnits="objectBoundingBox"
... beacuse the spec says that objectBoundingBox should be implemneted by appending an implicit transform
... so that basically the left side of the object is at 0 and the right side is at 1
... it would seem like units are useless here
... it'd be useful to change the spec to say that objectBoundingBox to modify what percentages are resolved against
... and remove the bit of the text that talks about the implicit transform, which makes the other units useless

DS: they probably meant more "conceptual" than "implicit", at a guess
... i think what you're saying makes a lot of sense

CM: would we have "1" be different from "1px"?

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
... you could mix viewport percentages and bbox percentages
... currently, %s are resolved against the viewport

JW: but not in objectBoundingBox

ED: really? we should test it.
... i've heard the same complaints several times, though
... so changing it might be a good idea still

JW: i thought %s were resolved against the bbox when objectBoundingBox is in use

<scribe> ACTION: Jonathan to test how percentages resolve with objectBoundingBox [recorded in http://www.w3.org/2009/03/16-svg-minutes.html#action03]

<trackbot> Created ACTION-2495 - Test how percentages resolve with objectBoundingBox [on Jonathan Watt - due 2009-03-23].

JW: if it does not cause a problem, should i just propose wording?

DS: yes, propose wording anyway

JW: if it does conflict, we'll bring it up at the next telcon

errors in the SVG 1.1 implementation notes

http://www.w3.org/mid/49BA1959.6080503@mindspring.com

ED: do we have the same wording in 1.2T?
... we don't have arcs, i guess

luckily each symbol in the "task to find" is a separate image

so should be easy to move

CL: it's just phi that's in the wrong place

I think F.6.4 also needs changing.

<scribe> ACTION: Chris to add an erratum for SVG 1.1 F.6.5 to move the variables around [recorded in http://www.w3.org/2009/03/16-svg-minutes.html#action04]

<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].

'image-fit" vs preserveAspectRatio

ED: this came up in css discussion
... people seem to be looking for a way to fit images into some viewport
... making sure they can control how it's positioned and fills the viewport
... so quite similar to SVG's pAR
... but image-fit also allows positioning to a finer degree than we support
... also it's a CSS property, which this attribute isn't
... i haven't followed the discussion, if there has been any

CM: i don't think there has been any
... apart from what was crossposted

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
... 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

ED: there are some problems with choosing pAR as a name of a property
... esp the camel casing
... i guess it could still be mapped into something that worked
... it'd only be an issue in svg content anyway
... we can't remove the attribute

DS: we needn't remove pAR
... what's their proposed property name?

ED: image-fit
... according to simon, they called it pAR first, not sure what's the reason for changing it

DS: they might've been concerned with it conflicting with SVG
... also it's long
... i wonder if there's a name that would better fit our and their use case
... for us, preserveAspectRatio is honestly not particularly clear, or if that's the best way of phrasing it
... we could just make a new aspect-ratio attribute that aligns with their
... and we could both add a property/attribute of the same name
... we define how it works wrt pAR
... e.g. this overrides pAR when both are supplied
... seems the easiest way, with the most gain for everyone

CM: i'd agree with that

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.
... is the name image-fit intuitive for SVG?

ED: it's not always about image fitting in SVG

DS: maybe aspect-ratio

ED: for things like symbols, any viewport establishing element

DS: will css people confuse this with screen aspect ratio?
... or svg people?

CL: they might think that

DS: aspect-ratio seems to get it

CL: the name we have is much more precise, i think

DS: image-fit is not particularly good for the SVG case

<ChrisL> aspect ratio preservation strategy

ED: so what do we want to suggest to them

DS: don't want to get into a shed painting discussion
... be more producting if we did come up with something that did fit ours and theirs, though, and propose that to them
... and say we'd like to adopt this, it overrides pAR like this, etc.

http://www.w3.org/mid/op.uqqgwlqxidj3kv@zcorpandell.linkoping.osa

<scribe> ACTION: Doug to reply to Simon about image-fit [recorded in http://www.w3.org/2009/03/16-svg-minutes.html#action05]

trackbot, hello?

<trackbot> Created ACTION-2497 - Reply to Simon about image-fit [on Doug Schepers - due 2009-03-23].

<trackbot> Sorry, heycam, I don't understand 'trackbot, hello?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

SVG in text/html

ED: two new files have been checked in to CVS
... starting point for proposals

DS: right

ED: have there been any edits so far?

DS: i haven't made any so far

ED: the edited one is -mod?

DS: yes
... the idea i had would be that it's easiest to work in the raw file, instead of in the wiki
... it'd allow easier diffs between the two

ED: so this modified document has everything that was commented out in the html 5 spec?

DS: yes, there was some other stuff that i stripped out
... this is the part i thought we wanted to the most modifications to
... svg is mentioned in other places in html 5, but it mostly all references this section
... he makes a difference between tag name and element name
... this might be terminology specifically for this foreign content handling
... i mentioned in the email what i think we should do
... 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
... liam quin (xml guy) liked the idea of reporting when/where missing attribute quotes, e.g., is reported

ED: looking at some of the feedback jwatt sent recently
... there are things we want to change based on feedback so far
... and on jonathan's suggestions

<ed_> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0222.html

<ed_> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0223.html

ED: how much of the feedback/agreements we have will we incorporate into the document?

maybe someone needs to collate the agreed-upon points

ED: what we agreed on might have changed based on comments we got back
... not sure if we should use the wiki page again, or just start working on the document directly
... it would be more efficient to just work on the modified document, and take any disagreements back to the list

DS: we should propose some wording for the upcoming HTML meeting

ED: I could allocate some time for that

CL: so hopefully we won't have any whitelisting, and will definitely allow current syntax?

<ChrisL> allow, but not require

CL: e.g. it'd be fine for namespaces to be omitted, but shouldn't require removing them
... similarly for casing; it shouldn't require element names to be specified in lowercase
... so you should be able to take content and paste it in svg
... taking content out of html into an svg authoring tool would be ok
... don't want to see tools that only export "new svg"

DS: our proposal wouldn't violate those requirements

- DRAFT -

SVG Working Group Teleconference

16 Mar 2009

Attendees

Contents