- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 18 Sep 2012 18:25:17 +0200
- To: SVG WG <public-svg-wg@w3.org>
http://www.w3.org/2012/09/18-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
18 Sep 2012
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda
Attendees
Present
Cameron, Doug, Chris, Cyril, Erik, Tab, Nikos,
Takagi-san, Konno-san, Brian, Dirk, Rik
Regrets
Chair
erik
Scribe
Cyril Concolato, Cyril
Contents
* [3]Topics
1. [4]mask-box-image, mask-image, clip-path: <shape>,
apply on obb?
2. [5]New value names -moz-objectFill, -moz-objectStroke,
-moz-objectValue (for
stroke-{dash{array,offset},width})
3. [6]Connectors
4. [7]Stars
5. [8]Dynamic document loading
6. [9]zooming and panning
7. [10]performances to transition in zooming and panning
8. [11]Mapping applications issues
9. [12]SVG2 fallback for modules that are behind.
10. [13]Moving the spec to git/github
11. [14]Change appendixes
12. [15]Next f2f meeting
13. [16]What to do with xml:base?
14. [17]What do do with version and baseProfile?
15. [18]What about xml:lang and lang?
16. [19]svg:transform
17. [20]<animateColor>
* [21]Summary of Action Items
__________________________________________________________
<heycam> trackbot, start telcon
<trackbot> Date: 18 September 2012
<heycam> Zakim: remind me in 8 hours to enjoy the view
<birtles> scribenick: birtles
mask-box-image, mask-image, clip-path: <shape>, apply on obb?
<krit>
[22]http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#
mask-box-image
[22]
http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-box-image
krit: we need to define what the border-box is
... we did it yesterday for mask-image and I'd like to do the
same here
... it's so we can do tiling
ChrisL: how does this apply to SVG?
... we don't have borders
TabAtkins: we have decorated bounding boxes which map to
borders
krit: it's mainly used for images
... to add a border
ChrisL: so why not add it just to images
shepazu: stroke would be enough for that
krit: everything inside the border box is affected by the
border box
heycam: do mask-image and border-box cover the same region
krit: yes, but they allow you to specify the mask differently
ChrisL: then I agree it should apply to the painted box
cabanier: why is this not a property on a mask image?
ChrisL: because it's constructing an image from a mask image
... this controls the way it scales
cabanier: why don't you just say, mask-image, "9 slice"?
... is this just to copy what CSS does?
krit: yes
RESOLUTION: mask-box-image works on the decorated bounding box
next, is clip-path: <shape>
<krit>
[23]http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#
the-clip-path
[23]
http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-clip-path
krit: we have new shapes, borrowed from CSS exclusions
... ellipse, etc.
... the problem is they can use percentages
... we need to resolve what they resolve against
heycam: normally it would be against the clipPath element but
you don't have that here
krit: that's right
heycam: in CSS it's just resolved against the containing block
krit: the problem is if you use the geometric bounding box
you'll lose half the stroke
heycam: that's also the case with objectBoundingBox units on
the clipPath element
... you can use negative percentages etc. to work around it
... if we decided clip-path always meant geometric bounding box
(like objectBoundingBox) then you could still use negative
percentages there too
... just like with the clipPath element
... that said, I don't like that
... because you don't know exactly how much you need to extend
the box
... e.g. -10% may or may not be enough
cabanier: so you can apply this to SVG?
krit: yes, that's right
heycam: for mask etc. we've decided to use the painted bounding
box right?
krit: yes
... the painted bbox may differ slightly between platforms due
to how stroking is calculated
heycam: I think there are three options
... (a) geometric bbox for consistency with objectBoundingBox
... (b) is painted bbox for consistency with masking
... (c) make it controllable
krit: for masking it's already (c)
... there's the mask-size and mask-origin properties
... mask-clip and mask-origin actually
heycam: it looks like mask-clip can do the clipping and the
percentage values differently
... i.e. clip to one box and have percentages relative to
another box
... mask-clip says which box to clip to
krit: mask-origin just says which of the boxes defines the
origin
... border-box is the painted area and content-box is the bbox
heycam: the mask properties seem to allow you to control these
two things (clipping box and origin) separately
... but SVG doesn't allow that
... for mask it's controllable
... but for clip-path is doesn't need to be controllable?
krit: yes
... we need to decide which box to use
ed: clip paths are always geometrical
... in SVG
heycam: if we make this like objectBoundingBox (geometric) then
it's like SVG
ed: clip paths are always just a shape
krit: the geometric bbox is probably more predictable for users
heycam: why isn't that always the case for mask
krit: well we already have those properties for mask
heycam: why is it useful for masks to have this control but not
clip paths?
krit: the mask properties are just there because they already
exist
heycam: is it useful
krit: for HTML, it seems to
cabanier: so should we add this to clip path too?
krit: so we'd need to clip-path-clip?
cabanier: instead of duplicating everything why don't we align
mask and clip so you just make a mask that does a hard clip?
heycam: I think we've discussed changing the SVG unit selection
to allow using the stroked bbox
... so it might be useful to introduce this control to SVG too
krit: we could add another property to specify the box for clip
paths
... but HTML also might want to clip away overflow
heycam: overflow: hidden?
krit: not sure you always want that
heycam: if we use percentage values for the shape then it's
similar to using objectBoundingBox
... but if you use regular lengths it's like userSpaceOnUse but
translated to the top-left of the bounding box
... do you disagree that clip path should have more control
TabAtkins: if it's just for percentages I don't care
heycam: but people will use lengths too
krit: right
... the clip path element has no hard clipping area unlike
masks
heycam: because there's no clip-path-clip property?
krit: right
heycam: clip-path-clip is a bit weird...
... you need to do geometry operations to combine the clip
rectangle with the clip path
krit: or you just do two clips
heycam: what is the default for mask... which box?
krit: border-box (paint area)
heycam: I think it would be good to have clip default to tht
... and maybe have control
krit: I'll add an issue for that
ed: I think that's reasonable
... probably what you want most of the time is the stroked bbox
heycam: I'm not exactly sure
... it might be ok for percentages
... but once you have strokes and lengths it might actually be
harder to use
cabanier: I think so too
krit: so objectBoundingBox might actually make sense with the
negative percentages
heycam: but then doesn't that apply to masks too?
krit: yes, but that's already there
heycam: I'm happy for this to be an issue in the spec
... but I would err on the side of consistency with mask (i.e.
painted bbox)
... the ability to control this would also probably be good
cabanier: also, you can stroke within a mask
... but if you do clipping, you can't stroke the clip path
contents
<scribe> ACTION: Dirk to add an issue to CSS masking about
which bounding box to use for percentages in clip-path shape
definitions [recorded in
[24]http://www.w3.org/2012/09/18-svg-minutes.html#action01]
<trackbot> Created ACTION-3362 - Add an issue to CSS masking
about which bounding box to use for percentages in clip-path
shape definitions [on Dirk Schulze - due 2012-09-25].
ed: going back to mask-box-image
... what if you wanted to do a filter
... that wouldn't be included in the decorated bbox
... it would be nice to slice up a filtered image
... e.g. a drop shadow
krit: but we have the issue we're not able to calculate the
filtered bbox
cabanier: if you use the shorthand you should know
krit: but some a potentially infinite
cabanier: in *some* cases you will know
krit: but in general, we don't
cabanier: for shorthands you should know
krit: is that defined?
cabanier: if not, perhaps it should be
krit: but for SVG filters it's not defined
... the filter region must be defined by the user
... and in many examples the filter region ends up being
equivalent to the viewbox size
ed: for us, internally we can calculate the filtered bbox
krit: but the lighting effect is still infinite
... but you clip it to viewbox
... also feTile etc. is infinite
ed: you could use the filter region
... I think the most common case is when you use a shadow
... people will often run into the problem when their shadow is
clipped away
krit: mask-clip and mask-origin would need a new keyword to use
the filter region
... this needs to be checked with the CSS WG as well
cabanier: if you do a text shadow is it defined how big it is
krit: the region is not defined
cabanier: it would be useful there as well
... since you don't want to clip that shadow either
krit: what's the order, masking then clipping?
... it matters if you're depending on the size of the bounding
box
cabanier: you can always work around it
... by adding an extra <div> or <g>
krit: yes, so what's more intuitive for the author
... if we add a keyword for the filter region
... then at least the user would know they need to set the
filter region correctly
ed: I think that would be ok
krit: how do you define the filter region for shorthands?
... we can discuss that later
... let's discuss it on the mailing list
<scribe> ACTION: Erik to send a mail to a suitable mailing list
about defining the filter region for filter shorthands (so we
can define masks to include the filtered result) [recorded in
[25]http://www.w3.org/2012/09/18-svg-minutes.html#action02]
<trackbot> Created ACTION-3363 - Send a mail to a suitable
mailing list about defining the filter region for filter
shorthands (so we can define masks to include the filtered
result) [on Erik Dahlström - due 2012-09-25].
New value names -moz-objectFill, -moz-objectStroke, -moz-objectValue
(for stroke-{dash{array,offset},width})
heycam: as part of the SVG in OpenType work
... Edwin has added these new prefixed values which are similar
to those Chris previous proposed
... -moz-objectFill and -moz-objectStroke are the same as
useFillPaint and useFillStroke
krit: why are they prefixed?
... they're just keywords
heycam: actually, they might not be prefixed since they're
behind a pref
(discussion about prefixing policy)
heycam: in any case, no one's using this feature yet but we
need to settle on the names
cyril: these keywords were proposed for markers right?
heycam: yes, but they're not actually implemented there yet
... for now they have been implemented for SVG in OpenType
<ChrisL> huh -
[26]http://lists.w3.org/Archives/Public/www-svg/2007Jun/0006.ht
ml
[26] http://lists.w3.org/Archives/Public/www-svg/2007Jun/0006.html
<Tav>
[27]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_eff
ects
[27] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects
[28]https://dl.dropbox.com/u/11894343/svg-wg/2012-06-28-111316_
1920x1080_scrot.png
[28]
https://dl.dropbox.com/u/11894343/svg-wg/2012-06-28-111316_1920x1080_scrot.png
(Cameron shows demo of SVG in OpenType in Firefox Nightly)
<heycam>
[29]http://people.mozilla.org/~cmccormack/temp/svg-glyph-basic.
svg
[29] http://people.mozilla.org/~cmccormack/temp/svg-glyph-basic.svg
<heycam>
[30]http://people.mozilla.org/~cmccormack/temp/smiley.svg
[30] http://people.mozilla.org/~cmccormack/temp/smiley.svg
ChrisL: I like currentFill and currentStroke from vector
effects
<ChrisL>
[31]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_eff
ects
[31] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects
ChrisL: but I don't like the names useCurrentFill and
useCurrentStroke
... and I find objectFill and objectStroke confusing
nikos: what about contextFill and contextStroke?
ChrisL: I like that
heycam: not bad
... or referencedFill / referencedStroke
... but which direction is the reference?
shepazu: I don't mind 'auto', i.e. takes the fill if used on
the fill
... I like context
heycam: what about contextValue
... imagine text has a stroke on it
... and you want to use that stroke on a circle in your
glyph/marker etc.
... you can't just use, e.g. the context stroke width there
since it's a different coordinate system
... it automatically adjusts the stroke-width, dash array etc.
to match the target coordinate system
ChrisL: it auto scales the values by the ratio of the two
coordinate systems
Tav: if I have two different size chars, e.g. super script etc.
... what happens to the width?
ChrisL: nothing
... the scaling should be the same for all glyphs as they are
defined on the same glyph coordinate system (em square)
... if you're faking small caps, superscript etc. but applying
a transform you'll have problems
... but that sort of approach is going away in favor of doing
it corectly tith opentypefeatures, see CSS3 Fonts
krit: if you have a pattern, can elements inside the pattern
use these keywords too
... which context will it reference?
heycam: the element which references the pattern
... it means if you implement patterns using bitmaps you may
need to generate different pattern bitmaps based on where it is
used
krit: imagine you have a chain of patterns where the elements
of a pattern references another pattern
... which context do you use in the nested context?
shepazu: it goes to the parent
... whichever is the least number of hops
... or whatever doesn't lead to infinite loops
ChrisL: if you limit it to one level, i.e. the pattern level,
then you could still do longer chaining by setting <pattern
fill="contextFill">
<ChrisL> resolved: change use* values to context*
Cyril: what do these values mean outside of a referencing
context?
ChrisL: if there isn't a context, contextFill means
currentFillPaint?
heycam: well, currentFillPaint means the fill on this element
itself
ChrisL: you want to be able to swap the values over without
having infinite recursion
heycam: and that only works if you look to the parent
ChrisL: I originally added the "paint" to the end of the
keyword to clarify that it is actually a paint and not just a
color
birtles: also contextStroke sounds like it includes the stroke
width, dash array etc, but contextStrokePaint is clear that
it's just the paint server
heycam: also I forgot to mention there's also
-moz-objectFillOpacity, -moz-objectStrokeOpacity so you can
swap them as well
<scribe> ACTION: ChrisL to write up contextFill(Paint),
contextStroke(Paint) proposal in coordination with Cameron
[recorded in
[32]http://www.w3.org/2012/09/18-svg-minutes.html#action03]
<trackbot> Created ACTION-3364 - Write up contextFill(Paint),
contextStroke(Paint) proposal in coordination with Cameron [on
Chris Lilley - due 2012-09-25].
heycam: one reason to prefer contextFill over contextFillPaint
(i.e. dropping the "paint" word) is that then the part after
"context" matches the corresponding property
ChrisL: I'm probably ok with that
heycam: also, as Doug mentioned should we use a camelCase name
or a css-like-name?
Tav: we already have currentColor
shepazu: we can alias it with current-color
ChrisL: yes, let's not follow the precedent of currentColor if
it's disliked
... let's put dashes in all of them
shepazu: Dash-All-The-Things!
<ChrisL> action-3364?
<trackbot> ACTION-3364 -- Chris Lilley to write up
contextFill(Paint), contextStroke(Paint) proposal in
coordination with Cameron -- due 2012-09-25 -- OPEN
<trackbot>
[33]http://www.w3.org/Graphics/SVG/WG/track/actions/3364
[33] http://www.w3.org/Graphics/SVG/WG/track/actions/3364
RESOLUTION: We will name the context keywords in CSS style and
without the paint keyword, e.g. context-fill,
context-fill-opacity, context-value etc.
<scribe> ACTION: Chris to propose the aliasing of current-color
to currentColor with the CSS WG [recorded in
[34]http://www.w3.org/2012/09/18-svg-minutes.html#action04]
<trackbot> Created ACTION-3365 - Propose the aliasing of
current-color to currentColor with the CSS WG [on Chris Lilley
- due 2012-09-25].
Cyril: we said fill="current-fill" is like inherit, isn't that
recursive?
heycam: I'm not sure about current-fill, only context-fill
... is current-fill valuable if we have context-fill?
Cyril: I think if we say context-fill and there's no
referencing happening then the context is the parent?
<ed> <rect fill="context-stroke" stroke="current-fill" />
heycam: if we can make context-fill meet the needs of
current-fill then we might not need both values
ChrisL: another reason I put "paint" on the end of the keywords
was to match the keywords in filters, e.g. FillPaint
Cyril: another question about context-value, why didn't you use
percentages in the first place?
... couldn't you meet the need with percentages?
heycam: percentages inside the glyph will be relative to the
glyph coordinate space which is 0 to 2000
... they don't get transformed into the coordinate space of the
referencing context
Cyril: if you say stroke="3" and the coordinate system has a
width of 300 and you want the stroke to be 1% right?
heycam: you don't choose the percentage inside the glyph
... that's the choice of the referencing context, not the font
author
... you don't inherit across documents
Cyril: the document coordinate space is 300 wide
... the width you want on the stroke is 3 pixels wide, i.e. 1%
... ok, I'll think about it
... the context-value goes across documents
... unlike inherit
... that needs to be noted
ed: can that apply to any value?
heycam: no, just fill and stroke properties
... hmm, and I suppose the context-fill-opacity and
context-stroke-opacity properties should also be allowed on the
opacity property (as not very comfortable just fill-opacity and
stroke-opacity)
... I'll look into the implementation in Gecko and see what it
currently does
<heycam> [35]https://github.com/edf825/SVG-OpenType-Utils --
scripts for inserting SVG documents as a table in the OpenType
font
[35] https://github.com/edf825/SVG-OpenType-Utils
<heycam> use the pyinsertsvg directory
-- break for 15mins --
<andreas> here is a nice astronomic clock from prague:
[36]http://drifted.in/horologium-app/
[36] http://drifted.in/horologium-app/
<Cyril> scribe: Cyril Concolato
Connectors
<Cyril> scribe: Cyril
<shepazu>
[37]http://dev.w3.org/SVG/modules/connector/SVGConnector.html
[37] http://dev.w3.org/SVG/modules/connector/SVGConnector.html
<scribe> scribeNick: Cyril
scribe-nick: Cyril
DS: if you're not familiar with the spec
<shepazu> [38]http://schepers.cc/w3c/svg/connector/
[38] http://schepers.cc/w3c/svg/connector/
DS: the connectors connect shapes
... even if sometimes the connector don't touch the shape
... there is a logic in the connection
... you can't figure out if it is connected or not
... I made a script library
... the idea is that we will add several attributes
... that can go on any rendering elements
... we would add one element
... 2 elements
... the SVG point element does not render
... the SVG connector element
... there was an idea on having the connector as an attribute
... going to center points, without path routing, is not
visually satisfactory for the user
... maybe we want to have connector points located on the shape
... the idea is to have SVG points define ports
... name it, and say that a line connects to this named port
... this is the basics of the connector proposal
... i don't think people will use it if there is no drawing
... later on if this is a successful, we could add routing
... but maybe this could be done with script
... for now it is only semantic
... as an author I want to define where the ports are
ed: how does it work when you animate the path
DS: this is not the perfect proposal
... if you are animating the shape, morphing, you'd have to
animate the ports too
ed: would it be useful to anchor them on top, bottom, left ...
ds: on rectangles yeah, but not on any shape
dirk: did you see the DIA library
... there are use cases where you want different type of
connectors
<ChrisL> [39]http://en.wikipedia.org/wiki/Dia_%28software%29
[39] http://en.wikipedia.org/wiki/Dia_%28software%29
nikos: what about using markers
tav: but we can't apply markers on rectangles
dirk: most people are fine if we define it only for paths
... there are details that can be improved
ds: with markers being child of elements, the marker is a good
modification
tav: you can define ports using percentages
cam: if you are changing it in one dimension, the percentages
will change
ds: I don't mind if we yoke markers
dirk: markers should just visualize points but not describe
points
tav: yes
ds: right now the point element is simply x,y
... we could adapt it to have smarter positing for markers
dirk: is there a drawing order
ds: marker, fill, stroke and then connectors
dirk: do you want to have it under the shape, above the shape
...
ds: we could use z-index
cl: I don't see why we need additional tools
... z-index and document order should be enough
tav: it would be nice to have an auto-path
ds: empty d or no d, it renders automatically
nikos: does it scale ?
ds: with auto yes, but when you remove auto, you'll have to
handle the rendering
<scribe> ACTION: Doug to work on event handling on connectors
[recorded in
[40]http://www.w3.org/2012/09/18-svg-minutes.html#action05]
<trackbot> Created ACTION-3366 - Work on event handling on
connectors [on Doug Schepers - due 2012-09-25].
heycam: I like the proposal a bit more
... but I'm worried with line routing
... straight lines is often not what you want
... but I'm not convinced that you want routing in the spec
... but if it would be easy for script to do the routing, I
would be convinced
cl: that's always been my main concern
... we should not have a routing algorithm
tav: inkscape implements connects
... it uses path with special attributes
... start object, and end object, and points on these objects
... there are a few routing hints
... go through, go round (like an exclusion)
... it's a path so it uses document order or z-indexing
... the scripting engine does the routing
ds: if we have an API, it would expose ports, type of ports,
connections on each port ...
... if the strings of the port and connectors match, they join
<ChrisL> [41]http://fritzing.org/news/new-autorouter/
[41] http://fritzing.org/news/new-autorouter/
ds: if in the future we decide to have routing, we could plug
in an algorithm
... via script
... but a little less complex that what I made
... or via CSS
... selecting via well define routing algorithms
... the rastereffect things could be used
... 90° angles with rounded corner
... you can also define points inside connectors
... the point can change
... you can have straight line or polylines
dirk: the rounded thing could go into a second level of the
spec
tav: you're propsing a new connector element
ds: yes
dirk: I think it would be better as attributes on the path
element
ds: there is something about that that bothers me
... it changes the way the path works
cl: it overloads the path too much for me
... I'm concerned that it messes up path
heycam: it you would want to do it, you could extend the path
syntax d="Shape1.port1 shape2.port1"
tav: what would browser most likely implement?
heycam: changing the path would not be sufficient to make the
semantics clear
ds: there is a question of API: connector API vs path API
... my specific proposal is: should I move forward or not?
... I studied all the major syntaxes for graphs
... you can describe all graphs
dirk: can you use symbol svg elements
heycam: I might be more amenable to the proposal if we could do
better port positioning
tav: you can use 'calc()'
ds: I struggled to have something good
... find use cases that it doesn't solve and I'll fix it
(brian's silence)
brian: is this part of SVG 2?
ds: perharps call it SVG 2 connectors as a separate spec
... a module
RESOLUTION: Connectors will be specified as a SVG 2 Connector
module
brian: so the primary benefit of this is the semantics?
ds: It is a new feature, unique to SVG, graphics and semantics
brian: there is already lots of things to do graphs
ds: yes, but this one brings semantics
... the original SVG proposal included connectors
... things like Visio and ODF said they couldn't use SVG
... there are graphics library that can't use SVG as an
interchange format
<scribe> ACTION: Doug to coordinate with Inkscape folks on
their connector stuff [recorded in
[42]http://www.w3.org/2012/09/18-svg-minutes.html#action06]
<trackbot> Created ACTION-3367 - Coordinate with Inkscape folks
on their connector stuff [on Doug Schepers - due 2012-09-25].
brian: I would like to explore the possibilities of this
... and I think the approach of saying in the future libraries
will handle routing is good
... but what are the parameters that will be needed
ds: I left this off, like strength of connections
... currently this could rely on the data attribute
<stakagi> I think that the logical road network of geographic
information has the almost same concept. Therefore, it may also
be one of the use cases.
ds: the things I've chosen are common to all graphs
heycam: the data thing is a good suggestion
Stars
ds: polygons are degenerated case of stars
<shepazu> [43]http://svg-whiz.com/svg/StarMaker.svg
[43] http://svg-whiz.com/svg/StarMaker.svg
ds: the example shows the different parameters that you can use
to tweak the stars
... these are useful for symbols
... it's a pain to draw from paths
... I'm fine using inkscape stars
... I just want to have a star primitive
<scribe> ACTION: Doug to work with Tav on the star proposal
[recorded in
[44]http://www.w3.org/2012/09/18-svg-minutes.html#action07]
<trackbot> Created ACTION-3368 - Work with Tav on the star
proposal [on Doug Schepers - due 2012-09-25].
ed: can we reuse the polygon element?
ds: this hasn't been fully explored
RESOLUTION: SVG 2 will the star element
<ChrisL> where polygon was changed to be like polyline:
[45]https://lists.w3.org/Archives/Member/w3c-svg-wg/1999AprJun/
0091.html
[45]
https://lists.w3.org/Archives/Member/w3c-svg-wg/1999AprJun/0091.html
heycam: sometimes you want to have a square marker and you have
to define many elements, it might be good to have marker
short-hand for simple shapes
lunch break!!!
<cabanier> scribenick: cabanier
opic: Dynamic document loading
Dynamic document loading
<ed>
[46]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Map
pingTopics#SVGTL_and_Dynamic_document_loading
[46]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics#SVGTL_and_Dynamic_document_loading
link:
[47]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Map
pingTopics
[47]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics
<ed>
[48]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/SVG
TL_and_DynamicDocumentLoading
[48]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/SVGTL_and_DynamicDocumentLoading
konno: we should read SVGTL and Dynamic document loading
wiki for dynamic document loading:
[49]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/SVG
TL_and_DynamicDocumentLoading
[49]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/SVGTL_and_DynamicDocumentLoading
Cyril: what is the global coordinate system?
... what is cascading tiling?
ChrisL: that is the image layering
... I dont see how the automatic fetching works
... in the previous you used the animation links, but now you
just point to it with some javascript
stakagi: we don't need javascript, but geo commity pointed out
this comment for submission
chrisl: I think it's important that you can point to a piece
... I don't like a system that relies on a huge webservice
since it's too heavy. I like the system where you have a bunch
of files on a filesystem
heycam: how do you generate the url from the tile and the zoom
level?
stakagi: the geomcommunity generate the url using script
... rather than doing that, the proposal is more generic
... you can set the url and generate the content automatically.
There is no fixed requirement to how they appear
heycam: instead of doing it ahead of time you can do it client
side?
ChrisL: I don't think so. the files are still stored on the
server
heycam: I don't know how much is generated and how much is in a
static file
stakagi: there was some feedback that everything is generated
by script but it's already to generate the tiles by script.
We're not revising the specification to be script based
... you just link to the iframe and it generates the links.
heycam: that seems the most flexible. If you want your own url
format, you can do it with script
Cyril: can someone summarize what is needed to be standardized
for the tiling part? It just seems like a guideline
birtles: I think we're coming to that
andreas: you have to parse everything to get to a certain zoom
level
... if I want to zoom into tokyou, how do I get the tokyo
tiles.
cabanier: is it because you always have to start completely
zoomed out?
andreas: yes
ChrisL: you can link to anywhere and continue down from there
birtles: how can you go back up?
ChrisL: ah, you can't. Unless you know how the URL are
constructed and then you can get back out
stakagi: you have to start from the way top if you want to go
back
ChrisL: it seems that every tile should have one that goes up
andreas: it seems like you don't want to start at the world.
Openstreet map and google have a way to do this
ChrisL: you read the documentation and find the url that gives
you the position.
... and then you could use upwards links so you can go to a
zoomed out tile
andreas: google maps has fixed tile size and this could allow
different tile sizes
Cyril: q-
ed: I see that there is an attribute 'externalResourceLoading'
for controlling when external things load, I assume this was on
the iframes
heycam: there is a feature where an image is loaded when the
user scrolls to it
ChrisL: this is in the spec
[50]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/SVG
TL_and_DynamicDocumentLoading#Dynamic_document_loading_accordin
g_to_LOD
[50]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/SVGTL_and_DynamicDocumentLoading#Dynamic_document_loading_according_to_LOD
externalResourceLoading =
"(onLoad|onVisible|inViewBox|inZoomRange)"
<andreas> here is a link describing the OSM?tiling scheme:
[51]http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames
[51] http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames
heycam: I'd rather see this in css
TabAtkins: we're trying to solve this case in HTML as well. My
proposal would be a little css to set this up
... the element has a callback that it wants to render. that
way you can do infinite scrolling without having the dom nodes
hanging around
... if you don't want it to garbage collect, you would hold on
to the reference yourself
ChrisL: there needs to be a mechanism to do that without the
user having to do that himself
TabAtkins: this allows compositted scrolling that is very
smooth but you do need fixed tilesizes
heycam: is it because you know the number of items
... how if you have different sizes per item
TabAtkins: you wouldn't know that
heycam: it seems that this is what is needed here
birtles: I think we need the declarative support as well.
ChrisL: you don't have the same problem here. ie like tumblr
because it's all one tree
TabAtkins: yes, it might not be an issue for this use case
andreas: I don't see a reason why there are different tile size
heycam: maybe because there are different system?
<stakagi> [52]http://svg2.mbsrv.net/devinfo/devstd/tiling/
[52] http://svg2.mbsrv.net/devinfo/devstd/tiling/
birtles: we think because they are different because of density
(ie a city vs an ocean)
stakagi: please look at the last picture
birtles: the file size is proportional to the complexity
TabAtkins: that is reasonable
andreas: in google maps they just have dummy tiles so they
don't download it over and over again
ed: what do we expect from this discussion?
konno: it would be sufficient to have a script api to do
dynamic loading
... would that be enough for maps as well?
birtles: no, I was discussing that
... two issues: performance and same origin restriction
heycam: if you have data from 2 different sites and 2 different
pyramids how do you combine them?
ChrisL: this is why you need a native implementation
(pointer-events, etc)
heycam: the issue with iframes and pointer events is a problem
ChrisL: yes
andreas: this is not something we can solve here
... in a workshop with experts who have already done this
ChrisL: the issue is that the mapping people will require
something that the implementors don't want to implement
heycam: I have feeling that there a 2 kind of mapping people:
the ones that want it all native and the ones that have already
done it through script
andreas: regarding the global coordinates system is the one
that google has, doesn't solve everything
... it is not possible to combine it with different projections
birtles: the main issues that we want to discuss is the level
of detail and the dynamic loading
... in seattle we thought we could do it with js or media
queries, but we want to see it done declaratively
... the iframe approach doesn't impact SVG very much
... the others topics we can discuss later
... we want to see iframe with recursive dynamic loading. A
declarative means to specify dynamic loading
... we don't have to figure out the specifics
ChrisL: can I ask Opera if it's reasonable to do this iframe
like approach with dynamic loading in SVG?
ed: yes, this sounds reasonable
birtles: maybe we can't even get it in html
ChrisL: I'd like to see some content up before we make a
proposal for HTML
birtles: we should flag the issue about pointer events
heycam: I think I sent an email about this
<heycam> [53]http://www.w3.org/mid/5050A664.1010005@mcc.id.au
[53] http://www.w3.org/mid/5050A664.1010005@mcc.id.au
<heycam>
[54]http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSe
p/0191.html
[54]
http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0191.html
<ChrisL> I'm reminded of
[55]http://www.w3.org/Graphics/ScalableReq.html where it says
"Levels of detail " - one of the few requirements SVG has yet
to meet
[55] http://www.w3.org/Graphics/ScalableReq.html
heycam: one thing I'm worried about is that it doesn;t give an
indication when you want to remove an object
... the browser can decide when things should be thrown away
but the app knows which ones will be reused
... if the user is scrolling rapidly or just moving around
TabAtkins: the quality is better if it is done in the browser
chrisl: the browser is in the best position to make that
decision
TabAtkins: I agree
ChrisL: do we have a resolution if this should go in SVG?
ed: I'd like to have this functionality
heycam: seems like a good idea
TabAtkins: HTML needs to be script based. In this case you have
everything you need so you know what need to be loaded/unloaded
resolution: Add an iframe-like element to SVG that includes
declarative support for dynamic loading
(… dialog on how pointer-event and iframes that go across
domains are potentially problematic)
<ed> s/I'd like to have this functionality/re the
functionality, everyone ok with allowing the content to
prevent/forbid the loading of the iframes data?
<scribe> ACTION: takagisan to write up a proposal for iframe
like syntax in SVG [recorded in
[56]http://www.w3.org/2012/09/18-svg-minutes.html#action08]
<trackbot> Sorry, couldn't find user - takagisan
<ed> s/I'd like to have this functionality/re the
functionality, everyone ok with allowing the content to prevent
or forbid the loading of the iframes data?
<ChrisL> trackbot, status
<scribe> ACTION: stakagi to write up a proposal for iframe like
syntax in SVG [recorded in
[57]http://www.w3.org/2012/09/18-svg-minutes.html#action09]
<trackbot> Created ACTION-3369 - Write up a proposal for iframe
like syntax in SVG [on Satoru Takagi - due 2012-09-25].
zooming and panning
<ed>
[58]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Map
pingTopics#Zooming_and_pannning
[58]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics#Zooming_and_pannning
ChrisL: in svg 1 we had this requirement but in the next
generation they all dropped it. and now you have it again
krit: zooming and panning should work
TabAtkins: it has issues with text selection
heycam: on mac, you can pinch zoom and tap
TabAtkins: gistures are intuitive to use
ChrisL: if you have it at all, it's like operating like an
etch-a-sketch
birtles: we had a discussion about things that don't scale
... was this written down
ChrisL: what are we aiming at in this section? is it : do you
expose pan and zoom somehow?
heycam: there is a difference between zooming the whole page
and just changing the viewbox
ChrisL: what is better here than the existing spec that
requires zoom and pan
heycam: we don't handle scrolling within the document
... for infinite scrolling situation, scroll bars are not
helpful
ChrisL: there are various ways of solving this problem
TabAtkins: overflow-style was supposed to solve this proble
<ChrisL> and its not clear we should costrain the browser how
it offers the functionality. Just that it must be offered
ed: opera already has this if you have a gesture device or
shortcuts with a mouse
TabAtkins: overflow-style tells you to do hidden, scroll bar or
pan
heycam: if we have elements that expose this, that would solve
this problem
birtles: is there still text zoom?
TabAtkins: most browsers are removing that and are doing full
page zoom
<ed> s/ opera already has this/ opera (mac, android e.g)
support pinch-zooming and so on
TabAtkins: this is done because layout breaks if you just
change the size of the text
birtles: I'm worried about accessibility here
TabAtkins: I'm unsure if this is something that the author can
reasonably control
heycam: I mentioned to ed that overflow-style would be nice on
SVG elements
resolution: having something like overflow-style to control
panning and zooming
<heycam> … on <svg> and maybe other viewport establishing
elements
<heycam> … and the ability to specify the valid range that you
can scroll/pan to (not just the bounding box of the content)
<ed> ACTION: heycam to write up a proposal for overflow and
panning [recorded in
[59]http://www.w3.org/2012/09/18-svg-minutes.html#action10]
<trackbot> Created ACTION-3370 - Write up a proposal for
overflow and panning [on Cameron McCormack - due 2012-09-25].
performances to transition in zooming and panning
[60]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Map
pingTopics#Performances_for_transition_in_zooming_and_panning
[60]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics#Performances_for_transition_in_zooming_and_panning
birtles: what you see when you do a quick zoom
... it's an issue for the browser
heycam: is it when you zoom into a tile but it hasnt come in
yet.
birtles: there is a concern that this is too heavy
heycam: this seems like a quality of implementation
... this happen on firefox for mobile where you see the zoomed
in vector
birtles: the desire is for an API to draw to a bitmap
... I follow up with takagi
<birtles> s/API to draw a bitmap/API to get a rasterized
version of vector graphics/
<scribe> ACTION: birtles to follow up with takagisan on what
exactly is needed to get the bitmap [recorded in
[61]http://www.w3.org/2012/09/18-svg-minutes.html#action11]
<trackbot> Created ACTION-3371 - Follow up with takagisan on
what exactly is needed to get the bitmap [on Brian Birtles -
due 2012-09-25].
<scribe> ACTION: andreas to organize a workshop on mapping
issues [recorded in
[62]http://www.w3.org/2012/09/18-svg-minutes.html#action12]
<trackbot> Sorry, couldn't find user - andreas
<birtles> Please see the use cases for non-scaling objects
described here:
[63]http://svg2.mbsrv.net/devinfo/devstd/non-scaling_objects/in
dex.html
[63]
http://svg2.mbsrv.net/devinfo/devstd/non-scaling_objects/index.html
<ed> -- 15 min break --
<birtles> We noted that Chris has the action to write-up
non-scaling objects
<TabAtkins> ScribeNick: TabAtkins
Mapping applications issues
andreas: Showing a few issues with mapping, see if there are
solutions in existing tech.
... First is pointer-events.
... Want all the elements at a given point, not just the
uppermost one.
TabAtkins: I'm already pursuing that in my list of DOM
improvements - getElementsFromPoint, to augment
getElementFromPoint.
andreas: Next is contour line labelling. When you put a label
on a counter (text on a path), the naive method might make some
labels upside down.
... Or when maps are rotated.
... Would like some way of ensuring that the text is always
right-side up.
ChrisL: So if it rotates more than 90deg off the horizontal,
flip it over.
shepazu: The question is how configurable.
TabAtkins: Don't think it needs configuration.
Cyril: Sounds like adding the animateMotion rotate attribute to
textPath.
andreas: Next is rendering order for bridges. You want some
parts over, some parts under.
... I think this is solved by adding z-index already.
ChrisL: And splitting up the bridges into multiple paths.
shepazu: Returning to the previous topic, how exactly would
they be flipped?
TabAtkins: They fill the exact same space, just flipping
around.
andreas: Next issue - some dashing problems.
... [shows an example where you want to put markers on the
corners, but suppress them if the segment is too small]
<stakagi>
[64]http://svg2.mbsrv.net/devinfo/devstd/SkeletonFramesForMap.p
ng
[64] http://svg2.mbsrv.net/devinfo/devstd/SkeletonFramesForMap.png
andreas: Another - wanting dashes just in the center of
segments.
TabAtkins: That's solved by Cam's marker improvements.
ed: But it's nsot markers, it's dashes.
andreas: Can markers clip out sections?
heycam: We want to make that possible, but haven't gotten a
proposal we like yet.
andreas: Similar to previous one, suppress dashes on very small
segments, to maintain the "body" of the line.
... Same with some curves.
TabAtkins: This is theoretically doable automatically - just
look for path segments that are small relative to the dash
size, and don't draw the dashes if they're too small.
heycam: That works if each segment is a visible segment on the
path, but not if you're doing a smooth curve with lots of small
path segments.
TabAtkins: Maybe an addition to <path> that lets you manually
suppress dashes on a segment?
heycam: In the <path> children proposal, maybe an element or
attribute on the child that does that.
<ChrisL> The setback functionality from vector effects might
help here
andreas: Additionally, when having multiple paths joining
together, you don't want dashes at the join points, so you can
maintain the visual fact of the join.
<ChrisL>
[65]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVecto
rEffects.html#veSetback-element
[65]
http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html#veSetback-element
ChrisL: Would you want the ability to stroke multiple paths as
one, so you can get a continuous dash pattern?
... We might bea ble to do that with superpath stuff.
andreas: Another topic: variable stroke width.
heycam: We have proposals for that. Unsure of its status.
andreas: Another topic: markers that repeat from their point
and reduce in size. Used for some types of path indicators in
maps.
<stakagi> SkeletonFrames
<stakagi>
[66]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#Skeleton_frames
[66]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Skeleton_frames
heycam: With marker-pattern, you can set up custom sets of
repeated markers, if you're okay with lots of duplication in
the element.
... To get the size change, you'd need 20 different-sized
markers, though. Maybe a scale factor.
andreas: Another topic - varied markers on a single path.
Random, or at least unpredictable.
heycam: You can do that with jsut the marker-pattern property.
Just specify several markers, done.
andreas: next topic, randomness in fill patterns.
heycam: Tav had a proposal for doing that exactly - use another
fill pattern as a probabilistic tiling control.
[several people saying they liked the idea]
heycam: So you can get denser in some areas, etc.
andreas: Another topic - when hatching, you don't want the
hatch lines to be parallel to the shape borders.
TabAtkins: That's maybe doable automatically - do a quick
linear algebra weighting the solutions based on how close to
perpendicular they are to all the borders.
andreas: Another mapping issue - in maps, especially older
ones, rivers are hatched parallel to the flow direction, and go
around islands, etc.
[several people expressing doubt that can reasonably be done
automatically]
SVG2 fallback for modules that are behind.
krit: Some modules may lag behind. What do we do when we
reference these?
Tav: Just pull them out?
ChrisL: Then what to do with the blank spot? Put a marker in
there pointing out?
TabAtkins: Yeah, we can word things that are just informative
references in SVG2 Core, and the modules refer normatively back
to Core.
heycam: I think we don't need to worry about this, until and
unless we are trying to exit CR and depending on things that
are too low.
[general agreement]
Moving the spec to git/github
ChrisL: Becaues the thing holding us back is the fact that we
haven't moved the spec in the last 3 months. ^_^
heycam: It's non-trivial, too - we already have a bunch of
tools on the server.
ChrisL: Why would we want to do this?
TabAtkins: It's slightly easier to develop on Window with
github, because their client is great.
<birtles>
[67]http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_merc
urial_as_our_dvcs/
[67]
http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/
TabAtkins: But I'm fine with staying where we are.
krit: I see a benefit that it gets more transparent and easier
to follow.
... Our readers can also review and do typofixes, etc. as pull
requests.
shepazu: I'm opposed to using third-party services.
heycam: I like git better, but I'm reluctant to make more work
for myself.
RESOLUTION: Keep the repository on hg.
Change appendixes
heycam: Should we have both a "changes from the previous spec"
appendix and a "changes since SVG 1.1" appendix?
krit: I definitely want a "changes from 1.1" verisons.
heycam: And reviewers want changes from the last version.
shepazu: Different parties want different things.
heycam: Okay, I'll do both (in the same file).
ChrisL: Can we annotate the changes with classes or something
to say which version they're from, so the "changes since last
version" can be automatically generated from the "changes since
1.1" list.
heycam: Only problem is that I sometimes combine multiple
changes into a single item, and if you add another thing that
should be appended to that, you can't with that proposal.
... it'll be more verbose, but maybe not too bad.
ChrisL: Also, perhaps we can have a short-ish prose description
of the changes since 1.1 for normal people to read, while the
full changelist is still out there for lawyers.
Next f2f meeting
heycam: We'll have a meeting early next year in Sydney.
ChrisL: Weren't we moving that from Jan to Feb to accommodate
???
heycam: yeah.
<ed> ACTION: heycam to setup the classes for the SVG2 changes
appendix (to cover changes from 1.1 and the diff from previous
draft) [recorded in
[68]http://www.w3.org/2012/09/18-svg-minutes.html#action13]
<trackbot> Created ACTION-3372 - Setup the classes for the SVG2
changes appendix (to cover changes from 1.1 and the diff from
previous draft) [on Cameron McCormack - due 2012-09-25].
heycam: And we were colocating Japan with CSS in April or so -
they haven't nailed down dates yet.
Cyril: Do we have dates for february?
heycam: Not yet.
nikos_office: I thought that the CSS meeting was in June?
TabAtkins: Dunno.
ChrisL: So for the feb meeting, week starting Feb 4?
heycam: We won't have a proper meeting at TPAC.
ed: Maybe do 5 days, since it'll be a long time since this
meeting?
ChrisL: Maybe with a break in the middle - halfday on
Wednesday.
shepazu: John Allsopp arranged a public meeting last time we
met in Sydney, and I think it went well. We should arrange that
again.
[general agreement]
RESOLUTION: First SVG f2f of 2013 is the week starting Feb 4.
It will be 5 days long.
heycam: I think that John Daggett will propose meeting June 5-7
for CSS.
... So ours will be June 3-5, with the overlap day being FX
stuff and CSS stuff interesting for SVG.
... Anyone object to those dates?
... In terms of hosting, it sounded like Fujisawa-san was
interested in hosting.
... Or maybe Moz will have a larger office by then.
TabAtkins: Or G can do it.
heycam: We dont' need to decide hosting yet.
ed: I cant' say for sure whether the dates are good for me.
... But they're probably fine.
RESOLUTION: Contingent on CSSWG choosing June 5-7 as expected,
we'll meet June 3-5 in Tokyo.
What to do with xml:base?
heycam: Should we keep it? It can be set on individual
subtrees.
TabAtkins: I've gotten good use of it in HTML.
ed: It's being used in some SVG content, with the subtree.
TabAtkins: Does XML define what happens with dynamic changes to
xml:base?
ChrisL: Not well. It points to HTML's <base> and says "like
that".
... So we have two choices.
... (1) define a new xml:base spec, and push it through the
disparate XML groups
... (2) define what xml:base does *for SVG*.
heycam: So we need to define xml:base properly.
... And think about integration with HTML's <base>.
RESOLUTION: Someone define what xml:base does properly (in
dynamic changes, too).
What do do with version and baseProfile?
TabAtkins: Drop 'em. they don't do anything.
Tav: They may be useful for authoring tools.
TabAtkins: You dont' want that normally - if you open an SVG,
and your authoring tool knows about SVG2, you want to have SVG2
features. If you *do* want to specifically author for an SVG1.1
UA, that's a switch at the authoring tool level.
RESOLUTION: Drop version and baseProfile.
What about xml:lang and lang?
heycam: I think we chose to use lang on <title>?
ChrisL: I think the i18n guys prefer one, I think it's lang.
heycam: What does HTML do with both lang and xml:lang?
TabAtkins: It's complex, but it eventually pops out a single
language. I think it's biased towards using lang.
heycam: Okay, so let's do the same. Allow both, define their
interaction, encourage lang over xml:lang.
RESOLUTION: Allow both lang and xml:lang, define their
interaction, encourage lang over xml:lang.
svg:transform
ChrisL: How do current kddi apps treat it? It's currently meant
to let you transform SVG coords to map coords.
<ed>
[69]http://www.w3.org/TR/SVG11/coords.html#SVGGlobalTransformAt
tribute
[69]
http://www.w3.org/TR/SVG11/coords.html#SVGGlobalTransformAttribute
ChrisL: I think people aren't using this? If so, can we remove
it?
heycam: If no one's using it, let's just remove that section.
ChrisL: Where the RDF stuff used to be in the spec, we should
use the simple examples for things people are actually using -
srsname and transform.
... I'd be fine calling it something other than "transform" - I
dont' like overloading the term.
heycam: Is this used by multiple organization?
ChrisL: I think Alex has implemented this. We should ask him.
heycam: It's just metadata, right? It's not used by us
natively.
ChrisL: Yes.
<ChrisL>
[70]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/
[70] http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/
<stakagi>
[71]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/
[71] http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/
<ChrisL>
[72]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#Geog
raphicCoordinates
[72]
http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#GeographicCoordinates
ChrisL: Just call it "geoTransform" or something.
heycam: Are these things going to be defined by a mapping
module?
TabAtkins: I think that's best, yeah.
ChrisL: I think that a "projection" attribute would be useful
too. SVGOpen people were pushing for at least one extra one.
heycam: So we remove the geo coords section right now, and move
it to the mapping module later.
RESOLUTION: Move the geo coords section to the mapping module,
and reword appropriately.
<animateColor>
heycam: Let's kill it.
<ed>
[73]http://lists.w3.org/Archives/Public/www-svg/2012Aug/0134.ht
ml
[73] http://lists.w3.org/Archives/Public/www-svg/2012Aug/0134.html
birtles: In that email, it's deprecated in SVG 1.1.
... So we shoudl remove it now.
TabAtkins: Do we deprecate but define it? Or just remove it
entirely?
... Depends on whether there's enough content that needs it,
such that a new browser would need to support it.
action tab to search for uses of <animateColor> on the web.
<trackbot> Created ACTION-3373 - Search for uses of
<animateColor> on the web. [on Tab Atkins Jr. - due
2012-09-25].
Summary of Action Items
[NEW] ACTION: andreas to organize a workshop on mapping issues
[recorded in
[74]http://www.w3.org/2012/09/18-svg-minutes.html#action12]
[NEW] ACTION: birtles to follow up with takagisan on what
exactly is needed to get the bitmap [recorded in
[75]http://www.w3.org/2012/09/18-svg-minutes.html#action11]
[NEW] ACTION: Chris to propose the aliasing of current-color to
currentColor with the CSS WG [recorded in
[76]http://www.w3.org/2012/09/18-svg-minutes.html#action04]
[NEW] ACTION: ChrisL to write up contextFill(Paint),
contextStroke(Paint) proposal in coordination with Cameron
[recorded in
[77]http://www.w3.org/2012/09/18-svg-minutes.html#action03]
[NEW] ACTION: Dirk to add an issue to CSS masking about which
bounding box to use for percentages in clip-path shape
definitions [recorded in
[78]http://www.w3.org/2012/09/18-svg-minutes.html#action01]
[NEW] ACTION: Doug to coordinate with Inkscape folks on their
connector stuff [recorded in
[79]http://www.w3.org/2012/09/18-svg-minutes.html#action06]
[NEW] ACTION: Doug to work on event handling on connectors
[recorded in
[80]http://www.w3.org/2012/09/18-svg-minutes.html#action05]
[NEW] ACTION: Doug to work with Tav on the star proposal
[recorded in
[81]http://www.w3.org/2012/09/18-svg-minutes.html#action07]
[NEW] ACTION: Erik to send a mail to a suitable mailing list
about defining the filter region for filter shorthands (so we
can define masks to include the filtered result) [recorded in
[82]http://www.w3.org/2012/09/18-svg-minutes.html#action02]
[NEW] ACTION: heycam to setup the classes for the SVG2 changes
appendix (to cover changes from 1.1 and the diff from previous
draft) [recorded in
[83]http://www.w3.org/2012/09/18-svg-minutes.html#action13]
[NEW] ACTION: heycam to write up a proposal for overflow and
panning [recorded in
[84]http://www.w3.org/2012/09/18-svg-minutes.html#action10]
[NEW] ACTION: stakagi to write up a proposal for iframe like
syntax in SVG [recorded in
[85]http://www.w3.org/2012/09/18-svg-minutes.html#action09]
[NEW] ACTION: takagisan to write up a proposal for iframe like
syntax in SVG [recorded in
[86]http://www.w3.org/2012/09/18-svg-minutes.html#action08]
[End of minutes]
__________________________________________________________
Received on Tuesday, 18 September 2012 16:26:10 UTC