W3C

- DRAFT -

SVG Working Group Teleconference

18 Sep 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


<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> 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> 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 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 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 - http://lists.w3.org/Archives/Public/www-svg/2007Jun/0006.html

<Tav> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects

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> http://people.mozilla.org/~cmccormack/temp/svg-glyph-basic.svg

<heycam> http://people.mozilla.org/~cmccormack/temp/smiley.svg

ChrisL: I like currentFill and currentStroke from vector effects

<ChrisL> 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 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> 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 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> https://github.com/edf825/SVG-OpenType-Utils -- scripts for inserting SVG documents as a table in the OpenType font

<heycam> use the pyinsertsvg directory

-- break for 15mins --

<andreas> here is a nice astronomic clock from prague: http://drifted.in/horologium-app/

<Cyril> scribe: Cyril Concolato

Connectors

<Cyril> scribe: Cyril

<shepazu> 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> 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> 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 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> 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 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> 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 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: 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> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics#SVGTL_and_Dynamic_document_loading

link: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics

<ed> 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: 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

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: 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> 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> http://www.w3.org/mid/5050A664.1010005@mcc.id.au

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0191.html

<ChrisL> I'm reminded of http://www.w3.org/Graphics/ScalableReq.html where it says "Levels of detail " - one of the few requirements SVG has yet to meet

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 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 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> 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 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

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 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 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: 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> 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> 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> 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> 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 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> 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> http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/

<stakagi> http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/

<ChrisL> 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> 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 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 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 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 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 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 http://www.w3.org/2012/09/18-svg-minutes.html#action06]
[NEW] ACTION: Doug to work on event handling on connectors [recorded in http://www.w3.org/2012/09/18-svg-minutes.html#action05]
[NEW] ACTION: Doug to work with Tav on the star proposal [recorded in 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 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 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 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 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 http://www.w3.org/2012/09/18-svg-minutes.html#action08]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/09/18 16:22:32 $

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 http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/all glyphs/all glyphs as they are defined on the same glyph coordinate system (em square)/
Succeeded: s/going away/going away in favor of doing it corectly tith opentypefeatures, see CSS3 Fonts/
Succeeded: s/ don't like useCurrentFill/ don't like the names useCurrentFill/
Succeeded: s/ dash all the things!/ dash-all-the-things!/
Succeeded: s/dash-all-the-things!/Dash-All-The-Things!/
Succeeded: s/we we say/if we say/
Succeeded: s/ there is an attribute on resource loading/ I see that there is an attribute 'externalResourceLoading' for controlling when external things load, I assume this was on the iframes/
WARNING: Bad s/// command: 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?
FAILED: 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?/
FAILED: s/ opera already has this/ opera (mac, android e.g) support pinch-zooming and so on/
Succeeded: s/vector /raster/
FAILED: s/API to draw a bitmap/API to get a rasterized version of vector graphics/
Succeeded: s/opposed to/not very comfortable/
Found ScribeNick: birtles
Found Scribe: Cyril Concolato
Found Scribe: Cyril
Inferring ScribeNick: Cyril
Found ScribeNick: Cyril
Found ScribeNick: cabanier
Found ScribeNick: TabAtkins
Scribes: Cyril Concolato, Cyril
ScribeNicks: birtles, Cyril, cabanier, TabAtkins
Present: Cameron Doug Chris Cyril Erik Tab Nikos Takagi-san Konno-san Brian Dirk Rik
Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda
Found Date: 18 Sep 2012
Guessing minutes URL: http://www.w3.org/2012/09/18-svg-minutes.html
People with action items: andreas birtles chris chrisl dirk doug erik heycam stakagi takagisan

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]