See also: IRC log
<trackbot> Date: 06 April 2009
<scribe> scribe: erik
<scribe> scribeNick: ed_
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
<heycam> 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
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 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].
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 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].
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 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].
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> 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 http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html and to test existing implementations (for exceptioncodes used if any etc) [recorded in http://www.w3.org/2009/04/06-svg-minutes.html#action04]
<trackbot> Created ACTION-2513 - Make an SVG 1.1 errata with the proposed changes in http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html and to test existing implementations (for exceptioncodes used if any etc) [on Cameron McCormack - due 2009-04-13].
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
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0007.html Found Date: 06 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/06-svg-minutes.html People with action items: ds heycam[End of scribe.perl diagnostic output]