See also: IRC log
<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
<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition#Doug
<ChrisL> Chair: Cameron
<ChrisL> ScribeNick: jwatt
<shepazu> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#clippath-pointer-events
<shepazu> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
<ChrisL> filters in safari (but out of date) 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
<jwatt> 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
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> http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-201-t.svg - http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-204-t.svg
<jwatt> here's my eRR test:
<jwatt> <svg xmlns="http://www.w3.org/2000/svg"
<jwatt> xmlns:xlink="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 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].
<ChrisL> created ISSUE-2277
<ChrisL> eRR useful?
<ChrisL> Is externalResourceRequired useful?
<jwatt> 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
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: 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> http://dev.w3.org/cvsweb/csswg/css3-flexbox/
http://www.w3.org/2009/06/05-CSS-minutes.html
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> 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> 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 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].
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) Found ScribeNick: jwatt WARNING: No scribe lines found matching ScribeNick pattern: <jwatt> ... Found ScribeNick: heycam Inferring Scribes: jwatt, heycam Scribes: jwatt, heycam ScribeNicks: jwatt, heycam Present: CL ED DS JW CM Found Date: 08 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/08-svg-minutes.html People with action items: doug jwatt[End of scribe.perl diagnostic output]