SVG Working Group Teleconference -- 06 Apr 2009

<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> 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 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 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 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> 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].

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

- DRAFT -

SVG Working Group Teleconference

06 Apr 2009

Attendees

Contents