<trackbot> Date: 03 June 2013

<TabAtkins> Hrm. I got confused and came up to Mori tower for some reason. Is the best way to fix this to head back down and use the subway again?

<heycam> TabAtkins, no, but it is about 15 minutes walk

<cabanier> scribenick: cabanier

<heycam> TabAtkins, (Mori tower is right where my hotel is)

<heycam> TabAtkins, do you have a map? it's a reasonably straightforward route

<TabAtkins> kk

<TabAtkins> i have google maps?

<TabAtkins> kinda?

<shans__> TabAtkins: I can come get you if you want

<TabAtkins> heh, sure

<TabAtkins> <3

<TabAtkins> birtles: Yeah, I have that up, but it doesn't stop me from being dumb.

<shans__> TabAtkins: OK, I'll meet you at the bottom of the mori tower?

<TabAtkins> yeah, i'm at the starbucks

<shans__> TabAtkins: alright, be there in 10

<TabAtkins> yay!

agenda

heycam: are there missing topics?

… don't worry about scribing

<TabAtkins> Shane has found me! Coming in.

should fill-rule apply to text elements?

heycam: in svg 1.0, it applies to shapes and text

… but does it make sense?

Tav: maybe for SVG in OpenType?

heycam: does it make sense to control how the path data is interpreted?

krit: per glyph or the whole word?

heycam: my feeling is that it's not very useful

… so wanted to see if other people feel the same way

… I discovered because a site was using

cabanier: yes, it should have no effect

… you are supposed to define them so that are unaware of the fill rule

… outlining glyphs should be unaware of winding rules

heycam: our implementation was slower for even odd

krit: we rely on the rendering engine so it doesn't affect the winding

nikos: so, subpixel-aa is also turned off

heycam: yes
... what if the glyphs overlap?

cabanier: they should paint separately and not interact with each other anyway

heycam: so, should they work?

everyone: no

heycam: so we'll change the text so it doesn't aooky

Cyril: maybe this is for SVG fonts?

heycam: that's possible
... for SVG in OpenType, there's no way either

resolution: fillrule does not apply to text

marker orientation issues

tav: I added it

… basically there are inconsistencies between browsers

… you can look at the examples

<krit> http://paullebeau.com/svg2/markers/

… and there's also the question of rectangles

… what do you do with rounded corners

heycam: I remember making a test for this

… I have a feeling that the spec should define this

… ie angle coming from 2 different directions

krit: is there a spec issue of is it just implemenation

Tav: it might be just implementaion

… for 2 subpath, they should not be treated as 1

… I think

(looking over the examples)

heycam: looks like rendering issue

tav: what with the double point?

heycam: I wonder what the spec says?

… (reading) it seems that you get 2 markers for double points

krit: why would you draw points on top?

tav: maybe in animations

krit: I would expect the markers over each other

tav: you always get the discontinuity

krit: I'm more talking about transparent markers

heycam: taking a look at the 'correct' version, I think he is right

krit: do we need to change the spec

heycam: yes, it should be make clearer. for instance the orientation shouldn't be in an appendxi

… it could benefit from being rewritten

… orientation is also used for motion path orientation

krit: text on a path

heycam: yes when the glyph is on the point

… it sounds like we agree with his findings

TabAtkins: we can't use his exact wording

… because he wants to use coincident points to be ignorder

heycam: he may be talking about the orientation

… do we all agree that there should be rendering for each point?

tav: yes

resolution: we agree with his finding to determine the orientation of the marker and we should paint a marker for each vertex even if they coincide

heycam: he also suggest a new value for the orient attribute

TabAtkins: that seems to make easy double arrows

heycam: given that you need to duplicate marker elements

TabAtkins: no, it will flip it around. the name is unclear

… start or reverse seem better names

heycam: I like the idea but not the name

tav: autoreverse?

TabAtkins: 'auto-reverse'

… could it be multi-value

heycam: not sure. let me check

<birtles> (discussed that 'auto-reverse' is used on animateMotion's rotate attribute with different meaning so it could be confusing)

… currently the value for marker orient is exposed as IDL attributes

… orient type which is an animated enumeration

— and the angle value

… maybe we can resolve on this new value

resolution: we'll have a new value for orient attribute to do the right thing for arrow heads

TabAtkins: there's an issue where there are begin and end markers on closed paths

heycam: I find it odd that the open subpaths don't have an end

TabAtkins: that's what the spec said. It's on path element itself

heycam: closed subpaths should only have marker mids?

all: yes

heycam: markers on rects and ellipses

(previous topic)

(discussion on just moveto's creating markers)

krit: we have patches to make that happen

heycam: I thought we had tests for all this

… but I can't find it

… so we should decide something

… I think it would be most consistent to paint both

krit: this is strange

TabAtkins: the problem is that this is a spec change

heycam: looking at subpaths makes more sense but it seems that most implementations already agree on the just looking per path element

… I'd be most happy with the small change

TabAtkins: it all seems broken

<TabAtkins> TabAtkins: All the existing renderings are broken. >_<

krit: we should add a note that it may change in the future

resolution: we'll keep start and end markers apply to the whole path

<TabAtkins> Hey shepazu, WRITE STAR.

<TabAtkins> Alternately, send me your notes and I'll write it.

<shepazu> TabAtkins, I'll write star

<shepazu> or at least start it

heycam: there was 1 remaining topic on markers

… rectangles, ellipses, etc

tav: what about rounded corners?

TabAtkins: all the remaining elements should define the equivalent path

heycam: you'd probably want to use marker pattern

… should that be doable

TabAtkins: yes

birtles: it would be useful to have path equivalents for the rect and ellipse

<birtles> (for variable-width stroke)

resolution: closed subpaths should get no start or end markers

<AlexD> +1 to that

heycam: I already have an action to come up with equivalent paths for rects and ellipses

<AlexD> Make sure ellipses use ellipse segments, not beziers!

cabanier: yes

TabAtkins: Canvas already defines this

… it uses it as 4 arc paths

<AlexD> Nice

heycam: I have the action so we can draw the dashes correctly

<TabAtkins> Canvas doesn't define it as 4 arc paths - it does it as one continuous arc. But still, its start point is the rightmost point.

<TabAtkins> So we should match.

… maybe we can copy rect over from svg tiny 1.2

<AlexD> We already have tests for dashing around rects & Arcs so should be easy to check they match

<AlexD> Ellipses, sorry

TabAtkins: yes, canvas has it with the start in upper left and going clockwise

<heycam> AlexD, good point

<AlexD> e.g. shapes-ellipse-03-t.svg

resolution: we need to have markers on rect, circle and ellipse and all basic shapes (in case of stars)
... rounded rects start at straight horizontal line of the top left
... rounded rects wind clockwise and include 0 length segments when the rounder corner is 50%
... for ellipses and circles, the path starts at right-most point and consists of 4 arcs going clockwise and each are 90 degrees

<scribe> ACTION: heycam to integrate the marker resolutions in the spec [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action01]

<trackbot> Created ACTION-3496 - Integrate the marker resolutions in the spec [on Cameron McCormack - due 2013-06-10].

<TabAtkins> ScribeNick: TabAtkins

feBlend issues

cabanier: feBlend as defined today does blending an compositing.
... This is usually fine today, but if you blend with backgroundIMage, you'll get double compositing, and there's no way to avoid it.

<Tav> http://tavmjong.free.fr/INKSCAPE/MANUAL/images/FILTERS/Filters_Background.svg

cabanier: We can either change feBlend (seems to be the only way)
... We can add an attr to feBlend, so it doesn't do the compositing.
... That is, do the "normal" compositing only.

krit: [draws an example]

cabanier: There's too much existing content out there for us to change the default behavior.
... And if you don't use backgroundImage, it's not bad, and sometimes good, to composite eagerly.
... So choices are add an attribute that stops compositing, or try to detect when backgroundImage is the input, and don't composite.

krit: I like the attribute, because it might sometimes be useful to do the extra composite.

[some side discussion about naming]

TabAtkins: So it looks like just dropping backgroundImage compositing would be web-compatible?

heycam: Anything else with this problem?

cabanier: feComposite, but that's much more intentional.

krit: There are more use-cases that might want only blending, so doing the attr seems better.

ACTION krit to define a new attribute (nocomposite?) on feBlend that turns off the compositing effect.

<trackbot> Created ACTION-3497 - Define a new attribute (nocomposite?) on feBlend that turns off the compositing effect. [on Dirk Schulze - due 2013-06-10].

RESOLUTION: Keep feBlend's current behavior (where it blends and composites), but add an attribute that turns off compositing.

enable-background issues

cabanier: Today, e-b has a really long description.
... I think IE implemented it, and Opera, but nobody else.

TabAtkins: I think roc is against it, and we (blink) have similar concerns.

cabanier: Yeah, it's really expensive.
... The way it's defined today you have to render twice - once to use as the background.
... Nice for authors, but hard/slow to implement.
... Adobe apps do something similar under the hood, which we can add in the future.

heycam: Isn't there a trick to keep you from double-rendering?

cabanier: Yes, but there are still issues where you have to keep two sets of pixels, and that kills performance.

<AlexD> double rendering? Isn't it just a backing store that you bitblt as the second pass? Blts are fast:-)

<nikos> http://www.svgopen.org/2005/papers/abstractsvgopen/

heycam: I think e-b isn't explained well in the spec, and if impls have a trick that can make it not so slow, the spec should define this.
... But you're saying that even with that trick, due tto the arch. of accel. compositors, it'll still be slower.

cabanier: Yeah. We can revisit this in the future, but we should get the basics right now.
... We can define similar things to HTML's "stacking contexts" - if you ahve a <g> with opacity, it's a stacking context.

<AlexD> The requirements to support e-b are the same as supporting filters. So if you can accelerate filters you should be able to accelerate e-b. Need hard data to falsify this claim:-)

No, it's not the same.

You can do filters with one copy of the data in a single gpu pass.

<AlexD> <g> with opacity already requires some intermediate thing - however you can do it with a pixel sequential renderer and no backing store.

You don't have to go retrieve data from a different gpu pass in order to render them.

[some discussion about transforms and stacking contexts]

<AlexD> agreed Tab, and you can model e-b in a similar way

<AlexD> backing stores can be a last resort fallback

cabanier: So I think we should get rid of e-b, and say that certain elements create a fresh background.

krit: e-b can still be used to create an isolation group for filters.
... That's what's done in Opera/IE.

<AlexD> If we get rid of e-b, then it should be replaced by something better, like PDFs transparency groups which are a better model

cabanier: It can also be used to make non-isolated groups.

krit: Some properties need to create isolated groups by default anyway. For example, opacity needs to be an isolated group independently of e-b.
... We already have some impls of e-b, and I'm not keen ot have it removed without asking the impls about it.

cabanier: In the current spec langauge, it says you *must* use e-b for blending to work. We don't want that either.

krit: e-b gets less necessary with the definition that some other properties make isolation groups.

<AlexD> I agree, haven't seen a strong argument that it's not implementable. Current architectures for H/W accelerate shouldn't degrade the model...

cabanier: If we can just change e-b without breaking the web, that's fine too.
... To summarize, everything that creates a stacking context, creates an isolated group.

heycam: So what's the use of e-b outside of that?

[something about the effects of removing e-b from the spec]

heycam: So when do you want e-b? Somewhere when there's not already an isolated group?

cabanier: Yeah, but there are several proeprties which can make isolation without any other effects, and the 'isolation' property specifically for that.

heycam: Okay, so it sounds easy to get rid of e-b, use 'isolation' or stackign contexts when you want to turn off background blending.
... As long as people don't think there's strong use-cases for people using the more complicated e-b stuff.

<AlexD> Maybe we can try to get some data about how much it's used in the wild. Does Inkscape support it to isolate layers, etc.

[rehashing of previous conversation]

krit: To be clear, e-b is implementable, just not with the perf characteristics we want.

<AlexD> Then you need to write better code krit:-) GPUs are so slow...

