See also: IRC log
<trackbot> Date: 16 March 2009
<jwatt> Zakim: ??P0 is me
<jwatt> heycam: nope
<jwatt> heycam: not a peep
<jwatt> System Preferences > Sound
<jwatt> heycam: Input Volume there
<ChrisL> try saying "is this thing on?"
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
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
<trackbot> ISSUE-2232 -- SVGSVGElement should not inherit from ViewCSS -- RAISED
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
[to be clear: mozilla has notn't implemented it, batik has]
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,
... 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
... 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?
... 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
<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].
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_> 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?
CM: i remember discussing it then
... 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
... 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
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
... 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
... 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].
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
... 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
... 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
ED: do we have the same wording
... 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].
ED: this came up in css
... 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
... 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
... 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?
... 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
... 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.
<scribe> ACTION: Doug to reply to Simon about image-fit [recorded in http://www.w3.org/2009/03/16-svg-minutes.html#action05]
<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
ED: two new files have been
checked in to CVS
... starting point for proposals
ED: have there been any edits so far?
DS: i haven't made any so far
ED: the edited one is -mod?
... 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: 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
... 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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/has/has not/ Succeeded: s/mozilla has/mozilla has not/ Succeeded: s/5/4/ Found Scribe: Cameron Found ScribeNick: heycam WARNING: No "Present: ... " found! Possibly Present: CL CM ChrisL DS ED JW P0 P1 P2 P3 ScribeNick anthony ed_ ed_work heycam joined jwatt shepazu svg trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0241.html Found Date: 16 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/16-svg-minutes.html People with action items: cameron chris doug jonathan[End of scribe.perl diagnostic output]