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

Minutes, Raleigh F2F 2009 day 1

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 9 Jun 2009 08:34:28 +1000
To: public-svg-wg@w3.org
Message-ID: <20090608223428.GD25546@arc.mcc.id.au>
Hello WG.

The minutes from the first day of the Raleigh F2F are available here:

  http://www.w3.org/2009/06/08-svg-minutes.html

and as text below.


   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

08 Jun 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/06/08-svg-irc

Attendees

   Present
          CL, ED, DS, JW, CM

   Regrets
   Chair
          heycam

   Scribe
          jwatt, heycam

Contents

     * [3]Topics
         1. [4]Pointer-events
         2. [5]Some 1.1 errata
         3. [6]CSS
         4. [7]MAE
     * [8]Summary of Action Items
     _________________________________________________________



   <trackbot> Date: 08 June 2009

   <ChrisL> (discussion of agenda and priorities)

   <ChrisL> Meeting: SVG WF f2f

   <ed> trackbot: close ACTION-2594

   <trackbot> ACTION-2594 Raise an issue to determine the encoding of
   external <script> closed

Pointer-events

   <shepazu>
   [9]http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_E
   dition#Doug

      [9] http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition#Doug

   <ChrisL> Chair: Cameron

   <shepazu>
   [10]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
   rrata.html#capturing-pointer-events-zero-opacity

     [10] http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#capturing-pointer-events-zero-opacity

   <ChrisL> ScribeNick: jwatt

   <shepazu>
   [11]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
   rrata.html#clippath-affects-bounding-boxes

     [11] http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#clippath-affects-bounding-boxes

   <shepazu>
   [12]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
   rrata.html#clippath-pointer-events

     [12] http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#clippath-pointer-events

   <shepazu>
   [13]http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty

     [13] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty

   <ChrisL> filters in safari (but out of date)
   [14]http://webkit.org/projects/svg/status.xml

     [14] http://webkit.org/projects/svg/status.xml

   <heycam> [doug discusses the problem, jwatt will gather his thoughts
   and we'll return to the problem later]

   <heycam> ScribeNick: heycam

Some 1.1 errata

   <jwatt>
   [15]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
   rrata.html#mention-live-values

     [15] http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#mention-live-values

   JW: first, about the second change (initialize) the text added
   ... in mozilla, there's no heavyweight dom there
   ... so these list objects are created on demand
   ... if we insert an item into the list, we just copy the value in
   and put it into our compact internal representation
   ... so the text about it being a copy and not a reference isn't good

   CL: we should just clarify if these are just handles to the values

   ED: in opera, too. the list types say that you have to take the
   objects out of any previous lists they're in. so there's no overhead
   at all for us to move them between lists.
   ... making the lists live is cheap for us

   JW: so they're live in one direction only? if you get the object,
   say item #2 in the list, and get an object back, if you change the
   object it will change the attribute that it's mapped to?

   ED: yes

   JW: but only the object that you asked for has a reference back to
   the element
   ... you can change the object you get back, e.g. change the
   SVGTransform
   ... because that object has a handle back to the element
   ... but we don't want the elements to have memory for all of the
   pointers to the objects

   CM: if you call getItem(0) twice in a row you get back two different
   objects?

   JW: for some of our list classes yes
   ... we could have one pointer to a tearoff wrapper object
   ... for what was being asked
   ... i don't particularly like that they're different objects
   ... but people don't in general check the identity of these objects
   ... so that's why we went with this optimisation
   ... adding text like in this erratum means it has to be the same
   object

   CM: but we already say that objects can't be in two lists

   ED: right, but you only need one pointer back to the list that it's
   in

   JW: but also you need to have the list keep a pointer to the list
   item that was asked for

   CM: it's only one pointer

   JW: i'm thinking also about consistency with other things, like
   rectElt.x
   ... should that return the same object all the time?

   ED: so you're concerned about having an element with an attribute
   x="", and use elt.x.baseVal to get to it, then change it with
   setAttribute(), would it update the object?

   JW: no that would, that's ok
   ... for an SVGLength object, it keeps a reference to the element,
   but the element doesn't keep a reference to the SVGLength object
   itself
   ... it saves memory on each element object
   ... if every time you ask for .x.baseVal you get the same SVGlength
   object, then you need to start keeping references
   ... i'm not concerned about cpu so much, just memory
   ... i withdraw my objection, i can use a hash table to store the
   tearoff objects

   <jwatt>
   [16]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
   rrata.html#container-element-rewording

     [16] http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#container-element-rewording

   JW: apart from two obvious typo changes, it changes "can" to "will"
   ... (disable progressive rendering)
   ... and adds "if that container includes elements that reference
   external resources"
   ... if eRR="true"

   CL: which i think is the intent of the original text
   ... so just setting it won't freeze rendering, only if it's
   triggered will it do that

   JW: my issues with that is that it will disable prog rendering but
   only if the container has external refs
   ... so in mozilla, chunks come in over the network and it paints as
   you go

   CL: that's fine, you go along and when you find the missing external
   reference, you stop rendering there

   CM: it doesn't remove the rendering for the preceding elements in
   the container

   CL: it's analagous to well formedness error handling
   ... there are two ways to interpret what's written
   ... 1) stop rendering just when you find a missing external
   reference, or 2) disable rendering of the whole container when you
   find a child missing external reference

   DS: if eRR="true" on the root, then nothing should be rendered until
   all external refs have downloaded, imo
   ... don't want the user to think they've got the whole document if
   they haven't
   ... i think the default should be that eRR="true" simply stops the
   rendering
   ... but progressiveRendering="true" (if that existed) would allow
   progressive rendering
   ... JW said yesterday that another use case is to delay script so
   that you can get at contentDocuments and so on

   [some discussion of SVGLoad delaying]

   CM: so with eRR="false", the default, SVGLoad won't be delayed for
   external resources
   ... which is unlike HTML's load

   [some discussion of the usefulness of SVGLoad being dispatched to
   elements without external refs]

   CM: just about every element can have external refs, like
   fill="url(...)"

   JW: i want SVGLoad to be dispatched only AT_TARGET (with no
   capturing)

   CM: but progressiveRendering="" doesn't exist, and we can't add that
   for a second edition
   ... or in an erratum
   ... who implements eRR=""?

   ED: opera does

   <ed>
   [17]http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-
   201-t.svg -
   [18]http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-
   204-t.svg

     [17] http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-201-t.svg
     [18] http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-204-t.svg

   <jwatt> here's my eRR test:

   <jwatt> <svg xmlns="[19]http://www.w3.org/2000/svg"

     [19] http://www.w3.org/2000/svg

   <jwatt> xmlns:xlink="[20]http://www.w3.org/1999/xlink"

     [20] http://www.w3.org/1999/xlink

   <jwatt> externalResourceRequired="true">

   <jwatt> <rect width="100%" height="100%" fill="lime"/>

   <jwatt> <image xlink:href="doobydoo" width="100" height="100"/>

   <jwatt> <rect width="100%" height="100%" fill="red"/>

   <jwatt> </svg>

   <jwatt> shows red in Opera 10 beta

   <jwatt> so it looks like it doesn't implement
   externalResourceRequired at all

   [after some discussion, we decide to move this erratum back to draft
   and discuss the larger issue of eRR/progressive rendering at a later
   stage]

   <scribe> ACTION: jwatt to move the eRR erratum back to draft
   [recorded in
   [21]http://www.w3.org/2009/06/08-svg-minutes.html#action01]

   <trackbot> Created ACTION-2600 - Move the eRR erratum back to draft
   [on Jonathan Watt - due 2009-06-15].

   <jwatt>
   [22]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
   rrata.html#container-element-rewording

     [22] http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#container-element-rewording

   <ChrisL> created ISSUE-2277

   <ChrisL> eRR useful?

   <ChrisL> Is externalResourceRequired useful?

   <jwatt>
   [23]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
   rrata.html#svgload-does-not-bubble

     [23] http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#svgload-does-not-bubble

   JW: the reason svg doesn't implement SVGLoad firing on every element
   is that it would have a negative impact on load time
   ... even if it doesn't bubble, it still has to go through the whole
   height of the tree for each element
   ... since it still has capture phase
   ... a possible solution is to make SVGLoad only have an AT_TARGET
   phase, no capture, no bubble
   ... there are no facilities in DOM 3 Events to say you can do that
   ... but it could be added
   ... currently for this erratum, the current text implies there is no
   capture or bubble phase, but the proposed changed text makes it have
   a capture phase
   ... so maybe this change makes things worse
   ... when it says that on the 'g' it won't be fired, it doesn't say
   it won't be fire in the bubbling phase, it says it won't be fired
   ... so it implies there is no capture phase
   ... with initEvent() there's no param to say there's no capture
   phase
   ... (there's a canBubble arg)
   ... olli pettay agreed that it's a bit hacking, but maybe having a
   canCapture attribute on Event (or setCaptures() method) could be
   used here
   ... so i wonder if we should make the change in this erratum

   [jwatt does some testing]

   JW: we dispatch SVGLoad only to <svg> elements, and any other
   elements that have onload="" attributes
   ... registered event listeners don't affect it
   ... and onload="" attributes only fire for bubbling/at_target phase

   CL: i agree that dispatching capture phase listeners for svgload
   events on every element is bad

   JW: should we leave the text suggest that there isn't a capture
   phase?

   CL: but dom events doesn't allow that
   ... it does seems like the best way would be to fix dom 3 events
   ... but then that would only affect SVG 2 (since 1.1 references dom
   2 events)

   JW: but if we apply this erratum, then we would conflict with our
   future SVG 2
   ... how about we dispatch events to all elements under a certain
   container if a capture event listener is registered on that
   ... so specifically using addEventListener for a capture listener
   ... my concern that the default cause of onload="" on the root <svg>
   not be hammered
   ... i'm less concerned with the use of addEventListener

   CL: would that still require the erratum?

   JW: it's covered under the original
   ... i'm just wondering if my concerns about performance are
   legitimate
   ... all the bubbling listeners, we don't need to dispatch load
   events to their children, since there's no bubble phase

   [we'll return to this issue later]

   <ed> trackbot, close ACTION-2575

   <trackbot> ACTION-2575 Remove the negative index size error
   exception on list interface methods and mention in changes appendix
   in 1.1SE closed

CSS

   CL: the spec which contains calc, values and units, i'm an editor of
   ... i can change that to be in line with implementor experience

   DS: i wanted to know how they felt about using calc and extending it

   CL: they were happy about svg using it, but open to it being
   changed/extended based on what implementors wanted to do
   ... there was no agreement on what level the expressions should be
   (just constant, or more)
   ... on web fonts, i had raised an issue on the variability of the
   font weight stuff
   ... i argued that platform problems shouldn't matter
   ... now the module has an appendix saying to watch out for issues on
   certain platforms
   ... in css2, it says there are 9 different weights and you fill in
   the holes using some algorithm
   ... but it says at the end that that's just an example of matching
   weights
   ... in jdaggett's draft, there was some vague wording using SHOULDs
   ... but there's a better algorithm later in the spec which is fine
   ... so there was no issue there, and it's testable, so i'm happy
   with that
   ... i've satisfied myself that it gives mostly the same results as
   the old alg
   ... john had xhtml test cases for assertions in the spec

   <ed> CSS3 webfonts: [24]http://dev.w3.org/csswg/css3-fonts/

     [24] http://dev.w3.org/csswg/css3-fonts/

   CL: in a month or two they'll be ready to convert to svg tests
   ... there are some issues with font-variant smallcap
   ... that was removed, but now it's back

   CM: do descriptors override data in the font?

   CL: yes
   ... xsl still want an xml representation of @font-face
   ... there was a proposal to add cmyk to css3 gcpm
   ... it didn't distinguish between calibrated cmyk and device cmyk
   ... i have an action to suggest better syntax, which i'll present
   tomorrow for svg print
   ... xsl also want it
   ... there was also a bit of discussion about layout
   ... flexible boxes
   ... summarizes the xul model

   JW: any discussion about non-xul models?

   CL: no
   ... the one complaint mentioned in the f2f was that you need to put
   in many spacer elements to stretch

   CM: elt::after { flex: something }?

   JW: is there any plan to get markup tag names? or would people use
   <span style='flex: ...'>?

   CL: we could add a bunch of elements with default styles

   <ChrisL> [25]http://dev.w3.org/cvsweb/csswg/css3-flexbox/

     [25] http://dev.w3.org/cvsweb/csswg/css3-flexbox/

   [26]http://www.w3.org/2009/06/05-CSS-minutes.html

     [26] http://www.w3.org/2009/06/05-CSS-minutes.html

   <ed> [27]http://twitpic.com/6nuje

     [27] http://twitpic.com/6nuje

MAE

   CL: nobody's editing this

   CM: how much overlap does it have with progress events?

   CL: a lot

   ED: mae is geared more towards real time video streaming

   <ChrisL>
   [28]http://www.w3.org/Graphics/SVG/Group/repository/spec/streaming-e
   vents/publish/StreamingEvents.xhtml

     [28] http://www.w3.org/Graphics/SVG/Group/repository/spec/streaming-events/publish/StreamingEvents.xhtml

   <ChrisL> (meber only, sorry)

   <ChrisL> so to what extent does that overlap with html5?

   <ed> [29]http://dev.w3.org/html5/spec/Overview.html#mediaevents

     [29] http://dev.w3.org/html5/spec/Overview.html#mediaevents

   DS: html5 duplicates the functionality of mae
   ... so before we move forward on mae we should email the htmlwg and
   see what they propose be done
   ... maybe those events defined in html should be split out into a
   spec so that it can apply to svg <video> etc.

   <scribe> ACTION: Doug to ask the htmlwg about mae vs html5 media
   events [recorded in
   [30]http://www.w3.org/2009/06/08-svg-minutes.html#action02]

   <trackbot> Created ACTION-2601 - Ask the htmlwg about mae vs html5
   media events [on Doug Schepers - due 2009-06-15].

Summary of Action Items

   [NEW] ACTION: Doug to ask the htmlwg about mae vs html5 media events
   [recorded in
   [31]http://www.w3.org/2009/06/08-svg-minutes.html#action02]
   [NEW] ACTION: jwatt to move the eRR erratum back to draft [recorded
   in [32]http://www.w3.org/2009/06/08-svg-minutes.html#action01]

   [End of minutes]
     _________________________________________________________


-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 8 June 2009 22:35:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 June 2009 22:35:14 GMT