[discussion of the values that 'isolate' has and their meanings]

<krit> AlexD: yeah, that is why I wrote everything for the CPU :P

<cabanier> cabanier: the issue is not GPU performace, the problem is that you need at least 2 extra readbacks from the backbuffer and 3 writes to the input buffer

heycam: Regardless of discussion over ease of implementation, because current impls dont' do it and don't want to do it, the spec should leave it out for the moment.

<AlexD> Again we need to get hard data on whether it's used. Currently it acts as a spot to run your filter chain back to. So we need to at least address that case.

<cabanier> cabanier: which accesses the memory a lot more which will drain your battery

heycam: If Alex can convince people later, we can add it.

krit: [wants a value for 'isolate' that prevents isolation of descendants even with stacking contexts. Pointed out that we can add this later and have 'auto' respond to it]

RESOLUTION: Remove e-b from this level of Filters.

<AlexD> For the record I'm not for or against, just want to make sure we don't break existing content in the field

krit: Should I remove e-b silently, or have a note?

several: Seems useful to have a note pointing back to the old definition.

What makes a stacking context?

cabanier: Anything in CSS that makes a stacking context - transforms, filters, etc.

heycam: Do you really want every transform attr to make a stacking context?

<AlexD> NOOOO!

cabanier: No, but we want to be simple and consistent with CSS. ;_;

krit: We all agree that SVG transforms are oftne just used for moving things around, and are quite basic, rather than something that requires stacking contexts.
... But impls all do normal CSS stuff.

cabanier: Maybe we can say that 2d transforms in SVG dont' make a stackign context?

heycam: If you want the same kinds of optimizations, maybe you do want stacking contexts.

cabanier: Like smooth transitions, yes.

krit: Does FF do transform transitions in hardware? WebKit doesn't do it yet (all software for SVG), but we want to change that.

heycam: Same.
... Seems like this will suck.

cabanier: It will.

krit: Rik tried to specify it around whether you're animating or not, but it didn't gain consensus - ugly flash when you change.

cabanier: So maybe we can just differentiate 2d vs 3d - 2d doesn't make a stacking context in SVG.

heycam: What if authors definitely want a separate layer, but ar ejust using 2d transforms?

TabAtkins: Use a null 3d transform, or just use 'isolate'.

heycam: Ah, I think I might be okay with using 'isolate' to get the stacking context.

Cyril: That seems to make sense.

<AlexD> I like isolate better than the 3d transform hack

krit: I think in practice implementors are going to use the same code as in HTML/CSS, so 2d transforms will be isoalting as well.
... I think we should add an agenda for Wed to ask the other CSS implementors.

cabanier: Back to the original context, also filters and opacity cause stacking contexts.

Cyril: z-index also makes a stacking context?

heycam: Yes, just like CSS.

Tav: Question about that - we have someone wanting to implementing connectors in Inkscape.
... You have symbols for the components, want connectors on different layers, etc.
... Suppose my symbol has things with different levels.
... And I want to have multiple symbols sometimes interleave?

[explanation of how stacking contexts work]

