- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 2 Mar 2011 17:19:24 +1300
- To: public-svg-wg@w3.org
http://www.w3.org/2011/03/01-svg-minutes.html
[1]W3C
[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
Attendees
Present
+1.649.363.aaaa, tbah, +1.425.868.aabb
Regrets
Chair
Cameron
Scribe
Cameron
Contents
* [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
Compositing
<anthony_nz>
[13]http://dev.w3.org/SVG/modules/compositing/master/Overview.html
[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
1.1?
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
duff?
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
[14]http://www.w3.org/2011/03/01-svg-minutes.html#action01]
<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
[15]http://www.w3.org/2011/03/01-svg-minutes.html#action02]
<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
newer...
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
clipping
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
week
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
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
to?
... 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
implementation
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 &
tests?
DS: No, candidate-recommendation is where that happens
... (and you might go back to last-call after being in CR)
Advanced Gradients
<anthony_nz>
[18]http://www.w3.org/Graphics/SVG/WG/wiki/images/f/fc/SVG_Advanced_
Gradients_Requirements.pdf
[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
illustrator.
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
that
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
meshes
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
cairo
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
Author
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
guess
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
time.
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
[20] http://cgit.freedesktop.org/cairo/tree/src/cairo-pattern.c#n801
(break)
<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
[21]http://www.w3.org/2011/03/01-svg-minutes.html#action04]
<trackbot> Created ACTION-2985 - Fix advanced gradients spec [on
Anthony Grasso - due 2011-03-08].
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
WOFF in SVG 2
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
woff
... 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
enforcement
... 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?
(no)
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
css3-fonts?
CL: right, because css3-fonts doesn't require any particular font
format
... 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_Fon
ts
[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
glyph
... 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
[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
selectors
... 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
stuff
... 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
shaping
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
closed
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
20
... 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
standardisation
... 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
mapping
... KDDI is also interested in HTML5 and TV on Web, from some other
people
... 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
[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
extensions
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
change
... 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
providers
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
specification
... 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 &
Layering
... 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
SVG in EPUB3
JF: I've been involved in the EPUB standardisation, in the last 24
months
... 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
features
... 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
Overlays
... 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
content
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
layout
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
element"
[32]http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-res
trictions
[32] http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-restrictions
<ChrisL>
[33]http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-res
trictions
[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
EPUB WG.
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
[34]http://www.w3.org/2011/03/01-svg-minutes.html#action05]
<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
<jun>
[35]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/012
9.html
[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
specification
... they currently use the schema published with SVG 1.1 First
Edition
... 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
conversion
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
[38]http://www.w3.org/2011/03/01-svg-minutes.html#action06]
<trackbot> Created ACTION-2987 - Contact Murata-san about an RNG
schema for SVG 1.1 Second Edition [on Chris Lilley - due
2011-03-09].
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
animated
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
explicitly
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
program
... 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
[40]http://www.w3.org/2011/03/01-svg-minutes.html#action07]
<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
[41]http://www.w3.org/2011/03/01-svg-minutes.html#action08]
<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
[42]http://www.w3.org/2011/03/01-svg-minutes.html#action09]
<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
support?
CL: if we had infinite time
AD: it could be reused for SVG2
<ChrisL>
[43]http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=
RenderingGraphite
[43] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite
JF: one more issue
<jun>
[44]http://idpf.org/epub/30/spec/epub30-ocf.html#font-obfuscation
[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
obfuscation
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
protection
... 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
value
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
<ChrisL>
[46]http://bizpal.jp/epub/ShowImage?id=32aefbb2-4626-4ec9-b0da-faa78
491588f
[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
suite?
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
(break)
compositing a bit more
<anthony_nz>
[47]http://dev.w3.org/SVG/modules/compositing/master/Overview.html
[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/SVGXxxL
ist-issues
[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
spec
... there are a few things that implementations aren't interoperable
on
... 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
object
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
[50]http://www.w3.org/2011/03/01-svg-minutes.html#action10]
<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
[53]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxL
ist-issues#Object_identity_given_indirect_changes to see if he
agrees with it [recorded in
[54]http://www.w3.org/2011/03/01-svg-minutes.html#action11]
[53] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes
<trackbot> Created ACTION-2990 - Review
[55]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxL
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
[56]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxL
ist-issues#Object_identity_given_indirect_changes to see if he
agrees with it [recorded in
[57]http://www.w3.org/2011/03/01-svg-minutes.html#action12]
[56] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes
<trackbot> Created ACTION-2991 - Review
[58]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxL
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:20:16 UTC