- From: Erik Dahlstrom <ed@opera.com>
- Date: Wed, 25 Jul 2012 23:16:02 +0200
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Same minutes URL as day 2, because rrsagent. Day 3 minutes start about
halfway in...
Minutes here:
http://www.w3.org/2012/07/24-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
24 Jul 2012
[2]Agenda
[2]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
See also: [3]IRC log
[3] http://www.w3.org/2012/07/24-svg-irc
Attendees
Present
+1.206.675.aaaa, Tav
Regrets
Chair
ed
Scribe
birtles, ChrisL, krit, cabanier, heycam, TabAtkins_
Contents
* [4]Topics
1. [5]Marker proposal review
2. [6]Revised text layout proposal
3. [7]white spaces edits in SVG
4. [8]SVG in Web IDL
5. [9]Quick question about mask: <funciri> auto
6. [10]Mapping update
7. [11]buffered rendering and image flattening
8. [12]HTML5 drag and drop
9. [13]SVG 2 section signoff for publication
10. [14]SVG/HTML integration
11. [15]SVG DOM improvements
12. [16]SVGOpen F2F meeting
* [17]Summary of Action Items
__________________________________________________________
<trackbot> Date: 24 July 2012
<Tav> Telephone?
<birtles> scribenick: birtles
Marker proposal review
<ChrisL> scribenick: ChrisL
<birtles>
[18]https://svgwg.org/svg2-draft/painting.html#Markers
[18] https://svgwg.org/svg2-draft/painting.html#Markers
<birtles> CM: I want to go through the marker part of the spec
<birtles> ... some might need changing
<birtles> ... I've rewritten that hold section using fewer
words
<birtles> .... I've defined different types of markers
<birtles> ... four kinds: (1) vertex markers
<birtles> ... you can do this currently
<birtles> ... (2) segment markers, this is a new one
<birtles> ... they place markers at the centre of the path
segment
<birtles> ... (3) repeating markers
<birtles> ... specify a pattern like a dash to repeat markers
at fixed distances along the patah
<ed> scribenick: birtles
UNKNOWN_SPEAKER: (4) position markers
... use markers as a child of a path element
... at fixed positions
<heycam>
[19]https://svgwg.org/svg2-draft/painting.html#MarkerSegmentPro
perty
[19] https://svgwg.org/svg2-draft/painting.html#MarkerSegmentProperty
UNKNOWN_SPEAKER: this is (2), similar to marker-mid
... but in the middle of the edge
ED: what happens if you have a zero-length segment
?
CM: I think it's defined but I would expect it to paint
DS: what about a zero-length path?
CM: I think it won't paint
... marker-mids render on zero-length segments right?
... so in keeping with that you'd do the same here
... and render even for zero-length segments
DS: what does that mean?
... so in order for it to render you have to have at least one
segment of non zero-length?
... so an empty path doesn't render
CM: right
... someone pointed out they'd prefer not to have a
discontinuity as segments get shorter and shorter
... they shouldn't suddenly disappear
ED: what about only rendering if the segment length is longer
than some length?
CM: that's an interesting idea
DS: could be a property
CM: apart from that marker segments aren't too complicated
... but marker patterns (3) are more interesting
<heycam>
[20]https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers
[20] https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers
CM: in Hamburg we discussed this
... talked about having a feature where you could say "skip to
the next vertex"
... but after thinking about that it didn't seem that useful to
me
... and if you want things on edges and vertices then you can
use the other properties
TA: looks good to me
CM: one thing you may want to do
... is stretch out the marker pattern so that it's an even
number of markers along the path
... perhaps the pathLength attribute could affect the distances
in the marker pattern?
... like with dash arrays
... so we should get that for free by using pathLength
... the lengths you specify in this property would be
proportions of the pathLength if you specify that property
DS: what's the big difference between marker and marker-pattern
CM: the existing markers can only be positioned on the vertices
... but this lets you put them by distance along the path
DS: if I click on one of these markers what happens?
CM: these ones (1)-(3) are the same, you can't click on them
... that don't have a unique ID
... so you won't know which one you clicked on
... but the positioned markers (4) do allow you to do that
<heycam>
[21]https://svgwg.org/svg2-draft/painting.html#MarkerElement
[21] https://svgwg.org/svg2-draft/painting.html#MarkerElement
CM: there is an example of positioned markers in the element
section
... at the end of that subsection
... below the attribute definitions
... you could use this for putting arbitrary patterns on a path
... the item marked "the cross" in example 1 in the spec
... in this example there are some marker children
... and the reason they are positioned markers and not regular
markers using the referencing scheme discussed yesterday is the
position attribute
... as well as the position attribute I've added an href
attribute
... since you might want to reference some existing marker
definition
... rather than duplicating it
... in that example, there's <marker href="#Square" ... />
DS: why no just use <use>?
CM: because then how do you know it's a marker?/
... I used a calc since we should be allowing calc wherever we
allow lengths
... that is, we should be allowing CSS lengths
CC: how does this work this the proposal we discussed yesterday
... where marker children become regular markers?
CM: well, a marker could serve both purposes
... a child marker could simultaneously by referenced from
marker-mid, marker-segment
... as well as being a positioned marker by having a position
attribute
... whether it is a positioned attribute or not is dependent
solely on whether or not it has a position attribute
RC: so a marker that doesn't have an href, has no refX, refY?
CM: there is a default value
... 0,0
... my example there should have a refX
... the thing with the positioned markers is that you can put
event listeners on those markers
CL: it would be worth calling that out
CM: yes, I have an issue to do that
DS: I like it
CM: re clipping, the problem was we wanted to specify parts of
the underlying path to knock out
... e.g. so it doesn't appear around the edge of the arrow head
... so I tried to make it easier to compute a single clipping
path to apply when rendering the whole path element
<Tav> [22]http://tavmjong.free.fr/blog/
[22] http://tavmjong.free.fr/blog/
TB: I think it would work better if you specify a clipping path
relative to the marker
... I have some examples of that
... you define the marker and you define a clipping path
relative to that
CM: clipping paths normally specify the part you preserve
rather than the part you remove
DS: I'd like to revisit that
CM: one issue is if you have a bunch of markers that overlap
... it would be nice if you could in the implementation, treat
it as a clipping path you apply before painting
... if each clipping path specifies the area you want to remove
... the implementation has to compute the inverse of that
... which might tricky but probably possible
DS: do you want the author or implementation to calculate it?
... it makes sense for the implementation to do it for simple
cases
... but for complex cases it doesn't
CM: I'm ok with the author specifying the clip path
CC: Figure 13, with knock out
... you have two paths joining
... and you specify marker start and end
... how many line segments do you have in these examples?
CM: 1
DS: these are shapes being cut out
... each of these labelled sections is a path
... and there's a knockout for those
CM: to make it easy to calculate intersection of shapes
... I limited it to some simple shapes
... it makes the computation easier for calculating
intersections
... so I specified the two halves of the shape you're knocking
out separately
CL: can left and right be different?
CM: yes
CC: what is the syntax
CM: it's underneath
DS: why can't the path in the mask be the clipping-path?
CL: I think that's common, e.g. the path plus 3px
CM: I think that's common but also I think these shapes are
useful
TB: how does this affect the fill on the path
CM: I haven't quite worked that out yet
... but you could either have this knockout the fill or not or
make it controllable
DS: can Tav's proposal also solve the problem?
CM: yes
CC: it would be nice to have more drawings in the spec about
how the triangle etc. are drawn
DS: if I clicked on one of these knockout areas what happens?
CM: I assume we do the same as clip-path, i.e. it doesn't hit
the element
DS: ok, we should make that explicit
CM: if we allow the author to specify arbitrary paths for the
area you want to remove
... or the area to include from the marker
... what you need to end up with is a clipping path as we
currently have it
... that you can apply before painting
... if you do that manually you need a big rect to cover the
bbox
... plus a reverse path for the section you want to remove
<ed> would be nice to have an example like this: ->>-
CM: you have to get the clipping path in that form
... unless you want to turn it into a mask (which would be
slower)
... so you need to get the clipping path in that form
(everything included except some bit)
... but you don't want the author to have to specify that
... since, for a start, the author doesn't know how big the
path will be
... so you could allow the author to just specify the bit to
remove
... or they specify the bit they want to include
... and the implementation computes the reverse shape
... and I'd rather not require implementations compute the
reverse shape
... to make it easiest for the author you want them to specify
some part of the shape
... but the implementation has to calculate the overall
clipping path
... and that's what I was trying to help with by using these
predefined shapes
... makes it easy for the implementation to do intersection
detection
DirkS: so you can calculate it rather than asking the graphics
library
CM: it's a lot simpler than bezier curves
... I'm not sure if this is the best way
DougS: what if I don't want to specify a knockout shape
... would the default be the bbox of the shape?
CM: bbox would work for some things like arrows
... but not for many other things
DougS: I think for other cases you use the knockout shapes
... but having a default be bbox it takes the burden off
authors from having to specify anything at all
... perhaps "auto" = bbox ?
<Zakim> ChrisL, you wanted to ask about child(n) and to
consider a keyword that takes the stroke width
CL: I was wondering if would be useful to have a keyword that
means the width of the stroke
... since I think that would be one of the most common knockout
cases
CM: that's the most you need to clip out is up to the width of
the stroke
DougS: yes, that might be more common than bbox
CM: if you're clipping out a square that is exactly the height
of the stroke
... you need to be careful that you do actually do cover the
whole stroke
... if you specify the clipping path you have the be careful
you don't run into precision issues
DougS: what happens if the stroke comes back again under the
marker
... what happens to that new bit of stroke?
CM: I think unless you want to split up the path into multiple
sections
... if you set up a single clipping path before you draw the
path
... you'll have problems
... at least, if you the area you're knocking out goes beyond
the marker shape
DirkS: paths are 1-D, so you apply the clipping path to the
whole path
CM: if you want overlapping behaviour, like the overlapping
road example, you have to split the path
DirkS: should the knockout area for a marker on a curved part
of the stroke also follow the curve?
CM: good question
... I think there are cases where the marker should be
distorted and cases where it shouldn't (e.g. subway circle)
... if the marker is empty and you just want to remove some
part of the path
... then you probably do want the knockout area to be curved
CC: this knockout property seems to make a different between
left and right
... but so far markers don't make that distinction
CM: the shape of your marker might not be symmetrical
... so you might want to knockout out different shapes on
different sides when the marker is in the middle of the path
ED: is the rendering order defined?
CM: yes, it's defined
... marker-start, alternating, segment vertex, marker-patterns,
children etc.
TA: why left / right?
... start / end?
CM: sounds good
<ed> ah, found it...
[23]https://svgwg.org/svg2-draft/painting.html#MarkerAlgorithm
[23] https://svgwg.org/svg2-draft/painting.html#MarkerAlgorithm
CM: when we publish the spec, is it ok to keep this part in?
All: yes, leave it in
Break time, 15mins
<krit> nickScribe: krit
<krit> scribeNick: krit
Revised text layout proposal
heycam: Wanted to reduce the amount tha I presented in Hamburg
<ed> [24]http://people.mozilla.org/~cmccormack/temp/text.pdf
[24] http://people.mozilla.org/~cmccormack/temp/text.pdf
heycam: I want to give the proposals and let people say yes or
no
... one: make it easier to integrate text layout
... text is chucked on abs. pos. at the moment
... each chuck is independent for shaping
... each chunk almost a different text element
... (has presentation on slides)
<ChrisL> relevant CSS work - line layout module
[25]http://dev.w3.org/csswg/css3-linebox/
[25] http://dev.w3.org/csswg/css3-linebox/
heycam: chunking affects how ordering happens, make it more
difficult to reuse text layout
... text elements should be blocks and child elements as spans
... chunks won't stop shaping accross elements
... absolute pos. happens once you got text layout
<ChrisL> also writing modes module
[26]http://dev.w3.org/csswg/css3-writing-modes/
[26] http://dev.w3.org/csswg/css3-writing-modes/
heycam: SVG allows specifying it by each glyph at the moment
AS what happens when you have liguaritures
heycam: there are rules in the spec how to apply chars into a
glyph
... and how to ignore
... We still need to solve the char to glyph mapping before
applying chunks
... evrything should happen across a text element as a whole
... what happens if you specify some pos. but other glyphs
don't have a pos?
... I think we should specify that glyphs without pos should be
relative positioned to previous glyph
fi n a l exampl
fi ligurature
x="100 1550 200"
fi 100
n 150
a 200
sorry wrong
fi 100
n 200
a = 212
l = 224
AS: luguature should break in roman text
Cyril: I miss the explaination why 150 is not used
heycam: that is what spec says currecntly, skip it
<Tav> telephone?
<ChrisL> we need to allow the flexibility of per-font defaults
for discretionary ligatures
<ChrisL> note that this changed recently in css3 fonts
no
heycam: I think it might make sense
ChrisL: don't disallow positioning ligatures
heycam: what is the default value?
ChrisL: do what the font says
... we agreed not to overwrite it
... or switch them of
... svg says, if chars have a pos, glyphs shouldn't ligatures
heycam: if more than one pos, is specified you get behavior
questional ligatures won't be formed
ChrisL: should say may not formed, dependent what the font says
AS: it is up to the font
... I would not expect to form ligatures, but think ChrisL is
right. It depends on the font
heycam: do the CSS layout first
... for the x positions you can not really say how it affects
the font
<ChrisL> see
[27]http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-
prop
[27] http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
AS: right, so you can't rely on the ligature forming
... We shouldn't let it to the font to decide
<ChrisL> Initial: normal
<ChrisL> A value of �normal� implies that the defaults set by
the font are used.
ChrisL: we have to see what the font syas
... initial value is normal - do what the font says
heycam: pos should not influence if ligatures should be formed
ChrisL: AS: agree
... It gives you more flexibiity
heycam: you can't know as an author which chars get a glyph
... after positioning anchoring
... I won't change how anchoring worsk
... the current behavior stays, fi and nal get anchored
... at 100 and 200
ed: end anchoring might be difficult
... basically wondering what happens
heycam: text-anchor is end
... you got 2 chunks
... first chung single glyph
... you should look at all glyphs within a chunk, and look at
the very right or left chunk (dependent on ltr) and shift it
from there
<ed> <text x="100 200" text-anchor="end">ABCDE</text> (and the
same with BIDI)
heycam: ltr text
... right edge of A would be 100, BCD on its's left Eat 200
ed: browsers don't do the same think
heycam: I think the spec is clear about that
ed: what if text was rtl
heycam: you would have the left edge of the A at 200
... you look at the left edge of all glyphs
... A is on the most left
... x should give you exactly the anchor position
Cyril: for my understanding: ltr example
... step one apply CSS layout?
heycam: yes
... lets say fi is a ligature
... then the described behavior is what UAs are doing
... in simple cases it gives you same results
... I show more complicated cases
<text x="300 100">1nab</text>
heycam: 1. perfm css layout and find glyph pos
... n 1 a b
... 20,10,20,32
ChrisL: what you show is the backing store \
heycam: mark up is visual order
<ChrisL> alef and bet are the two letters, btw - see
[28]http://en.wikipedia.org/wiki/Hebrew_alphabet
[28] http://en.wikipedia.org/wiki/Hebrew_alphabet
heycam: normal position
n and 1 are hebrew
heycam: 2. preform CSS layout and find glyph pos
... n is at 200
... 1 is at 100
... a at 110
... b at 122
... a and b calculated according to pref pos
... 1 ab n
... old behavior 1ab n
... I want to change SVG behvaior
AS: 1 and n are rtl
... ab would be pos to the right of n
heycam: I think my proposal makes it possible just to look at
last char in memory
Cyril: english hebrew english
... ——> <—— ------>
... english he___brew english
... don't want to have second english word pos between hebrew
chunks
krit: I think positioning of glyphs is stupid
... we should deprecate it
heycam: well, it is complicated
... at least my proposal is simple to implement
... look from left to right, shift all position
<cabanier> slide deck:
[29]http://people.mozilla.org/~cmccormack/temp/text.pdf
[29] http://people.mozilla.org/~cmccormack/temp/text.pdf
heycam: Opera renders the example correctly according to the
current spec
krit: can we deprecate it?
heycam: yes
... but we need to specify how the deprecated feature is
supposed to work
krit: :P
heycam: have no strong feeling disabling anchoring all together
... propably not important
ChrisL: you have a backing store of glyphs and order them in
rendering order
... where does text-anchor: none go
<ChrisL> the slides are confusing the source display and the
backing store order - slides could be improved for clarity
there
heycam: have to check anchoring: none, but I think it is an
unimportant case
... undefined behavior in the spec t the moment:
<textPath>…</textPath>TextAfterTextPath
... where should it ogo?
... the bottom left of the text path should be relevant for
positioning text after textpath
... we should relax some restictions and allow x,y on textpath
... it just translates the content by transforming the space of
the text path
... we should also allow textpath in tspan
... summary, di what CSS is doing and apply SVG on top of it
shepazu: Can we have a resolution to make textPath element as
top level element (not surrounded by text element)?
general agreement to do so
RESOLUTION: textPath must not surrounded by text element
anymore.
<ed> [30]https://svgwg.org/svg2-draft/text.html#WhiteSpace
[30] https://svgwg.org/svg2-draft/text.html#WhiteSpace
ChrisL: I edited the section about white space handling
s/RESOLUTION: textPath not needed to be surrounded by text
element anymore./RESOLUTION: textPath not needed to be
surrounded by text element anymore.
Cyril: I think I am fine with the proposal
... but am concerned about the complexity of the basic thing
... Is it still from the same complexity as before?
heycam: depends on you implementation of the text rendering
... I don't think that you need to implement all the CSS now
... it is quite unprecise in some cases anyway
<ChrisL> it is the linebox and writing-modes and text modules
of CSS3
<ChrisL> see [31]http://dev.w3.org/csswg/ for links to those
[31] http://dev.w3.org/csswg/
heycam: you don't have to worry about the whole CSS box model.
And the CSS text layout isn't much greater than it is currently
krit: CSS is a requirement anyway
Cyril: I am thinking about the cost to implement it
ChrisL: It does things for browsers easier, but for sure more
complicated fot viewers without CSS engine
heycam: I can put current proposal into the spec and ask if it
makes sense.
... I tried to make it simple
... I think it is easy to implement it
... I can ask Mozilla people as well
RESOLUTION: Add Camerons proposal to spec and ask for wider
feedback
white spaces edits in SVG
<ChrisL> [32]https://svgwg.org/svg2-draft/text.html#WhiteSpace
[32] https://svgwg.org/svg2-draft/text.html#WhiteSpace
ChrisL: previously whitespace was notgood and complicated
... we removed tests from test suite
... I kept it in
... for legacy
... white space handling is using whitespece-property now
... added it to the spec
... added a third section for old and new whitespaces
... and how to do both
... I felt it needs to be adressed
heycam: not hane any XML white space behavior and use property
to select whitespace behavior
... there are still differences
... but should be mostly the same, inore differences and switch
over to white-space: normal and pre
... I have implemented it using a UI style sheet rule
shepazu: we are not talking about word breaking
heycam: ChrisL: yes we are
s/word breaking/collapsing/ ?
ChrisL: I think we want pre-wrap
heycam: CSS people already splitting out whit space collapsing
... If white space is normal I would like to wrap if the width
attribute is specified on the text element
... width attribute is new for text
TabAtkins_: how far do we want to go? We want to have <p> in
SVG anyway
krit: use cases might be different
ChrisL: that is right
[33]http://dev.w3.org/csswg/css3-text/#white-space
[33] http://dev.w3.org/csswg/css3-text/#white-space
<ChrisL>
[34]http://dev.w3.org/csswg/css3-text/#soft-wrap-opportunity
[34] http://dev.w3.org/csswg/css3-text/#soft-wrap-opportunity
ChrisL: it is just using space collapsing
... I think we agree that we want to remove things from the XML
ns.
<scribe> ACTION: ChrisL to work out things on removing XML ns
stuff on text and figure things out with the CSS WG [recorded
in [35]http://www.w3.org/2012/07/24-svg-minutes.html#action01]
<trackbot> Created ACTION-3323 - Work out things on removing
XML ns stuff on text and figure things out with the CSS WG [on
Chris Lilley - due 2012-07-31].
<ChrisL> action-3323?
<trackbot> ACTION-3323 -- Chris Lilley to work out things on
removing XML ns stuff on text and figure things out with the
CSS WG -- due 2012-07-31 -- OPEN
<trackbot>
[36]http://www.w3.org/Graphics/SVG/WG/track/actions/3323
[36] http://www.w3.org/Graphics/SVG/WG/track/actions/3323
<ed> -- 15 min break --
<cabanier> scribenick: cabanier
<ChrisL> scribenick: ChrisL
<scribe> scribenick: cabanier
<ed>
[37]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interf
ace_reorganization
[37]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
SVG in Web IDL
CM: I propose to redo the SVG idl
[38]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interf
ace_reorganization
[38]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
…turn "stylable", "locatable" and "transformable" in actual
element
…SVGtransformable is inherited the most
WebIDL doesn't support multiple inheritance
…there is nothing too contraversial
…I do propose to get of the SVG namespace. move away from XML
lang
…there is only a couple of elements that you can't use the
properties on
…if you use xml lang on animate, it's not going to have any
effect
TA: it negotiates fonts.
…for different languages
BB: ElementTimeControl
will it disappear all together?
CM: yes
BB: this is how I test for SMIL support. We might break content
if we remove interfaces
… gecko and webkit support it. Opera doesn't
CM: I can leave it in.
BB: not sure if there's content that relies on it
... I can change my content
CC: in some case you remove multiple inheritance by merging. In
others they implement. I don't understand how you made the
decision
CM: take SVGFitToViewBox. SVGSVGElement needs it and a couple
of others.
…SVGSVGElement we want to be able to transform but not
SVGMarker
CC: the solution to multiple inheritance
DS: why not multiple inheritance?
CM: because JavaScript doesn't support it
…there is a difference between 'implements' and 'inherits'
… implements is a new copy of the function while fill:inherits
is the same
… the reason SVGGraphicsElement and SVGDefinitionElement are
introduced because it's a good place to hang the mixed in
interface instead of the more specific
from the spec: "Having these two interfaces gives us a place to
mix in other common interfaces (like SVGTests) without having
to do it on each sub-interface."
… this is how we might reorganize the interfaces
… Jen, don't you use WebIDL directly
J: not sure about that
CM: any questions?
All: no
resolution: we will adopt Cameron's proposal for Proposals/IDL
interface reorganization
CM: let's move SVGStylable up to the SVGElement
All: agreed
BB: so get rid of stylable element?
all: yes
BB: that's great
resolution: we will get rid of SVGStylableElement
<scribe> ACTION: Cameron to do all this interface stuff
(Proposals/IDL interface reorganization) [recorded in
[39]http://www.w3.org/2012/07/24-svg-minutes.html#action02]
<trackbot> Created ACTION-3324 - Do all this interface stuff
(Proposals/IDL interface reorganization) [on Cameron McCormack
- due 2012-07-31].
CM: can we get rid of externalresourcesrequired?
all: what's it for?
BB: it should line up with DOMContentLoaded
all: yes
CL: people wanted that if one resource doesn't load, nothing
should load
RC: externalresourcesrequired was more granular since it worked
per group and we especially helpful for fonts
… but I don't think anyone implements or use it
DS/ED: we believe that is true
ED: Opera implements it, but eRR isn't used much
DS: are there cases where this is useful?
BB: if that's true, we should do it for HTML as well.
resolution: remove ExternalResourcesRequired from the spec
CM: That's all for the IDL talk
BB does a demo of an animation application written in SVG
BB: having viewbox as a property would be very helpful in
conjunction with media queries
CM: is viewbox the CSS name?
css syntax:
svg { viewbox: 0 0 240px 240px; }
<ed> ick, why the units?
<ChrisL> because CSS
CM: does it make sense to non-svg?
DS: such as iframe
<ChrisL> can the units be optional?
TA: yes, just iframe establishes a viewport
<ed> if we allow units, then we should allow units in the
viewbox attribute too, but sure, that follows from making it a
presentation attribute I guess...
<heycam> ed, agreed
fixed CSS syntax: svg { view-box: 0 0 240px 240px; }
<ed> calc too?
<heycam> of course
<ed> people are probably already writing "viewbox" in
html-with-inline-svg, and "viewBox" in svg... and then
"view-box"?
Doug: this seems to be a very nice feature in combination with
auto scaling
…there is a question with auto
… what happens when things move around? content will start
growing/shrinking
DirkS: then you should absolute coordinates
…should we apply to HTML as well?
TA: HTML and iframe create a viewbox
resolution: convert viewbox to a property and give it an 'auto'
characteristic
<scribe> ACTION: Tab Atkins to take HTML and Iframe view-box
property to the CSS working group [recorded in
[40]http://www.w3.org/2012/07/24-svg-minutes.html#action03]
<trackbot> Created ACTION-3325 - Atkins to take HTML and Iframe
view-box property to the CSS working group [on Tab Atkins Jr. -
due 2012-07-31].
<scribe> ACTION: brian birtles to write up a proposal for
view-box property for SVG [recorded in
[41]http://www.w3.org/2012/07/24-svg-minutes.html#action04]
<trackbot> Created ACTION-3326 - Birtles to write up a proposal
for view-box property for SVG [on Brian Birtles - due
2012-07-31].
Quick question about mask: <funciri> auto
BB: in the case you have a mask property, let the mask decide
what it is: luminance or alpha
<birtles> current syntax proposal: [ <funciri> | child |
element(<compound-selector>) | none ] [ luminance | alpha |
auto ]?
… auto means do what the mask says
… but if you point it to an image, what should it be?
<ChrisL> you need to be able to choose either
RC: it seems that you should get luminance
DirkS: I think it should be alpha
CL: people that want alpha point to a grayscale. I have a
feeling that it should be alpha
<ChrisL> alpha alpha alpha, ra ra ra
resolution: alpha is chosen when selection 'auto' is set and
mask is pointed to an image
... the property alpha/luminosity wins when pointing to a mask
element
<krit> <!DOCTYPE html>
<krit> <html lang="en">
<krit> <head>
<krit> </head>
<krit> <body>
<krit> <svg>
<krit> <rect width="100%" height="100%" fill="green"/>
<krit> </svg>
<krit> </body>
<krit> </html>
<krit> [42]http://jsfiddle.net/FcQVn/
[42] http://jsfiddle.net/FcQVn/
<krit> [43]http://jsfiddle.net/FcQVn/
[43] http://jsfiddle.net/FcQVn/
<krit> [44]http://jsfiddle.net/WFCZz/
[44] http://jsfiddle.net/WFCZz/
<krit> [45]http://jsfiddle.net/WFCZz/
[45] http://jsfiddle.net/WFCZz/
<krit> [46]http://jsfiddle.net/j9zJw/
[46] http://jsfiddle.net/j9zJw/
<krit> [47]http://jsfiddle.net/Mym5r/
[47] http://jsfiddle.net/Mym5r/
<krit> [48]http://jsfiddle.net/FcQVn/1/
[48] http://jsfiddle.net/FcQVn/1/
<krit> [49]http://jsfiddle.net/WFCZz/1/
[49] http://jsfiddle.net/WFCZz/1/
<krit> [50]http://jsfiddle.net/j9zJw/1/
[50] http://jsfiddle.net/j9zJw/1/
<krit> [51]http://jsfiddle.net/Mym5r/1/
[51] http://jsfiddle.net/Mym5r/1/
<heycam> shepazu,
[52]http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
[52] http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
<nikos>
[53]http://en.wikipedia.org/wiki/Magic_Roundabout_%28Swindon%29
[53] http://en.wikipedia.org/wiki/Magic_Roundabout_%28Swindon%29
<ChrisL> action chris to rewrite the SVG2 Concepts chapter to
make more sense in 2012
<trackbot> Created ACTION-3327 - Rewrite the SVG2 Concepts
chapter to make more sense in 2012 [on Chris Lilley - due
2012-08-01].
<ed> going for coffee now, back in 15min
<heycam> trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 25 July 2012
<heycam> Chair: Cameron
<heycam> ScribeNick: heycam
Mapping update
<birtles> [54]http://www.slideshare.net/brianskold/web-maps
[54] http://www.slideshare.net/brianskold/web-maps
BB: I want to give a little update with where we're at with
mapping
… I spoke to Takagi-san from KDDI last month
… I want to summarise some of the materials he sent me
… some of it we looked at in Sydney in January
… some of it is new
… I also spoke to some folks at Mozilla last week, and we have
some thoughts about what we think the next steps are
… he suggests that maps are as fundmanetal to the web as video,
just another data type
… he expects that that usage will grow, especially with mobile
computing
… and also the fact that Apple is entering the maps space
… suggesting it's an important area
… that said, it's already possible to do maps on the web, there
are mapping services already
… why do we need to do anything more?
… Takagi-san's concern is current systems are closed, and
you're at the mercy of the mapping service to do local storage
of map data, ad hoc sharing, mashing up data with other
providers
… wrt offline access, that seems to be particularly important
in the wake of the disasters in Japan last year, where internet
access was unreliable during relief work
… there was a recommendation from ITU-T that SVG mapping be
pursued as a possible technology to assist in disaster relief
situations, especially for the offline access but also ad-hoc
sharing, taking map data from one source
… for example the base data comes from OSM and extra regional
data, relief centres for example, that you would overlay
… also Takagi-san argues that the web should be decentralised,
and current mapping services are very much run by one server
… there's not really a facility for sharing data
… if the processing is done more on the client side, the user
is in more control
CC: for offline usage you need navigation logic to be stored
locally, right?
BB: yes
… it's not that offline access is completely impossible, I
think Google Maps offline is available
NA: there's Off Maps on the iPhone
BB: but you're at the mercy of the mapping service
… if there was client side technology, there would be
guarantees that you could cache that data
CL: that ties in with the approach with the Linked Open Data
people, instead of everyone uses my mapping service, everyone
publishes data and can use them together
BB: it's not entirely impossible with current services, with
Google maps you can take KML files from different sources
… but you are at the mercy of the service as to what services
are available
… what would be needed to achieve the model that Takagi-san is
promoting?
… the main piece of it is the Tiling and Layering feature
… I want to go into that a littble bit
<krit>
[55]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Map
ping
[55] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping
… we looked at this in January, basically you have container
files that reference other SVG filtes
s/filtes/files/
… and you can cascade those container files
[example shown using <animation> elements, and
<globalCoordinateSystem>]
… in SVG, the <image> element is static, it's basically just
converted into four channel image data
… <animation> from 1.2T allows dynamic content
… that's why he used that here, but he's open to using some
different element
… the other main piece is the <globalCoordinateSystem>, and we
talked about that a lot in January
… that's a mapping from the coordinate system of the tile's SVG
file to a global coordinate space, and then you have the same
element in the container file so that you can transform into
the coordinate space of the container file
Dirk: it's a 2D coordinate system?
BB: I think it's a standard cartographic coordinate system
… the x/y/width/height on the <animation> indicates which tiles
you need to load, and it also does clipping
… the other feature of T&L is layering, where you put the
pieces on top of each other
… not sure how that bit works
… there's also the min/max zoom thing, which tells you at which
points to show and hide any element, but typically applied to a
tile
… that's the basic features of the Tiling & Layering spec
… it has lots of applications beyond maps, Takagi-san had a
list of them
<birtles>
[56]http://www.w3.org/Graphics/SVG/WG/wiki/Use-cases_of_SVGTL
[56] http://www.w3.org/Graphics/SVG/WG/wiki/Use-cases_of_SVGTL
… on that page are a list of places you could use T&L
… that's the main piece of what Takagi-san is proposing
… some other pieces we discussed last time, non-scaling-stroke
which I think is implemented widely now
… shared paths is something which we agreed was good but
there's no commitment from anyone to write that up for SVG2
… that's especially useful for borders between countries, where
you want the same line to be shared between different shapes,
and stroked just once
… fixed size objects, we talked about reintroducing
transform-ref from 1.2T, but that seems to be at risk too
… non-linear transformations we've rejected
… UI features, we knocked back built-in map controls
… we also rejected the idea of programming-less geolocation,
e.g. centre the map on my location
… I am not sure what we have decided on SVG views with
geographic coords, but there's no commitment to have that in
SVG2
… API features for smooth transitions of zooming/panning, but I
think we didn't understand what that was about
… if we do support global coordinate systems, then it makes
sense to have an API for that
… but that's assuming we have the <globalCoordinateSystem>
element
… finally, if we were to introduce some sort of <tile> element
then it needs to have contentDocument, contentWindow for
accessing the contents
… I want to present a summary of the discussions I had with
Mozilla folks last week
… basically, one of the things we discussed was that map UIs
are very complicated, for example they can do all sorts of
things like if the label is close to the edge of the viewport,
you shift it so that it's readable
… Google Maps has integration with WebGL
… so it seems hard to imagine you could standardised a set of
map features that would be competitive with existing map
services
… you obviously can't get UAs to implement all the features of
Google Maps
… so we thought it would be better to agree on a standard
markup for maps, and then have at least one open source app
that consumes that data
… so it's still client side, and the user is in control, but
without requiring UAs to implement the mapping features
… in response to that, Takagi-san agrees that complex mapping
services should still be realised as web apps with JS, but he
would like to see some sort of minimum subset as a UA native
implementation
… I think his argument is that then you would have some
guarantees that the map data is independent from the mapping
services
… Takagi-san believes there are good reasons for implementing a
base set of features in UAs
… he'll be at the next F2F so can explain better at that point
Dirk: I don't see anything that can't be done with current
markup that we have
… we can still provide some microformats, just introduce some
name conventions
… at the end you still need an application that knows about all
these terms
BB: that's basically the Mozilla position
… with the exception of the next piece, we think tiling is
generally useful beyond maps, and are interested in some sort
of iframe-like element in SVG
CL: I didn't understand the relationship between those two
… I didn't understand why you would then use iframe
BB: the idea would be to add something along the lines of
<animation> element, which allows embedding SVG, also in
combination with that having a load on demand facility
… so that those items wouldn't be loaded when they're not in
the viewport, or some heuristic like that
… that's one way you could realise tiling
Dirk: what about using <use>?
… if you want to have tiling as well, you could surround it
with <svg> inline element, because they act as clipping region
BB: that's worth investigating
… I think iframe is attractive because it gives some features
like sandboxing, although that might not be important in this
case
… something of that nature anyway
Dirk: we'll eventually <iframe> in SVG anyway
CL: one obvious use case is high res imaging, medical or
photography
… being able to just specify "here's a high res source" and
have it automatically bring in low res things on demand, is
useful general functionality
… with DOM support too, but without needing script for base
level functionality
CM: I think one reason for suggesting iframe was to avoid
introducing a new element that does the just the same thing as
an existing element
Doug: we've talked about tiling in two different ways this week
… there's the tiling as decorative, taking a preexisting
resource and repeating it in different permutations
… and there's also tiling as in fetching external resources on
demand, and not repeating them
<ChrisL> the first one is the css background tiling
… we should somehow converge those two if it's useful
CL: I think it's better to use different terminology, since
they're mostly different things
… one is replication of an image
Doug: one area where they might be related, the superpath where
you want to join different tiles up
… a road doesn't end one tile
… so there is the matching of edges aspect, so that might be
related on both
BB: as to the minimum subset that is needed, Takagi-san
identified two things
… one is the T&L feature, and the other is zooming & panning
… (browser native UI to zoom and pan the image)
CL: in SVG 1 we said that all UAs had to have that feature, and
the first round of UAs did have that
… but they all did it differently
… the second generation of implementations in browsers either
ignored it completely, or just gave you scroll bars which is
not ideal
… and suggested that authors use script to do this
Doug: as an author, I've run into situations where I did and
didn't want users to zoom/pan
… if we're not going to provide UI controls, which I think is a
shame, we should at least provide a rich API for panning and
zooming
… for example "zoom to a particular rectangle"
… "zoom centered around a particular point"
… maybe we could have a zoom to rect, zoom at point API
… and something for panning as well
CM: I think that is in line with what we've previously
resolved, to not have native UI but to make it easy for script
to implement zoom/pan
DS: I would like to see browsers implement native zoom and pan
controls
… maybe they could be turned on or off in preferences
BB: so today I'm not aiming for particular resolutions, I'm
just summarising where we're up to
… in Zurich Takagi-san can present his thoughts and concerns
… perhaps the most concrete thing that could come out of this
is to investigate some sort of use/iframe element for this sort
of thing
… one thing I realised for <iframe> is that it has has seamless
Dirk: you have to maybe specify inherit as the property value
Doug: one problem with iframe is that it has its own coordinate
system embedded in it
… that might be a good thing or a bad thing
… you might want to have a coordinate system in the tile
… but you probably want it relative to the other tiles
… we need to write down use cases and requirements for exactly
what is required for T&L
BB: right
Doug: do you really expect to have dozens of iframes how is
that going to affect performance?
BB: I don't think there's any particular performance concern
Doug: what about overlaps?
BB: I don't know exactly how it works in the proposal
Takagi-san has put forward, but there are a lot of ways to
realise that
Doug: there would be some metadata that says "I am this portion
of this other document"
… if you have a raster that you've tiled and you're zooming in
on an x-aray
s/aray/ray/
… each segment knows what part of the larger image it is
… also, are these things injected into the dom automatically,
and removed?
… or is it more like a <use> where there's a shadow tree?
… does each tile actually have an element, or is there
something weird going on?
BB: I think all that stuff needs to be worked out
… you would probably have contentDocument on the DOM node,
especially if it's an iframe that would be the obvious way to
approach it
… wrt the load on demand facility, you might say that when it
goes out of view the contentDocument becomes null
Doug: currently if you have a <use> or an <image> which it
hasn't retrieved it, it doesn't give you an indication that
there's something missing
… I think we need something that shows the missing image, maybe
a pseudo class
… and then you could style it yourself
BB: I think we need a concrete proposal for what is required
… we need to investigate further the load on demand for zoom
levels
… that would be a step towards the T&L spec, but not
necessarily committing to do the whole thing
BB: that's it
… I think we need a specific proposal for an element like
animation/iframe that can contain the SVG
Doug: I'd like to know how it would be like iframe
… it has a particular DOM interface, features
CM: I think Mozilla's view is that rather than come up with a
new element that has substantial overlap with an existing one,
that we extend the existing one for the new features (like load
on demand)
Dirk: we've been discussing this topic for nearly a year now,
but we still don't have a proposal
… it doesn't seem like we're making progress
BB: I guess Mozilla is saying that we're not interested in
implementing the proposal as it stands, but we're intersted in
pulling off one of the features of it and implementing that
… the feature where you can include another SVG or raster image
and have load on demand control
Dirk: can't you already do that? <foreignObject><iframe>?
BB: it's not iframe specifically, it's the load on demand
feature
… it might be possible with a <use> element, if so great
… but the automatic loading of subresources based on zoom level
and viewport is the part we're interested in
CM: what is the next concrete step?
BB: someone to come up with a proposal for an element for
pulling in subresources on demand with zoom level control
Dirk: should it work with other formats?
BB: yes, definitely raster images too
… it needs to do more than SVG, but it can't do less than
dynamic SVG
… as opposed to the <image> element
… but also should allow raster graphics as well
CC: is it really zoom level control? or bit rate control?
CL: it's more zoom level control
CC: I was thinking in terms of bit rate control. does it have
to be inside SVG, or could we have some indirection level where
you first get some resource which describes other resources and
you get one of them?
… when I was talking about the adaptive streaming that's how it
behaves
… not suggesting to use exactly that, but having that extra
level of indirection might be useful
Dirk: how does the dynamic stuff work? so you zoom in and this
makes the document load?
… it still sounds very specific
… I'm just wondering if it's better to write a JS library to do
it
BB: I think for say a medical image you would want that to
happen automatically, browsers could optimise the prefetching
NA: you can also use that kind of feature for handling small
screens
Doug: maybe media queries would be good for this
CM: yes I keep thinking of media queries too
CC: what about switch?
Doug: MQ is friendlier than switch, with switch you have to use
a specific document structure
BB: MQs don't currently take into account the transforms you
apply for zooming in, it's just the viewport you render into
… the T&L spec has this min/max zoom attributes, and that may
be one way to do it
Dirk: with MQ you can just put the details or want or not want
in classes, and then just not display them, for a certain
viewport size
BB: when you have the cascading style you need to control
specific tile loading some levels deep
ack
ack
<ChrisL>
[57]http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#mult
ires
[57] http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires
CL: there's a concrete proposal
… it did have a fully specced out way of doing this, not saying
it's a good idea, but it's something to look at
… Kodak demoed an implementation in Batik at one point
TA: HTML is doing srcset
… you specify several urls with an alternate resources giving
the pixel ratio
BB: that's only a single level though
CC: I agree the solution should not be specific to SVG
CL: see how this multires proposal has minpixelsize and
maxpixelsize
<TabAtkins_>
[58]http://www.whatwg.org/specs/web-apps/current-work/multipage
/embedded-content-1.html#attr-img-srcset
[58]
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset
… however it's still not great because you've got explicit
markup, you have to do this slicing yourself
… take an image, slice it into four, take those and slice it
into four, inventing a naming scheme for tile files
CM: I think Takagi-san's proposal requires that too
BB: but these subresources could also use multiimage, so that
would support the cascading
… I think the cascading is an important feature
Dirk: I still think it's too tied to the markup and it should
be done in script
s/cascading/cascading or recursion/
BB: so I think what's missing is what's needed is someone to
work on this
… maybe the thing then is to bring this up in Zurich, I can't
find the time before then to work on this
… so we should bring it up when Takagi-san is present
CL: would be useful to get feebdack from Alex Danilo on the
problems he found when implementing it for his player
buffered rendering and image flattening
CC: I have ACTION-2863
<Cyril>
[59]https://www.w3.org/Graphics/SVG/WG/track/actions/2863
[59] https://www.w3.org/Graphics/SVG/WG/track/actions/2863
… the action is quite generic, investigate how to improve
buffered-rendering for SVG2
… I tried to think about it and look at the requirements so far
… we have another requirement called "flatten to image"
… to keep an image as pixels and not as a dom structure
… if you look at it, buffered-rendering has 3 values: auto,
static, dynamic
… dynamic is a hint that the content of the group will change,
so it's not worth caching it
… static means it might not change, so it might be worth
caching
… auto means do whatever you want
… but it's just a hint
… I'd like to discuss the possibility to have not a hint, but
something normative with conformance statements
… where if you put the value say "static", the browser is
allowed to keep the object cached without the associated dom
structure
… thereby reducing the memory required to store the object
… it does not need to be a pixel representation, it could be a
vector representation
… it could be controlled by the rendering hints
… the idea would be to have something a bit like canvas, where
you just give JS calls and the result is an object in memory
that you can reuse
… in this case you don't use JS calls but you describe it with
the dom
… when it's loaded, if it's a clip art for instance you know
you won't animated it or script it
… it won't change, so the browser can keep it efficiently in
its cache
Dirk: but still vectors?
CC: I think it should, but we could discuss it
RC: is that a problem with keeping the dom around?
… if you still have a vector representation...
Dirk: you might have dom access during a rendering
… if we have a dom tree and a render tree, you could even throw
away some render tree and just keep say the cairo context with
its path
CC: why would you not always have an efficient render tree?
... marshalling things between the DOM and the render tree is
expensive
Dirk: if nothing changes, you don't need the dom
CC: the DOM consumes memory right?
CM: I think that's what cyril is worried about
BB: if you get rid of the dom, there are things in there that
describe how to scale for example, and once you set static you
won't have enough implementation to rerender properly
ED: I don't think it would be a problem to define this as
getting a snapshot
CC: when an html image element points to an svg, are you
optimising that?
BB: they can be animated, so we keep the dom around
… even for things like percentage lengths they'll change if you
drop the dom
ED: the question is whether that's acceptable
BB: I'm dubious
Dirk: what about hit testing?
CM: this seems very dependent on how implementations are
currently written
Dirk: each render tree object is associated with a dom object
… in WebKit when you destroy a DOM object the render object is
destroyed
CC: what happens when you have a canvas?
<ed> hit testing should work just fine assuming the UA keeps
the vector representation around
… you don't have a dom, but you have a render tree?
Dirk: for a canvas you always need the dom object
CC: if you have a group with this property set to static, the
whole tree could be collapsed to one object
Dirk: I think that is what Rik was suggesting
CC: so with SVG you have a big DOM, with JS you have a bunch of
JS, maybe there's a way in between
Dirk: we need to specify how hit testing works
… if WebKIt decides not to implement for example, hit testing
would still apply
… wouldn't want the behaviour to be different from
implementations that do do it
JY: what's the advantage of html img?
… if you have a static svg file, browsers could just optimise
it themselves couldn't they?
BB: I think percentage lengths is something that's difficult
… you could have a rectangle that is 300 high, 80% wide
… the aspect ratio is going to depend on the viewport
… it's fine to say take a snapshot, but when?
… if that's in an html document and you reflow, the aspect
ratio would hcange
… what you would get depends on when you take the snapshot
JY: what is the expected behaviour when you set it to static?
BB: maybe in one browser it happens to snapshot just after a
font is loaded?
CC: can't you just resize the object? you have to resize
individual parts?
… indeed that's a problem
RC: I think the buffered-rendering hint works fine, the auto
thing can detect if something changes
CC: I think having a hint is useless, it's better not having a
hint
… if browsers don't use the hint, then authors will use the
hint in the wrong situation
… browsers will then have to ignore it anyway
CM: I agree
RC: it cannot really know, it can't know what the JS user is
going to do
<Cyril> ack
ack
CC: I agree there are problems, if we go in this direction we'd
need to specify when the snapshot is taken
… and how it behaves for picking and so on
… we could say when the full document is loaded, or when the
tree is loaded, when DOMContentLoad is generated
… or if we don't know exactly, we could go for an API
… call .flattenTree()
BB: I think you'd need to require a viewBox, so you don't end
up with inconsistent sizes
… so you have a fixed aspect ratio
CC: this is for a subtree
BB: that wouldn't help then, unless you require a viewBox on
the top
CC: when you have flattened the tree, you should be able to
rescale and keep good quality, but the result shouldn't be that
you rescale text only horizontally for example
… the example about percentages or ems, should not be allowed
Dirk: I think it doesn't really help if the size should always
be in the same ratio
… because you would get pixellation if you scale a lot
BB: but this is a vector snapshot
CC: I think this would bridge the performance gap between
canvas and svg
ED: from our experience, traversing trees is a big cost
CM: if you are traversing a render tree isn't it that same?
ED: it's quicker for us to traverse the render tree compared to
the dom tree
CC: I just want a single render object with a sequence of
drawing commands
CM: this would be a lot of work for us
Dirk: also for us it wouldn't help with performance much
CC: I think there is a gain in performance and memory here
… if you don't have to traverse the dom
Dirk: we don't traverse the dom
<nikos>
[60]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#Flatten_to_image
[60]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Flatten_to_image
[some discussion about implementation internals]
JY: big files coming from inkscape or illustrator, you can just
reference that with an <image>
… then browsers can optimise that themselves
… or for large things generated by script, if you want you can
render that to canvas yourself
NA: we have the flatten to image requirement from the SVG2 list
… this is not exactly the same as cyril's thing, but maybe that
approach would be better
BB: there's drawElement on canvas
CM: I think relying on the browser's on optimisation for
<image> elements is fine here
BB: animations run in HTML <img>
… in firefox/chrome/safari/opera
… but I think the <image> element in SVG is static
ED: in opera we support animated png in SVG <image>
… so why forbid svg animations in there
CM: what about buffered-rendering?
ED: that's already in the spec
… but I think this action was about exploring other things
… I think it's still useful, for some devices
CC: in an interoperable way?
ED: whether it's there or not doesn't make a difference
BB: firefox allows animations in SVG <image>
Doug: let's just change the spec
<ed> s/for rendering it doesn't matter if BR is specified or
not, it should produce an identical rendering result/
<ed> s/whether it's there or not doesn't make a difference/for
rendering it doesn't matter if BR is specified or not, it
should produce an identical rendering result/
RESOLUTION: SVG <image> will allow declarative or frame-based
animated images
<shepazu> s/SVG <image> will allow declarative or frame-based
animated images/SVG <image> will allow declarative or
frame-based animated images, but not scripted animations/
RESOLUTION: SVG2 won't have a flatten to image feature
HTML5 drag and drop
<ed>
[61]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/SVG_DragAn
dDrop#Proposal_for_adding_the_HTML5_dnd_attributes_to_svg
[61]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/SVG_DragAndDrop#Proposal_for_adding_the_HTML5_dnd_attributes_to_svg
ED: this is a proposal to add all of the drag and drop
attribtues and events to svg
… currently HTML5 specifies that drag and drop attributes only
apply to html elements
… you can have svg inside html, but currently it's not
specified to do anything for svg elements
… so this proposal is to add those
… there's a list here of changes that would be needed to be
made
… a list of events that html has, the event attributes like
ondrag
… two attributes, one could draggable, one called dropzone
… to all svg elements
… then the question is how much would need to be repeated in
the spec, how much can we depend on html to define this
… I'd like to hear what people think about this
CM: I think it would be good to have on SVG
<krit> what about moving drag and drop to DOM from HTML?
Doug: there is widespread dislike for html's drag and drop
CL: if there are better things why aren't they in the spec
then?
Doug: there's nothing better implemented
… I agree in general it's better to align with html, but let's
not fool ourselves that's it's a good solution
<krit> again, what about moving it to DOM4?
ED: I have seen lots of people ask how to drag html elements
into svg
… things like files from the desktop, too
… I don't think this helps with the problem of getting mouse
event coordinates in the right coordinate space
<ChrisL> OH: steaming pile of bovine manure
ED: I don't think we should come up with something new SVG
specific
s/ED/Doug/
Doug: should do it in webapps or whereever
<ed> s/… I don't think this helps with the problem of getting
mouse event coordinates in the right coordinate space/Doug: I
don't think this helps with the problem of getting mouse event
coordinates in the right coordinate space
Doug: you can't just let things be draggable, you have to use
script to do it
… maybe we should contact jquery ui guys and ask them whether
we should ignore this api for now or come up with something new
ED: I think though with SVG inline in HTML people would expect
it to work on SVG elements
… specifically I've heard people wanting to drag and drop
images into svg, but also with compound documents dragging
elements between html and svg and having things draggable and
droppable
CM: may as well just allow it to work on svg elements
RESOLUTION: SVG elements will support the HTML drag & drop API
CM: I'd prefer for us to copy as little text defined in HTML as
possible
<krit> heycam: Did someone even consider moving it to DOM?
ED: referencing HTML is fine?
CL: I think so
krit, I am not sure
<krit> :(
ED: I am not sure if it makes sense, especially if it depends
on markup
<ChrisL> s/think so/think so, they will likely be at CR by the
time we get to CR/
… (moving it to DOM that is)
<scribe> ACTION: Erik to add the drag & drop functionality to
SVG2 [recorded in
[62]http://www.w3.org/2012/07/24-svg-minutes.html#action05]
<trackbot> Created ACTION-3328 - Add the drag & drop
functionality to SVG2 [on Erik Dahlström - due 2012-08-01].
SVG 2 section signoff for publication
[63]https://svgwg.org/svg2-draft/text.html#WhiteSpace
[63] https://svgwg.org/svg2-draft/text.html#WhiteSpace
CM: first thing is the white-space changes Chris has made
… sounded like everyone was ok with that
CM: next is
[64]https://svgwg.org/svg2-draft/text.html#TextElementWidthAttr
ibute
[64] https://svgwg.org/svg2-draft/text.html#TextElementWidthAttribute
[65]https://svgwg.org/svg2-draft/text.html#TextOverflowProcessi
ng
[65] https://svgwg.org/svg2-draft/text.html#TextOverflowProcessing
… which Erik has added
CM: next is painting chapter changes
… most things after the introduction
[66]https://svgwg.org/svg2-draft/painting.html
[66] https://svgwg.org/svg2-draft/painting.html
[67]https://svgwg.org/svg2-draft/painting.html#SpecifyingFillPa
int
[67] https://svgwg.org/svg2-draft/painting.html#SpecifyingFillPaint
… I rewrote that section
[68]https://svgwg.org/svg2-draft/painting.html#StrokeShape
[68] https://svgwg.org/svg2-draft/painting.html#StrokeShape
… is that new section useful?
<ChrisL> I made changes to the fonts chapter, but didn't put in
the class for the changes sorry
<ChrisL> [69]https://svgwg.org/svg2-draft/fonts.html
[69] https://svgwg.org/svg2-draft/fonts.html
ED: I think it's useful
CL: I changed the introduction to the Fonts chapter to talk
about woff, remove css2 references
… and moved around the order of the chapter
… i put the svg fonts at the end
… so the first thing is @font-face
… I haven't yet trimmed down the section on fonts so it just
describes tine fonts
s/tine/tiny/
… but there's a purple box to say we'll do that
CM: are we keeping the <font-face> elements?
CL: we could discuss that
… I would fine with removing it
… and I think we should be encouraging @font-face
… they're equivalent
… not sure if all implementations do both, though
JY: we don't do the <font-face> elements, but we do do
@font-face
CM: maybe we can drop top-level <font-face>, but keep it as a
child for <font> for implementations that do SVG Fonts
RESOLUTION: SVG2 will drop support for top-level <font-face> in
favour of @font-face, but keep <font-face> child of <font> for
SVG Fonts
<scribe> ACTION: Chris to remove support for top-level
<font-face> for external font referencing support [recorded in
[70]http://www.w3.org/2012/07/24-svg-minutes.html#action06]
<trackbot> Created ACTION-3329 - Remove support for top-level
<font-face> for external font referencing support [on Chris
Lilley - due 2012-08-01].
Doug: we haven't discussed: html has <!DOCTYPE> as a switch
CM: rewritten section in color chapter
[71]https://svgwg.org/svg2-draft/color.html
[71] https://svgwg.org/svg2-draft/color.html
[72]https://svgwg.org/svg2-draft/color.html#ColorProperty
[72] https://svgwg.org/svg2-draft/color.html#ColorProperty
CM: that's to remove the definition of color in SVG
… is it too much removed?
CL: for white-space I still included the blue property
definition table, but pointed to the other spec for the
definitions of the values
… the property table is fairly concise
… also our table has whether the property is animatable, which
the css one doesn't
… so I'm tending to say to include the property definition
table
<scribe> ACTION: Cameron to add back property definition tables
[recorded in
[73]http://www.w3.org/2012/07/24-svg-minutes.html#action07]
<trackbot> Created ACTION-3331 - Add back property definition
tables [on Cameron McCormack - due 2012-08-01].
[74]https://svgwg.org/svg2-draft/pservers.html#MeshGradients
[74] https://svgwg.org/svg2-draft/pservers.html#MeshGradients
CM: Tav's gradient mesh work
[75]https://svgwg.org/svg2-draft/masking.html#MaskElementMaskTy
peAttribute
[75]
https://svgwg.org/svg2-draft/masking.html#MaskElementMaskTypeAttribute
CM: Brian's maskType attribute addition
BB: I haven't marked it yellow yet
… I reworked parts of the introduction as well
… but I'm yet to add things about referencing mask elements
CM: but ok to publish?
BB: yes
CL: Tuesday 21st August for publication?
CM: sounds ok
[76]https://svgwg.org/svg2-draft/filters.html
[76] https://svgwg.org/svg2-draft/filters.html
CL: what about compositing?
<ed>
[77]http://www.w3.org/TR/SVG11/render.html#ParentCompositing
[77] http://www.w3.org/TR/SVG11/render.html#ParentCompositing
… we need to review chapter 14 whether we can remove things in
favour of the compositing chapter
… we need a resolution to publish compositing
RESOLUTION: SVG WG agrees with publishing the Compositing spec
<scribe> ACTION: Nikos to add notes to SVG2 referencing
Compositing, and remove any duplicated text if that can be done
before publication [recorded in
[78]http://www.w3.org/2012/07/24-svg-minutes.html#action08]
<trackbot> Created ACTION-3332 - Add notes to SVG2 referencing
Compositing, and remove any duplicated text if that can be done
before publication [on Nikos Andronikos - due 2012-08-01].
[79]https://svgwg.org/svg2-draft/masking.html#ObjectAndGroupOpa
cityProperties
[79]
https://svgwg.org/svg2-draft/masking.html#ObjectAndGroupOpacityProperties
[80]https://svgwg.org/svg2-draft/script.html
[80] https://svgwg.org/svg2-draft/script.html
CM: I removed contentScriptType and contentStyleType
[81]https://svgwg.org/svg2-draft/animate.html#Introduction
[81] https://svgwg.org/svg2-draft/animate.html#Introduction
CL: do we still want to point to web animations instead of SMIL
here?
BB: I want to drop the whole chapter and reference Web
Animations specs
CM: also I removed all mention of DTDs
RESOLUTION: We will publish SVG2 FPWD mid August
<scribe> ACTION: Cameron to remove eRR from SVG2 [recorded in
[82]http://www.w3.org/2012/07/24-svg-minutes.html#action09]
<trackbot> Created ACTION-3333 - Remove eRR from SVG2 [on
Cameron McCormack - due 2012-08-01].
<Cyril>
[83]http://lists.w3.org/Archives/Public/public-whatwg-archive/2
012Jul/0152.html
[83]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0152.html
<scribe> ACTION: Cameron to define "default object size" so
that css3-images <image> works for SVG paints [recorded in
[84]http://www.w3.org/2012/07/24-svg-minutes.html#action10]
<trackbot> Created ACTION-3334 - Define "default object size"
so that css3-images <image> works for SVG paints [on Cameron
McCormack - due 2012-08-01].
<TabAtkins_>
[85]http://dev.w3.org/csswg/css3-images/#default-object-size
[85] http://dev.w3.org/csswg/css3-images/#default-object-size
ACTION-3344:
[86]http://dev.w3.org/csswg/css3-images/#default-object-size
[86] http://dev.w3.org/csswg/css3-images/#default-object-size
<trackbot> Sorry... adding notes to ACTION-3344 failed, please
let sysreq know about it
<TabAtkins_> heycam, you also need to add <image> to the
definition of <paint>.
right
<krit> heycam: If you need something, ping me at any time
<scribe> ACTION: Cameron to work out whether to add a new repo
for all new modules, or a new repo for each [recorded in
[87]http://www.w3.org/2012/07/24-svg-minutes.html#action11]
<trackbot> Created ACTION-3335 - Work out whether to add a new
repo for all new modules, or a new repo for each [on Cameron
McCormack - due 2012-08-01].
<krit> heycam: wait
<krit> 1406@137.194.5.208
<krit> heycam: --^
SVG/HTML integration
BB: I don't have anything to sa
s/sa/say
… where are we up to?
… at hamburg we talked about both including HTML elements in
SVG directly, without having to wrap them in <foreignObject>
… and we also talked about the opposite direction, including
SVG elements directly in HTML without wrapping them in <svg>
… I was just wondering what the next step is there, because I
think it sounds good
… is this something we should be pushing for? does it have any
connection svg2?
… how can we drive it forward?
Doug: make an experimental implementation
… that will help point out flaws
BB: I agree that sounds good
<krit> shepazu: in JS? :D
… just curious if people think that this would never happen
<krit> heycam: It will happen
TA: henri is against it
<krit> heycam: might take till next year :)
… the svg wg didn't want an explicit list for the parser
Doug: SVG Integration was meant to have that list
… we didn't want HTML5 to white list what SVG elements are
allowed
Doug: but i would be happy with whitelisting the svg2 elements
for now
TA: there are four conflicting elements
… style, script, a, font
<ChrisL> a is changing to a href
<ChrisL> the other difference is svg a can next
CL: SVG's <a> can nest, but HTML's doesn't
CM: I think that is just enforced by the parser
… the behaviour is still defined though because you can do it
in teh dom
s/teh/the/
Doug: I think it's not a big deal if in text/html you can't
nest them
TA: Hixie is against unifying SVG and HTML script, because SVG
script is sane and HTML is not
… but Henri argued for unifying
Doug: innerHTML and document.write aren't allowed in SVG script
<ChrisL> hooray
TA: several people are opposed to having chameleon HTML/SVG
namespaces
… the final element conflict is <font>
CM: I would fine with requiring wrapping <svg> around <font> if
that solves the problem
TA: I'm still not entirely sure why chameleon namespaces are
problematic
… on a related note, we have two element conflicts with MathML
… it's in semantic MathML which nobody implements
… <image> and <set>
<ChrisL> where 'nobody' means 'no browsers, jst mathematical
software'
BB: seems like most people are generally in favour of that
direction
TA: Hixie's largest argument against embedding SVG directly in
HTML, is that embedding a <rect> into a <p> doesn't gain you
much
… that might not be true if you are doing a path to do a star,
for example
… and if you are embedding a <g> you may as well embed an <svg>
<ChrisL> I agree with Hixie there (shock, horror)
CM: Brian's <mask> children would be good to support too
Dirk: it's just another thing for authors to learn
<birtles> Some single elements do give you quite a lot of
value, e.g. <animate>
JY: it is a bit strange to have to wrap say <filter>, but for
rendering things it's not as useful
Dirk: should these elements have a CSS layout box? I think they
should, but we don't have anything defined in the spec to
handle this
TA: if you have a <path> as a child of a flex box, what does
that do?
... for embedding HTML in SVG I can write that up, that's easy
… embedding SVG in HTML is more controversial
… we need to convince hsivonen, dbaron and maybe abarth
… and have us all agree on what the correct solution for this
problem is
… I will work on the proposal for HTML in SVG
BB: maybe we can just allow <mask>, etc. as children in HTML
JY: there's also the question of whether people would put that
directly in their document, or reference an external file
TA: being able to reduce external requests is a nice thing
ED: there are some complications, percentages depending on the
viewport
… if a mask has a maskWidth="50%" what do you resolve that
against
… solvable of course but not defined
Dirk: we have that in filters too, we use the bounding client
rect of the element
<ed> s/maskWidth/mask @width/
<ed>
[88]http://www.w3.org/TR/SVG11/masking.html#MaskElementWidthAtt
ribute
[88] http://www.w3.org/TR/SVG11/masking.html#MaskElementWidthAttribute
BB: depends on maskUnits, whether it resolves against the thing
being masked or the viewport the <mask> element is in
ED: what if you have <mask> with text inside?
TA: you can just put display:none on it
... I will look at the selected SVG elements in HTML too
SVG DOM improvements
TA: how do we improve the SVG DOM without a big red switch?
CM: we are a bit limited in the improvements we can do without
a big switch
Dirk: with turning every attribute into a property, do we still
need the SVG DOM?
TA: a lot of the benefit disappears when you can the CSS OM
rect.x.px += 20
CM: that is no worse than using CSS OM
TA: in CSS OM it would convert it into the current unit you're
using
… if you are using percentages, and you add 20px, it would
convert the result into %
… if throwing the CSS OM on top lets us ignore animVal/baseVal,
that would be good
CM: should I just write up a concrete proposal for the x.px
thing?
CL: yes
BB: this is not going to help with say path interfaces, so we
definitely need something there and can't rely on CSS OM
<scribe> ACTION: Cameron to propose SVGAnimatedLength
improvements [recorded in
[89]http://www.w3.org/2012/07/24-svg-minutes.html#action12]
<trackbot> Created ACTION-3336 - Propose SVGAnimatedLength
improvements [on Cameron McCormack - due 2012-08-01].
<TabAtkins_> ScribeNick: TabAtkins_
heycam: We've decided we're meeting just after svgopen - the
mon-wed directly afterards. Sep 17-19.
... Andreas asked if we want to meet something in the mountains
rather than the svgopen conference venue.
SVGOpen F2F meeting
krit: I have to leave at noon on wednesday.
heycam: But that means you'll miss all of wednesday anyway.
... Continuing, andreas says there are hotels in the mountains
with meeting rooms we can use.
<heycam> Schuders
heycam: And there is one place, Schuders, that is a 2hr train
ride from Zurich.
Cyril: My parents are an hour or two away from Zurish, so I was
planning on commuting from them sometimes.
heycam: Prices are between $50 and $75 swiss franks, which
includes breakfast.
shepazu: The frank is about 1-1 with the dollar, so that's
cheap and beautiful.
<heycam> www.postschuders.ch
<ChrisL> looks like a fun place
<ChrisL> i won't be hiking anywhere though
Cyril: Let's get Tav's opinion as well.
ChrisL: We can still decide now.
<heycam> RESOLUTION: We will meet at Andreas's suggested Swiss
mountain town.
<heycam> ACTION: Cameron to set up a wbs for SVG Open F2F and
let Andreas know [recorded in
[90]http://www.w3.org/2012/07/24-svg-minutes.html#action13]
<trackbot> Created ACTION-3337 - Set up a wbs for SVG Open F2F
and let Andreas know [on Cameron McCormack - due 2012-08-01].
ed: Any plans for the next meeting after that?
Cyril: I can offer Paris any time.
heycam: you don't want to go to australia or nz?
Cyril: That would be fine too. ^_^
heycam: Okay, so we get Alex Danilo to arrange it for us.
nikos: Or maybe Canon.
Cyril: So, dates? Sometime in January?
... week starting with the 21st is no good for me.
... Conflicting meeting.
<ed> feb 4 - 8, 2013
<heycam> january 14 - 17 is better
<heycam> RESOLUTION: We will meet January 14 - 17, 2013 in
Sydney.
<heycam> good idea to meet with CSS in Tokyo in April which it
sounds like they might be
<ed> trackbot, make minutes
<trackbot> Sorry, ed, I don't understand 'trackbot, make
minutes'. Please refer to
[91]http://www.w3.org/2005/06/tracker/irc for help
[91] http://www.w3.org/2005/06/tracker/irc
Summary of Action Items
[NEW] ACTION: brian birtles to write up a proposal for view-box
property for SVG [recorded in
[92]http://www.w3.org/2012/07/24-svg-minutes.html#action04]
[NEW] ACTION: Cameron to add back property definition tables
[recorded in
[93]http://www.w3.org/2012/07/24-svg-minutes.html#action07]
[NEW] ACTION: Cameron to define "default object size" so that
css3-images <image> works for SVG paints [recorded in
[94]http://www.w3.org/2012/07/24-svg-minutes.html#action10]
[NEW] ACTION: Cameron to do all this interface stuff
(Proposals/IDL interface reorganization) [recorded in
[95]http://www.w3.org/2012/07/24-svg-minutes.html#action02]
[NEW] ACTION: Cameron to propose SVGAnimatedLength improvements
[recorded in
[96]http://www.w3.org/2012/07/24-svg-minutes.html#action12]
[NEW] ACTION: Cameron to remove eRR from SVG2 [recorded in
[97]http://www.w3.org/2012/07/24-svg-minutes.html#action09]
[NEW] ACTION: Cameron to set up a wbs for SVG Open F2F and let
Andreas know [recorded in
[98]http://www.w3.org/2012/07/24-svg-minutes.html#action13]
[NEW] ACTION: Cameron to work out whether to add a new repo for
all new modules, or a new repo for each [recorded in
[99]http://www.w3.org/2012/07/24-svg-minutes.html#action11]
[NEW] ACTION: Chris to remove support for top-level <font-face>
for external font referencing support [recorded in
[100]http://www.w3.org/2012/07/24-svg-minutes.html#action06]
[NEW] ACTION: ChrisL to work out things on removing XML ns
stuff on text and figure things out with the CSS WG [recorded
in [101]http://www.w3.org/2012/07/24-svg-minutes.html#action01]
[NEW] ACTION: Erik to add the drag & drop functionality to SVG2
[recorded in
[102]http://www.w3.org/2012/07/24-svg-minutes.html#action05]
[NEW] ACTION: Nikos to add notes to SVG2 referencing
Compositing, and remove any duplicated text if that can be done
before publication [recorded in
[103]http://www.w3.org/2012/07/24-svg-minutes.html#action08]
[NEW] ACTION: Tab Atkins to take HTML and Iframe view-box
property to the CSS working group [recorded in
[104]http://www.w3.org/2012/07/24-svg-minutes.html#action03]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [105]scribe.perl version
1.136 ([106]CVS log)
$Date: 2012/07/25 21:10:19 $
__________________________________________________________
[105] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[106] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [107]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[107] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/pint/paint/
Succeeded: s/this markers/these markers/
Succeeded: s/specify relative/specify a clipping path relative/
Succeeded: s/pth/path/
Succeeded: s/DS: so/DirkS: so/
Succeeded: s/questions/question/
Succeeded: s/would be 200/would be 100/
Succeeded: s/at 100/at 200/
Succeeded: s/middle/none/
Succeeded: s/surouned/surrounded/
Succeeded: s/edded/edited/
FAILED: s/RESOLUTION: textPath must not surouned by text element anymore
./RESOLUTION: textPath not needed to be surrounded by text element anymo
re./
Succeeded: s/RESOLUTION: textPath must not surouned by text element anym
ore./RESOLUTION: textPath not needed to be surrounded by text element an
ymore./
Succeeded: s/coast/cost/
WARNING: Bad s/// command: s/word breaking/collapsing/ ?
Succeeded: s/it doesn't see much use/Opera implements it, but eRR isn't
used much/
FAILED: s/filtes/files/
Succeeded: s/DS/Doug/
Succeeded: s/inherit/fill:inherit/
FAILED: s/aray/ray/
FAILED: s/cascading/cascading or recursion/
Succeeded: s/CC/RC/
FAILED: s/for rendering it doesn't matter if BR is specified or not, it
should produce an identical rendering result//
FAILED: s/whether it's there or not doesn't make a difference/for render
ing it doesn't matter if BR is specified or not, it should produce an id
entical rendering result/
FAILED: s/SVG <image> will allow declarative or frame-based animated ima
ges/SVG <image> will allow declarative or frame-based animated images, b
ut not scripted animations/
FAILED: s/ED/Doug/
FAILED: s/… I don't think this helps with the problem of getting mouse e
vent coordinates in the right coordinate space/Doug: I don't think this
helps with the problem of getting mouse event coordinates in the right c
oordinate space/
FAILED: s/think so/think so, they will likely be at CR by the time we ge
t to CR/
FAILED: s/tine/tiny/
FAILED: s/sa/say/
FAILED: s/teh/the/
FAILED: s/maskWidth/mask @width/
Found ScribeNick: birtles
Found ScribeNick: ChrisL
Found ScribeNick: birtles
Found ScribeNick: krit
Found ScribeNick: cabanier
WARNING: No scribe lines found matching ScribeNick pattern: <cabanier> .
..
Found ScribeNick: ChrisL
Found ScribeNick: cabanier
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
Inferring Scribes: birtles, ChrisL, krit, cabanier, heycam, TabAtkins_
Scribes: birtles, ChrisL, krit, cabanier, heycam, TabAtkins_
ScribeNicks: birtles, ChrisL, krit, cabanier, heycam, TabAtkins_
WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa Tav mdyck TimMills
New list: +1.206.675.aaaa Tav
Default Present: +1.206.675.aaaa, Tav
Present: +1.206.675.aaaa Tav
WARNING: Fewer than 3 people found for Present list!
Agenda: [108]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_20
12/Agenda#Agenda
Found Date: 24 Jul 2012
Guessing minutes URL: [109]http://www.w3.org/2012/07/24-svg-minutes.html
People with action items: atkins birtles brian cameron chris chrisl erik
nikos tab
[108]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
[109] http://www.w3.org/2012/07/24-svg-minutes.html
End of [110]scribe.perl diagnostic output]
[110] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 25 July 2012 21:16:43 UTC