[conclusion is - it'll work, but making the symbol itself a stacking context will prevent it]

Cyril: [discussion of a layer use-case]

heycam: BAck to main discussion, are people expecting blending to work through opacity?

cabanier: Probably, but it's hard to make work.

krit: We make them isolated groups, and I think FF does too.
... Also masks and clips are stacking contexts.

cabanier: Why are clips?

TabAtkins: They're basically inverses of each other.

heycam: Simple clips can be done simpler than masks, but complex clips (with overlapping curves, or text, etc.) might use the same code path.

krit: Remember, this is the firsst level of blending. In the next level, we can do "real" blending, so it can go through stackign contexts, etc.

buffered rendering

Cyril: It's a hint.

krit: That's the problem. Blink is looking to implement it.
... So it can make a stackign context sometimes - "auto" is determined by the engine.
... So we should change "auto" to mean "don't make an image buffer".

Stacking contexts, cont.

[I meant that 'buffered-rendering' also causes stackign contexts.

RESOLUTION: buffered-rendering:auto/dynamic never create a stacking context; "static" does.

<Cyril> scribe: Cyril

<scribe> scribeNick: Cyril

heycam: someone should actually note those things that create a stacking context in the spec

<scribe> ACTION: Rik to note those things that create a stacking context in the spec [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action02]

<trackbot> Created ACTION-3498 - note those things that create a stacking context in the spec [on Rik Cabanier - due 2013-06-10].

heycam: the rendering model chapter should reference the compositing/blending

nikos: I did start updating it

<heycam> https://svgwg.org/svg2-draft/render.html

cabanier: the CSS compositing spec references that and extends it

https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#module-interactions

cabanier: we believe that CSS Blending and CSS Filters currently extend SVG 1.1 and don't need to reference SVG 2

krit: it depends on when SVG 2 goes to CR state

cabanier: there needs to be a link back from SVG 2 to those 2 specs
... does this mean those 2 specs need to be at CR stage ?

krit: no

review of hatches

<Tav> https://svgwg.org/svg2-draft/pservers.html#Hatches

Tav: I'd like people to review it and tell me if it is ok

krit: how would you implement hatches ?

tav: creating a pattern on the fly could work

krit: hatch as a dimension

tav: inifinite in one direction
... you can go to one tile but need to be carefull at tile boundary
... I would make the tile the size of the whole thing
... as long as you take car of the boundaries, it should work

heycam: can you summarize the new elements

<AlexD> Take a look at my open source hatching that I emailed ages ago - it's really easy to hatch. You generate the bound box of the thing being filled, generate the lines and clip them against the polygon.

tav: the hatch element copied from the pattern element

<heycam> AlexD, but does that work if you want to use the hatch in the stroke of a shape?

<heycam> (unless you have good stroke-to-path routines)

<AlexD> Yes - you have to generate the outline of the stroke of course

tav: the hatch has a pitch to repeat

<AlexD> http://www.ishtek.com/hpgl2.htm

tav: the hatch has a path which defaults to a line
... and an offset from the origin

heycam: can you choose the origin ?

tav: yes, that's copied from patterns

<AlexD> Source code is http://www.ishtek.com/gl2-0_1.zip

<shepazu> (isn't the problem with patterns a matter of implementation, not an inherent problem with the spec?)

tav: the fdifference between a normal path and a hatch path, you don't have to provide the original move to
... if not, the y is 0 and x is that last x value
... that's how you get the continuous

heycam: why y = 0 ?

tav: because you're repeating in the y direction
... look at the 1st squiggle example

krit: why do you need to introduce a hatchPath element? why not reuse the path element?

Tav: no initial move to
... it's necessary to repeat
... examples 9 and 10 show the difference between having the initial move to or not

krit: why do you need the angle attribute since you have the transform attribute ?

tav: maybe not needed then ...

krit: it can be confusing in which order they apply

tav: I have to think about it

nikos: should the d attribute be called differently ?

krit: I'm worried about the transform attribute
... we already have the gradientTransform ...

tav: that's fine with me, I just copied over from pattern

heycam: this brought the issue of capitalization of elements
... we did not resolve firmly on it
... especially given the HTML parsing algorithm
... each new mixedCase name that we introduce we need to update the HTML parser

krit: I think we should continue with our naming

heycam: and update the HTML spec ?
... otherwise the casing will not be preserved
... I'm pretty sure there will be a problem if we don't do anything
... we could say that both names work in the DOM

krit: is it only when SVG elements are not used in an SVG subtree ?

heycam: no, even if in an SVG subtree because the HTML parser won't know that new element

Tav: that must be trivial to fix

heycam: yes, but that could create problem between parsing and DOM manipulations
... maybe it's not a big deal because people won't be doing that
... one solution could be to allow both cases to produce the same DOM element
... because if we don't allow that we have to file a bug on the HTML spec

krit: can you fill hatch paths ?

Tav: no
... that needs to be clarified

krit: what about filters ?

heycam: and markers ?
... can you use the normal stroke properties ?

Tav: yes
... even variable width stroke, but it depends on the use case

heycam: it makes sense to allow all stroke properties
... you could do overlapping, which you can't easily do with patterns

Tav: overflow on the parent is not defined

<AlexD> Yes, and it does that in GL/2 i.e. hatch lines are clipped, then the stroke can go outside the original shape with line ends, etc.

heycam: if overflow is set to hidden, then there must be some rectangular region used for clipping

tav: the rectangular region is infinite length

(tav drawing on the board)

krit: there would be a difference between overflow x and overflow y

Tav: it would be nice to have overflow on patterns

krit: it was implemented but then removed from the spec

Tav: it would be easier for authors

heycam: I do it 4 times and clip the middle

krit: it was not implemented by Opera and Firefox

Tav: can we revisit that for SVG 2

heycam: let's start without it

Tav: any other issue that people see ?

heycam: I would start with the assumption that all stroke properties work

krit: should all paint servers work ?

Tav: like a hatch inside a hatch ?
... why not if it can be implemented easily

<AlexD> Mmmm, fractal hatching:-)

heycam: most people won't use it
... if you have a hatch whose stroke properties references a paint sever defined in terms of objectboundingbox
... which bounding box would you use, the small one or the infinite one ?

krit: can we leave that undefined for now
... unspecified

heycam: I don't think it should stay unspecified

TabAtkins: it is a mistake to leave it undefined

Tav: we could say only solid colors for now

RESOLUTION: Hatch will only support solid color paint servers

Cyril: can you reuse a path?

Tav: that's not really the same as another path?
... currently there is only a hatchPath and it cannot reference something else

krit: I would leave it like that

heycam: there is a xlink:href attribute on the hatch element

break

<TabAtkins> /break

<TabAtkins> [Presentation from IDPF about "Advanced Hybrid Layouts" to get input from SVGWG for some questions.]

<TabAtkins> [Slides will be published shortly.]

example of "intra-navigation rendition" for Comics using SVG: http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/

works only in Firefox

<TabAtkins> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-area-shape

heycam; we could have the overflow property apply to the view element

krit: does it need to be the view element ?

TabAtkins: yes because there is no nested svg element
... it has to be a view

krit: you could use the view element with use elements

IDPF: would you feel offended if we added our own attribute

heycam: we would prefer to define it in SVG

TabAtkins: it sounds useful for general SVG

IDPF: multi-lingual manga, tapping an area or moving the mouse over to change the language
... it dosn't work on tablet

birtles: you can use SVG animations

TabAtkins: or HTML with hidden option elements
... with pure HTML, no JavaScript

heycam: relies on the fragment changing and links?

TabAtkins: using check boxes and radio buttons and pseudo-classes
... use check to display none
... you can cycle between language

birtles: if your UA supports SVG animations, it would be a lot simpler and more semantically intersting to use SVG

IDPF: what about CSS animations?

TabAtkins: some of it will be only possible in SVG animations
... what about scaling to 100 languages

IDPF: with menus maybe

TabAtkins: JS would become more useful

IDPF: could you use SVG animations to store your language preference

Cyril: maybe using SMIL state

birtles: you could use the switch element

krit: I would not rely on the switch element

IDPF: how well is the support for animation

birtles: well in all browsers except IE

krit: but you could use JS libraries

http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/

<TabAtkins> data:text/html;charset=utf-8,<!DOCTYPE%20html>%0A<div%20id%3Dbackground>%0A%20%20<input%20name%3Dfoo%20type%3Dradio%20id%3Di1%20checked><label%20for%3Di2>1%2C%202%2C%203<%2Flabel>%0A%20%20<input%20name%3Dfoo%20type%3Dradio%20id%3Di2><label%20for%3Di3>%E4%B8%80%2C%20%E4%BA%8C%2C%20%E4%B8%89<%2Flabel>%0A%20%20<input%20name%3Dfoo%20type%3Dradio%20id%3Di3><label

<TabAtkins> %20for%3Di1>i%2C%20ii%2C%20iii<%2Flabel>%0A<%2Fdiv>%0A<style>%0Ainput%2C%20input%3Anot(%3Achecked)%20%2B%20label%20%7B%20display%3A%20none%3B%20%7D%0A<%2Fstyle>

<TabAtkins> D'oh, terrible link handling.

IDPF: How should we capture regions ?

<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2271

<TabAtkins> ^^^ Example of cycling language via HTML.

<TabAtkins> (And it can be powered up with a "default language" selection as well.)

IDPF: Should we use SVG views, SVG elements in the rendition tree or SVG elements in <defs>

Cyril: you want to describe metadata

IDPF: yes
... a tree of regions
... for navigation
... the rest is flat

heycam: is the description of the hierarchy inside or outside the SVG document ?

IDPF: outside

<TabAtkins> (Also, the basic mechanics in my example are captured in a draft CSS spec on my blog, and the CSSWG is interested in pursuing it, so this might be usable for SVG as well.)

TabAtkins: if you extend media fragment to add a polygon that might do a lot

IDPF: yes

Cyril: it would be good to add the metadata in the SVG document to enable viewing it with browsers
... possibly with JS navigation logic

IDPF: why having both views and fragment identifiers ?

heycam: maybe for flexibility

TabAtkins: yes it depends on who is the author of the document

<birtles> SVG version of above: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2272

heycam: we can answer to the IDPF questions in a liaison
... we need also to wok on the clipping question

TabAtkins: overflow should clip the content
... I will take the question to the CSS group
... and we need to work on swapping text around

heycam: there is also a work on custom media queries

TabAtkins: to avoid creating a class attribute on the body (modernizr)

IDPF: we are wondering if we should use media queries for text direction or language

TabAtkins: it should work
... your use cases seem appropriate for MQ
... some properties like luminance are in CSS MQ 4

<heycam> http://www.w3.org/mid/CAAWBYDBbJ5qSDZzHAvThdA9W0PDmEOTh7+ApLaQYtHwi6U0o_Q@mail.gmail.com

heycam: in summary we need to answer how to represent non rectangular view, clip them, swap text, more media queries

<TabAtkins> Also: where to put region information?

<TabAtkins> heycam: Keep it in content where possible.

heycam: we can consider that for SVG 2
... you need to point to the views from outside
... and for browser fallback to use # to those views and have sensible behavior

IPDF: we like CR

heycam: the original plan was to have a stable version at the end of this year
... but I'm not sure we can make that
... we could right a separate specification if that would make your life easier

IDPF: yes that would
... we would need to decorate semantically the views

heycam: I think that would be fine for you to define the semantics in the SVG document in a different namespace

IDPF: yes that's our plan
... also order would be significant

heycam: arbritrary authoring tools might not preserve the order

IDPF: but we might need to represent the order in our external navigation metadata documet

heycam: I will gather our ideas and send that as a liaison

<scribe> ACTION: heycam to gather ideas for solving IDPF issues and send that as a liaison [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action03]

<trackbot> Created ACTION-3499 - Gather ideas for solving IDPF issues and send that as a liaison [on Cameron McCormack - due 2013-06-10].

<heycam> ScribeNick: heycam

multiple paint servers on one element

Tav: sometimes you want a crosshatch

… you could have multiple fills on an object

… it might be useful to have a colour fill and with a hatch on top

… how to specify this?

… maybe a comma separated list?

krit: and what about the fallback value?

… fill/stroke have a paint server reference and a fallback value

… how does that work?

TabAtkins: just like background, the last thing would be a colour

… and you'd fall back to that

… it's comma separated, but the last layer can be a colour

krit: you have a space separated fallback colour in fill/stroke now

heycam: why not have <paint> for each item?

krit: then we need to define the paint order. we should do it like background-image.

heycam: so it's backwards?

Tav: that's how I'd do it

krit: what about having fill-attachment, fill-clip, ...?

TabAtkins: do we really want that? it might be a good idea, but...

heycam: allow that for stroke as well?

Tav: yeah

RESOLUTION: We will allow multiple paints in the fill and stroke properties in SVG 2.

<TabAtkins> Comma-separated, painting first layer on top, last on bottom. Only last layer can be a color or have a fallback color.

cabanier: what about the other stroke properties, like stroke-width?

heycam: having a comma separated list of stroke-dasharrays would be problematic

… we could wrap them in a function if we need to, though

krit: I don't want to support those yet

… let's just do fill and stroke properties, and leave stroke-* properties as single items for now

heycam: ok

<scribe> ACTION: Tav to put multiple fills/strokes in SVG 2. [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action04]

<trackbot> Created ACTION-3500 - Put multiple fills/strokes in SVG 2. [on Tavmjong Bah - due 2013-06-10].

RESOLUTION: <hatch angle> will be renamed <hatch rotate>.
... <hatch rotate> will allow angle units.

<TabAtkins> abab

<TabAtkins> ab

<TabAtkins> abab

<trackbot> Meeting: SVG Working Group Teleconference

<trackbot> Date: 03 June 2013

<scribe> Chair: Cameron

<scribe> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Tokyo_2013/Agenda

<shepazu> birtles, why don't I just skype into someone else's skype?

<birtles> shepazu, it might be easier to hear on the polycom

<AlexD> I can't Skype, can we Zakim or G+ hangout?

<krit1> https://adobe.intercallonline.com/listNumbersByCode.action?confCode=8603022084

<krit1> Conference code: 1842346653

<krit1> shepazu: AlexD: --^

<cabanier1> usa: 8558705454

<AlexD> ACK

<krit1> numbers are free of charge

<cabanier1> australia: 0800006620

<AlexD> That Aus no. is invalid

<cabanier1> sorry: 1800038970

<nikos> it's valid in austria ;)

<nikos> scribenick: nikos

Text flow

<Tav> http://tavmjong.free.fr/SVG/TEXT_FLOW/

Tav: You can see some examples from InkScape
... This never gained traction
... for svg 2 we need to re think it and keep it simple and consistent with CSS
... my proposal is to rely on CSS exclusions and shapes
... 1.2 flowed text missed padding
... those are defined in CSS exclusions
... flow between shapes goes from the first shape listed to the next
... my explanation is how it works in CSS

dirk: you can't flow text from different shapes in CSS

TabAtkins: you need to use regions for that

Tav: regions might be overkill for svg, but we can discuss that later
... there are a couple of problems. We don't have the line break and paragraph
... you can work around that using whitespace property with pre wrap and pre line
... there a a lot of other interesting things from CSS 3 that we would need: text-align, etc
... you could keep x and y on tspan and if a renderer is capable of flowing text it would ignore them and if not then use them as fallback
... so that's my proposal. Doug has another.

heycam: you said in your blog post that some features dissapeared from CSS?

Tav: exclusions was split into two and the ability to link to SVG paths was removed
... shape inside was deferred to a future version
... this was done a couple of weeks ago. I don't know why

cabanier1: I think it was to speed up progress

Tav: the way inkscape implements is to create a path. It's not any harder to do shape inside

<stearns_> shape-inside also has an issue with overflow - can't size shape to content easily

cabanier1: It's hard to specify but I don't know the details exactly

krit: The problem is with floating I think
... the idea is to iterate over the specifications quickly
... do shape outside first and then shape inside next

heycam: it seems like shape inside is the more important for SVG

shepazu: I'm fully supportive of this proposal, I think it's the right way to go in the long term
... I think you should continue to work with the CSS WG
... to ensure the SVG use cases and the nice features that you have are included in the spec
... I like the notion of the fall back and allowing people to have multiple fall backs for shaped text

krit: How do you work with x, y, and rotate on the text element?
... one of the biggest use cases is to position different characters in the doc
... how does it work in InkScape

Tav: there's no change for rotated text

krit: I mean each character is rotated independently

Tav: I think rotate is ignored
... dx and dy apply. It would be reasonable to move after positioning

Alex: I'd like to ask for aligning the box direction

heycam: how is that handled in the CSS specs?

AlexD: I'm not sure it is
... we had an algorithm in 1.2 didn't we?
... display-line?
... the second thing that people have asked for - to wrap a rectangle or shape to the text that they have
... I don't know if we should look at that now or leave it for the future

heycam: I think it makes more sense to consider it as part of broader dynamic layout in svg
... there are probably other elements that you want to change the position of (not just text)

AlexD: if we provide a js API that gives you the height of the blocks you can use js to shape the content

heycam: I'd expect that to work already
... getBBox()

shepazu: I agree that people have been asking for this a while
... getting the path of the text from the API would also be nice
... having shapes that adapt to the size of the text, that's something that we should defer and use calc()
... not a characteristic of text, but a generic use of calc() in attributes in SVG
... so they can dynamically size things according to text or other factors

heycam: one thing that might be worth tackling before the broader layout issue
... might he solved on CSS size
... is to change the size of the text to fit

shepazu: going back a level there was the problem of having text grow or shrink to fit the available space - is that available in flexbox?

TabAtkins: no. It's been discussed in the past and might come up in the CSS f2f
... it's a hard problem because of constraints - how far it will grow
... but it's an idea we want to pursue

shepazu: has a proposal been put forward for a new unit?

TabAtkins: that's normally called percent
... in a lot of circumstances percent is relative to the space of the outer container

shepazu: I don't think SVG would deal with percentages well in that context
... unless we do width and height
... which is in my proposal

TabAtkins: having a specific unit would probably be fine
... in SVG

shepazu: one of the things about having the shape fit the size of the text
... we could allow properties from css like background colour, or outline

krit: outline is already defined for svg

shepazu: I don't know the complexity of adding that to svg

AlexD: rect with x, y and width, height = auto would be awesome

shepazu: I'd rather we add a bit of the CSS box model to SVG than make authors do it with js

heycam: it could make sense to have a rectangular area for laying out text in. We could start with that

shepazu: with Tav's proposal you don't need that
... I think our proposals are complimentary
... I'll talk about my proposal
... link at the end of Tav's proposal
... it's very simple
... depending on how clever and internationalised we want to be
... we can either allow width and height on text
... maybe you could demo your build cam?

[Doug explains his proposal]

scribe: I have a second proposal

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text

scribe: I only implemented the bit where you can specify width on the text element and it will flow downwards

[Cam shows his demo]

scribe: y is the top of the rectangle rather than the origin of the first glyph

shepazu: the one reason I'd say is to not have that behaviour as default is for the fall back case it's better if the text is rendered on the same line as it normally would be

heycam: that might make it difficult to position the text rectangle

Tav: could define a different x and y

shepazu: when you want to put a line break I'd suggest we use tspans with dy having a value like 1.5 em or something
... and it establishes a line break context
... this brings up another point that is a failure tspan
... if you want a new paragraph, with dy you have to reset it back to the original co-ordinates in order for it to align with the first paragraph start point
... we should have something like x or dx inherit
... I have a second proposal which I don't like as much but has some advantages
... add properties text-wrap and text-extent
... text wrap defines the point at which the text wrap
... text-extent is the point at which the line wrapping stops
... they would also apply to vertical languages

TabAtkins: we already have terms in CSS, measure for logical width and extent for logical height

heycam: I know that CSS was talking about logicalised versions of properties

TabAtkins: we still intend to but we are not sure how or when

shepazu: I'd defer to CSS and follow them
... for now we go with intuitive (to westerners), width and height
... I don't think we should change the y location of something just because we set a width and height

krit: what about using the text area element from 1.2?

heycam: the name is bad

shepazu: in 1.2 we define an algorithm and I don't think that's a good idea for what I'm proposing
... I just want to make it super easy to use and intuitive and rely on the behaviour that comes out of CSS

krit: the switch of behaviour of the text element with exclusion or width and height is confusing to me
... for shapes suddenly x and y are not relevant anymore
... and for your propsal y changes meaning

shepazu: not in my proposal, that's just Cam's implementation

krit: x and y set the position of individual characters in general

heycam: if you specify width and height x and y get ignored
... but if you don't use automatic wrapping they are used
... I don't think it makes sense to combine automatic wrapping with glyph position

shepazu: I don't see the argument for adding a new element

TabAtkins: the argument is that switching modes based on some indicator is not nice

heycam: I like continuing with the text element. It feels like it's not a bigger feature
... I don't see a problem with making x and y have no effect when you're in a certain mode

shepazu: let's be clear, cam is proposing different behaviour than me
... my proposal is for the version without text wrapping, the text is all on one line
... that's CSS behaviour, if you don't specify a width the text will just keep going
... I thought I heard Cameron say that he wants to solve the case of aligning the text box to another shape
... by overriding the y property

heycam: if you want the rectangle you use top and left, if you just want wrapping you use x and y

krit: we may not need the fall back for Tav's proposal

heycam: an authoring tool would want to output x and y positions for manual line wrapping for ua's that don't do the wrapping automatically

krit: in Tav's proposal you always have tspans which represent one line

heycam: Doug what do you think about supporting both positioning proposals?
... one origin based with x,y and the other the corner of the rect with top,left

shepazu: it seems sensible to me
... the goal I have is to make the most intuitive, easiest text wrapping the default
... the box model CSS like thing that you are talking about might be the behaviour that CSS people default to
... I would hope that an authoring tool would provide x and y for fall back

krit: regarding Tav's proposal, if we discuss comma separated shapes, they are seen as one shape
... what you need is the overflow region spec

TabAtkins: it sounds like we want a property that gives a positioning mode and sets whether x and y is the start corner or the baseline of the first line of text
... I don't know if I like how top,left and x,y would combine together

shepazu: I'm a little more sympathetic to Tab's proposal than yours Cam
... it seems to me that both behaviours are desirable
... makes more sense to set alignment models
... there is a text-valign in CSS?

TabAtkins: what you want is the alignment properties in the alignment draft

<TabAtkins> http://dev.w3.org/csswg/css-align

shepazu: the reason I like Tab's proposal more is that it seems manipulable in the same way as other things in CSS
... and the more we rely on out the box CSS behaviour the easier it is for implementers and authors

AlexD: I like Tav's proposal and we should pursue it

<AlexD> Tav's not Tab's

shepazu: I want to go back to Tav's proposal - i believe that the x and the y inside flowing areas would probably just be ignored when inside alignment things
... my proposal would still allow the fall-backs
... Tav's proposal would follow the pace of the CSS WG. My solution we could get out quickly
... I'd like to pursue this
... I would like to ask for resolution to see if we can start putting this in the spec
... and refining the details
... I'd like to start with width and height being a proposal for SVG 2

Tav: I think the only difference is that your proposal defines a rectangle differently to mine. I think we can do both

shepazu: I agree

krit: My concern is that we keep adding features to SVG 2 and we'll never finish

Tav: this is one of the most important features

shepazu: yes

krit: I have nothing against adding it to the specification, I'm just saying we should finish what we have

Tav: I think this will be the last major thing that we add

birtles: fixing the DOM is the other big one

AlexD: is textarea from 1.2 deprecated?
... I really think we should look at the more complex proposal that Tav has put together.
... the simple proposal may take longer than we think and the complex proposal is on a quick path

shepazu: Mine can be implemented very quickly and relies on CSS
... I think it's also much simpler for authors
... this is the equivalent of a canned effect for text
... it will be intuitive to authors because they are familiar with CSS
... I think we should do both but I think my proposal makes it easy for authors to do the simple cases

AlexD: the webkit and blink code support css regions so it makes it trivial to implement the shape filling
... Cam I'd like to know how yours works with x,y,dx,dy on tspans
... I can see lots of complications

heycam: I ignored it because it was a quick implementation
... I think it would interpret dx,dy post layout
... following x,y,dx,dy when wrapping to a rectangle doesn't make much sense so they should be used for fall-back
... at least for x,y
... you could possibly do something with dx,dy

AlexD: I would suggest we take Doug's proposal to the FXTF and get opinions
... I could see it getting hit over the head

heycam: I think the problems in the past were related to defining our own algorithms
... this might not have the same problem

shepazu: let's take it to the CSS WG and see what they say

heycam: we can bring it up during the FX meeting to get a feel

krit: Do we want to make a resolution or discuss on the mailing list?

AlexD: how about someone spend 5 minutes and propose to FX

shepazu: We'll talk about it tomorrow and make any resolutions then

heycam: Does it make sense to have overflow:auto and overflow:scroll ?
... it's common flash
... and could handle the case where you have a different font

shepazu: I anticipated that would fall out of the model during implementation

heycam: I think it's something to consider making work in the spec
... I think in Switzerland we were talking about more general overflow in SVG
... we may want to re-visit that

shepazu: it could be that CSS WG wants us to talk about margins and padding for these regions
... whatever let's us get it out there

Break time

<cabanier1> scribenick: cabanier

CSS syntax in presentation attributes

<cabanier1> heycam: should attributes use all the css parsing rules

<cabanier1> … my view is that it's simpler if it's the same parsing

<cabanier1> … but we could disable comments and escapes

<cabanier1> krit: is that a requirement?

<cabanier1> heycam: it's doesn't exactly say

<cabanier1> … but implementation vary

<cabanier1> krit: ff and wk support comment

<cabanier1> TabAtkins: in my syntax draft I have 2 algorithms that svg can use

<cabanier1> … in general SVG wants use parser componentvalue

<cabanier1> … and parse al ist of component values

<cabanier1> … and then you put whatever grammar on top that you want

<cabanier1> heycam: I think I agree with that but Tav expressed doubt in the past

<cabanier1> TabAtkins: being consisten with the rest of the platform is a good benfit

<cabanier1> … writing the parser based on my spec should be very little work.

<cabanier1> krit: so it can start with a '{'

<cabanier1> TabAtkins: that would be an invalid value

<cabanier1> heycam: the issue is if we want to parse with the css parser

<cabanier1> krit: how about uniltless values

<cabanier1> TabAtkins: that's beyond this spec. it's just a scanner

<cabanier1> … it will matches braces against each other

<cabanier1> krit: it's a tokenizer

<cabanier1> TabAtkins: yes

<cabanier1> heycam: difference is that whitespace is now allowed

<cabanier1> … we don't say how to parse them

<cabanier1> TabAtkins: the values spec says it should be ignored

<cabanier1> heycam: not all implementations do that

<cabanier1> … maybe how those things are parsed are new so might be different from the past

<cabanier1> krit: how about width?

<cabanier1> TabAtkins: an svg length can be a number or a unit

<cabanier1> … you can say that the grammar for the presentation attribute can be a number or a unit

<cabanier1> … with the number be a unit like px

<cabanier1> … so when you read it back out, you'd get a unit

<cabanier1> … the presentation attributes would have made the switch for you

<cabanier1> krit: we'd need a grammar section in SVG then

<cabanier1> TabAtkins: yes

<cabanier1> krit: we have a parsing section in the svg spec

<cabanier1> heycam: we will have to create rules to map presentation attributes to property values, and we will allow a <number> at that point

<krit> http://www.w3.org/TR/SVG/single-page.html#types-BasicDataTypes

<cabanier1> krit: svg 1.2 had the grammar section but it seems to be removed from 2.0

<cabanier1> heycam: much of this section can go away

<cabanier1> … but we need to replace it what parser to use and how to map presentation attributes to property values

<cabanier1> TabAtkins: the quirks modes spec defines a quirky length that we can reuse

<cabanier1> krit: how about angle

<cabanier1> heycam: I don't think we need to care

<cabanier1> krit: svg transform needs it but I think I handled it in CSS Transforms

<cabanier1> heycam: there are non-presentation attributes such as x, y on rect

<cabanier1> … but not a problem since we don't handle them as SVG animated lenghts

<cabanier1> TabAtkins: hmmm, looks like you can't use quirky length

<cabanier1> heycam: so, does anyone else have objections?

<cabanier1> krit: I can live with it

<cabanier1> heycam: I prefer the css parser

<cabanier1> krit: it makes sense

<cabanier1> Tav: If it's really simple it sounds good

<cabanier1> RESOLUTION: presentation attributes will be parsed using the css parser so they will accept comments, etc

SVGSVGElement.current{Translate,Scale,Rotation}

<krit> http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement

<cabanier1> krit: we want to have transforms on SVGSVGElement

<cabanier1> … there are properties like currentScale and currentTranslate

<cabanier1> … the definition is not specified for innerSVGElement

<cabanier1> … the question what it should return for the root SVG element that has a transform on it

<cabanier1> heycam: I think they were for current zoom level

<cabanier1> … and panning

<cabanier1> TabAtkins: I don't think that transform should apply here

<cabanier1> … just the pan and zoom

<cabanier1> RESOLUTION: currentScale and currentTranslate is not affected by transforms

<cabanier1> ACTION: krit to specify unspecified behavior of currentScale and currentTranslate [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action05]

<trackbot> Created ACTION-3501 - Specify unspecified behavior of currentScale and currentTranslate [on Dirk Schulze - due 2013-06-11].

Security of resource documents

krit: there are 2 different security concern

… svg as an image

… and svg in a different document that is reference

heycam: like a resource document

krit: the first use case is to have the user upload an SVG doc

… and you can reference an image in a different domain

… and then you can figure out how many people open your document

… this is why we should't allow external resources

… or scripting

heycam: what is the best list of things to disable

<heycam> https://svgwg.org/specs/integration/

… I need to do some work on it so Doug can publish it

krit: all browsers already implement this

… things that should not be enabled

heycam: data uri is fine

krit: references within the same document are fine

TabAtkins: same origin with a unique origin

heycam: no external references.

cabanier: not even on the same

… server

krit: no, because of redirects

heycam: you can put in a link that sends you to the local redirect which will then forward you to the external site

krit: scripting is also out

… js functions are not called

heycam: having script being able to modify it would be strange

… you'd have to find all the things like xhr that try to get out and block them

<heycam> https://svgwg.org/specs/integration/#secure_static_mode

<heycam> sorry, this one: https://svgwg.org/specs/integration/#secure_animated_mode

krit: I'm unsure that 'external references' is enough

heycam: are you allowed to reference 'a#xxx' or '#xxx'

<heycam> where "a" is the actual URL of the resource document

krit: we need more text for external reference and then it's fine

heycam: 2.1 defines it

krit: we should discuss this with Anne

https://svgwg.org/specs/integration/#definitions

… I think we are in agreement?

heycam: yes, for all image-like use

… did roc say that you want to allow external resource if there's a cors attribute on the image element

krit: maybe we can do that in the next version
... let's move on to the external reference case

… an external document should have no information that can leak

… ie evil.com should not get any data from myback.com

… can have mask, patterm, etc that can leak any privacy

… roc's filter case uses a fedisplacement map and in combination with visiblepainted pointer event "alpa=0" it can leak information

heycam: because you can check which element are under the point

krit: pointer events should not be affected by alpha

heycam: let's talk about that later

krit: can marker etc leak information

heycam: yes

krit: but does it leak?

heycam: it could show that you're logged in

krit: clippath can influence your hit region

… and therefor you can't trust

… it implies that you have different fetching rules

… ff included the cors checking

… and we should specify this

… the referenced resource can reference other resources

… what should we do there?

… FF does this but has no restrictions on images

heycam: ok this is a resource doc, it can reference any image

krit: yes. I don't think that is a problem.

… WK can't reference anything external

… maybe we should ask experts to see if there's a problem

heycam: one thing in svg2 is that it gets the size automatically

… would that leak information because you can look at the boundingbox

… if the external site put cors on, it means that it's safe

… so I think that means it's OK

krit: SVG resource loading needs to be CORS enable

… and this is missing from the integration spec

… and we need to differ between image and external SVG resources

heycam: we should clarify that

… otherwise, do you want to run animations?

krit: yes

<stakagi> iframe?

krit: iframe is also an external resource

… so we should look between image and everything else

heycam: and the image content is most restricted

RESOLUTION: images should not allow any external resources and run in Secure Animated Mode
... for resource documents we want animated mode and external references are CORS enabled and images are always allowed

<scribe> ACTION: krit to talk to Doug, Anne, Boris and Roc about resource handling security in SVG and ask for review of the model [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action06]

<trackbot> Created ACTION-3502 - Talk to Doug, Anne, Boris and Roc about resource handling security in SVG and ask for review of the model [on Dirk Schulze - due 2013-06-11].

(some discussion on mask-image)

krit: I need to talk to Anne

heycam: Roc, I and krit agree on what we should do

krit: the last email from roc confused me. I didn't understand it

heycam: me neither

krit: we can't use the same fetching for images and resources

heycam: what for new properties that might reference an element or a whole document

… are there going to be more case where the # changes fetching behave

krit: yes, everything that url uses

… we can reuse the same technique in the CSS shapes proposal for instance

… same for fill and stroke. those can use css image in the future

… I don't like the current model

… I would prefer to redesign the url function so it's consistent everywhere it's used

heycam: yes. that's your preferece

… my proposal is to specify the mask properties so it doesn't run into this problem

… has this been discussed at public-fx?

krit: we agreed on doing the #-hack

heycam: not sure if I like it

SVG streaming

<krit> scribeNick: krit

<Cyril> http://dev.w3.org/SVG/modules/streaming

Cyril: in revious F2F I presented SVG streaming
... I updated it
... it contains 3 main sections 1) use cases
... streaming cartoons graphical annotations, lyrics, synchronized with audio (karaoke)
... 2) some definitions and associate processing
... how progressive loading works in browsers
... main definition is SVG stream, composed chunks of data, called Access Units
... some accessunits are important and needed to get current frame
... you can add it to containers like webM, MPEG

