<heycam> trackbot, start telcon
<trackbot> Date: 18 September 2012
<heycam> Zakim: remind me in 8 hours to enjoy the view
<birtles> scribenick: birtles
krit: we need to define what the
... 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
... we don't have borders
TabAtkins: we have decorated bounding boxes which map to borders
krit: it's mainly used for
... 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?
RESOLUTION: mask-box-image works on the decorated bounding box
next, is clip-path: <shape>
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?
... the painted bbox may differ slightly between platforms due to how stroking is calculated
heycam: I think there are three
... (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
... 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
... but SVG doesn't allow that
... for mask it's controllable
... but for clip-path is doesn't need to be controllable?
... we need to decide which box to use
ed: clip paths are always
... 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
... 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
... 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
... the clip path element has no hard clipping area unlike masks
heycam: because there's no clip-path-clip property?
heycam: clip-path-clip is a bit
... 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
... probably what you want most of the time is the stroked bbox
heycam: I'm not exactly
... 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
... 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
... 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
... but you clip it to viewbox
... also feTile etc. is infinite
ed: you could use the filter
... 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
... it matters if you're depending on the size of the bounding box
cabanier: you can always work
... 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].
heycam: as part of the SVG in
... 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
... 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
(Cameron shows demo of SVG in OpenType in Firefox Nightly)
ChrisL: I like currentFill and currentStroke from 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
... 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?
... 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
... which context do you use in the nested context?
shepazu: it goes to the
... 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
<trackbot> ACTION-3364 -- Chris Lilley to write up contextFill(Paint), contextStroke(Paint) proposal in coordination with Cameron -- due 2012-09-25 -- OPEN
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
... couldn't you meet the need with percentages?
heycam: percentages inside the
glyph will be relative to the glyph coordinate space which is 0
... 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
... 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
<Cyril> scribe: Cyril
<scribe> scribeNick: Cyril
DS: if you're not familiar with the spec
DS: the connectors connect
... 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
... 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
... there are use cases where you want different type of connectors
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
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
... 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
... 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
... we should not have a routing algorithm
tav: inkscape implements
... 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
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
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
... find use cases that it doesn't solve and I'll fix it
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
... 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
ds: polygons are degenerated case of stars
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
<cabanier> scribenick: cabanier
opic: Dynamic document loading
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
... what is cascading tiling?
ChrisL: that is the image
... I dont see how the automatic fetching works
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?
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
... 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
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
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?
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
... 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
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
... 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
... 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
<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].
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].
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
... 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
andreas: Showing a few issues
with mapping, see if there are solutions in existing
... 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
... [shows an example where you want to put markers on the corners, but suppress them if the segment is too small]
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: 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.
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]
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.
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.
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.
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.
heycam: We'll have a meeting early next year in Sydney.
ChrisL: Weren't we moving that from Jan to Feb to accommodate ???
<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?
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.
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.
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
... And think about integration with HTML's <base>.
RESOLUTION: Someone define what xml:base does properly (in dynamic changes, too).
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.
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.
ChrisL: How do current kddi apps treat it? It's currently meant to let you transform SVG coords to map coords.
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: 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.
heycam: Let's kill it.
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].
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]