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

Minutes, April 6, 2009 telcon

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 06 Apr 2009 10:01:58 +0200
To: public-svg-wg@w3.org
Message-ID: <op.uryglkyngeuyw5@blorp.xn--dahlstrm-t4a.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 08:02:58 GMT