krit: is a WebM a real container format?

Cyril: it has an issue "to need defined"
... there is another section on HTML 5

5

<Cyril> http://concolato.wp.mines-telecom.fr/2013/05/31/playing-svg-content-in-html5-video-elements/

Cyril: I suggest allowing in video element or track element
... used JS player for this demo and modified it to support SVG streaming
... it allows SVG animation
... that is very nice
... [descripbes strategies to make it possible]
... video does not have CORS restriction

heycam: I think video is more like an image
... animations are allowed in referenced SVG, but not script

Cyril: there shouldn't be any restrictions on the origin of the content

heycam: it should have the same restrictions as discussed on last topic
... [describes Avatar story for social media]

Cyril: yeah, same restrictions should apply
... when you seek into the future you can data from the future
... didn't have the JS lib the last time
... I tried to map HTML5 video elements (pause)
... it doesn't pause document time, but animation
... SVG didn't pause time when I did pause() (webkit bug?)
... I needed to have a duration attribute to enable loop, hope it will be defined in WebAnimations
... I reorganized and trimmed the content of the document
... I'll contact Silvia and ask for feedback
... File formats give mapping between time and byte ranges
... [describes section 3]

heycam: if you have different elements in the doc and this could cause different behvaior on CSS selectors

Cyril: once you are on a access point, then you run as if loaded the doc for first time
... CSS would be the same
... I'd like a review of document
... it gives defintions, guidlines ect.
... you should scope elements to access points
... and the processing of stream (seeking to future)
... normative parts to SVG, HTML5
... + what happens when you put SVG in MPEG container
... I want to have an official ED for the spec

