- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 17 Mar 2009 08:02:42 +1100
- To: public-svg-wg@w3.org
http://www.w3.org/2009/03/16-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
16 Mar 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0241.html
See also: [3]IRC log
[3] http://www.w3.org/2009/03/16-svg-irc
Attendees
Present
Regrets
Chair
Erik
Scribe
Cameron
Contents
* [4]Topics
1. [5]Transforms
2. [6]SVGSVGElement inheriting from ViewCSS
3. [7]Circular references and error processing
4. [8]objectBoundingBox and absolute lengths
5. [9]errors in the SVG 1.1 implementation notes
6. [10]'image-fit" vs preserveAspectRatio
7. [11]SVG in text/html
* [12]Summary of Action Items
_________________________________________________________
<trackbot> Date: 16 March 2009
<jwatt> Zakim: ??P0 is me
<jwatt> heycam: nope
<jwatt> heycam: not a peep
<jwatt> yeah
<ChrisL>
[13]http://discussions.apple.com/message.jspa?messageID=6235454
[13] 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> [14]http://www.w3.org/Graphics/SVG/WG/track/issues/2232
[14] 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
[15]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
[16]http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F9DE
@mailkeeper.mdigitalm.com
[16] 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_> [17]http://www.w3.org/TR/SVGMobile12/linking.html#IRIandURI
[17] 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_>
[18]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/linking.html.d
iff?r1=1.105&r2=1.106&f=h
[18] http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/linking.html.diff?r1=1.105&r2=1.106&f=h
<ed_> [19]http://www.w3.org/Graphics/SVG/WG/track/actions/2024
[19] 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_> [20]http://www.w3.org/Graphics/SVG/WG/track/actions/2023
[20] 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
[21]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
[22]http://www.w3.org/mid/49BA6295.1040001@jwatt.org
[22] 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
[23]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
[24]http://www.w3.org/mid/49BA1959.6080503@mindspring.com
[24] 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
[25]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.
[26]http://www.w3.org/mid/op.uqqgwlqxidj3kv@zcorpandell.linkoping.os
a
[26] http://www.w3.org/mid/op.uqqgwlqxidj3kv@zcorpandell.linkoping.osa
<scribe> ACTION: Doug to reply to Simon about image-fit [recorded in
[27]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 [28]http://www.w3.org/2005/06/tracker/irc for help
[28] http://www.w3.org/2005/06/tracker/irc
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_>
[29]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/022
2.html
[29] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0222.html
<ed_>
[30]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/022
3.html
[30] 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
Summary of Action Items
[NEW] ACTION: Cameron to create an erratum for ISSUE-2232 [recorded
in [31]http://www.w3.org/2009/03/16-svg-minutes.html#action01]
[NEW] ACTION: Chris to add an erratum for SVG 1.1 F.6.5 to move the
variables around [recorded in
[32]http://www.w3.org/2009/03/16-svg-minutes.html#action04]
[NEW] ACTION: Doug to reply to Lee asking what the recursion
detection softening should actually be [recorded in
[33]http://www.w3.org/2009/03/16-svg-minutes.html#action02]
[NEW] ACTION: Doug to reply to Simon about image-fit [recorded in
[34]http://www.w3.org/2009/03/16-svg-minutes.html#action05]
[NEW] ACTION: Jonathan to test how percentages resolve with
objectBoundingBox [recorded in
[35]http://www.w3.org/2009/03/16-svg-minutes.html#action03]
[End of minutes]
_________________________________________________________
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 16 March 2009 21:03:26 UTC