minutes, SVG WG Auckland F2F, day 3



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

                               - DRAFT -

                   SVG Working Group Teleconference

01 Mar 2011

   See also: [2]IRC log

      [2] http://www.w3.org/2011/03/01-svg-irc


          +1.649.363.aaaa, tbah, +1.425.868.aabb




     * [3]Topics
         1. [4]Compositing
         2. [5]Advanced Gradients
         3. [6]WOFF in SVG 2
         4. [7]SVG Fonts
         5. [8]SVG IG Japan report
         6. [9]SVG in EPUB3
         7. [10]compositing a bit more
         8. [11]SVG DOM list object identity
     * [12]Summary of Action Items

   <trackbot> Date: 01 March 2011

   <dholbert> SCRIBENICK: dholbert



     [13] http://dev.w3.org/SVG/modules/compositing/master/Overview.html

   AG: That has the latest version
   ... Doug originally merged the language and the primer
   ... It was originally in 2 parts, each property had 2 sections. I've
   merged it all together & added a few examples to it
   ... I also had a few coments from people on the mailing list;
   addressed those
   ... I also put simplified versions for the blend mode equations.
   Equivalent to more complicated earlier forms

   <pdengler_home> i'm in

   AG: I believe this is ready for last call for publication & we
   should take it to CR
   ... Doesn't have a test suite, but the examples can be used as (to
   make) tests

   CM: So we've got enable-background - is that same definition as in

   AG: No - it's different from filter enable background, if that's
   what you're asking

   CM: Ah, so it only applies to filters in 1.1?

   AD: This new rewording is meant to clarify that a bit

   CM: Have there been many changes since we last looked at it?

   AG: Not really - some of the equations have been tweaked
   ... (asks AD about accumulate w/ enable-background)

   AD: The big problem w/ integrating porter-duff w/ svg
   enable-background accumulate is you have to do a removal step
   ... Only matters in porter duff modes other than "over"
   ... Once we worked out that you needed that technique, it required a
   lot of math to work out how that works for all of the modes

   CM: Is that in the spec?

   AD: Yes

   AG: What about accumulate?

   AD: You only need to worry about accumulate if you're applying
   porter-duff to that group

   <pdengler_home> Is someone scribing

   CM: I'm happy for this to go to last-call

   ED: One little thing - it's normatively referencing 1.2

   CL: 1.2 tiny?

   ED: No, 1.2 full

   AG: I can make that 1.1 instead

   CL: Yeah, do that

   DS: So this in itself is sufficient for anybody to do compositing?

   AD: From an author's point of view, they only really care about the
   blend modes, since they're in photoshop & illustrater. The porter
   duff modes being in there help it work with Java 2D

   CM: Do you have some examples of cool stuff you can do with porter

   AD: Original paper has some - e.g. plus lets you smoothly blend
   between two videos

   CL: It'd be handy to have those sorts of examples in the spec

   AG: Can I reference Second Edition?

   CL: Yes, you can't not do that
   ... In the references section, it mentions PDF, but that's not
   actually used/cited anywhere

   CM: Actually none of those references are used/cited anywhere

   AG: Yeah, I should go through that

   CM: Do you know if the spec builds properly?

   AG: Yes, I think we got that working
   ... So with the references ...

   CM: If you're going to have a normative reference, it'd be SVG 1.1
   ... If you wanted to include an explicit actual reference/citation
   in the spec, just do it the first time you mention SVG

   RESOLUTION: Move compositing spec to last-call, after references
   have been fixed

   DS: There's a couple of things you'll need to fix in the images -
   some are missing xlink:href namespace decl

   <ChrisL> ACTION: ChrisL to request puiblication of compositing spec
   [recorded in

   <trackbot> Created ACTION-2982 - Request puiblication of compositing
   spec [on Chris Lilley - due 2011-03-08].

   DS: Also, some of the images are using a raster as the background,
   and when it blows up, it looks really bad.
   ... I'll make a SVG version of that background that you can use

   <scribe> ACTION: Doug to fix the images in the compositing spec
   [recorded in

   <trackbot> Created ACTION-2983 - Fix the images in the compositing
   spec [on Doug Schepers - due 2011-03-08].

   DS: As a general rule, where we have images in the spec, I'd like to
   have SVG with a fallback to the PNG, rather than having a PNG that
   links to SVG

   CL: That's good if it's using SVG 1.1, but if it's using something

   DS: for newer features, we can make a mockup using SVG 1.1

   CM: Might have to use a PNG for mocking up some things

   DS: Sure, we can do that if we need to

   RO: Main issue I have w/ enable-background is (with filters) -- if
   you have an input image bigger than the viewport, and you're
   filtering it, you might need to sample regions of the image outside
   of the viewport. What that means is, when you've got
   enable-background operating, you can't apply normal viewport

   CL: Can't you calculate how far out you'd need?

   RO: You can, but some filter primitives require that you'd draw the
   whole background
   ... Normally the natural thing to do is to clip to the viewport at
   the beginning
   ... it's possible to have things that are infinite in extent, like a
   tiled CSS background
   ... so no one has implemented it correctly yet, so it's not clear
   that it's implementable

   <shepazu> (anthony, the following files need an xlink namespace
   declaration, in
   [16]http://dev.w3.org/SVG/modules/compositing/master/examples/ :
   compop-porterduff-examples.svg, compop-blend-examples.svg,
   clip-to-self-examples.svg )

     [16] http://dev.w3.org/SVG/modules/compositing/master/examples/

   AG: w/ references - did we write a requirements doc for compositing?

   CL: Normally you don't need to reference that from within the spec

   AG: I'll work on those references today and have it ready by next

   DS: Can you fix those xlink:href's too? and I'll work on the
   background thing

   RO: Ah, so the issue that I talked about w/ clipping doesn't come up
   with this spec. But do we need enable-background?

   AS: So the standard blending modes are just using alpha compositing
   - don't need to worry about enable-background for those


   AD: ... but with the more complex ones, it's important

   RO: So with the new rectangle thing, do we need that, or can we
   infer that?
   ... We can probably optimize that automatically

   AG: It's an implementation hit, and I'd put it in because someone
   requested it

   CL: Let's keep it in the spec, but later add a comment saying that
   it's not mandatory and can be dropped
   ... for last-call

   RO: It adds extra work for us to do that clipping, when it's not
   always necessary/useful
   ... In the clip-to-self property, it talks about whether you use
   bounded vs unbounded operators
   ... it talks about the shape of the object. But is that well-defined
   for all shapes? e.g. circle with stroke of dashes - what do we clip
   ... so if it's dashed with opacity 0, do we consider that part of
   the shape of the object?

   CM: If it's fill:none, it wouldn't be included, but if it's opacity
   0, it would

   AD: This is partly for compatibility with Java 2D

   RO: We had similar issues with canvas
   ... I think this needs to be clarified - all these edge cases,
   whether pixels are affected or not

   AD: yeah, which pixels have been 'touched'

   RO: We need to define what 'touched' pixels means

   CM: spec says -- "for filled and stroked shapes and text, the object
   is directly converted to a clipping path"
   ... Perhaps that means 'if you stuck it in a <clipPath>'?

   CL: No, it's clipped as if it _was_ a clipping path

   <scribe> ACTION: Anthony to clarify clip-to-self behavior [recorded
   in [17]http://www.w3.org/2011/03/01-svg-minutes.html#action03]

   <trackbot> Created ACTION-2984 - Clarify clip-to-self behavior [on
   Anthony Grasso - due 2011-03-08].

   RO: I think it'd be useful if it matched clipPath behavior

   AD: but clip-to-self works with antialiased edges

   RO: We can say the shape is the same, but the edges are up to the

   CL: We shouldn't use wording that suggests that anything magical
   happens with an anonymous <clipPath> under the hood

   CM: Maybe we should express it in terms of a mask instead?

   AG: so it's just 'whatever pixels are painted'?

   RO: That's still not entirely clear
   ... It has to be precise, but we shouldn't so much suggest how to
   implement it

   AG: So are we still happy to publish, then?

   CM: So we've got note about enable-background new, the references,
   clip-to-self -- is that all that's required?

   RO: So we don't leave last-call until there are 2 implementations &

   DS: No, candidate-recommendation is where that happens
   ... (and you might go back to last-call after being in CR)

Advanced Gradients


     [18] http://www.w3.org/Graphics/SVG/WG/wiki/images/f/fc/SVG_Advanced_Gradients_Requirements.pdf

   AG: So this was discussed last year - making some sort of feature
   better than the current gradients that we have, because they're
   fairly basic
   ... I drafted some use-cases & requirements for some advanced
   gradient feature
   ... I think SVG 2 would look a bit poor with just the basic
   gradients that we have

   CM: Given how often people have been asking for advanced gradients

   AG: I've left the draft pretty open-ended in terms of focusing on
   specific tech
   ... Some of the input that went into this came directly from authors
   & usability specialists - the people who actually do the drawing
   ... I haven't committed it yet since I don't really know where to
   stick it
   ... (The wiki wouldn't let me upload an HTML document, so that's why
   it's a PDF right now.)
   ... (puts spec on projector)
   ... The first part is just boilerplate. The bits that are different
   from the template are the introduction...
   ... So 'usage scenarios' is the first bit that I added.

   CM: So are these what your designers said they wanted?

   AG: Yeah - they wanted to be able to produce naturalistic images in
   a pretty simple way, with a compact representation
   ... they're used to it in photoshop, where it works but is difficult
   to lay down all the mesh points
   ... They want something between that and what they can do in

   DS: Would be nice to somehow combine gradients

   AD: Tav had some demo page. I had to implement some of that and it
   was quite hard

   <tbah> [19]http://tavmjong.free.fr/SVG/MESH/Mesh.html

     [19] http://tavmjong.free.fr/SVG/MESH/Mesh.html

   AD: I did a lot of investigation. What you'd have to do is provide a
   triangular mesh and at each mesh point provide a normal

   DS: suboptimal from an author's point of view

   CL: I'm wondering if you could lay out your mesh, and at each point
   use luminance to get a height, and then calculate normals based on

   AD: The phong formulas assume light reflection, and that requires an
   angle of incidence w/ triangle, which you need the normals up-front
   for.. I guess the conclusion is it's non-trivial

   DS: So it's non-trivial to author?

   AD: It's trivial with authoring tools like Maya, etc

   AG: But what about hand-authoring to tweak something?

   CM: What about animating it?

   AD: If you define the syntax right, it wouldn't be too hard
   ... Making the object move might be tricky - but making it look like
   the light is moving would be trivial (by animating the normals)

   CM: Can you do that with filters, too?

   AD: Yeah

   AG: So -- I put a few examples in there of the usage scenarios
   ... (opens an artistic effect demo) At the moment, to do this in SVG
   is nontrivial / impossible

   CM: Do you have a summary of tools & which kinds of gradients they
   can do?

   AG: No, not yet

   CM: If mesh gradients are tricky, they might still be worth it if
   people are familiar with them

   AG: (scrolls to 'special considerations for advanced gradients')
   ... So there's a section for memory & processor requirements

   DS: We should ask other authoring tool companies what they think
   about this

   ED: Scribus has mesh gradients, and they export SVG, but I don't
   know what syntax they use

   TB: Now that Cairo has support for mesh gradients, there's a lot of
   interest in them

   AG: I noticed you have a lot of good information on that link you
   dropped in - would it be possible to put that into advanced
   gradients use cases/requirements?

   TB: Sure, you can take anything you want

   AG: Yeah, it'd be nice to just take that research and put it into a
   W3C document

   DS: In a Google-search for cairo gradient mesh, the fifth link is
   Tav's document

   TB: mm hm

   CM: Anyone know if other graphics libraries like CoreGraphics have
   advanced gradient support?

   DS: So it sounds like gradient meshes are certainly of interest -
   regardless of what else we do, we should probably have gradient

   AG: One of the things designers want is to control how far color
   spreads out from a point

   DS: More like an ellipse or like a circle?

   CM: so normal gradient meshes do color interpolation between the
   three points

   TB: tensor meshes have extra control points - that is implemented by

   DS: We should talk to the cairo guys

   RO: We can look at the code & documentation

   AG: I added animatability as one of the requirements
   ... Also, 'syntax can be easily authored by hand', or at least
   easily understood by authors
   ... also, I added a requirement that we maintain compatibility with
   CSS where possible

   DS: They'll likely follow whatever this spec does

   <ChrisL> A new CAD mesh segmentation method, based on curvature
   tensor analysis

   DS: There was an action on Tav to talk to Tab Atkins

   <ChrisL> Computer-Aided Design

   <ChrisL> Volume 37, Issue 10, 1 September 2005, Pages 975-987

   TB: Haven't done that yet

   <ChrisL> Guillaume Lavou�Corresponding Author Contact Information,
   E-mail The Corresponding Author, Florent DupontE-mail The
   Corresponding Author and Atilla BaskurtE-mail The Corresponding

   CM: Easily authoring by hand will be tricky - even authoring paths
   by hand is difficult

   AG: I meant more that it's easy to follow. With paths, you can look
   at it and see "cubic bezier, etc".

   CM: Ah, yeah - so just 'not a binary blob' I guess

   DS: So RE animation -- the gradient itself must be animatable, I

   BB: So what about diffusion curves?

   AG: Authors like that concept, but they have some problems - e.g.
   how they interact with each other. They'd like more control over how
   the color diffuses and what the color stops are
   ... and they'd like to make it so only one side will diffuse

   <tbah> I just got cutoff and the access code is "restricted" at this

   AG: so it has things they like, but they have issues with it

   <roc> shepazu: cairo's "mesh patterns":

     [20] http://cgit.freedesktop.org/cairo/tree/src/cairo-pattern.c#n801


   <tbah> OK, I'll probably just head off to lala land. Thanks.

   AG: so I'll make the suggested changes, and then we can publish at
   some point

   <scribe> ACTION: Anthony to fix advanced gradients spec [recorded in

   <trackbot> Created ACTION-2985 - Fix advanced gradients spec [on
   Anthony Grasso - due 2011-03-08].

   <heycam> Scribe: Cameron

   <heycam> ScribeNick: heycam


   CL: [summarises history of downloadable fonts]
   ... [summarises why SVG fonts were devised, and what WOFF does]
   ... so coming into SVG 2 we have WOFF which is everywhere now
   ... we can do nicer things in svg now that we have this font format
   ... it's way better internationalized than svg fonts
   ... i looked at using graphite with svg fonts, but there'd be a lot
   of work for that
   ... and it's not the direction the industry is going
   ... so my proposal is to mandate woff in svg 2
   ... i'd like to see it in batik
   ... it's already in firefox since 3.6, and opera since 11.1 or so
   ... in ie9 since preview 2
   ... the only format that mobile safari used to support was svg fonts
   ... which is why fontsquirrel etc. output svg fonts
   ... i believe the new mobile safari supports woff

   ED: are there any other formats that should be mandated? any reason
   to just require woff?

   CL: if you've got a ttf/otf font you can convert it to woff easily
   ... some browsers support linking to native ttf/otf, some don't
   ... most of hte font vendors hate the idea of link to tt/otf
   ... even though they know it's trivial to convert between them and
   ... it's the difference between picking up a wallet on the street,
   and taking it out of a car
   ... we've been careful in the fonts wg to not require any browser
   ... so the font guys are happy to license fonts for desktop (otf) or
   the same font in woff for online
   ... it's a big deal. there's a whole new font industry now.
   ... and the free font industry too, the open font library
   ... if we require it that you're linking to raw otf then it's going
   to ruffle a lot of feathers

   RO: ie9 does allow linking to raw ttf fonts, if they've got the
   correct permissions bits set

   CL: right, and also enforces a same origin restriction

   DS: but nobody objects to requiring woff?


   JF: what is the current status with html5 and woff?

   CL: html5 doesn't mention woff, because it doesn't talk about
   formatting as such
   ... it's css that talks about formatting
   ... currently it's completely separate. the css3-fonts spec which
   says how to link to fonts.
   ... the woff spec references css3-fonts, but there's no requirement
   in css3 to support woff

   JF: you are suggesting svg2 to reference directly to woff, not just

   CL: right, because css3-fonts doesn't require any particular font
   ... if that requirement moved to css3-fonts, we wouldn't need to
   have it in our spec
   ... for the moment i think it makes sense to put it in there
   ... we can take it out later if css3-fonts starts to require woff
   ... we should also link to css3-fonts instead of css3 in svg2
   ... which also gets us the cool new features

   JF: if we mandate the use of woff in svg, does that mean html5
   implementations also need to support woff?

   DS: svg support is not required by html5
   ... but an html5 & svg user agent would be required to

   CL: the implementaitons of html5 already have woff support, mostly

   JF: i'm just wondering if we should align with html5

   CL: we can suggest that html5 requires that, but i suspect it won't,
   because it's css's job to do the rendering
   ... but i notice that epub3 requires woff

   RESOLUTION: We will mandate WOFF support in SVG 2.

   AD: should we consider being able to encode it inline just like in
   svg fonts?
   ... so we can have self contained files with font data?
   ... that's a major benefit of svg fonts

   CL: something other than using a data uri?

   AD: something like data uri

   CL: yes that would already work

   RO: how abotu the size of a woff font compared to an svg font?

   CL: svg fonts have not much overhead, once gzipped is reasonable

   RO: MB-sized data uris work fine in gecko

   AD: it's be nice to have a better encoding for data uris

   CL: that's a general thing for binary stuff, xml isn't very good at
   including binary stuff

   AD: base64 was designed in an old era that doesn't really apply
   ... for an era when you only had 6 guaranteed bits

   DS: just write an rfc for it

   CL: you could an extra encoding, other than ",base64" to data uris

   AD: base64 decoding is slow
   ... if the encoding was simpler...
   ... so something similar to base64 but using more bits
   ... base64 requires a lot of bit shifting

   CL: feel free to have at it. it's not for this wg to do, though.

SVG Fonts

   ED: i wrote up a short page


     [22] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVG_Fonts

   scribe: this will require SVG 1.2 Tiny Fonts for SVG 2, but to leave
   out the complex fonts for a separate module

   AD: i think that's a sensible thing, since so many devices already
   implement 1.2T SVG Fonts

   ED: SVG Tiny 1.1 defined it too
   ... but better defined in 1.2T

   CL: the tiny fonts are simpler, you don't have any content as a
   ... so all the cool stuff you can't do in opentype, you can't do in
   Tiny SVG Fonts
   ... but you can build it on the fly with script
   ... some things tiny svg fonts can do that opentype can't do
   ... various path shapes aren't allowed in opentype, like
   self-intersecting curves, and many requirements on curve control
   point positions

   BB: is that an extra feature?

   DS: it's ease of use

   CL: it's extra stuff that you have to do with an opentype font
   ... you can mix cubic/quadratic curves in the same glyph, whatever
   you want
   ... producing something on the fly, or draw a handwriting font, is
   more tractable using svg fonts

   ED: altGlyph isn't part of Tiny fonts

   DS: i think we should be looking at a variety of possible options
   for SVG2
   ... one of them is allowing a <glyph> to be inline, so it doesn't
   have to be associated with a font parent
   ... could just be a glyph inline

   (some discussion about y-up coordinate systems)

   BB: i want to know what we get by requiring 1.2T fonts in SVG2
   ... so we get access to the path data, and it's easier to author

   DS: and also it's embedded in one file

   BB: which you can already do with data uris

   AD: there are 100s of millions of devices with Tiny fonts out there
   ... and there's lots of content on mobile that supports it. all the
   ipad stuff is using Tiny fonts.

   <ChrisL> data uri kitchen

     [23] http://software.hixie.ch/utilities/cgi/data/data

   BB: by the time svg2 out those devices will have woff support

   AD: it's a backward compatibility thing
   ... you can write some script to modify the font on the fly

   CL: another concrete benefit is that it's already widely implemented
   on some desktop platforms, and almost all mobile platforms

   BB: so backwards compat

   DS: authoring tools too

   AD: corel draw e.g., you can click export and it will subset system
   fonts and turn them into svg fonts

   CL: since corel draw 8

   CM: inkscape can generate svg fonts too

   DS: it's fairly lightweight, not particularly difficult to implement
   ... there are lots of tools that already do it, it solves some use
   cases that woff doesn't, why not do it?

   JF: i'd like to talk about use cases in the japanese market
   ... in the epub wg we talked a lot about the use of svg fonts and
   woff fonts
   ... we found important use cases for svg fonts
   ... the first is to use svg fonts to support emoji characters

   <ChrisL> s/emojoy/emoji/

   JF: which are part of unicdode 6.0
   ... they can be animated
   ... opentype cannot support emoji characters, but svg fonts can
   ... emoji is very important for japanese, since there are many
   mobiles targetted towards keitai users

   RO: but that's full fonts, not tiny fonts?

   JF: yes
   ... the other use case includes in japan we need to support
   variation characters
   ... the current implementation of browsers and ereading systems does
   not support IVS yet
   ... but that's easy with svg fonts. you can easily define variation
   characters using the svg font mechiansm.
   ... you can just use the variation selector, so that text content is
   a proper unicode sequence
   ... you can use svg font defined variation characters

   BB: for emoji, is that a bounded set?

   JF: yes

   BB: do you ever have e.g. novels where they want to use a new
   character that's not in the set?

   JF: also there can be one or two special characters in a novel that
   are not covered in unicode

   BB: with the unicode variant, is this a backwards compat issue?
   ... i believe in firefox we allow variants to be selected from fonts

   RO: why wouldn't the variant selectors work with opentype?

   JF: because some leading systems, their OSes don't support variation
   ... and it's sometimes difficult to implement on those systems

   BB: so it's a compatibility issue there. it is possible to do that
   with css3 and opentype, but some of the devices don't support that?

   JF: yeah
   ... it's a kind of lightweight workaround

   BB: with the emoji, if there are new ones publishers want to use, it
   sounds like we need another feature

   JF: we think that is not that important, and it can just be a user
   defined feature

   CM: (shows some examples on the board)

   JF: i have one suggestion for svg fonts
   ... fonts in tiny do not support vertical alignment
   ... we'd like to see that supported by svg fonts in svg2

   CL: i'm hearing a proposal that it should be tiny fonts as
   implemented, but possible with alyGlyph and adding the vertical
   ... i think we may have removed vertical font support because
   vertical text wasn't supported in tiny

   AD: the people doing the tiny font subset weren't interested in
   vertical text

   ED: opera has the horiz-adv-y for svg fonts as well
   ... it's a small addition

   DS: the proposal is svg2 includes that starts with 1.2T SVG Fonts
   with a couple of additions

   ED: and dividing it in to an optional module for svg full fonts

   DS: pushback?

   BB: i just want to be clear what the benefits are
   ... we should be arguing why we need it, not why not

   DS: there are arguments from both sides

   RO: i have a question
   ... one that i'd like to understand is...
   ... let's assume there are good use cases supported by tiny fonts
   ... we know that we basic or nonexistent shaping in tiny fonts
   ... i assume these use cases are also valid use cases in the context
   of indic characters, which require complex shaping
   ... what's the plan to support those use cases in those languages?
   ... i think we need a plan, a story to tell -- how we'll support
   those use cases on the web
   ... we don't want to say we just won't support those scripts
   ... does it mean extend fonts to handle those scripts, or handling
   these use cases with a differently technology?

   DS: talking to some font guys, i asked them are you guys interested
   in moving beyond what 1.1 full fonts have? to solve the real
   problems you have with fonts?

   <ed> i would say tiny12 has basic shaping support, with arabic-form,
   so it's not nonexistent

   DS: started taking about svg thing, but moved on to not necessarily
   needing to be
   ... that discussion i think should happen outside the svg wg

   AD: you're spot on with the shaping stuff
   ... it's effectively programmatic
   ... the support for arabic in svg full fonts is pretty basic
   compared to what font engines can do
   ... you virtually need a programming lgnauge in the font to do the

   RO: opentype does support shaping for indic
   ... it's a lot of custom logic in the font engine

   CL: it's in the font engine, so you've got all these tables, and if
   it knows how to do it then it does shpaing, otherwise it doesn't

   RO: in practice everyone need to implement this for opentype shaping
   ... and there are open source ones like harfbuzz
   ... where i'm going is, are you guys saying that there'll be some
   new font tech that will solve it?

   AD: no
   ... i think there are specialists in fonts/shaping who would be
   better to ask about future font techs

   RO: if we extend svg fonts with advanced shaping to handle indic
   etc. we could say that's what we think will happen.
   ... or, we could say it's less work to say opentype where shaping is
   already solved, and extend an opentype based solution to address the
   use cases that would otherwise be solved by svg fonts

   AD: company logos e.g. is a different kind of use case
   ... it needs to be accessible

   RO: i'd like to have an answer to that question

   AD: for the longer future?
   ... when we're talking about tiny


   CL: [talks about investigating graphite-like support for svg fonts]

   trackbot, close ACTION-2939

   <trackbot> ACTION-2939 Look into batik failing filters-overview-01

   RESOLUTION: SVG 2 will mandate support for SVG Tiny fonts support,
   and SVG Full fonts will be specified in a separate module.

SVG IG Japan report

   JF: first i'll talk a bit about SVG IG Japan
   ... SVG IG Japan, we started the activity two years ago
   ... core members consist of 8-10 people
   ... mainly interested in SVG for mapping
   ... we've had 7 f2f meetings int he past two years
   ... total number of people who have attended these meetings is over
   ... we invite guest speakers from, for example, google japan
   ... or from mozilla tokyo
   ... also w3c people like doug, who attended the first f2f meeting
   ... the main topic of discussion in SVG IG Japan has been SVG JIS
   ... and SVG extensions for mapping
   ... these are the two main topics we discuss
   ... there is an effort to make an SVG JIS standard in japan
   ... there have been three committees for standardising SVG
   ... the first committee translated the draft specification of SVG
   1.2 Tiny, about three yesars ago
   ... then the second committee created a new SVG extension for
   mapping, that was in 2009/2010
   ... we (mozilla) are now working in the third committee, whose goal
   is to use the translation of SVG 1.2 Tiny to prepare for official
   publishing of SVG 1.2 Tiny JIS and extensions for mapping
   ... we have applied to have two official JIS standards: one for
   1.2T, one for the mapping extensions
   ... we are currently working on the final stage of review, and we
   will finish this third phase of the committee by next March
   ... so you can expect to get these two JIS standards published some
   time before 2013

   CL: once something has become a JIS standard, a few years later it's
   elegible to become an ISO standard, is taht right?

   JF: three years ago we did the translation of 1.2T, and that's just
   a TS -- technical specification
   ... that's not an official JIS standard
   ... our goal now is to publish the official JIS standard, some time
   in 2012 or 2013
   ... that work will be finished by march

   CL: the mapping extensions was started in 2009, is that dervied from
   the KDDI extensions?

   JF: yes, exactly
   ... in the last two years we tried to align JIS SVG extensions and
   W3C/SVG specificaiton
   ... that was the reason why we proposed to create the new module SVG
   Tiling & Layers

   CL: this is in japanese. will there be an english translation of the
   mapping part?

   JF: yes

   AD: there's an english description on the web
   ... and I've got a demo of a Tiling implementation

   DS: along those lines, one of the problems was how to get the IP
   that KDDI might have around this, and I believe this is going to be
   solved in April?

   JF: yes
   ... they decided to join W3C
   ... also they are very interested in joining the SVG WG
   ... to work on the SVG TIling & Layering specification
   ... that's their intention

   CL: that's good news they're rejoining
   ... we want to understand the original principles, so that we don't
   accidentally change things they need

   DS: you think 2012-13 is when you'll complete that part of the JIS
   standard as well?

   JS: yes
   ... but ths SVG JIS committee to work on that standard will be
   finished in March

   DS: maybe version 2 could have some changes?

   JF: yes
   ... at first, we may start with two different specifications

   DS: I've also been tlaking to other people, people from medical
   imaging, and other things where you are bringing in subsets of
   larger documents

   <roc> ed: [24]http://people.mozilla.com/~roc/LightPosition.xml the
   question is whether the light position should be the center of the
   circle or not

     [24] http://people.mozilla.com/~roc/LightPosition.xml

   DS: and I talked to them about tiling and layering, and it's exactly
   what they're interested in, from a different perspective than
   ... KDDI is also interested in HTML5 and TV on Web, from some other
   ... I'd like to put before this group about having a mapping
   taskforce of the SVG WG that looks specifically at the topics of
   mapping, and what we could add to SVG2 without too much trouble to
   make it better for mapping
   ... I have a draft charter for that

   <roc> ed: the spec says 'x' is the "X location for the light source
   in the coordinate system established by attribute ‘primitiveUnits’
   on the ‘filter’ element.", which here is "objectBoundingBox", and
   [25]http://www.w3.org/TR/SVG/coords.html#ObjectBoundingBox describes
   the object bounding box coordinate system in a way that implies
   0.5,0.5 would be the center of the circle

     [25] http://www.w3.org/TR/SVG/coords.html#ObjectBoundingBox


     [26] http://www.w3.org/Graphics/SVG/map/map-charter.html

   <shepazu> 12[27]http://www.w3.org/Graphics/SVG/map/map-charter.html

     [27] http://www.w3.org/Graphics/SVG/map/map-charter.html

   <shepazu> 12[28]http://www.w3.org/Graphics/SVG/map/map-charter.html

     [28] http://www.w3.org/Graphics/SVG/map/map-charter.html

   <shepazu> 12[29]http://www.w3.org/Graphics/SVG/map/map-charter.html

     [29] http://www.w3.org/Graphics/SVG/map/map-charter.html

   <shepazu> 12test

   DS: it's not formal
   ... I'm open to suggestions
   ... one of the high level things we want for SVG mapping
   suggestions, if something can be generally useful for other content,
   make sure it's applicable to other contnet

   AD: for example the tiling module, we did stuff for 1.2F, multi
   image resolution
   ... some of the KDDI datasets are like 5GB of map data
   ... but you can navigate it effectively with those kinds of

   DS: what is the implementation burden?

   AD: it's not a lot
   ... the root container has a mapping from whatever coordinates
   space, WGS84
   ... when you load the child SVG content, it can be whatever it is,
   as long as it declares its mapping to WGS84
   ... the globalCoordinateSystem element is a sibling of the graphics,
   rather than a parent of the graphics, for some reason
   ... that's a bit of a mistake in the design
   ... it means that anyone that implements a standard graphics state
   stack to affect all the siblings

   <roc> ed: [30]http://people.mozilla.com/~roc/LightPosition2.xml the
   x and y coordinates for the filter primitive subregion *are*
   interpreted in object bounding box space in all browsers, so 0.5 0.5
   is the center of the circle

     [30] http://people.mozilla.com/~roc/LightPosition2.xml

   CL: the way W3C did was to have a child <metadata> element with the
   mapping information in it

   <roc> ed: the spec says "These attributes are defined according to
   the same rules as other filter primitives' coordinate and length
   attributes and thus represent values in the coordinate system
   established by attribute ‘primitiveUnits’ on the ‘filter’ element."

   AD: the early prototypes used the rdf stuff
   ... then they decided they wanted a first class citizen element

   CL: is this how it's specified in the JIS standard?

   AD: yes

   CL: has it shipped in implementations?

   AD: probably not

   CL: can we change it?

   <roc> so I think it's pretty clear that those x and y attributes
   should be treated the same as the x and y in the light elements

   CL: what timeline is there?

   JF: I'm not sure, the JIS standard is in the very last stage

   <roc> ed: but Opera and Batik treat them differently I guess

   DS: it's going to mean content is not compatible, but it's not a big
   ... and there will probably be other changes as well

   CL: ISO has an errata process, corrigenda
   ... I assume that JIS also has such a process?

   JF: yes

   CL: we could put in feedback that way
   ... if something's going to move from being a sibling to being a
   parent, it's an easy change to make before oyu have much content
   ... but after, it's annoying

   AD: this only applies to geographic transforms, nothing to do with
   tiling & layering

   JF: I suggest to make a suggestion to Tagaki-san

   AD: I've spoken to him about these changes, and the feedback he's
   given me is that they welcome what W3C suggests
   ... they also use ref() transforms from 1.2T, and they modifieid it
   to interact with the geographic transforms
   ... and that's not defined

   CL: we can fix these things up

   AD: I don't think they'd have a problem with converting the map data
   they already have

   DS: to what degree is this client side, and what server?

   AD: the server is responsible for producing all of the tiles

   CL: the benefit is that you can connect to multiple servers

   AD: one of the examples I've got is where they generate tiles from
   open street map
   ... from two different places

   RO: should web browsers be able to display raw map data?
   ... all the mapping applications I currently see have interfaces
   that let you search, and apply overalys
   ... they're all using script
   ... is it something we really need to display map data, without
   using script?

   CL: one provider can provide a script library to do that, btu it
   makes it difficult to use other providers' data
   ... the declarative information lets you easily merge it from other

   AD: the primary benefit of the tiling module is that as you pan out,
   the resources are already released
   ... if I've got a dataset 100GB in size, map tiles of the world, I
   can just pan around and the browser just decides when to throw out
   cached tiles

   RO: there are a lot of use cases like that, e.g. massive tables of
   data, an Excel spreadsheet
   ... those sorts of use cases need to be solved, but SVG shouldn't
   solve that general problem
   ... there are a bunch of features that mapping featuers have, even
   aside from the tiling and LoD stuff

   JF: the charter mentions CSS WG

   DS: that's a copy/paste error

   JF: that makes more sense
   ... I'd like to discuss one thing
   ... SVG Map specification, the original one from Takagi-san, was a
   kind of profile of SVG
   ... that includes various extensions used for mapping
   ... after reviewing the specification in SVG IG, and in this group,
   we decided to modify the specification to split into two parts
   ... the first part is the Tiling & Layering
   ... and we think that it's the most important part of the
   ... and we should create a new module to provide such feature
   ... other features, such as Level of Detail, and the support of
   z-index, are removed from the original specification
   ... because we think these features are useful for other use cases
   ... so given that we wil start the SVG Mapping taskforce, I want to
   make sure is this still the right direction for us, to focus on the
   Tiling & Layering as a single module?

   DS: since we'll be forming a taskforce specifically for this, I
   think that the SVG IG Japan, I think it's still useful for you to
   meet and discuss these things because of languagei ssues
   ... and you can give feedback to the TF and the WG in general
   ... but I think it should be focussed on by the mapping TF

   JF: do you still think it's a good idea to continue developing the
   Tiling & Layering specification?

   CL: as a separate specification, from the mapping stuff?

   JF: or shoudl we create an SVG Mapping profile again?

   CL: no I think splitting it out is good
   ... mapping gets split out, is smaller, and depends on Tiling &
   ... that would mean it is more likely to be implemented
   ... it should continue to take requirements from mapping, but also
   requirements from other areas like medical imaging
   ... the way you split it makes sense

   JF: the current feature set covered by the Tiling & Layering
   proposal is a good start for discussion?

   DS: absolutely
   ... the other features you talked about you want generalised, we can
   talk about those in the SVG WG in general


   JF: I've been involved in the EPUB standardisation, in the last 24
   ... especially I'm involved in the subgroup called EGLS [enhanced
   global language support] which specialised in new features of EPUB3
   to better support global language, including eastern language
   ... currently IPDF is working on the new version of EPUB, 3.0
   ... that's a major revision of EPUB
   ... it's expected to be released in May
   ... major new features include support for multimedia functions --
   video and audio -- as well as scripting and interactivity
   ... also supports global language capabilities
   ... also improved accessibility, enhanced styling and layout
   ... there is a public review draft and it was released on Feb 15
   ... they are currently under review

   <jun> [31]http://idpf.org/epub/30/spec/epub30-overview.html

     [31] http://idpf.org/epub/30/spec/epub30-overview.html

   JF: here you can get the overview document
   ... EPUB3 actually consists of various parts
   ... that's the overview page
   ... there's also EPUB Publications, EPUB Content, EPUB Media
   ... also a list of changes from EPUB2

   <shepazu> s/paste error/paste error, which I've now fixed/

   JF: they're linked to from the overview document
   ... I will quickly summarise the important points
   ... one is that EPUB3 is based on HTML5
   ... EPUB2 used to be based on XHTML 1.0
   ... they use the XML serialisation of HTML5
   ... with namespaced SVG content
   ... for EPUB3, HTML as well as SVG can be the root document
   ... so you don't need to use SVG from inside HTML

   CL: can you put HTML5 inside a <foreignObject> in SVG?

   JF: yes
   ... both are possible

   ED: is foreignObject required?

   AD: it's required, and I think it's a subset of HTML elements that
   must be supported in foreignObject
   ... I think there's a restriction on the size of the foreignObject

   JF: EPUB used to be considered a text oriented format
   ... but now we can use EPUB3 for more layout oriented document,
   using SVG, or we can create comics -- graphically oriented documents
   ... that's good news for us
   ... for styling EPUB3, it supports CSS 2.1
   ... also supports several CSS3 modules
   ... the baseline is CSS2.1, but also supports CSS Speech module and
   css3-fonts, to use embedded fonts, including WOFF fonts
   ... it also supports css3-text
   ... and css3-writing-modes
   ... these two modules are very important to support vertical writing
   in Japanese lanugage
   ... we're working closely with fantasai and other CSS WG members to
   make sure these specifications are ready for use
   ... probably you know there is a new WD published on
   css3-writing-modes and css3-text
   ... which is referenced by the current draft
   ... EPUB3 also supports CSS MQ, css multicolumn layout, also some
   extensions specific to EPUB to support ruby
   ... it defines some EPUB-specific display properties
   ... EPUB WG decided to define the ruby module as a temporary
   solution, because W3C does not have a good specification for ruby

   CL: html5 has some basic support for ruby, but doesn't have very
   good support
   ... did it not meet your needs, and you had to create a new one?

   JF: yes

   CL: it would be good to transmit that information to the HTML WG,
   ideally before LC

   AD: EPUB doens't use css3 paged media module
   ... they say different screen sizes will make intelligent decisions
   ... their recommendation is to use SVG documents for exact page

   CL: in the Content Documents, it says "restrictions on SVG 1.1"
   ... the last one is puzzling
   ... "it should include the width/height attributes on the svg


     [32] http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-restrictions


     [33] http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-restrictions

   scribe: if it's inline, you would use width/height
   ... but if hte SVG is the root, and you're displaying on different
   devices/screen sizes, and you want it to be displayed full size, why
   would you want to force width/height to be specified?

   JF: I have no idea. I think it's a good idea to give feedback to the

   AD: judging by their overview document, for targetting different
   display sizes, use HTML -- but for fixed sizes, you would choose SVG

   <scribe> ACTION: Chris to mail the EPUB WG to ask whether
   width/height on root <svg> elements should be allowed [recorded in

   <trackbot> Created ACTION-2986 - Mail the EPUB WG to ask whether
   width/height on root <svg> elements should be allowed [on Chris
   Lilley - due 2011-03-09].

   JF: there are several issues in the EPUB WG regarding SVG


     [35] http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0129.html

   JF: I sent some of them to the SVG WG mailing list
   ... the first one is the question about which version of SVG to use
   in EPUB3
   ... they currently refer to SVG 1.1 Second Edition
   ... I'll have to make sure that's the right choice

   CL: yes
   ... second edition fixes hundreds of issues with first edition

   <jun> [36]http://code.google.com/p/epub-revision/issues/detail?id=63

     [36] http://code.google.com/p/epub-revision/issues/detail?id=63

   CL: the last call disposition of comments is almost complete, same
   for the test suite
   ... so the next transition will be to Proposed Recommendation
   ... not clear what will come first SVG 1.1F2, or CSS 2.1

   JF: it's good to hear that
   ... EPUB WG are very serious about their schedule
   ... they even said they will not publish EPUB3 if it will be delayed
   ... they will publish some time in May

   <jun> [37]http://code.google.com/p/epub-revision/issues/detail?id=76

     [37] http://code.google.com/p/epub-revision/issues/detail?id=76

   JF: another questions is about the use of RelaxNG schema in the
   ... they currently use the schema published with SVG 1.1 First
   ... it's not normative

   CL: also it wasn't produced by the WG
   ... we did produce a schema for 1.2T
   ... we did plan to produce one for 1.1F2 based on that
   ... that's hard work, we couldn't get someone to do it on contract
   ... we would love to have a schema that murata-san produced for us,
   since he knows relaxng very well
   ... but not starting with the 1.1F2 one, since it's just a DTD

   JF: what can we do about this?

   CL: I can write to murata-san and ask him about this

   JF: is there any plan to prepare a normative RNG schema for 1.1F2?

   CL: it was planned
   ... I'm not sure it would get published at the same time as the spec
   ... we could produce another specification called RelaxNG schema for
   SVG 1.1F2
   ... in general W3C is not putting schemas under technical reports
   ... it puts them somewhere else
   ... we normally have a dated schema, as well as a current one
   ... a simple standards track spec for the schema would be ok to do

   JF: we are happy to review his result, to make sure it reflects the
   changes in second edition?

   CL: ye

   <scribe> ACTION: Chris to contact Murata-san about an RNG schema for
   SVG 1.1 Second Edition [recorded in

   <trackbot> Created ACTION-2987 - Contact Murata-san about an RNG
   schema for SVG 1.1 Second Edition [on Chris Lilley - due

   JF: as you may notice, SVG animation is not allowed in EPUB
   ... and some of you might be happy or unhappy with this

   CL: I felt it was OK, and I understood why
   ... e.g. there are ebook readers that have unpowered displays
   ... but I see scripting can also be supported

   AD: peter sorotokin said that it was because it was just thought to
   be not important

   BB: if you're targetting manga, you can get manga on keitai that are

   JF: we are about to change the animation feature in SVG 2.0, so I
   think it's not a good idea to include it in EPUB3

   DS: so for EPUB4

   CL: I can understand it
   ... that's fine

   JF: do we want to suggest to use CSS Animation?

   CL: the two are being harmonised, so neither is more stable
   ... I would suggest to use the harmonised result of that, which can
   be used from SVG or CSS
   ... in EPUB4

   JF: the next issue is about the CSS properties defined in SVG
   ... people think we will probably prepare one stylesheet to cover
   both SVG and HTML content
   ... in that case, is it OK to use SVG specific CSS properties in ...

   CL: each specification can add more properties
   ... CSS is the set of all defined properties
   ... and they can all go in one style sheet
   ... you can use CSS3 namespace selectors to select SVG element

   JF: css namespaces is not used in EPUB3
   ... if you use CSS namespaces, there is no problem to share the
   single style sheet for both SVG and HTML

   <ChrisL> [39]http://www.w3.org/TR/css3-namespace/

     [39] http://www.w3.org/TR/css3-namespace/

   <ChrisL> CSS Namespaces Module

   <ChrisL> W3C Candidate Recommendation 23 May 2008

   JF: EPUB WG is planning to develope some kind of EPUB check program
   ... they plan to use W3C CSS validation service within their check
   ... they want to see the support of some kind of EPUB3 profile as
   one of the profiles supported by the css3 validator

   DS: if they are willing to do some work on that, I don't think that
   will be a problem

   <scribe> ACTION: Talk to Yves Lafon about adding a new profile to
   the CSS validator for EPUB3-supported properties [recorded in

   <trackbot> Sorry, couldn't find user - Talk

   <scribe> ACTION: Christ to talk to Yves Lafon about adding a new
   profile to the CSS validator for EPUB3-supported properties
   [recorded in

   <trackbot> Sorry, couldn't find user - Christ

   <scribe> ACTION: Chris to talk to Yves Lafon about adding a new
   profile to the CSS validator for EPUB3-supported properties
   [recorded in

   <trackbot> Created ACTION-2988 - Talk to Yves Lafon about adding a
   new profile to the CSS validator for EPUB3-supported properties [on
   Chris Lilley - due 2011-03-09].

   JF: another issue is about font embedding

   <ChrisL> s/Christ/@SVGesus/

   JF: in EPUB3, the support of WOFF format is mandatory
   ... you can also support SVG Fonts optionally

   CL: I was happy with it until today, when we decided we were going
   to require SVG Tiny font support
   ... maybe that changes it?

   JF: EPUB3 references SVG 1.1 though

   CL: in SVG 1.1, Tiny fonts don't have vertical

   <ChrisL> but 1.1 fonts do

   DS: what is the lifecycle of EPUB? when will EPUB4 come out?

   JF: some of the WG members have started working on the next version
   ... some of the features are omitted from the EPUB3 draft
   ... some of the features might take some time to be finished, so
   they're moved to the next version

   DS: how long between EPUB2 and EPUB3?

   JF: over three years now
   ... some people want to have EPUB 3.1

   DS: so anywhere from 1-4 years is likely for another version of EPUB

   JF: our feedback to the EPUB WG is we are happy with the mandatory
   support of WOFF?

   CL: yes

   JF: and suggest to support the Tiny subset of SVG Fonts

   CL: with vertical support

   DS: that's our suggestion

   JF: should it be mandatory in EPUB?

   CL: I would say that's our feedback, it's up to them what they
   decide, but they may like to take into account that we just resolved
   that SVG2 will have SVG Tiny fonts support plus vertical support

   AD: if someone were to be interested in mobile again, would we want
   to have another module for 1.2T for SVG Tiny Fonts with vertical

   CL: if we had infinite time

   AD: it could be reused for SVG2


     [43] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite

   JF: one more issue


     [44] http://idpf.org/epub/30/spec/epub30-ocf.html#font-obfuscation

   JF: font embedding
   ... it's about font obfuscation

   CL: are you asking is the right thing to do?

   JF: yes
   ... the current version of EPUB has similar features
   ... in order to allow the embedding of OTF fonts
   ... now EPUB decided to support WOFF fonts
   ... so it seems possible to just embed WOFF fonts without using

   CL: I think obfuscation... it's easy to undo
   ... so it's a picket fence, it's not protection in any sense
   ... but you have to actively do something to circumvent it
   ... I feel that information is better than a half hearted attempt at
   ... with WOFF it has the license right there in the file, which I
   think is better
   ... I don't think it's actively harmful to have the obfuscation, and
   now that you have woff, you shouldn't need it
   ... but if there is an agreement to have it then maybe there is some

   AD: XPS introduced the same obfuscation in their pacakaging, and
   it's more to make the foundries be happy to embed fonts

   CL: I know that many foundries are happy with WOFF
   ... I think we can question the value of the obfuscation, given that
   font foundries are happy with WOFF as a better packaging for their
   font data, instead of raw opentype

   s/... I think/AD: I think/

   CL: my feedback is not to remove the obfuscation, but to reexamine
   that it still adds value, now that you have WOFF

   JF: one more comment

   <jun> [45]http://bizpal.jp/epub/00010

     [45] http://bizpal.jp/epub/00010

   JF: that screenshot is using webkit to do vertical text layout
   ... this uses most of the proposals of css3 vertical text/writing
   modes, implemented in webkit
   ... there's a link on that page to the source content of that
   webpage screenshot


     [46] http://bizpal.jp/epub/ShowImage?id=32aefbb2-4626-4ec9-b0da-faa78491588f

   JF: I want to encourage mozilla guys to consider supporting vertical
   writing in order to be used as an EPUB reading system
   ... to be compatible with japanese vertical writing content

   CL: are any mozilla people looking at that?

   RO: I think there are still some -- I can't remember what the spec
   stage is at, but there were some disputes about stylesheets that
   should affect both horizontal and vertical writing
   ... which quite deeply affect how you actually do it
   ... and I know John Daggett had some strong opinions on it

   AD: a general question: is the group developing any conformance test

   JF: yes, they're working on it

   AD: will it be publicly available?

   JF: I think so, but I'm not sure
   ... canon is not a member of EPUB WG
   ... but I'm an invited expert


compositing a bit more


     [47] http://dev.w3.org/SVG/modules/compositing/master/Overview.html

   AG: I've moved the text around a bit, so it follows on a bit better
   ... extended "object" a bit
   ... explained what to do to get the outline of the objects

   <dholbert> " A User Agent MUST effect the pixel region as specified
   by the 'clip-to-self' property. " --> s/effect/affect/ I think

   <ed> "The optional vaues for the new property is under
   consideration" --> s/vaues/values/ too

   DS: if the compositing stuff is useful, is there anything svg
   specific about it? or should it be in css?

   AD: it should be in css

   DS: it'd be nicer if people who have svg or css UAs could implement
   it royalty free

   AD: i think the porter duff modes are less useful for css content,
   but blend modes are very useful

SVG DOM list object identity


     [48] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues

   JW: there are various things that are unspecified in the current SVG
   ... there are a few things that implementations aren't interoperable
   ... I have here a proposal for how I think it should work
   ... which is biased towards how we do it, but we can talk about the
   pros and cons of it
   ... one of the topics is the SVGAnimatedLengthList object
   ... when the SVGAnimatedLengthList object should be thrown away and
   replaced with a new object, such as a setAttribute call

   AD: you want it to be live?

   JW: that implies changes you make to it are reflected to the screen
   ... for the entire lifetime of the document
   ... to be more specific, the object is never replaced with a
   different object
   ... unless, as an optimization, the script would not be able to
   detect it has changed
   ... so if script has a reference to that object, or its
   animVal/baseVal, or one of the items in the lists, it wouldn't be
   allowed to replace the object

   DH: that behaviour's not part of the spec?

   JW: it's ambiguous
   ... currently we never throw the object away
   ... opera seems to throw it away in some circumstances that don't
   make sense to me
   ... webkit never throws it away
   ... IE always keeps the same object as well
   ... the only exception is opera, which sometimes throw it away

   ED: seems like a bug

   JW: no objections to speccing it?

   ED: where would you spec it?
   ... i wouldn't be unhappy to go over this in SVG2, but for 1.1 it's
   maybe too late to make those kinds of changes

   JW: but going forward?

   ED: that's fine

   JW: then there's the identity of the baseVal and animVal objects
   ... I suggest we never throw away that object if script has
   references to them
   ... same idea
   ... then there's the item themselves
   ... the way we've implemented it, we basically never throw away
   items from a list unless the length of the list requires items to be
   thrown away
   ... objects are just references into the list
   ... so if any of these 7 things happen, we still return the same

   CM: seems reasonable

   ED: we should use these tests and convert them to use the new
   testing framework

   <shepazu> [49]http://nodelist.org/

     [49] http://nodelist.org/

   JW: what the spec currently says, vaguely, is that if an item is
   inserted into a list, when it already belongs to another list, it's
   removed from the list it already belongs to

   CM: but consistent with NodeList

   JW: it depends how you conceptually see them
   ... are they like a js array?
   ... the conclusion of thinking of it like that, is to allow items in
   more than one list

   CM: could thrown an exception

   JW: it appeals to me in some way, to thrown an exception
   ... forces authors to be explicit

   CM: i don't like copy

   JW: in gecko, if the item doesn't belong to anything, it'll insert
   it into the list
   ... if it does belong to another list, it'll insert a copy
   ... reasoning being if you create one with createSVGLength, you
   probably want to edit that SVGlength object you just inserted
   ... the reason we copy is due to considering it to be a list, rather
   than a dom tree
   ... and it avoids confusing behaviour

   [discussions about options]

   (we eventually agree to throw when you try to insert an SVGLength
   into an SVGLengthList if that SVGLength is currently owned by
   anything else)

   <scribe> ACTION: jwatt to write spec text about insertItem etc.
   throwing when the object already has an owner [recorded in

   <trackbot> Created ACTION-2989 - Write spec text about insertItem
   etc. throwing when the object already has an owner [on Jonathan Watt
   - due 2011-03-09].

   <dholbert> s/by anything else/by anything/

   <dholbert> (including the same list)

   JW: last case is mutability
   ... the way IE and Mozilla implement animVal lists and their items,
   they're read only
   ... while they're still in the document
   ... for opera and webkit, they're mutable
   ... you can't change the list
   ... the only thing i'd add, is that if an animation causes the
   animVal to shorten, so then animVal items are discarded from the
   list, then those items become mutable

   ISSUE: animVal list items that are removed from their list should
   become mutable

   <trackbot> Created ISSUE-2405 - AnimVal list items that are removed
   from their list should become mutable ; please complete additional
   details at
   [51]http://www.w3.org/Graphics/SVG/WG/track/issues/2405/edit .

     [51] http://www.w3.org/Graphics/SVG/WG/track/issues/2405/edit

   ISSUE: Define how SVGLengths resolve % (and other) values when they
   are not owned by an element

   <trackbot> Created ISSUE-2406 - Define how SVGLengths resolve % (and
   other) values when they are not owned by an element ; please
   complete additional details at
   [52]http://www.w3.org/Graphics/SVG/WG/track/issues/2406/edit .

     [52] http://www.w3.org/Graphics/SVG/WG/track/issues/2406/edit

   <scribe> ACTION: Erik to review
   ist-issues#Object_identity_given_indirect_changes to see if he
   agrees with it [recorded in

     [53] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes

   <trackbot> Created ACTION-2990 - Review
   ist-issues#Object_identity_given_indirect_changes to see if he
   agrees with it [on Erik Dahlström - due 2011-03-09].

     [55] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes

   <scribe> ACTION: Patrick to review
   ist-issues#Object_identity_given_indirect_changes to see if he
   agrees with it [recorded in

     [56] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes

   <trackbot> Created ACTION-2991 - Review
   ist-issues#Object_identity_given_indirect_changes to see if he
   agrees with it [on Patrick Dengler - due 2011-03-09].

     [58] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes

   trackbot, end telcon

Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 2 March 2011 04:21:17 UTC