heycam: does some one disagree?
... what about conformance? just published by SVG WG?
... can be resolved later

RESOLUTION: SVG Streaming can get ED

<shepazu> yay!

<heycam> ScribeNick: heycam

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems

global coordinate system

stakagi: I want to respond to your comments about global corodinate systems

… I've prepared this page

heycam: does this differ from the proposal from last time?

stakagi: it is the same, except for the viewBox indicating the global coordinate system

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems#7.13.2_Indication_of_viewBox_in_global_coordinate_systems

birtles: in switzerland we went over the global coordinate system proposal

… we were thinking it's not necessary, or might be necessary

… in January this year we decided to focus on the iframe issue first

… so I'm not sure that we said it wasn't necessary

… but there was some confusion

krit: I think it's required to have a reference to a global coordinate system

… or at least know where in the gcs you are

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems#Issues_for_this_method

stakagi: I've listed some issues with SVG's coordinate system here

… orientation of axes is one issue

heycam: if you as the author putting together these separate iframes know that a given iframe's coordinate system has x flipped, can you not put a transform="" on the iframe yourself to flip it back?

… so if you are using tile data from some provider, how do you know what coordinate system it is in?

birtles: stakagi will think about that issue some more and get back to you

heycam: the idea of declaring a named coordinate system in the document, and then being able to reference it from a #svgView() with a viewbox in that coordinate system seems like an ok idea
... these days it's not so fashionable to use a url to identify something like a particular well known coordinate system

