- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 06 Apr 2009 10:01:58 +0200
- To: public-svg-wg@w3.org
Minutes are available here:
http://www.w3.org/2009/04/06-svg-minutes.html
or as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
06 Apr 2009
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0007.html
See also: [3]IRC log
[3] http://www.w3.org/2009/04/06-svg-irc
Attendees
Present
Doug_Schepers, [IPcaller], ed_, heycam, anthony
Regrets
Chair
Cameron
Scribe
erik
Contents
* [4]Topics
1. [5]Additional value for image-rendering
2. [6]Selectors, getElementsByTagName() and camelCase SVG
3. [7]ISSUE-2255: Effect of modifying
SVGSVGElement::useCurrentView unclear
4. [8]ISSUE-2254: Consider changing which elements have load
dispatched to them
5. [9]ISSUE-2253: <foreignObject>s should be allowed as
children of container elements
6. [10]ISSUE-2216: Not clear whether assigning to
SVGLength.valueAsString can change the unitType
7. [11]f2f meeting
8. [12]transforms
* [13]Summary of Action Items
_________________________________________________________
<trackbot> Date: 06 April 2009
<scribe> scribe: erik
<scribe> scribeNick: ed_
Additional value for image-rendering
CM: bringing this up since we discussed it last week
... i think our conclusion was to use nearestNeighbor for it
... but robert longson didn't get a response on www-svg, so they've
renamed their value -moz-crisp-edges
... not the one we chose in the end
DS: didn't feel that strongly about it
CM: me neither, just wanted to respond quickly to them
... crisp-edges makes some sense, it's used elsewhere
... so either we go for something like that or we go on with
nearestNeighbor
ED: I'd prefer nearestNeighbor, but as long as crispEdges is defined
to be nearestNeighbor that's ok, people might find it easier to
understand crispEdges
CM: ok, so we'll leave it at that then
Selectors, getElementsByTagName() and camelCase SVG
<heycam>
[14]http://www.w3.org/mid/2E216A7B-066B-4996-91FE-562CA633F9C5@iki.f
i
[14] http://www.w3.org/mid/2E216A7B-066B-4996-91FE-562CA633F9C5@iki.fi
CM: thread started by hsivonen
... what getelementsbytagname should do, given that we'll have
camelcased elements in the dom now
... the practical effect is that it does case-insensitive matchinig
... because the html parser does lowercase folding, and gebtn does
lowercase folding of the element string argument that's passed to it
... if it's left as it's defined now in html5, you wouldn't be able
to match the camelcased elements that are in the dom
... in practice I would expect most svg content to use
... *NS methods, so wouldn't run into the problems with non-NS
methods
DS: reviewing it, I do use getElementsByTagName in svg
... and in pure svg too
... because I know the content is svg, however if I wanted to use it
in html+svg I would switch to use the *NS method
CM: I tend to avoid the non-NS methods
ED: I do use the non-NS methods sometimes, and would like them to
work as well as possible
CM: there was a suggestion to use the parser algorithm (case-fixing
table) for getElementsByTagName
... which is probably ok
ED: that would make it a bit more consistent, so I'd prefer
something like that
CM: so weird-case elements would not work, but such elements
wouldn't be useful
<heycam> document.createElementNS(svgns, 'ReCt')
CM: so that ReCT element wouldn't be matched by getElementsByTagName
DS: I don't see a problem with this
CM: another issue that was brought up is 'textArea'
... because if you convert it to the canonical case you wouldn't
know to which element to convert to, 'textArea' or 'textarea'
... same issue in CSS selectors too
... there's no context
... the solution of using canonical case wouldn't work for textArea
DS: isn't it the actual name of the element?
CM: they want to work out the canoical case of the element
DS: not happy about the textArea element, but we're working out
potential future issues with this
CM: do we want to decide something or just chime in on that thread?
... the suggestions there seem sensible
... if we're stuck with textArea, and want it to work
... we should say that we want to be able to select either textArea
or textarea
... will test current browser behaviour with that
ISSUE-2255: Effect of modifying SVGSVGElement::useCurrentView unclear
CM: please get all errata-related actions done asap, so we can
publish second edition
... not sure how useful the useCurrentView attribute is
... you can modify it
... but ti's meant to indicate if the iri had a fragment on it
... not sure it makes sense to be able to modify it
... I'd suggest to change it to readonly
... opera implements the view stuff?
ED: yes
... I agree it should probably be readonly
CM: ok, leave it in there and make it correct
<scribe> ACTION: heycam to make an SVG 1.1 erratum to make
SVGSVGElement.useCurrentView be readonly, and to remove the
exception on it [recorded in
[15]http://www.w3.org/2009/04/06-svg-minutes.html#action01]
<trackbot> Created ACTION-2510 - Make an SVG 1.1 erratum to make
SVGSVGElement.useCurrentView be readonly, and to remove the
exception on it [on Cameron McCormack - due 2009-04-13].
ISSUE-2254: Consider changing which elements have load dispatched to
them
CM: haven't fully thought it through
... it's about the load event in svg
... it differs a bit form the html load event
... to make things more similar svg <-> html
... in svg all elements get a load event, but in html only gets load
events if it's having an external resource
... may be that dispatching load for all elements may be a
performance problem
... tested in opera and firefox, both dispatched load on every
element in svg
... may not be such a big issue
... could be that it's already optimized
DS: not convinced that it's like the mutation events
CM: traditionally the mutation events haven't got good
implementation/interop, but the load events in svg are
... it's not common to have listeners on all elements in svg (for
load)
DS: unless there's an event lsiterner, then it shouldn't be much of
a burden
CM: I'd expect such optimizations yes
ED: Opera does have slight differences in
... load and svgload
... would prefer to align with the html behaviour
CM: svgload is dispatched to every element, but load is only
dispatched to elements that have external resources
AG: don't see the usefulness of dispatching the event to elements
that don't have ext resources
CM: right, so I usually put it on <image> but not on other elements
AG: what's the impact on implementations?
CM: haven't tested the tiny implementations
AG: probably do the optimization for it mentioned before
CM: we have tests for it in the testsuite?
... so 'onload' will listen to 'SVGLoad'?
ED: yes, you can listen for 'load' with addEventListener
DS: svg is different form html in that it can take longer to render
svg
... notable in firefox, for when boundingboxes are available (onload
or otherwise)...could be solved by onrender event...
... in html all references are external, but in svg they can be
internal as well
... having onload there, or onrender would be useful, for
document-internal references too
... e.g if you reference forward in the file
... with larger files, we can use progress events
... onload could be replaced by onrender and progress events, and
then we could align onload with html
CM: in 1.1 there's no requirements on 'load' just for 'SVGLoad', so
they could be different
... the requirement for SVGLoad to be sent to an element when all
its child elements are loaded, not sure how useful that is really
ED: probably only if using externalResourcesRequired
CM: if we're going to change this, do we want to change it in core-2
or in 1.1 errata?
AG: probably core-2, it's a rather large change
... thing onrender idea is useful too
ED: onrender sounds like it might be resource-demanding,
expensive...but depends on what you mean with it
DS: we already say something about getbbox
... onrender would mean everything has been rendered to screen
... mauybe you already know it's going to be expensive, moving many
elements, you just want to know when it's rendered
CM: i think it would happen when the scriptblock has finished
... so setTimeout(0...)
... onrender might be cleaner though
... no spec really says when render happens
... there are conventions, but not really specified
... you didn't want it for every render? or just the first one?
DS: just speculating, what do ppl want when they use onload
AG: might be something we could work out for core2
CM: yeah, what ppl use onload for would be useful info
DS: we could ask on svgdevelopers, are ppl relying on onload being
different?
... is there some advantage?
CM: should we leave this issue open?
DS: we should ask svgdevelopers
... maybe we could get it into an errata
<scribe> ACTION: DS to ask svgdevelopers / svgig about
onload/svgload events and how they use it [recorded in
[16]http://www.w3.org/2009/04/06-svg-minutes.html#action02]
<trackbot> Created ACTION-2511 - Ask svgdevelopers / svgig about
onload/svgload events and how they use it [on Doug Schepers - due
2009-04-13].
ISSUE-2253: <foreignObject>s should be allowed as children of container
elements
CM: noticed while doing the 1.1 dtd, you're not allowed to put
foreignObject anywhere but as a child of switch
... though in tiny12 you can have it anywhere
DS: it was never really implemented in 1.1, not sure it matters,
does it say anything in the spec?
CM: I'd understand if there was a reason for it in the spec, but you
can still put conditional attributes on the foreignObject itself
without switch
... suggest allowing it in any container element
ED: yes, sounds good
<scribe> ACTION: heycam to make an SVG 1.1 errata for allowing
foreignObject in any container element (not just in <switch>)
[recorded in
[17]http://www.w3.org/2009/04/06-svg-minutes.html#action03]
<trackbot> Created ACTION-2512 - Make an SVG 1.1 errata for allowing
foreignObject in any container element (not just in <switch>) [on
Cameron McCormack - due 2009-04-13].
ISSUE-2216: Not clear whether assigning to SVGLength.valueAsString can
change the unitType
CM: what should happen with the unittype on the length object
... I think that what's intended is that the unittype changes if you
assign something with valueAsString
... doesn't define exceptions to throw if something bad is assigned,
e.g 'x'
... probably should raise some exception
<heycam>
[18]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/000
8.html
[18]
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html
AG: what's the change for the newValueSpecifiedUnits/convert...
methods?
CM: they throw on bad values, didn't say before what should happen
in such cases
AG: ok, I'm ok with that
ED: looks ok to me too
CM: another issue is open how you resolve units on lengthobjects
... wll address that separetely
<scribe> ACTION: heycam to make an SVG 1.1 errata with the proposed
changes in
[19]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/000
8.html and to test existing implementations (for exceptioncodes used
if any etc) [recorded in
[20]http://www.w3.org/2009/04/06-svg-minutes.html#action04]
[19]
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html
<trackbot> Created ACTION-2513 - Make an SVG 1.1 errata with the
proposed changes in
[21]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/000
8.html and to test existing implementations (for exceptioncodes used
if any etc) [on Cameron McCormack - due 2009-04-13].
[21]
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html
f2f meeting
AG: could we move it one week later?
CM: chris had a css meeting the week before, right?
DS: yes
CM: I don't mind
DS: ok with me
AG: jwatt will attend?
DS: I'd expect so
ED: I'd prefer the 8-13 june, the week after is a bit worse for me
AG: ok, I'm fine with the week starting the 8th...
DS: slight preference to keeping it as it is
transforms
DS: AG you had an action to explain why a 3x3 is as good as a 4x4
matrix...
AG: 4x3 you mean?
DS: right
... dean want's to have an explanation, perhaps on the wiki?
... as a bonus we'd be compatible with openvg
... helpful if this could be done soon
AG: regarding modules, are we go for publishing again?
DS: yes
Summary of Action Items
[NEW] ACTION: DS to ask svgdevelopers / svgig about onload/svgload
events and how they use it [recorded in
[22]http://www.w3.org/2009/04/06-svg-minutes.html#action02]
[NEW] ACTION: heycam to make an SVG 1.1 errata for allowing
foreignObject in any container element (not just in <switch>)
[recorded in
[23]http://www.w3.org/2009/04/06-svg-minutes.html#action03]
[NEW] ACTION: heycam to make an SVG 1.1 errata with the proposed
changes in
[24]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/000
8.html and to test existing implementations (for exceptioncodes used
if any etc) [recorded in
[25]http://www.w3.org/2009/04/06-svg-minutes.html#action04]
[NEW] ACTION: heycam to make an SVG 1.1 erratum to make
SVGSVGElement.useCurrentView be readonly, and to remove the
exception on it [recorded in
[26]http://www.w3.org/2009/04/06-svg-minutes.html#action01]
[24]
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [27]scribe.perl version 1.135
([28]CVS log)
$Date: 2009/04/06 08:00:25 $
_________________________________________________________
[27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[28] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [29]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/8-15/8-13 june/
Found Scribe: erik
Found ScribeNick: ed_
Default Present: Doug_Schepers, [IPcaller], ed_, heycam, anthony
Present: Doug_Schepers [IPcaller] ed_ heycam anthony
Agenda: [30]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJu
n/0007.html
Found Date: 06 Apr 2009
Guessing minutes URL: [31]http://www.w3.org/2009/04/06-svg-minutes.html
People with action items: ds heycam
[30]
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0007.html
[31] http://www.w3.org/2009/04/06-svg-minutes.html
End of [32]scribe.perl diagnostic output]
[32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 6 April 2009 08:02:57 UTC