W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes, March 16 2009 telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 17 Mar 2009 08:02:42 +1100
To: public-svg-wg@w3.org
Message-ID: <20090316210242.GA11947@arc.mcc.id.au>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 16 March 2009 21:03:28 GMT