… I think you need that functionality, because you can't be sure that #gcs will be the ID of the GlobalCoordinateSystem element in the child tile

… but maybe a registry of coordinate system keywords would be better than urls

stakagi: I don't mind, these are just possibilities

heycam: I think both a well known coordinate system ID and being able to reference with a #hash could be useful

… the latter if you don't want to register a new keyword, and you are in control of generating the tiles and using the tiles

… is the axis orientation the only issue that requires a globalCoordinateSystem?

birtles: there are two issues listed there

… one we've talked about before is precision issues

… but we decided that might not have been a big deal, you can work around it with transforms at the top level

… also you want the individual files to be oriented in a particular view when you open the standalone

… but another position when you use them as a tile

heycam: in this proposal do you have to position the iframe explicitly? or does it happen automatically due to the gcs?

birtles: the iframe defines the area in which content will be rendered in the outer document

… (and is also used for automatic loading)

… but you still have the extra transform due to the gcs that makes the tile content appear at the right position within the iframe's rectangle

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems#7.13.3_Coodrdinate_Transformation_and_Viewport_Establishment

heycam: I see the parent document also has a gcs element. is that used in the mapping of coordinate system from the child to the parent, or only for the parent in another ancestor context?

<shepazu> I think it's important to note that a lot of this work on coordinate transformations has been done in the excellent and popular D3.js library, so we should leverage that work if possible

