- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 9 Jun 2009 08:34:28 +1000
- To: public-svg-wg@w3.org
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 UTC