shepazu, I'm not sure we're doing anything more than applying CTMs that are declared in the document though. doesn't need special knowledge about WGS84 means for example.

heycam: I feel a bit better about the proposal at this iteration. the syntax needs a bit more refinement imo.

birtles: I need to process it a bit more to ensure that the gcs is strictly necessary
... takagi-san things that the parts of the specification have become clearer now, and he'd like feedback

… he doesn't mind what form the feedback takes

… being part of SVG 2 would be ideal; if there are other suggestions, that's ok too

heycam: are there parts apart from gcs and iframe?

birtles: the #svgView

heycam: maybe that's part of the gcs part of the proposal

birtles: takagi-san said this gcs might go in the metadata section of the spec

heycam: I think if it's meant to have behavioural changes it should go in the coordinate systems chapter
... maybe these proposals can remain in a separate module, and if they solidify quickly enough they could go in to SVG 2

… but for the moment stay separate

<scribe> ACTION: Brian to investigate the issues that require the global coordinate system feature [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action07]

<trackbot> Created ACTION-3503 - Investigate the issues that require the global coordinate system feature [on Brian Birtles - due 2013-06-11].

<ys-uchida> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Zoom_feature_for_media_queries

zoom feature for media queries

ys-uchida: we have two proposals

… first is a zoom feature ofr media queries

… the second is a way to calculate the zoom ratio for the display

… I'll explain the first proposal

… in the current implementation, we can control the content in the child tile according to its width or height on the parent svg, if the parent references this child svg

… the wiki page has an example of this

… the content changes its appearance according to its width and height

… it references sub-svg in different scales

… the rendering result shows how this works in current browsers

… I think the problem of using max/min-width/height properties is that you need to specify the width/height if the target content has different sizes

… we cannot simultaneously control different content with different sizes

… if we have a zoom feature, we can control different elements with different sizes, using one condition

… for example change to a high resolution version of some content if the scale is doubled

… here we propose to add a zoom feature to css mq

krit: this is something that we cannot decide in the SVG WG

… I think this is something that needs to be discussed along with the CSS WG

ys-uchida: I heard in previous meetings we have proposed similar techniques, and I heard that this should be discussed in SVG before bringing it to the CSS WG

birtles: it started here because it started as an SVG attribute, and then we decided it would probably be better as a mq

… I think it's ok for us to discuss the feature, and if we agree it's reasonable, then bring it to the css wg

Cyril: what about the custom mqs that were mentioned yesterday?

… Tab mentioned there was the possibility to define custom mqs

heycam: I think it might need information outside the document, so not sure that would help here

ys-uchida: the scale is defined by the ctm

… it's sqrt(abs(det of ctm))

… I'm not sure whether it can be defined in that way in CSS, since there's also perspective transforms, but this works for affine transforms

krit: this is not related to the zoom property?

heycam: I think this is something different from the zoom property?

<krit> http://www.css3.com/css-zoom/

krit: if it's not related to the zoom property, maybe a different name would be better

heycam: so the values of min/max-zoom are the ratio of scale of the child's root coordinate system to the parent's?
... you want the ratio of the scale of the natural width of the child tile (when you view it as a standalone document), to the size it gets rendered at in the end as part of the hierarchy of tiles

ys-uchida: my preference is that you could choose between the zoom factor calculated based on only looking at the parent, or by going up the whole hierarchy of ctms

heycam: I think using a plain number in min/max-zoom makes more sense than an absolute length value

ys-uchida: I don't have a strong opinion yet. I think always look at the chain of ctms, without using the absolute unit length values in the mq, would be ok.

heycam: this sounds a bit similar to the responsive images use cases

… not sure if it should be solved the same way or not

… maybe CSS or HTML folks would know more about that

birtles: I feel like they are related but different

… looking at <img srcset>, I'm not sure this covers the same use case

[some discussion about why min-height doesn't work]

heycam: so you could have something like "min-height: outer 100px" to mean if the height is at least 100px once you transformed the child's size to the outermost coordinate system, and including zooming

… that or specifying min-zoom: 0.5 or whatever seems to be equivalent

… not sure which is more convenient

[Tab discusses an idea he has been having for a similar media query feature]

[Tab explains that the use case expressed here isn't possible with current MQs or with his idea]

heycam: let's bring this up at the FXTF meeting tomorrow to see what CSS people think about it

Progress report of browser implementation for SVG Map

konno: I have two simple issues I want to discuss

… first is to report the progress of the browser implementation of these mapping features

… the second is a proposal to have a externalResourcesRequired-like attribute for dynamic loading

… we know that eRR was removed from SVG 2

… but an alternative is needed for dynamic loading for us

<Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Progress_report_of_browser_implementation_for_SVG_Map

… we extended Chrome to support the SVG Map features

… this supports SVG <iframe>

… we've started working on an addon for Firefox

[shows demo]

… we've started a native implementation for Firefox

… we tried to support the SVG <iframe> element, btu we haven't finished this yet

… dynamic loading is essential for mapping with tiles

… the tiles that are out of the viewport should not be loaded

… we need to control the loading according to the viewport

… so we need a means to do this

… and for unloading

… there was externalResourcesRequired in SVG 1.1

… to preserve the consistency of the existing specification, we tried to extend that attribute

… I don't have a strong opinion to re-use that attribute

… but this feature is needed for mapping

… to control loading and unloading

Cyril: you want to control loading and unloading?

konno: yes

birtles: the desire is for a hint to the user agent

… UAs at the moment try to read as much as they can initially, since on mobile devices it can be slow to warm up the data connection later

… things like MQs, generally UAs fetch all of these things immediately

… but for mapping cases, you're linking to so many resources, you want to hint the UA that you don't need to read everything that's available

Cyril: this reminds me a lot of picture/srcset

… you don't want to load it if you don't need it

birtles: ideally we want to let the browser do everything

… but does it have enough information to make that decision?

Cyril: I think we should separate the loading from unloading

… in the responsive images requirements, they had a requirement to not use scripting

… they did not want to wait for all the load events to trigger, and then make a separate request for the image

… is that also a requirement here, or can you use JS to do it here?

birtles: you're already declaratively linking to iframes

Cyril: you could create the iframes on the fly

birtles: seems a bit undesirable to have to use script just for this

… I think this is just a hint to know what strategy to employ

… if the browser had unlimited memory it shouldn't need to unload anything

Cyril: what information could you give to help the browser decide?

… when something goes out of range, it knows that

birtles: but it would still load it

Cyril: the loading is a separate issue

birtles: if you're using CSS properties to position these things, they're going to get loaded

… HTML srcset is different

… that actually controls when things get loaded

Cyril: so why don't we use <picture> or srcset? this is the same use case

birtles: I don't think it's the same

TabAtkins: I don't think UAs will be smart enough to not fetch iframe tiles

Cyril: and if you use the picture element?

TabAtkins: same thing

… it doesn't give you lazy loading behaviour. it's for resource selection behaviour.

Cyril: but you could have a <picture> element per tile?

TabAtkins: you usually don't want that in <picture>

Cyril: in <picture> there's a condition to load

TabAtkins: you want a hint that the browser can work around and figure what's best, based on the information it has

heycam: I am a bit concerned that the heuristics are hard to express as hints

… don't want these hints to just be useful for certain kinds of maps

birtles: maybe certain maps you would tend to pan, others you would tend to zoom

[konno shows the eRR extension proposal]

heycam: maybe this attribute should be able to indicate whether the user would likely zoom rather than pan? who knows

konno: I have an example of the use of this attribute in on the wiki page

… two questions: is it acceptable to extend eRR, or if not what would be an acceptable name for this?

heycam: I think eRR is not the right attribute, since it's defined to control when the load event is dispatched

… was thinking maybe display:none vs display:inline could control whether loading happens

… but that doesn't help with discarding

Cyril: I would prefer to use the same mechanism as say <picture>

… maybe the condition needs to become fuzzier

heycam: sounds a bit similar to web pages loading images as you scroll to them

Cyril: if we could introduce fuzzy conditions for media queries, then you would need a <picture> with an <iframe> inside

-- break --

heycam: I think someone should look into whether <picture> or srcset="" can work for this use case

TabAtkins: also look at preload="" on <video>
... I don't think you need control on unloading at all

heycam: so maybe there are only two values you want: one the default, for "load always, never unload", one for "load when in viewport, maybe if outside viewport, unload maybe when outside viewport"
... you always distinguish between display/visibility -- is that important?

TabAtkins: display:none will already suppress loading and maybe throw away the document

heycam: I think the visibility-based one isn't important

konno: we don't have a strong opinion on that

[konno-san will investigate <picture>, srcset, etc., and if these can't work, propose an updated attribute with a better name and values]

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Embedded_Content

heycam: I agree it makes sense to put all those elements in the one chapter

… it's a bit weird that <image> is in the Structure chapter

<Cyril> scribe: Cyril

<scribe> scribeNick: Cyril

Variable Width Stroke

birtles: I have a strawman proposal about the syntax
... Tav sent questions on how the feature should work
... Rik made some research on how illustrator works

<cabanier> proposal: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke

birtles: I'm not too invested in it
... I sent something to the list
... the few people who replied were positive
... suggested to split the width and position
... this is good as you can animate separately
... the rest I'm not sure about, it's a starting point, the @ thing is weird

Tab: I don't like position type
... we had the same thing with gradients
... putting a requirement that you can only used one unit at a time is not good
... there are ways to fix that

birtles: good feedback
... positions would become a series of length
... don't know how to handle the segment thing

tab: you can make new units

heycam: we had the same issue in marker
... maybe we can solve that in the same way

birtles: the @ symbol, I don't know what to do with that

heycam: you can use the word 'at'

TabAtkins: you could have value position , value position, ... a comma for each pair

birtles: possible notation for this feature
... I've also put an asymmetric example

heycam: have we decided ?

<TabAtkins> stroke-widths: [<width> <position>]# repeat?

birtles: no but we wanted to make sure that it was extensible

TabAtkins: why is stroke width value just a number

heycam: this will become a length

birtles: no they are multipliers

TabAtkins: we should use % instead so that we can do absolute if needed
... % would be relative to the width value

birtles: ok

Tav: it makes the string a bit longer

birtles: it could start to add up

TabAtkins: I don't understand why we are minimizing the size of the property

birtles: fine
... that's it for syntax

nikos: what about defining a stroke widht pattern and apply it to multiple paths

birtles: that's the .hair pattern in the example

TabAtkins: what does repeat do when you use %

cabanier: I don't think repeat is really necessary
... brushes would be better

birtles: there is also a star example (letter c)

Cyril: you can't have discontinuity/jump at segment?

birtles: no you cannot
... with position you could

heycam: do the numbers mean points on a Catmull-Rom curves or straight lines

Tab: we are talking about having one smoothing type
... for the interpolation type

Cyril: with an additional property

Tav: why not
... and there is the question on whether you could change the interpolation type per point

heycam: I'm not sure you want to embed general path syntax in the property
... you could use functional notation maybe

<heycam> stroke-widths-values: curve(10, 20, 10) straight(10) curve(10, 20, 10)

<TabAtkins> stroke-width-values: 10 c, 20 c, 10 c, 10 s, 10 c, 20 c, 10 c;

<TabAtkins> stroke-width-values: [[c | s]? && <length>]#

C 10, 20, 10, L 10 C 20 10 ...

TabAtkins: what happens at position 0 in the path ?
... the default should just be 100%

cabanier: yes

TabAtkins: this is equivalent to using the base value in animations

<Tav> http://tavmjong.free.fr/SVG/VARIABLE_WIDTHS/

birtles: I think we should have one width per point

TabAtkins: you wouldn't be able to mix arbitrary position and point-position

Tav: I posted a link with some experiments with caps and joins

cabanier: doe sInkscape have that ?

Tav: partly
... it's pretty obvious what to do with butt and round
... not sure about square
... that's the difference between the blue or black
... I think the black would be more reasonnable

heycam: it's the same reasoning as for circle

Cyril: do we allow negative widths ?

birtles: no
... once you have asymmetrical, negative width could be useful

Tav: do you change the fill ?

Cyril: according to the rendering model, no

birtles: there is a lot of added complexity with the asymmetric version

<birtles> (or more particularly, the negative stroke widths)

Tav: what do we do with arcs in end caps
... we have them in line join, not in end caps
... at first, I thought they would be
... but I think you can do the same with the last width be 0
... it's probably not worth the complexity
... round joins are also a bit complicated
... the grey is what you would get from the red lines

<cabanier> https://docs.google.com/file/d/0B26l3CHMT6bfeWwwREljMmpVRzQ/edit

birtles: still a lot details to work out

<heycam> ACTION: Brian to update the syntax of the variable stroke width proposal [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action08]

<trackbot> Created ACTION-3504 - Update the syntax of the variable stroke width proposal [on Brian Birtles - due 2013-06-11].

Color interpolation: scaling, etc.

<Tav> http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/

<heycam> ScribeNick: heycam

Tav: there are still a few problems with lighting filters, but mostly filters handle color interpolation well

… I think there is a bug in Firefox's lighting filters

… all of those on should match the colour inside as outside

… for gradients it is interesting to use linearRGB; it looks better

… the Google I/O logo would've looked better with color-interpolation:linearRGB

krit: we're not planning to do this… not clear if we can implement this in all WebKits

heycam: because you're relying on underlying libraries to do gradients for you?

krit: Skia could implement linearRGB gradients but don't yet

cabanier: wouldn't it be better to specify values in Lab and interpolate in Lab?

TabAtkins: at computed values time it's already converted to rgb

Tav: I think it's not how you define the colours, but how you interpolate them

… next is up and downscaling

… the 1x1 SVG should match the solid colour below it

heycam: what is your suggested way of doing this? opt in?

Tav: as long as it is an option

heycam: color-interpolation-scaling?

TabAtkins: just use color-interpolation

cabanier: I don't think you want color-interpolation:linearRGB to affect scaling an <image> with a PNG

… it will affect how alpha compositing happens

Tav: what does blending/compositing spec say about color interpolation?

cabanier: doesn't say anything about it

… so it should be in sRGB

Tav: so I just want people to be aware of the problems with color interpolation, and in the long run try to move towards something more correct
... ideally browsers do all operations in an ideal colour space, and then we don't need to use color-interpolation to do scaling operations correctly

cabanier: I think we need to get browsers to care about colour management

<scribe> ACTION: Tav to draft some wording for recommended scaling techniques in SVG 2 [recorded in http://www.w3.org/2013/06/03-svg-minutes.html#action09]

<trackbot> Created ACTION-3505 - Draft some wording for recommended scaling techniques in SVG 2 [on Tavmjong Bah - due 2013-06-11].

-- finish --

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/starts/stars/
Succeeded: s/0% line segments/0 length segments when the rounder corner is 50%/
Succeeded: s/with that/with using 'isolate' to get the stacking context/
Succeeded: s/in the x/in the y/
Succeeded: s/hatch path/hatchPath/
Succeeded: s/lines/hatch lines/
Succeeded: s/ignore than/ignore them/
Succeeded: s/sizde/size/
Succeeded: s/ I like Tab's proposal and we should pursue it/ I like Tav's proposal and we should pursue it/
Succeeded: s/turn things into the appropiate value/map presentation attributes to property values, and we will allow a <number> at that point/
Succeeded: s/repr/pr/
Succeeded: s/pictures/picture/
Succeeded: s/is out/goes out/
Succeeded: s/grapical anutations/graphical annotations/
Succeeded: s/karaoki/karaoke/
Succeeded: s/2) defintions precessing/2)  some definitions and associate processing/
Succeeded: s/defintion of SVG stream, composed junks of data/main definition is SVG stream, composed chunks of data, called Access Units/
Succeeded: s/HTML%/on HTML 5/
Succeeded: s/ i wanted to have iterations of loops/I needed to have a duration attribute to enable loop/
Succeeded: s/ the documetnt/ the document/
Succeeded: s/Filte formats/File formats/
Succeeded: s/scrope/scope/
Succeeded: s/Camull/Catmull/
Succeeded: s/down/up and down/
WARNING: No scribe lines found matching ScribeNick pattern: <Cyril> ...
Found ScribeNick: cabanier
Found ScribeNick: TabAtkins
Found Scribe: Cyril
Inferring ScribeNick: Cyril
Found ScribeNick: Cyril
Found ScribeNick: heycam
Found ScribeNick: nikos
Found ScribeNick: cabanier
Found ScribeNick: krit
Found ScribeNick: heycam
Found Scribe: Cyril
Inferring ScribeNick: Cyril
Found ScribeNick: Cyril
Found ScribeNick: heycam
ScribeNicks: cabanier, TabAtkins, Cyril, heycam, nikos, krit
Present: Jun Cyril Tav Tab Satoru Yusuke Tomoaki Cameron Rik Dirk Nikos Brian Shane
Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Tokyo_2013/Agenda
Found Date: 03 Jun 2013
Guessing minutes URL: http://www.w3.org/2013/06/03-svg-minutes.html
People with action items: brian heycam krit rik tav