IRC log of svg on 2013-06-03

Timestamps are in UTC.

00:10:39 [RRSAgent]
RRSAgent has joined #svg
00:10:40 [RRSAgent]
logging to
00:10:41 [trackbot]
RRSAgent, make logs public
00:10:42 [Zakim]
Zakim has joined #svg
00:10:43 [trackbot]
Zakim, this will be GA_SVGWG
00:10:44 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
00:10:44 [trackbot]
Meeting: SVG Working Group Teleconference
00:10:45 [trackbot]
Date: 03 June 2013
00:10:49 [heycam]
RRSAgent, this meeting spans midnight
00:16:42 [nikos]
nikos has joined #svg
00:28:06 [Tav]
Tav has joined #svg
00:28:33 [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?
00:29:15 [heycam]
TabAtkins, no, but it is about 15 minutes walk
00:29:20 [cabanier]
scribenick: cabanier
00:29:22 [Cyril]
Cyril has joined #svg
00:29:29 [heycam]
TabAtkins, (Mori tower is right where my hotel is)
00:29:35 [krit]
krit has joined #svg
00:30:08 [heycam]
TabAtkins, do you have a map? it's a reasonably straightforward route
00:30:11 [TabAtkins]
00:30:18 [shans__]
shans__ has joined #svg
00:30:20 [TabAtkins]
i have google maps?
00:30:24 [TabAtkins]
00:30:35 [shans__]
TabAtkins: I can come get you if you want
00:30:47 [TabAtkins]
heh, sure
00:30:49 [TabAtkins]
00:31:19 [TabAtkins]
birtles: Yeah, I have that up, but it doesn't stop me from being dumb.
00:31:25 [shans__]
TabAtkins: OK, I'll meet you at the bottom of the mori tower?
00:31:32 [TabAtkins]
yeah, i'm at the starbucks
00:31:42 [shans__]
TabAtkins: alright, be there in 10
00:31:56 [TabAtkins]
00:33:11 [heycam]
Chair: Cameron
00:33:14 [heycam]
00:35:07 [thorton]
thorton has joined #svg
00:35:15 [konno]
konno has joined #svg
00:35:16 [konno_]
konno_ has joined #svg
00:38:02 [cabanier]
topic: agenda
00:38:12 [cabanier]
heycam: are there missing topics?
00:38:25 [cabanier]
… don't worry about scribing
00:40:10 [stakagi]
stakagi has joined #svg
00:41:11 [TabAtkins]
Shane has found me! Coming in.
00:45:02 [cabanier]
topic: should fill-rule apply to text elements?
00:45:17 [cabanier]
heycam: in svg 1.0, it applies to shapes and text
00:45:22 [cabanier]
… but does it make sense?
00:45:37 [cabanier]
Tav: maybe for SVG in OpenType?
00:45:56 [cabanier]
heycam: does it make sense to control how the path data is interpreted?
00:46:09 [cabanier]
krit: per glyph or the whole word?
00:46:11 [jun]
jun has joined #svg
00:46:18 [cabanier]
heycam: my feeling is that it's not very useful
00:46:31 [cabanier]
… so wanted to see if other people feel the same way
00:46:47 [jun]
jun has joined #svg
00:46:57 [cabanier]
… I discovered because a site was using
00:47:07 [cabanier]
cabanier: yes, it should have no effect
00:47:42 [thorton]
thorton has joined #svg
00:47:53 [cabanier]
… you are supposed to define them so that are unaware of the fill rule
00:48:29 [cabanier]
… outlining glyphs should be unaware of winding rules
00:48:46 [cabanier]
heycam: our implementation was slower for even odd
00:49:05 [cabanier]
krit: we rely on the rendering engine so it doesn't affect the winding
00:49:26 [cabanier]
nikos: so, subpixel-aa is also turned off
00:49:28 [cabanier]
heycam: yes
00:50:27 [cabanier]
heycam: what if the glyphs overlap?
00:50:48 [cabanier]
cabanier: they should paint separately and not interact with each other anyway
00:51:07 [cabanier]
heycam: so, should they work?
00:51:16 [cabanier]
everyone: no
00:51:57 [cabanier]
heycam: so we'll change the text so it doesn't aooky
00:52:45 [cabanier]
Cyril: maybe this is for SVG fonts?
00:52:51 [cabanier]
heycam: that's possible
00:53:16 [cabanier]
heycam: for SVG in OpenType, there's no way either
00:53:35 [cabanier]
resolution: fillrule does not apply to text
00:53:47 [cabanier]
topic: marker orientation issues
00:53:55 [cabanier]
tav: I added it
00:54:08 [TabAtkins]
TabAtkins has changed the topic to:
00:54:10 [cabanier]
… basically there are inconsistencies between browsers
00:54:22 [cabanier]
… you can look at the examples
00:54:31 [krit]
00:55:03 [cabanier]
… and there's also the question of rectangles
00:55:17 [cabanier]
… what do you do with rounded corners
00:55:37 [cabanier]
heycam: I remember making a test for this
00:55:49 [cabanier]
… I have a feeling that the spec should define this
00:56:06 [cabanier]
… ie angle coming from 2 different directions
00:56:21 [cabanier]
krit: is there a spec issue of is it just implemenation
00:56:32 [cabanier]
Tav: it might be just implementaion
00:57:37 [cabanier]
… for 2 subpath, they should not be treated as 1
00:58:32 [cabanier]
… I think
00:58:37 [cabanier]
(looking over the examples)
01:02:15 [cabanier]
heycam: looks like rendering issue
01:02:28 [cabanier]
tav: what with the double point?
01:02:51 [cabanier]
heycam: I wonder what the spec says?
01:03:51 [cabanier]
… (reading) it seems that you get 2 markers for double points
01:06:18 [cabanier]
krit: why would you draw points on top?
01:06:30 [cabanier]
tav: maybe in animations
01:07:12 [cabanier]
krit: I would expect the markers over each other
01:07:27 [cabanier]
tav: you always get the discontinuity
01:07:55 [cabanier]
krit: I'm more talking about transparent markers
01:08:38 [cabanier]
heycam: taking a look at the 'correct' version, I think he is right
01:09:19 [cabanier]
krit: do we need to change the spec
01:09:38 [cabanier]
heycam: yes, it should be make clearer. for instance the orientation shouldn't be in an appendxi
01:09:50 [cabanier]
… it could benefit from being rewritten
01:10:06 [cabanier]
… orientation is also used for motion path orientation
01:10:14 [cabanier]
krit: text on a path
01:10:25 [cabanier]
heycam: yes when the glyph is on the point
01:10:39 [cabanier]
… it sounds like we agree with his findings
01:10:58 [cabanier]
TabAtkins: we can't use his exact wording
01:11:38 [cabanier]
… because he wants to use coincident points to be ignorder
01:11:49 [cabanier]
heycam: he may be talking about the orientation
01:12:08 [cabanier]
… do we all agree that there should be rendering for each point?
01:12:13 [cabanier]
tav: yes
01:12:51 [AlexD]
AlexD has joined #svg
01:13:00 [cabanier]
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
01:13:23 [cabanier]
heycam: he also suggest a new value for the orient attribute
01:13:44 [cabanier]
TabAtkins: that seems to make easy double arrows
01:14:03 [cabanier]
heycam: given that you need to duplicate marker elements
01:14:44 [cabanier]
TabAtkins: no, it will flip it around. the name is unclear
01:15:01 [cabanier]
… start or reverse seem better names
01:15:30 [cabanier]
heycam: I like the idea but not the name
01:16:36 [cabanier]
tav: autoreverse?
01:16:52 [cabanier]
TabAtkins: 'auto-reverse'
01:18:13 [cabanier]
… could it be multi-value
01:18:22 [cabanier]
heycam: not sure. let me check
01:18:38 [birtles]
(discussed that 'auto-reverse' is used on animateMotion's rotate attribute with different meaning so it could be confusing)
01:18:52 [cabanier]
… currently the value for marker orient is exposed as IDL attributes
01:19:03 [cabanier]
… orient type which is an animated enumeration
01:19:10 [cabanier]
— and the angle value
01:21:02 [cabanier]
… maybe we can resolve on this new value
01:21:41 [cabanier]
resolution: we'll have a new value for orient attribute to do the right thing for arrow heads
01:23:04 [cabanier]
TabAtkins: there's an issue where there are begin and end markers on closed paths
01:23:40 [cabanier]
heycam: I find it odd that the open subpaths don't have an end
01:24:23 [cabanier]
TabAtkins: that's what the spec said. It's on path element itself
01:24:47 [cabanier]
heycam: closed subpaths should only have marker mids?
01:24:53 [cabanier]
all: yes
01:25:46 [cabanier]
heycam: markers on rects and ellipses
01:27:20 [cabanier]
(previous topic)
01:29:45 [cabanier]
(discussion on just moveto's creating markers)
01:30:02 [cabanier]
krit: we have patches to make that happen
01:31:37 [cabanier]
heycam: I thought we had tests for all this
01:32:03 [cabanier]
… but I can't find it
01:32:23 [cabanier]
… so we should decide something
01:33:16 [cabanier]
… I think it would be most consistent to paint both
01:33:32 [cabanier]
krit: this is strange
01:35:16 [cabanier]
TabAtkins: the problem is that this is a spec change
01:36:07 [cabanier]
heycam: looking at subpaths makes more sense but it seems that most implementations already agree on the just looking per path element
01:36:45 [cabanier]
… I'd be most happy with the small change
01:38:54 [thorton]
thorton has joined #svg
01:39:05 [cabanier]
TabAtkins: it all seems broken
01:39:22 [TabAtkins]
TabAtkins: All the existing renderings are broken. >_<
01:40:21 [cabanier]
krit: we should add a note that it may change in the future
01:40:53 [cabanier]
resolution: we'll keep start and end markers apply to the whole path
01:41:40 [TabAtkins]
Hey shepazu, WRITE STAR.
01:42:05 [TabAtkins]
Alternately, send me your notes and I'll write it.
01:43:15 [shepazu]
TabAtkins, I'll write star
01:43:32 [shepazu]
or at least start it
02:09:20 [Cyril]
Cyril has joined #svg
02:10:06 [cabanier]
heycam: there was 1 remaining topic on markers
02:10:15 [cabanier]
… rectangles, ellipses, etc
02:10:40 [cabanier]
tav: what about rounded corners?
02:11:02 [cabanier]
TabAtkins: all the remaining elements should define the equivalent path
02:11:41 [Zakim]
Zakim has left #svg
02:13:16 [cabanier]
heycam: you'd probably want to use marker pattern
02:13:22 [cabanier]
… should that be doable
02:13:25 [cabanier]
TabAtkins: yes
02:15:01 [cabanier]
birtles: it would be useful to have path equivalents for the rect and ellipse
02:15:12 [birtles]
(for variable-width stroke)
02:16:02 [cabanier]
resolution: closed subpaths should get no start or end markers
02:16:23 [AlexD]
+1 to that
02:19:36 [cabanier]
heycam: I already have an action to come up with equivalent paths for rects and ellipses
02:20:41 [AlexD]
Make sure ellipses use ellipse segments, not beziers!
02:22:25 [cabanier]
cabanier: yes
02:22:41 [cabanier]
TabAtkins: Canvas already defines this
02:23:00 [cabanier]
… it uses it as 4 arc paths
02:23:08 [AlexD]
02:23:50 [cabanier]
heycam: I have the action so we can draw the dashes correctly
02:24:10 [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.
02:24:19 [TabAtkins]
So we should match.
02:24:40 [cabanier]
… maybe we can copy rect over from svg tiny 1.2
02:24:52 [AlexD]
We already have tests for dashing around rects & Arcs so should be easy to check they match
02:25:05 [AlexD]
Ellipses, sorry
02:25:09 [cabanier]
TabAtkins: yes, canvas has it with the start in upper left and going clockwise
02:25:17 [heycam]
AlexD, good point
02:26:47 [AlexD]
e.g. shapes-ellipse-03-t.svg
02:28:38 [cabanier]
resolution: we need to have markers on rect, circle and ellipse and all basic shapes (in case of starts)
02:28:49 [TabAtkins]
02:29:59 [cabanier]
resolution: rounded rects start at straight horizontal line of the top left
02:30:44 [cabanier]
resolution: rounded rects wind clockwise and include 0% line segments
02:31:29 [cabanier]
s/0% line segments/0 length segments when the rounder corner is 50%
02:33:28 [cabanier]
resolution: for ellipses and circles, the path starts at right-most point and consists of 4 arcs going clockwise and each are 90 degrees
02:34:14 [cabanier]
action: heycam to integrate the marker resolutions in the spec
02:34:14 [trackbot]
Created ACTION-3496 - Integrate the marker resolutions in the spec [on Cameron McCormack - due 2013-06-10].
02:34:52 [TabAtkins]
ScribeNick: TabAtkins
02:35:32 [TabAtkins]
Topic: feBlend issues
02:36:39 [TabAtkins]
cabanier: feBlend as defined today does blending an compositing.
02:36:56 [TabAtkins]
cabanier: This is usually fine today, but if you blend with backgroundIMage, you'll get double compositing, and there's no way to avoid it.
02:37:52 [Tav]
02:38:04 [TabAtkins]
cabanier: We can either change feBlend (seems to be the only way)
02:38:14 [TabAtkins]
cabanier: We can add an attr to feBlend, so it doesn't do the compositing.
02:38:38 [TabAtkins]
cabanier: That is, do the "normal" compositing only.
02:40:04 [TabAtkins]
krit: [draws an example]
02:41:32 [TabAtkins]
cabanier: There's too much existing content out there for us to change the default behavior.
02:41:46 [TabAtkins]
cabanier: And if you don't use backgroundImage, it's not bad, and sometimes good, to composite eagerly.
02:42:27 [TabAtkins]
cabanier: So choices are add an attribute that stops compositing, or try to detect when backgroundImage is the input, and don't composite.
02:42:44 [TabAtkins]
krit: I like the attribute, because it might sometimes be useful to do the extra composite.
02:44:10 [TabAtkins]
[some side discussion about naming]
02:45:57 [TabAtkins]
TabAtkins: So it looks like just dropping backgroundImage compositing would be web-compatible?
02:46:08 [TabAtkins]
heycam: Anything else with this problem?
02:46:17 [TabAtkins]
cabanier: feComposite, but that's much more intentional.
02:48:25 [TabAtkins]
krit: There are more use-cases that might want only blending, so doing the attr seems better.
02:48:51 [TabAtkins]
ACTION krit to define a new attribute (nocomposite?) on feBlend that turns off the compositing effect.
02:48:52 [trackbot]
Created ACTION-3497 - Define a new attribute (nocomposite?) on feBlend that turns off the compositing effect. [on Dirk Schulze - due 2013-06-10].
02:51:03 [TabAtkins]
RESOLUTION: Keep feBlend's current behavior (where it blends and composites), but add an attribute that turns off compositing.
02:51:21 [TabAtkins]
Topic: enable-background issues
02:51:34 [TabAtkins]
cabanier: Today, e-b has a really long description.
02:51:42 [TabAtkins]
cabanier: I think IE implemented it, and Opera, but nobody else.
02:52:03 [TabAtkins]
TabAtkins: I think roc is against it, and we (blink) have similar concerns.
02:52:08 [TabAtkins]
cabanier: Yeah, it's really expensive.
02:52:24 [TabAtkins]
cabanier: The way it's defined today you have to render twice - once to use as the background.
02:52:31 [TabAtkins]
cabanier: Nice for authors, but hard/slow to implement.
02:52:44 [TabAtkins]
cabanier: Adobe apps do something similar under the hood, which we can add in the future.
02:52:59 [TabAtkins]
heycam: Isn't there a trick to keep you from double-rendering?
02:53:14 [TabAtkins]
cabanier: Yes, but there are still issues where you have to keep two sets of pixels, and that kills performance.
02:53:43 [AlexD]
double rendering? Isn't it just a backing store that you bitblt as the second pass? Blts are fast:-)
02:53:46 [nikos]
02:54:42 [TabAtkins]
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.
02:55:03 [TabAtkins]
heycam: But you're saying that even with that trick, due tto the arch. of accel. compositors, it'll still be slower.
02:55:20 [TabAtkins]
cabanier: Yeah. We can revisit this in the future, but we should get the basics right now.
02:56:12 [TabAtkins]
cabanier: We can define similar things to HTML's "stacking contexts" - if you ahve a <g> with opacity, it's a stacking context.
02:56:20 [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:-)
02:56:35 [TabAtkins]
No, it's not the same.
02:56:51 [TabAtkins]
You can do filters with one copy of the data in a single gpu pass.
02:56:59 [AlexD]
<g> with opacity already requires some intermediate thing - however you can do it with a pixel sequential renderer and no backing store.
02:57:01 [TabAtkins]
You don't have to go retrieve data from a different gpu pass in order to render them.
02:57:26 [TabAtkins]
[some discussion about transforms and stacking contexts]
02:57:29 [AlexD]
agreed Tab, and you can model e-b in a similar way
02:57:44 [AlexD]
backing stores can be a last resort fallback
02:57:49 [TabAtkins]
cabanier: So I think we should get rid of e-b, and say that certain elements create a fresh background.
02:58:38 [TabAtkins]
krit: e-b can still be used to create an isolation group for filters.
02:58:48 [TabAtkins]
krit: That's what's done in Opera/IE.
02:58:51 [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
02:59:09 [TabAtkins]
cabanier: It can also be used to make non-isolated groups.
03:00:01 [TabAtkins]
krit: Some properties need to create isolated groups by default anyway. For example, opacity needs to be an isolated group independently of e-b.
03:00:43 [TabAtkins]
krit: We already have some impls of e-b, and I'm not keen ot have it removed without asking the impls about it.
03:00:59 [TabAtkins]
cabanier: In the current spec langauge, it says you *must* use e-b for blending to work. We don't want that either.
03:01:22 [TabAtkins]
krit: e-b gets less necessary with the definition that some other properties make isolation groups.
03:01:29 [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...
03:01:36 [TabAtkins]
cabanier: If we can just change e-b without breaking the web, that's fine too.
03:02:44 [TabAtkins]
cabanier: To summarize, everything that creates a stacking context, creates an isolated group.
03:03:03 [TabAtkins]
heycam: So what's the use of e-b outside of that?
03:04:29 [TabAtkins]
[something about the effects of removing e-b from the spec]
03:05:06 [TabAtkins]
heycam: So when do you want e-b? Somewhere when there's not already an isolated group?
03:05:29 [TabAtkins]
cabanier: Yeah, but there are several proeprties which can make isolation without any other effects, and the 'isolation' property specifically for that.
03:05:53 [TabAtkins]
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.
03:06:17 [TabAtkins]
heycam: As long as people don't think there's strong use-cases for people using the more complicated e-b stuff.
03:07:30 [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.
03:08:19 [TabAtkins]
[rehashing of previous conversation]
03:08:51 [TabAtkins]
krit: To be clear, e-b is implementable, just not with the perf characteristics we want.
03:09:51 [AlexD]
Then you need to write better code krit:-) GPUs are so slow...
03:10:53 [TabAtkins]
[discussion of the values that 'isolate' has and their meanings]
03:11:08 [krit]
AlexD: yeah, that is why I wrote everything for the CPU :P
03:11:31 [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
03:11:45 [TabAtkins]
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.
03:12:27 [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.
03:12:39 [cabanier]
cabanier: which accesses the memory a lot more which will drain your battery
03:12:43 [TabAtkins]
heycam: If Alex can convince people later, we can add it.
03:13:26 [TabAtkins]
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]
03:14:00 [TabAtkins]
RESOLUTION: Remove e-b from this level of Filters.
03:14:35 [AlexD]
For the record I'm not for or against, just want to make sure we don't break existing content in the field
03:15:36 [TabAtkins]
krit: Should I remove e-b silently, or have a note?
03:15:48 [TabAtkins]
several: Seems useful to have a note pointing back to the old definition.
03:15:53 [TabAtkins]
Topic: What makes a stacking context?
03:16:12 [TabAtkins]
cabanier: Anything in CSS that makes a stacking context - transforms, filters, etc.
03:16:54 [TabAtkins]
heycam: Do you really want every transform attr to make a stacking context?
03:17:03 [AlexD]
03:17:15 [TabAtkins]
cabanier: No, but we want to be simple and consistent with CSS. ;_;
03:18:16 [TabAtkins]
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.
03:18:31 [TabAtkins]
krit: But impls all do normal CSS stuff.
03:18:51 [TabAtkins]
cabanier: Maybe we can say that 2d transforms in SVG dont' make a stackign context?
03:19:04 [TabAtkins]
heycam: If you want the same kinds of optimizations, maybe you do want stacking contexts.
03:19:10 [TabAtkins]
cabanier: Like smooth transitions, yes.
03:20:15 [TabAtkins]
krit: Does FF do transform transitions in hardware? WebKit doesn't do it yet (all software for SVG), but we want to change that.
03:20:17 [TabAtkins]
heycam: Same.
03:20:38 [Cyril]
RRSAgent, pointer
03:20:38 [RRSAgent]
03:20:59 [TabAtkins]
heycam: Seems like this will suck.
03:21:02 [TabAtkins]
cabanier: It will.
03:21:05 [Cyril]
RRSAgent, draft minutes
03:21:05 [RRSAgent]
I have made the request to generate Cyril
03:21:25 [TabAtkins]
krit: Rik tried to specify it around whether you're animating or not, but it didn't gain consensus - ugly flash when you change.
03:22:23 [TabAtkins]
cabanier: So maybe we can just differentiate 2d vs 3d - 2d doesn't make a stacking context in SVG.
03:23:06 [TabAtkins]
heycam: What if authors definitely want a separate layer, but ar ejust using 2d transforms?
03:23:15 [TabAtkins]
TabAtkins: Use a null 3d transform, or just use 'isolate'.
03:23:22 [TabAtkins]
heycam: Ah, I think I might be okay with that.
03:24:19 [TabAtkins]
Cyril: That seems to make sense.
03:25:04 [heycam]
s/with that/with using 'isolate' to get the stacking context/
03:25:06 [AlexD]
I like isolate better than the 3d transform hack
03:27:57 [TabAtkins]
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.
03:29:09 [TabAtkins]
krit: I think we should add an agenda for Wed to ask the other CSS implementors.
03:30:56 [TabAtkins]
cabanier: Back to the original context, also filters and opacity cause stacking contexts.
03:32:56 [TabAtkins]
Cyril: z-index also makes a stacking context?
03:33:02 [TabAtkins]
heycam: Yes, just like CSS.
03:33:22 [TabAtkins]
Tav: Question about that - we have someone wanting to implementing connectors in Inkscape.
03:33:34 [TabAtkins]
Tav: You have symbols for the components, want connectors on different layers, etc.
03:34:31 [TabAtkins]
Tav: Suppose my symbol has things with different levels.
03:37:34 [TabAtkins]
Tav: And I want to have multiple symbols sometimes interleave?
03:37:41 [TabAtkins]
[explanation of how stacking contexts work]
03:38:02 [TabAtkins]
[conclusion is - it'll work, but making the symbol itself a stacking context will prevent it]
03:39:24 [TabAtkins]
Cyril: [discussion of a layer use-case]
03:39:37 [TabAtkins]
heycam: BAck to main discussion, are people expecting blending to work through opacity?
03:39:42 [TabAtkins]
cabanier: Probably, but it's hard to make work.
03:39:52 [TabAtkins]
krit: We make them isolated groups, and I think FF does too.
03:41:53 [TabAtkins]
krit: Also masks and clips are stacking contexts.
03:41:57 [TabAtkins]
cabanier: Why are clips?
03:42:18 [TabAtkins]
TabAtkins: They're basically inverses of each other.
03:42:45 [TabAtkins]
heycam: Simple clips can be done simpler than masks, but complex clips (with overlapping curves, or text, etc.) might use the same code path.
03:44:05 [TabAtkins]
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.
03:44:10 [TabAtkins]
Topic: buffered rendering
03:44:17 [TabAtkins]
Cyril: It's a hint.
03:44:29 [TabAtkins]
krit: That's the problem. Blink is looking to implement it.
03:45:07 [TabAtkins]
krit: So it can make a stackign context sometimes - "auto" is determined by the engine.
03:45:20 [TabAtkins]
krit: So we should change "auto" to mean "don't make an image buffer".
03:45:47 [TabAtkins]
Topic: Stacking contexts, cont.
03:46:00 [TabAtkins]
[I meant that 'buffered-rendering' also causes stackign contexts.
03:46:36 [TabAtkins]
RESOLUTION: buffered-rendering:auto/dynamic never create a stacking context; "static" does.
05:07:40 [cabanier]
cabanier has joined #svg
05:09:24 [stakagi]
stakagi has joined #svg
05:09:34 [jun]
jun has joined #svg
05:10:13 [shans__]
shans__ has joined #svg
05:10:53 [ys-uchida]
ys-uchida has joined #svg
05:11:28 [krit]
krit has joined #svg
05:13:40 [Cyril]
scribe: Cyril
05:13:45 [Cyril]
scribeNick: Cyril
05:14:03 [Cyril]
heycam: someone should actually note those things that create a stacking context in the spec
05:14:17 [Cyril]
ACTION: Rik to note those things that create a stacking context in the spec
05:14:17 [trackbot]
Created ACTION-3498 - note those things that create a stacking context in the spec [on Rik Cabanier - due 2013-06-10].
05:14:40 [Cyril]
heycam: the rendering model chapter should reference the compositing/blending
05:14:51 [Cyril]
nikos: I did start updating it
05:15:18 [heycam]
05:16:26 [Cyril]
cabanier: the CSS compositing spec references that and extends it
05:17:08 [Cyril]
05:18:25 [Cyril]
cabanier: we believe that CSS Blending and CSS Filters currently extend SVG 1.1 and don't need to reference SVG 2
05:18:51 [Cyril]
krit: it depends on when SVG 2 goes to CR state
05:19:06 [Cyril]
cabanier: there needs to be a link back from SVG 2 to those 2 specs
05:19:20 [Cyril]
cabanier: does this mean those 2 specs need to be at CR stage ?
05:19:26 [Cyril]
krit: no
05:19:40 [Cyril]
Topic: review of hatches
05:19:49 [konno]
konno has joined #svg
05:19:49 [Tav]
05:20:03 [Cyril]
Tav: I'd like people to review it and tell me if it is ok
05:20:29 [Cyril]
krit: how would you implement hatches ?
05:20:48 [Cyril]
tav: creating a pattern on the fly could work
05:20:58 [Cyril]
krit: hatch as a dimension
05:21:05 [Cyril]
tav: inifinite in one direction
05:21:24 [Cyril]
... you can go to one tile but need to be carefull at tile boundary
05:21:35 [Cyril]
... I would make the tile the size of the whole thing
05:21:58 [Cyril]
... as long as you take car of the boundaries, it should work
05:22:06 [Cyril]
heycam: can you summarize the new elements
05:22:12 [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.
05:22:22 [Cyril]
tav: the hatch element copied from the pattern element
05:22:37 [heycam]
AlexD, but does that work if you want to use the hatch in the stroke of a shape?
05:22:54 [heycam]
(unless you have good stroke-to-path routines)
05:22:58 [AlexD]
Yes - you have to generate the outline of the stroke of course
05:23:25 [Cyril]
.... the hatch has a pitch to repeat
05:23:33 [AlexD]
05:23:49 [Cyril]
... the hatch has a path which defaults to a line
05:23:56 [Cyril]
... and an offset from the origin
05:24:09 [Cyril]
heycam: can you choose the origin ?
05:24:20 [Cyril]
tav: yes, that's copied from patterns
05:24:26 [AlexD]
Source code is
05:24:47 [shepazu]
(isn't the problem with patterns a matter of implementation, not an inherent problem with the spec?)
05:25:13 [Cyril]
tav: the fdifference between a normal path and a hatch path, you don't have to provide the original move to
05:25:29 [Cyril]
... if not, the y is 0 and x is that last x value
05:25:47 [Cyril]
... that's how you get the continuous
05:25:53 [Cyril]
heycam: why y = 0 ?
05:26:05 [Cyril]
tav: because you're repeating in the x direction
05:26:25 [Cyril]
... look at the 1st squiggle example
05:26:44 [Cyril]
s/in the x/in the y/
05:27:08 [Cyril]
krit: why do you need to introduce a hatch path element? why not reuse the path element?
05:27:15 [Cyril]
Tav: no initial move to
05:27:27 [Cyril]
... it's necessary to repeat
05:27:40 [Cyril]
... examples 9 and 10 show the difference between having the initial move to or not
05:28:32 [Cyril]
krit: why do you need the angle attribute since you have the transform attribute ?
05:28:45 [Cyril]
tav: maybe not needed then ...
05:29:34 [Cyril]
krit: it can be confusing in which order they apply
05:29:41 [Cyril]
tav: I have to think about it
05:30:10 [Cyril]
s/hatch path/hatchPath/
05:30:21 [Cyril]
nikos: should the d attribute be called differently ?
05:30:33 [Cyril]
krit: I'm worried about the transform attribute
05:30:43 [Cyril]
... we already have the gradientTransform ...
05:31:13 [Cyril]
tav: that's fine with me, I just copied over from pattern
05:31:25 [Cyril]
heycam: this brought the issue of capitalization of elements
05:31:33 [Cyril]
... we did not resolve firmly on it
05:31:53 [Cyril]
... especially given the HTML parsing algorithm
05:32:14 [Cyril]
... each new mixedCase name that we introduce we need to update the HTML parser
05:32:26 [Cyril]
krit: I think we should continue with our naming
05:32:36 [Cyril]
heycam: and update the HTML spec ?
05:32:48 [Cyril]
... otherwise the casing will not be preserved
05:33:12 [Cyril]
... I'm pretty sure there will be a problem if we don't do anything
05:33:25 [Cyril]
... we could say that both names work in the DOM
05:34:03 [Cyril]
krit: is it only when SVG elements are not used in an SVG subtree ?
05:34:26 [Cyril]
heycam: no, even if in an SVG subtree because the HTML parser won't know that new element
05:34:33 [Cyril]
Tav: that must be trivial to fix
05:34:57 [Cyril]
heycam: yes, but that could create problem between parsing and DOM manipulations
05:35:13 [Cyril]
... maybe it's not a big deal because people won't be doing that
05:35:45 [Cyril]
heycam: one solution could be to allow both cases to produce the same DOM element
05:36:14 [Cyril]
... because if we don't allow that we have to file a bug on the HTML spec
05:36:40 [Cyril]
krit: can you fill hatch paths ?
05:36:44 [Cyril]
Tav: no
05:37:00 [Cyril]
... that needs to be clarified
05:37:20 [Cyril]
krit: what about filters ?
05:37:24 [Cyril]
heycam: and markers ?
05:37:35 [Cyril]
... can you use the normal stroke properties ?
05:37:42 [Cyril]
Tav: yes
05:37:54 [Cyril]
... even variable width stroke, but it depends on the use case
05:38:05 [Cyril]
heycam: it makes sense to allow all stroke properties
05:38:54 [Cyril]
heycam: you could do overlapping, which you can't easily do with patterns
05:39:12 [Cyril]
Tav: overflow on the parent is not defined
05:39:42 [AlexD]
Yes, and it does that in GL/2 i.e. lines are clipped, then the stroke can go outside the original shape with line ends, etc.
05:40:00 [AlexD]
s/lines/hatch lines/
05:41:12 [Cyril]
heycam: if overflow is set to hidden, then there must be some rectangular region used for clipping
05:41:50 [Cyril]
tav: the rectangular region is infinite length
05:42:04 [Cyril]
(tav drawing on the board)
05:43:02 [Cyril]
krit: there would be a difference between overflow x and overflow y
05:43:47 [Cyril]
Tav: it would be nice to have overflow on patterns
05:43:56 [Cyril]
krit: it was implemented but then removed from the spec
05:44:06 [Cyril]
Tav: it would be easier for authors
05:44:36 [Cyril]
heycam: I do it 4 times and clip the middle
05:44:56 [Cyril]
krit: it was not implemented by Opera and Firefox
05:45:06 [Cyril]
Tav: can we revisit that for SVG 2
05:45:25 [Cyril]
heycam: let's start without it
05:46:09 [Cyril]
Tav: any other issue that people see ?
05:46:24 [Cyril]
heycam: I would start with the assumption that all stroke properties work
05:46:41 [Cyril]
krit: should all paint servers work ?
05:46:52 [Cyril]
Tav: like a hatch inside a hatch ?
05:47:00 [Cyril]
... why not if it can be implemented easily
05:47:06 [AlexD]
Mmmm, fractal hatching:-)
05:47:12 [Cyril]
heycam: most people won't use it
05:50:02 [Cyril]
heycam: if you have a hatch whose stroke properties references a paint sever defined in terms of objectboundingbox
05:50:22 [Cyril]
... which bounding box would you use, the small one or the infinite one ?
05:50:48 [Cyril]
krit: can we leave that undefined for now
05:50:53 [Cyril]
... unspecified
05:51:06 [Cyril]
heycam: I don't think it should stay unspecified
05:51:46 [Cyril]
TabAtkins: it is a mistake to leave it undefined
05:52:02 [Cyril]
Tav: we could say only solid colors for now
05:54:40 [Cyril]
RESOLUTION: Hatch will only support solid color paint servers
05:55:04 [Cyril]
Cyril: can you reuse a path?
05:55:16 [Cyril]
Tav: that's not really the same as another path?
05:55:39 [Cyril]
... currently there is only a hatchPath and it cannot reference something else
05:55:47 [Cyril]
krit: I would leave it like that
05:56:02 [Cyril]
heycam: there is a xlink:href attribute on the hatch element
05:59:09 [Cyril]
06:20:06 [mgylling]
mgylling has joined #svg
06:20:35 [TabAtkins]
06:21:01 [TabAtkins]
[Presentation from IDPF about "Advanced Hybrid Layouts" to get input from SVGWG for some questions.]
06:21:08 [TabAtkins]
[Slides will be published shortly.]
06:28:34 [Cyril]
example of "intra-navigation rendition" for Comics using SVG:
06:28:42 [Cyril]
works only in Firefox
06:29:50 [TabAtkins]
06:44:49 [Cyril]
heycam; we could have the overflow property apply to the view element
06:45:07 [Cyril]
krit: does it need to be the view element ?
06:45:19 [Cyril]
TabAtkins: yes because there is no nested svg element
06:45:24 [Cyril]
... it has to be a view
06:45:44 [Cyril]
krit: you could use the view element with use elements
06:46:16 [Cyril]
IDPF: would you feel offended if we added our own attribute
06:46:25 [Cyril]
heycam: we would prefer to define it in SVG
06:46:41 [Cyril]
TabAtkins: it sounds useful for general SVG
06:47:34 [Cyril]
IDPF: multi-lingual manga, tapping an area or moving the mouse over to change the language
06:47:56 [Cyril]
... it dosn't work on tablet
06:48:10 [Cyril]
birtles: you can use SVG animations
06:48:24 [Cyril]
TabAtkins: or HTML with hidden option elements
06:48:55 [Cyril]
... with pure HTML, no JavaScript
06:49:03 [Cyril]
heycam: relies on the fragment changing and links?
06:49:17 [Cyril]
TabAtkins: using check boxes and radio buttons and pseudo-classes
06:49:30 [Cyril]
... use check to display none
06:49:43 [Cyril]
... you can cycle between language
06:50:54 [Cyril]
birtles: if your UA supports SVG animations, it would be a lot simpler and more semantically intersting to use SVG
06:51:15 [Cyril]
IDPF: what about CSS animations?
06:51:37 [Cyril]
TabAtkins: some of it will be only possible in SVG animations
06:51:50 [Cyril]
TabAtkins: what about scaling to 100 languages
06:51:56 [Cyril]
IDPF: with menus maybe
06:52:08 [Cyril]
TabAtkins: JS would become more useful
06:52:38 [Cyril]
IDPF: could you use SVG animations to store your language preference
06:52:43 [Cyril]
Cyril: maybe using SMIL state
06:52:53 [Cyril]
birtles: you could use the switch element
06:53:01 [Cyril]
krit: I would not rely on the switch element
06:53:16 [Cyril]
IDPF: how well is the support for animation
06:53:27 [Cyril]
birtles: well in all browsers except IE
06:53:37 [Cyril]
krit: but you could use JS libraries
06:54:09 [Cyril]
06:55:39 [TabAtkins]
06:55:39 [TabAtkins]
06:55:47 [TabAtkins]
D'oh, terrible link handling.
06:55:47 [Cyril]
IDPF: How should we capture regions ?
06:55:58 [TabAtkins]
06:56:12 [TabAtkins]
^^^ Example of cycling language via HTML.
06:56:39 [TabAtkins]
(And it can be powered up with a "default language" selection as well.)
06:57:13 [Cyril]
... Should we use SVG views, SVG elements in the rendition tree or SVG elements in <defs>
06:57:40 [Cyril]
Cyril: you want to describe metadata
06:57:43 [Cyril]
IDPF: yes
06:57:49 [Cyril]
... a tree of regions
06:58:06 [Cyril]
... for navigation
06:58:10 [Cyril]
... the rest is flat
06:58:29 [Cyril]
heycam: is the description of the hierarchy inside or outside the SVG document ?
06:58:34 [Cyril]
IDPF: outside
06:58:52 [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.)
06:59:35 [Cyril]
TabAtkins: if you extend media fragment to add a polygon that might do a lot
06:59:40 [Cyril]
IDPF: yes
07:00:28 [Cyril]
Cyril: it would be good to add the metadata in the SVG document to enable viewing it with browsers
07:00:38 [Cyril]
... possibly with JS navigation logic
07:01:17 [Cyril]
IDPF: why having both views and fragment identifiers ?
07:01:22 [Cyril]
heycam: maybe for flexibility
07:01:44 [Cyril]
TabAtkins: yes it depends on who is the author of the document
07:04:11 [birtles]
SVG version of above:
07:06:52 [Cyril]
heycam: we can answer to the IDPF questions in a liaison
07:07:05 [Cyril]
... we need also to wok on the clipping question
07:08:51 [Cyril]
TabAtkins: overflow should clip the content
07:09:00 [Cyril]
... I will take the question to the CSS group
07:09:35 [Cyril]
TabAtkins: and we need to work on swapping text around
07:09:58 [Cyril]
heycam: there is also a work on custom media queries
07:10:47 [Cyril]
TabAtkins: to avoid creating a class attribute on the body (modernizr)
07:11:15 [Cyril]
IDPF: we are wondering if we should use media queries for text direction or language
07:11:20 [Cyril]
TabAtkins: it should work
07:11:45 [Cyril]
... your use cases seem appropriate for MQ
07:12:02 [Cyril]
... some properties like luminance are in CSS MQ 4
07:12:37 [heycam]
07:13:51 [Cyril]
heycam: in summary we need to answer how to represent non rectangular view, clip them, swap text, more media queries
07:20:25 [TabAtkins]
Also: where to put region information?
07:20:33 [TabAtkins]
heycam: Keep it in content where possible.
07:21:36 [Cyril]
heycam: we can consider that for SVG 2
07:22:09 [Cyril]
... you need to point to the views from outside
07:22:26 [Cyril]
... and for browser fallback to use # to those views and have sensible behavior
07:23:22 [Cyril]
IPDF: we like CR
07:23:40 [Cyril]
heycam: the original plan was to have a stable version at the end of this year
07:23:49 [Cyril]
... but I'm not sure we can make that
07:24:04 [Cyril]
heycam: we could right a separate specification if that would make your life easier
07:24:10 [Cyril]
IDPF: yes that would
07:26:47 [Cyril]
... we would need to decorate semantically the views
07:27:10 [Cyril]
heycam: I think that would be fine for you to define the semantics in the SVG document in a different namespace
07:27:24 [Cyril]
IDPF: yes that's our plan
07:27:36 [Cyril]
... also order would be significant
07:28:18 [Cyril]
heycam: arbritrary authoring tools might not preserve the order
07:29:38 [Cyril]
IDPF: but we might need to represent the order in our external navigation metadata documet
07:29:52 [Cyril]
heycam: I will gather our ideas and send that as a liaison
07:30:08 [Cyril]
ACTION: heycam to gather ideas for solving IDPF issues and send that as a liaison
07:30:08 [trackbot]
Created ACTION-3499 - Gather ideas for solving IDPF issues and send that as a liaison [on Cameron McCormack - due 2013-06-10].
07:58:52 [heycam]
ScribeNick: heycam
07:59:06 [heycam]
Topic: multiple paint servers on one element
08:00:33 [heycam]
Tav: sometimes you want a crosshatch
08:00:37 [heycam]
… you could have multiple fills on an object
08:00:45 [heycam]
… it might be useful to have a colour fill and with a hatch on top
08:00:49 [heycam]
… how to specify this?
08:00:55 [heycam]
… maybe a comma separated list?
08:00:59 [heycam]
krit: and what about the fallback value?
08:01:08 [heycam]
… fill/stroke have a paint server reference and a fallback value
08:01:11 [heycam]
… how does that work?
08:01:15 [heycam]
TabAtkins: just like background, the last thing would be a colour
08:01:20 [heycam]
… and you'd fall back to that
08:01:36 [heycam]
… it's comma separated, but the last layer can be a colour
08:01:55 [heycam]
krit: you have a space separated fallback colour in fill/stroke now
08:03:02 [heycam]
heycam: why not have <paint> for each item?
08:03:21 [heycam]
krit: then we need to define the paint order. we should do it like background-image.
08:03:25 [heycam]
heycam: so it's backwards?
08:03:29 [heycam]
Tav: that's how I'd do it
08:06:35 [heycam]
krit: what about having fill-attachment, fill-clip, ...?
08:06:47 [heycam]
TabAtkins: do we really want that? it might be a good idea, but...
08:07:00 [heycam]
heycam: allow that for stroke as well?
08:07:03 [heycam]
Tav: yeah
08:08:25 [heycam]
RESOLUTION: We will allow multiple paints in the fill and stroke properties in SVG 2.
08:09:12 [TabAtkins]
Comma-separated, painting first layer on top, last on bottom. Only last layer can be a color or have a fallback color.
08:12:23 [heycam]
cabanier: what about the other stroke properties, like stroke-width?
08:12:32 [heycam]
heycam: having a comma separated list of stroke-dasharrays would be problematic
08:12:40 [heycam]
… we could wrap them in a function if we need to, though
08:13:42 [heycam]
krit: I don't want to support those yet
08:13:52 [heycam]
… let's just do fill and stroke properties, and leave stroke-* properties as single items for now
08:13:52 [heycam]
heycam: ok
08:14:22 [heycam]
ACTION: Tav to put multiple fills/strokes in SVG 2.
08:14:22 [trackbot]
Created ACTION-3500 - Put multiple fills/strokes in SVG 2. [on Tavmjong Bah - due 2013-06-10].
08:21:26 [heycam]
RESOLUTION: <hatch angle> will be renamed <hatch rotate>.
08:23:12 [heycam]
RESOLUTION: <hatch rotate> will allow angle units.
08:26:00 [heycam]
RRSAgent, make minutes
08:26:00 [RRSAgent]
I have made the request to generate heycam
08:27:44 [heycam]
Present: Jun, Cyril, Tav, Tab, Satoru, Yusuke, Tomoaki, Cameron, Rik, Dirk, Nikos, Brian, Shane
08:28:23 [heycam]
RRSAgent, make minutes
08:28:23 [RRSAgent]
I have made the request to generate heycam
08:32:36 [TabAtkins]
08:32:49 [TabAtkins]
08:32:53 [TabAtkins]
08:39:02 [cabanier]
cabanier has joined #svg
08:39:45 [cabanier1]
cabanier1 has joined #svg
09:31:53 [cabanier]
cabanier has joined #svg
10:54:36 [mgylling]
mgylling has joined #svg
10:58:22 [ys-uchida]
ys-uchida has joined #svg
12:57:26 [cabanier]
cabanier has joined #svg
13:52:32 [Tav]
Tav has joined #svg
14:26:25 [ys-uchida]
ys-uchida has joined #svg
15:15:08 [thorton]
thorton has joined #svg
23:57:13 [RRSAgent]
RRSAgent has joined #svg
23:57:13 [RRSAgent]
logging to
23:57:15 [trackbot]
RRSAgent, make logs public
23:57:15 [Zakim]
Zakim has joined #svg
23:57:17 [trackbot]
Zakim, this will be GA_SVGWG
23:57:17 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
23:57:18 [trackbot]
Meeting: SVG Working Group Teleconference
23:57:18 [trackbot]
Date: 03 June 2013
23:57:22 [heycam]
RRSAgent, this meeting spans midnight
23:57:24 [heycam]
Chair: Cameron
23:57:37 [heycam]
00:03:45 [stakagi]
stakagi has joined #svg
00:04:01 [AlexD]
AlexD has joined #svg
00:08:07 [shepazu]
birtles, why don't I just skype into someone else's skype?
00:08:56 [birtles]
shepazu, it might be easier to hear on the polycom
00:09:02 [AlexD]
I can't Skype, can we Zakim or G+ hangout?
00:09:02 [Cyril]
Cyril has joined #svg
00:15:36 [krit1]
krit1 has joined #svg
00:15:58 [stakagi]
stakagi has joined #svg
00:17:19 [jun]
jun has joined #svg
00:18:31 [cabanier1]
cabanier1 has joined #svg
00:19:15 [krit1]
00:19:16 [krit1]
00:19:16 [krit1]
Conference code: 1842346653
00:19:32 [krit1]
shepazu: AlexD: --^
00:19:38 [cabanier1]
usa: 8558705454
00:19:48 [AlexD]
00:19:50 [krit1]
numbers are free of charge
00:19:54 [cabanier1]
australia: 0800006620
00:20:37 [AlexD]
That Aus no. is invalid
00:20:41 [cabanier1]
sorry: 1800038970
00:20:45 [nikos]
it's valid in austria ;)
00:20:56 [konno]
konno has joined #svg
00:23:07 [nikos]
scribenick: nikos
00:23:23 [nikos]
Topic: Text flow
00:25:03 [Tav]
Tav has joined #svg
00:25:10 [Tav]
00:25:33 [nikos]
Tav: You can see some examples from InkScape
00:25:40 [nikos]
... This never gained traction
00:25:52 [nikos]
... for svg 2 we need to re think it and keep it simple and consistent with CSS
00:25:59 [nikos] proposal is to rely on CSS exclusions and shapes
00:26:19 [nikos]
... 1.2 flowed text missed padding
00:26:30 [nikos]
... those are defined in CSS exclusions
00:27:09 [nikos]
... flow between shapes goes from the first shape listed to the next
00:27:26 [nikos]
... my explanation is how it works in CSS
00:27:56 [nikos]
dirk: you can't flow text from different shapes in CSS
00:28:02 [nikos]
TabAtkins: you need to use regions for that
00:28:12 [nikos]
Tav: regions might be overkill for svg, but we can discuss that later
00:28:26 [nikos]
... there are a couple of problems. We don't have the line break and paragraph
00:28:39 [nikos]
... you can work around that using whitespace property with pre wrap and pre line
00:28:57 [ys-uchida]
ys-uchida has joined #svg
00:29:03 [nikos]
... there a a lot of other interesting things from CSS 3 that we would need: text-align, etc
00:29:30 [nikos]
... you could keep x and y on tspan and if a renderer is capable of flowing text it would ignore than and if not then use them as fallback
00:29:42 [nikos]
s/ignore than/ignore them
00:29:58 [nikos]
... so that's my proposal. Doug has another.
00:30:19 [shepazu]
00:30:26 [nikos]
heycam: you said in your blog post that some features dissapeared from CSS?
00:30:39 [nikos]
Tav: exclusions was split into two and the ability to link to SVG paths was removed
00:30:46 [nikos]
... shape inside was deferred to a future version
00:31:06 [nikos]
... this was done a couple of weeks ago. I don't know why
00:31:15 [nikos]
cabanier1: I think it was to speed up progress
00:31:38 [nikos]
Tav: the way inkscape implements is to create a path. It's not any harder to do shape inside
00:31:43 [stearns_]
shape-inside also has an issue with overflow - can't size shape to content easily
00:31:53 [nikos]
cabanier1: It's hard to specify but I don't know the details exactly
00:32:09 [nikos]
krit: The problem is with floating I think
00:32:21 [nikos]
... the idea is to iterate over the specifications quickly
00:32:30 [nikos]
... do shape outside first and then shape inside next
00:32:39 [nikos]
heycam: it seems like shape inside is the more important for SVG
00:33:41 [nikos]
shepazu: I'm fully supportive of this proposal, I think it's the right way to go in the long term
00:33:51 [nikos]
... I think you should continue to work with the CSS WG
00:34:07 [nikos]
... to ensure the SVG use cases and the nice features that you have are included in the spec
00:34:18 [nikos]
... I like the notion of the fall back and allowing people to have multiple fall backs for shaped text
00:34:29 [nikos]
krit: How do you work with x, y, and rotate on the text element?
00:34:37 [nikos]
... one of the biggest use cases is to position different characters in the doc
00:34:43 [nikos]
... how does it work in InkScape
00:34:52 [nikos]
Tav: there's no change for rotated text
00:35:02 [AlexD]
AlexD has joined #svg
00:35:04 [nikos]
krit: I mean each character is rotated independently
00:35:11 [nikos]
Tav: I think rotate is ignored
00:35:37 [nikos]
... dx and dy apply. It would be reasonable to move after positioning
00:36:00 [AlexD]
AlexD has joined #svg
00:36:04 [nikos]
Alex: I'd like to ask for aligning the box direction
00:36:18 [nikos]
heycam: how is that handled in the CSS specs?
00:36:23 [nikos]
AlexD: I'm not sure it is
00:36:37 [nikos]
... we had an algorithm in 1.2 didn't we?
00:36:47 [nikos]
... display-line?
00:37:40 [nikos]
... the second thing that people have asked for - to wrap a rectangle or shape to the text that they have
00:37:49 [shepazu]
00:38:02 [nikos]
... I don't know if we should look at that now or leave it for the future
00:38:14 [nikos]
heycam: I think it makes more sense to consider it as part of broader dynamic layout in svg
00:38:26 [nikos]
... there are probably other elements that you want to change the position of (not just text)
00:38:45 [nikos]
AlexD: if we provide a js API that gives you the height of the blocks you can use js to shape the content
00:38:50 [nikos]
heycam: I'd expect that to work already
00:38:56 [nikos]
... getBBox()
00:39:13 [nikos]
shepazu: I agree that people have been asking for this a while
00:39:25 [nikos]
... getting the path of the text from the API would also be nice
00:39:31 [shans__]
shans__ has joined #svg
00:39:47 [nikos]
... having shapes that adapt to the size of the text, that's something that we should defer and use calc()
00:39:59 [nikos]
... not a characteristic of text, but a generic use of calc() in attributes in SVG
00:40:09 [nikos]
... so they can dynamically size things according to text or other factors
00:40:43 [nikos]
heycam: one thing that might be worth tackling before the broader layout issue
00:40:51 [nikos]
... might he solved on CSS sizde
00:40:59 [nikos]
... is to change the size of the text to fit
00:41:02 [nikos]
00:41:29 [nikos]
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?
00:41:44 [nikos]
TabAtkins: no. It's been discussed in the past and might come up in the CSS f2f
00:41:54 [nikos]
... it's a hard problem because of constraints - how far it will grow
00:42:00 [nikos]
... but it's an idea we want to pursue
00:42:15 [nikos]
shepazu: has a proposal been put forward for a new unit?
00:42:28 [nikos]
TabAtkins: that's normally called percent
00:42:39 [nikos]
... in a lot of circumstances percent is relative to the space of the outer container
00:42:50 [nikos]
shepazu: I don't think SVG would deal with percentages well in that context
00:42:55 [nikos]
... unless we do width and height
00:43:00 [nikos]
... which is in my proposal
00:43:14 [nikos]
TabAtkins: having a specific unit would probably be fine
00:43:27 [nikos]
... in SVG
00:43:43 [nikos]
shepazu: one of the things about having the shape fit the size of the text
00:44:04 [nikos]
... we could allow properties from css like background colour, or outline
00:44:20 [nikos]
krit: outline is already defined for svg
00:44:33 [nikos]
shepazu: I don't know the complexity of adding that to svg
00:44:48 [nikos]
AlexD: rect with x, y and width, height = auto would be awesome
00:45:10 [nikos]
shepazu: I'd rather we add a bit of the CSS box model to SVG than make authors do it with js
00:45:45 [nikos]
heycam: it could make sense to have a rectangular area for laying out text in. We could start with that
00:45:51 [nikos]
shepazu: with Tav's proposal you don't need that
00:45:58 [nikos]
... I think our proposals are complimentary
00:46:10 [nikos]
shepazu: I'll talk about my proposal
00:46:18 [nikos]
... link at the end of Tav's proposal
00:46:24 [nikos]
... it's very simple
00:46:36 [nikos]
... depending on how clever and internationalised we want to be
00:46:42 [nikos]
... we can either allow width and height on text
00:46:50 [nikos]
... maybe you could demo your build cam?
00:47:07 [nikos]
[Doug explains his proposal]
00:48:27 [nikos]
... I have a second proposal
00:48:35 [shepazu]
00:49:01 [nikos]
... I only implemented the bit where you can specify width on the text element and it will flow downwards
00:49:26 [nikos]
[Cam shows his demo]
00:49:49 [nikos]
...y is the top of the rectangle rather than the origin of the first glyph
00:50:25 [nikos]
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
00:50:48 [nikos]
heycam: that might make it difficult to position the text rectangle
00:50:57 [nikos]
Tav: could define a different x and y
00:51:39 [nikos]
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
00:51:45 [nikos]
... and it establishes a line break context
00:52:05 [nikos]
... this brings up another point that is a failure tspan
00:52:33 [nikos]
... 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
00:52:46 [nikos]
... we should have something like x or dx inherit
00:53:11 [nikos]
... I have a second proposal which I don't like as much but has some advantages
00:53:20 [nikos]
... add properties text-wrap and text-extent
00:53:26 [nikos]
... text wrap defines the point at which the text wrap
00:53:35 [nikos]
... text-extent is the point at which the line wrapping stops
00:53:46 [nikos]
... they would also apply to vertical languages
00:54:07 [nikos]
TabAtkins: we already have terms in CSS, measure for logical width and extent for logical height
00:54:21 [nikos]
heycam: I know that CSS was talking about logicalised versions of properties
00:54:29 [nikos]
TabAtkins: we still intend to but we are not sure how or when
00:54:36 [nikos]
shepazu: I'd defer to CSS and follow them
00:54:55 [nikos]
... for now we go with intuitive (to westerners), width and height
00:55:27 [nikos]
... I don't think we should change the y location of something just because we set a width and height
00:55:36 [nikos]
krit: what about using the text area element from 1.2?
00:55:39 [nikos]
heycam: the name is bad
00:56:07 [nikos]
shepazu: in 1.2 we define an algorithm and I don't think that's a good idea for what I'm proposing
00:56:27 [nikos]
... I just want to make it super easy to use and intuitive and rely on the behaviour that comes out of CSS
00:56:46 [nikos]
krit: the switch of behaviour of the text element with exclusion or width and height is confusing to me
00:56:58 [nikos]
... for shapes suddenly x and y are not relevant anymore
00:57:08 [nikos]
... and for your propsal y changes meaning
00:57:16 [nikos]
shepazu: not in my proposal, that's just Cam's implementation
00:57:35 [nikos]
krit: x and y set the position of individual characters in general
00:57:42 [nikos]
heycam: if you specify width and height x and y get ignored
00:57:56 [nikos]
... but if you don't use automatic wrapping they are used
00:58:07 [nikos]
... I don't think it makes sense to combine automatic wrapping with glyph position
00:58:23 [nikos]
shepazu: I don't see the argument for adding a new element
00:58:40 [nikos]
TabAtkins: the argument is that switching modes based on some indicator is not nice
00:58:55 [nikos]
heycam: I like continuing with the text element. It feels like it's not a bigger feature
00:59:09 [nikos]
... I don't see a problem with making x and y have no effect when you're in a certain mode
00:59:20 [nikos]
shepazu: let's be clear, cam is proposing different behaviour than me
01:00:01 [nikos]
... my proposal is for the version without text wrapping, the text is all on one line
01:00:23 [nikos]
... that's CSS behaviour, if you don't specify a width the text will just keep going
01:00:57 [nikos]
shepazu: I thought I heard Cameron say that he wants to solve the case of aligning the text box to another shape
01:01:11 [nikos]
... by overriding the y property
01:01:29 [nikos]
heycam: if you want the rectangle you use top and left, if you just want wrapping you use x and y
01:02:05 [nikos]
krit: we may not need the fall back for Tav's proposal
01:03:04 [nikos]
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
01:03:23 [nikos]
krit: in Tav's proposal you always have tspans which represent one line
01:03:50 [nikos]
heycam: Doug what do you think about supporting both positioning proposals?
01:04:00 [nikos]
... one origin based with x,y and the other the corner of the rect with top,left
01:04:14 [nikos]
shepazu: it seems sensible to me
01:04:39 [nikos]
... the goal I have is to make the most intuitive, easiest text wrapping the default
01:04:58 [nikos]
... the box model CSS like thing that you are talking about might be the behaviour that CSS people default to
01:05:13 [nikos]
... I would hope that an authoring tool would provide x and y for fall back
01:05:41 [nikos]
krit: regarding Tav's proposal, if we discuss comma separated shapes, they are seen as one shape
01:06:10 [nikos]
... what you need is the overflow region spec
01:06:51 [nikos]
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
01:07:07 [nikos]
... I don't know if I like how top,left and x,y would combine together
01:07:24 [nikos]
shepazu: I'm a little more sympathetic to Tab's proposal than yours Cam
01:07:54 [nikos]
shepazu: it seems to me that both behaviours are desirable
01:08:07 [nikos]
... makes more sense to set alignment models
01:08:46 [nikos]
... there is a text-valign in CSS?
01:08:59 [nikos]
TabAtkins: what you want is the alignment properties in the alignment draft
01:09:37 [TabAtkins]
01:10:00 [nikos]
shepazu: the reason I like Tab's proposal more is that it seems manipulable in the same way as other things in CSS
01:10:14 [nikos]
... and the more we rely on out the box CSS behaviour the easier it is for implementers and authors
01:10:14 [nikos]
01:10:31 [nikos]
AlexD: I like Tab's proposal and we should pursue it
01:11:02 [AlexD]
Tav's not Tab's
01:11:23 [nikos]
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
01:11:40 [nikos]
s/ I like Tab's proposal and we should pursue it/ I like Tav's proposal and we should pursue it
01:11:57 [nikos]
shepazu: my proposal would still allow the fall-backs
01:12:18 [nikos]
... Tav's proposal would follow the pace of the CSS WG. My solution we could get out quickly
01:12:24 [nikos]
... I'd like to pursue this
01:12:30 [AlexD]
AlexD has joined #svg
01:12:58 [nikos]
shepazu: I would like to ask for resolution to see if we can start putting this in the spec
01:13:03 [nikos]
... and refining the details
01:13:12 [nikos]
... I'd like to start with width and height being a proposal for SVG 2
01:13:30 [nikos]
Tav: I think the only difference is that your proposal defines a rectangle differently to mine. I think we can do both
01:13:32 [nikos]
shepazu: I agree
01:13:42 [nikos]
krit: My concern is that we keep adding features to SVG 2 and we'll never finish
01:13:57 [nikos]
Tav: this is one of the most important features
01:13:59 [nikos]
shepazu: yes
01:14:15 [nikos]
krit: I have nothing against adding it to the specification, I'm just saying we should finish what we have
01:14:30 [nikos]
Tav: I think this will be the last major thing that we add
01:14:35 [nikos]
birtles: fixing the DOM is the other big one
01:14:48 [nikos]
AlexD: is textarea from 1.2 deprecated?
01:15:59 [nikos]
... I really think we should look at the more complex proposal that Tav has put together.
01:16:26 [nikos]
... the simple proposal may take longer than we think and the complex proposal is on a quick path
01:16:37 [nikos]
shepazu: Mine can be implemented very quickly and relies on CSS
01:16:48 [nikos]
... I think it's also much simpler for authors
01:17:15 [nikos]
... this is the equivalent of a canned effect for text
01:17:35 [nikos]
... it will be intuitive to authors because they are familiar with CSS
01:17:55 [nikos]
... I think we should do both but I think my proposal makes it easy for authors to do the simple cases
01:18:20 [nikos]
AlexD: the webkit and blink code support css regions so it makes it trivial to implement the shape filling
01:18:37 [nikos]
... Cam I'd like to know how yours works with x,y,dx,dy on tspans
01:18:42 [nikos]
... I can see lots of complications
01:18:51 [nikos]
heycam: I ignored it because it was a quick implementation
01:19:03 [nikos]
... I think it would interpret dx,dy post layout
01:19:22 [nikos]
... following x,y,dx,dy when wrapping to a rectangle doesn't make much sense so they should be used for fall-back
01:19:27 [nikos]
... at least for x,y
01:19:33 [nikos]
... you could possibly do something with dx,dy
01:19:49 [nikos]
AlexD: I would suggest we take Doug's proposal to the FXTF and get opinions
01:19:55 [nikos]
... I could see it getting hit over the head
01:20:09 [nikos]
heycam: I think the problems in the past were related to defining our own algorithms
01:20:14 [nikos]
... this might not have the same problem
01:21:14 [nikos]
shepazu: let's take it to the CSS WG and see what they say
01:21:24 [nikos]
heycam: we can bring it up during the FX meeting to get a feel
01:22:43 [nikos]
krit: Do we want to make a resolution or discuss on the mailing list?
01:23:05 [nikos]
AlexD: how about someone spend 5 minutes and propose to FX
01:25:36 [nikos]
shepazu: We'll talk about it tomorrow and make any resolutions then
01:26:01 [nikos]
heycam: Does it make sense to have overflow:auto and overflow:scroll ?
01:26:05 [nikos]
... it's common flash
01:26:14 [nikos]
... and could handle the case where you have a different font
01:26:28 [nikos]
shepazu: I anticipated that would fall out of the model during implementation
01:26:41 [nikos]
heycam: I think it's something to consider making work in the spec
01:26:50 [nikos]
... I think in Switzerland we were talking about more general overflow in SVG
01:26:56 [nikos]
... we may want to re-visit that
01:27:09 [nikos]
shepazu: it could be that CSS WG wants us to talk about margins and padding for these regions
01:27:16 [nikos]
... whatever let's us get it out there
01:27:22 [nikos]
Break time
01:51:27 [cabanier1]
scribenick: cabanier
01:51:42 [cabanier1]
topic: CSS syntax in presentation attributes
01:51:57 [cabanier1]
heycam: should attributes use all the css parsing rules
01:52:08 [cabanier1]
… my view is that it's simpler if it's the same parsing
01:52:22 [cabanier1]
… but we could disable comments and escapes
01:52:30 [cabanier1]
krit: is that a requirement?
01:52:38 [cabanier1]
heycam: it's doesn't exactly say
01:52:45 [cabanier1]
… but implementation vary
01:52:52 [cabanier1]
krit: ff and wk support comment
01:53:09 [cabanier1]
TabAtkins: in my syntax draft I have 2 algorithms that svg can use
01:54:13 [cabanier1]
… in general SVG wants use parser componentvalue
01:54:42 [cabanier1]
… and parse al ist of component values
01:54:58 [cabanier1]
… and then you put whatever grammar on top that you want
01:55:16 [cabanier1]
heycam: I think I agree with that but Tav expressed doubt in the past
01:55:36 [cabanier1]
TabAtkins: being consisten with the rest of the platform is a good benfit
01:55:53 [cabanier1]
… writing the parser based on my spec should be very little work.
01:56:32 [cabanier1]
krit: so it can start with a '{'
01:56:46 [cabanier1]
TabAtkins: that would be an invalid value
01:57:33 [cabanier1]
heycam: the issue is if we want to parse with the css parser
01:57:46 [cabanier1]
krit: how about uniltless values
01:58:05 [cabanier1]
TabAtkins: that's beyond this spec. it's just a scanner
01:58:17 [cabanier1]
… it will matches braces against each other
01:58:22 [cabanier1]
krit: it's a tokenizer
01:58:24 [cabanier1]
TabAtkins: yes
01:58:49 [cabanier1]
heycam: difference is that whitespace is now allowed
01:59:01 [cabanier1]
… we don't say how to parse them
01:59:13 [cabanier1]
TabAtkins: the values spec says it should be ignored
01:59:21 [cabanier1]
heycam: not all implementations do that
01:59:43 [cabanier1]
… maybe how those things are parsed are new so might be different from the past
01:59:53 [cabanier1]
krit: how about width?
02:00:11 [cabanier1]
TabAtkins: an svg length can be a number or a unit
02:01:01 [cabanier1]
… you can say that the grammar for the presentation attribute can be a number or a unit
02:01:13 [cabanier1]
… with the number be a unit like px
02:01:33 [cabanier1]
… so when you read it back out, you'd get a unit
02:01:50 [cabanier1]
… the presentation attributes would have made the switch for you
02:02:04 [cabanier1]
krit: we'd need a grammar section in SVG then
02:02:07 [cabanier1]
TabAtkins: yes
02:02:24 [cabanier1]
krit: we have a parsing section in the svg spec
02:02:51 [cabanier1]
heycam: we will have to create rules to turn things into the appropiate value
02:03:27 [heycam]
s/turn things into the appropiate value/map presentation attributes to property values, and we will allow a <number> at that point/
02:04:21 [krit]
02:04:37 [krit]
krit has joined #svg
02:04:42 [cabanier1]
krit: svg 1.2 had the grammar section but it seems to be removed from 2.0
02:05:17 [cabanier1]
heycam: much of this section can go away
02:05:41 [cabanier1]
… but we need to replace it what parser to use and how to map presentation attributes to property values
02:06:40 [cabanier1]
TabAtkins: the quirks modes spec defines a quirky length that we can reuse
02:07:00 [cabanier1]
krit: how about angle
02:07:16 [cabanier1]
heycam: I don't think we need to care
02:07:32 [cabanier1]
krit: svg transform needs it but I think I handled it in CSS Transforms
02:08:22 [cabanier1]
heycam: there are non-representation attributes such as x, y on rect
02:08:50 [heycam]
02:08:58 [cabanier1]
… but not a problem since we don't handle them as SVG animated lenghts
02:09:22 [cabanier1]
TabAtkins: hmmm, looks like you can't use quirky length
02:09:41 [cabanier1]
heycam: so, does anyone else have objections?
02:10:22 [cabanier1]
krit: I can live with it
02:10:29 [cabanier1]
heycam: I prefer the css parser
02:10:37 [cabanier1]
krit: it makes sense
02:10:54 [cabanier1]
Tav: If it's really simple it sounds good
02:11:26 [cabanier1]
RESOLUTION: presentation attributes will be parsed using the css parser so they will accept comments, etc
02:12:28 [cabanier1]
topic: SVGSVGElement.current{Translate,Scale,Rotation}
02:12:40 [krit]
02:12:45 [cabanier1]
krit: we want to have transforms on SVGSVGElement
02:13:06 [cabanier1]
… there are properties like currentScale and currentTranslate
02:13:21 [cabanier1]
… the definition is not specified for innerSVGElement
02:13:56 [cabanier1]
… the question what it should return for the root SVG element that has a transform on it
02:14:12 [cabanier1]
heycam: I think they were for current zoom level
02:14:17 [cabanier1]
… and panning
02:15:03 [cabanier1]
TabAtkins: I don't think that transform should apply here
02:15:25 [cabanier1]
… just the pan and zoom
02:16:05 [cabanier1]
RESOLUTION: currentScale and currentTranslate is not affected by transforms
02:19:02 [cabanier1]
ACTION: krit to specify unspecified behavior of currentScale and currentTranslate
02:19:02 [trackbot]
Created ACTION-3501 - Specify unspecified behavior of currentScale and currentTranslate [on Dirk Schulze - due 2013-06-11].
02:19:36 [cabanier1]
topic: Security of resource documents
02:19:58 [cabanier]
cabanier has joined #svg
02:21:27 [cabanier]
krit: there are 2 different security concern
02:21:34 [cabanier]
… svg as an image
02:21:47 [cabanier]
… and svg in a different document that is reference
02:21:54 [cabanier]
heycam: like a resource document
02:22:29 [cabanier]
krit: the first use case is to have the user upload an SVG doc
02:22:43 [cabanier]
… and you can reference an image in a different domain
02:23:17 [cabanier]
… and then you can figure out how many people open your document
02:23:41 [cabanier]
… this is why we should't allow external resources
02:23:46 [cabanier]
… or scripting
02:24:10 [cabanier]
heycam: what is the best list of things to disable
02:24:26 [heycam]
02:24:32 [cabanier]
… I need to do some work on it so Doug can publish it
02:25:02 [cabanier]
krit: all browsers already implement this
02:25:29 [cabanier]
… things that should not be enabled
02:25:36 [cabanier]
heycam: data uri is fine
02:25:54 [cabanier]
krit: references within the same document are fine
02:26:28 [cabanier]
TabAtkins: same origin with a unique origin
02:27:08 [cabanier]
heycam: no external references.
02:27:15 [cabanier]
cabanier: not even on the same
02:27:19 [cabanier]
… server
02:27:36 [cabanier]
krit: no, because of redirects
02:29:03 [cabanier]
heycam: you can put in a link that sends you to the local redirect which will then forward you to the external site
02:29:14 [cabanier]
krit: scripting is also out
02:29:26 [cabanier]
… js functions are not called
02:29:50 [cabanier]
heycam: having script being able to modify it would be strange
02:30:11 [cabanier]
… you'd have to find all the things like xhr that try to get out and block them
02:30:25 [heycam]
02:30:43 [heycam]
sorry, this one:
02:31:34 [cabanier]
krit: I'm unsure that 'external references' is enough
02:32:40 [cabanier]
heycam: are you allowed to reference 'a#xxx' or '#xxx'
02:33:01 [heycam]
where "a" is the actual URL of the resource document
02:33:33 [cabanier]
krit: we need more text for external reference and then it's fine
02:33:41 [cabanier]
heycam: 2.1 defines it
02:34:10 [cabanier]
krit: we should discuss this with Anne
02:34:26 [cabanier]
02:34:35 [cabanier]
… I think we are in agreement?
02:34:50 [cabanier]
heycam: yes, for all image-like use
02:36:07 [cabanier]
… did roc say that you want to allow external resource if there's a cors attribute on the image element
02:36:35 [cabanier]
krit: maybe we can do that in the next version
02:37:47 [cabanier]
krit: let's move on to the external reference case
02:38:04 [cabanier]
… an external document should have no information that can leak
02:38:23 [cabanier]
… ie should not get any data from
02:38:48 [cabanier]
… can have mask, patterm, etc that can leak any privacy
02:39:43 [cabanier]
… roc's filter case uses a fedisplacement map and in combination with visiblepainted pointer event "alpa=0" it can leak information
02:39:57 [cabanier]
heycam: because you can check which element are under the point
02:40:12 [cabanier]
krit: pointer events should not be affected by alpha
02:41:16 [cabanier]
heycam: let's talk about that later
02:41:27 [cabanier]
krit: can marker etc leak information
02:41:34 [cabanier]
heycam: yes
02:41:44 [cabanier]
krit: but does it leak?
02:41:55 [cabanier]
heycam: it could show that you're logged in
02:42:06 [cabanier]
krit: clippath can influence your hit region
02:42:29 [cabanier]
… and therefor you can't trust
02:43:11 [cabanier]
… it implies that you have different fetching rules
02:43:27 [cabanier]
… ff included the cors checking
02:43:34 [cabanier]
… and we should specify this
02:43:44 [cabanier]
… the referenced resource can reference other resources
02:43:52 [cabanier]
… what should we do there?
02:44:06 [cabanier]
… FF does this but has no restrictions on images
02:44:25 [cabanier]
heycam: ok this is a resource doc, it can reference any image
02:44:42 [cabanier]
krit: yes. I don't think that is a problem.
02:44:52 [cabanier]
… WK can't reference anything external
02:45:16 [cabanier]
… maybe we should ask experts to see if there's a problem
02:45:43 [cabanier]
heycam: one thing in svg2 is that it gets the size automatically
02:46:03 [cabanier]
… would that leak information because you can look at the boundingbox
02:46:34 [cabanier]
… if the external site put cors on, it means that it's safe
02:46:42 [cabanier]
… so I think that means it's OK
02:47:02 [cabanier]
krit: SVG resource loading needs to be CORS enable
02:47:11 [cabanier]
… and this is missing from the integration spec
02:47:15 [nikos1]
nikos1 has joined #svg
02:47:25 [cabanier]
… and we need to differ between image and external SVG resources
02:47:47 [cabanier]
heycam: we should clarify that
02:48:00 [cabanier]
… otherwise, do you want to run animations?
02:48:03 [cabanier]
krit: yes
02:48:23 [stakagi]
02:48:56 [cabanier]
krit: iframe is also an external resource
02:49:13 [cabanier]
… so we should look between image and everything else
02:49:24 [cabanier]
heycam: and the image content is most restricted
02:49:24 [Zakim]
Zakim has left #svg
02:52:51 [cabanier]
RESOLUTION: images should not allow any external resources and run in Secure Animated Mode
02:55:04 [cabanier]
RESOLUTION: for resource documents we want animated mode and external references are CORS enabled and images are always allowed
02:56:01 [cabanier]
action: krit to talk to Doug, Anne, Boris and Roc about resource handling security in SVG and ask for review of the model
02:56:02 [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].
02:58:19 [cabanier]
(some discussion on mask-image)
02:58:24 [cabanier]
krit: I need to talk to Anne
02:58:44 [cabanier]
heycam: Roc, I and krit agree on what we should do
02:59:11 [cabanier]
krit: the last email from roc confused me. I didn't understand it
02:59:18 [cabanier]
heycam: me neither
02:59:58 [cabanier]
krit: we can't use the same fetching for images and resources
03:00:23 [cabanier]
heycam: what for new properties that might reference an element or a whole document
03:00:45 [cabanier]
… are there going to be more case where the # changes fetching behave
03:00:58 [cabanier]
krit: yes, everything that url uses
03:01:25 [cabanier]
… we can reuse the same technique in the CSS shapes proposal for instance
03:01:55 [cabanier]
… same for fill and stroke. those can use css image in the future
03:03:10 [cabanier]
… I don't like the current model
03:03:32 [cabanier]
… I would prefer to redesign the url function so it's consistent everywhere it's used
03:03:44 [cabanier]
heycam: yes. that's your preferece
03:04:04 [cabanier]
… my proposal is to specify the mask properties so it doesn't run into this problem
03:04:32 [cabanier]
… has this been discussed at public-fx?
03:04:42 [cabanier]
krit: we agreed on doing the #-hack
03:04:49 [cabanier]
heycam: not sure if I like it
03:06:14 [cabanier]
topic: SVG streaming
03:06:35 [krit]
scribeNick: krit
03:06:49 [Cyril]
03:06:52 [krit]
Cyril: in revious F2F I presented SVG streaming
03:06:57 [krit]
Cyril: I updated it
03:07:14 [krit]
Cyril: it contains 3 main sections 1) use cases
03:07:38 [krit]
Cyril: streaming cartoons grapical anutations, lyrics, synchronized with audio (karaoki)
03:07:46 [krit]
Cyril: 2) defintions precessing
03:08:07 [krit]
Cyril: how progressive loading works in browsers
03:08:20 [krit]
Cyril: defintion of SVG stream, composed junks of data
03:08:42 [krit]
Cyril: some accessunits are important and needed to get current frame
03:09:00 [krit]
Cyril: you can add it to containers like webM, MPEG
03:09:34 [krit]
krit: is a WebM a real container format?
03:09:43 [krit]
Cyril: it has an issue "to need defined"
03:09:50 [krit]
Cyril: there is another section HTML%
03:09:51 [krit]
03:10:08 [Cyril]
03:10:10 [krit]
Cyril: I suggest allowing in video element or track element
03:10:37 [krit]
Cyril: used JS player for this demo and modified it to support SVG streaming
03:10:43 [krit]
Cyril: it allows SVG animation
03:11:43 [krit]
Cyril: that is very nice
03:11:58 [krit]
Cyril: [descripbes strategies to make it possible]
03:12:33 [krit]
Cyril: video does not have CORS restriction
03:13:11 [krit]
heycam: I think video is more like an image
03:13:25 [krit]
heycam: animations are allowed in referenced SVG, but not script
03:14:00 [krit]
Cyril: there shouldn't be any restrictions on the origin of the content
03:14:18 [krit]
heycam: it should have the same restrictions as discussed on last topic
03:14:49 [krit]
heycam: [describes Avatar story for social media]
03:15:03 [krit]
Cyril: yeah, same restrictions should apply
03:15:46 [krit]
Cyril: when you seek into the future you can data from the future
03:15:54 [krit]
Cyril: didn't have the JS lib the last time
03:16:15 [krit]
Cyril: I tried to map HTML5 video elements (pause)
03:16:26 [krit]
Cyril: it doesn't pause document time, but animation
03:17:32 [krit]
Cyril: SVG didn't pause time when I did pause() (webkit bug?)
03:17:52 [krit]
Cyril: i wanted to have iterations of loops, hope it will be defined in WebAnimations
03:18:23 [krit]
Cyril: I reorganized and trimmed the content of the documetnt
03:18:35 [krit]
Cyril: I'll contact Silvia and ask for feedback
03:18:56 [krit]
Cyril: Filte formats give mapping between time and byte ranges
03:19:25 [krit]
Cyril: [describes section 3]
03:22:15 [krit]
heycam: if you have different elements in the doc and this could cause different behvaior on CSS selectors
03:22:38 [krit]
Cyril: once you are on a access point, then you run as if loaded the doc for first time
03:22:44 [krit]
Cyril: CSS would be the same
03:23:55 [krit]
Cyril: I'd like a review of document
03:24:11 [krit]
Cyril: it gives defintions, guidlines ect.
03:24:24 [krit]
Cyril: you should scrope elements to access points
03:24:40 [krit]
Cyril: and the processing of stream (seeking to future)
03:24:48 [krit]
Cyril: normative parts to SVG, HTML5
03:25:04 [krit]
Cyril: + what happens when you put SVG in MPEG container
03:25:57 [krit]
Cyril: I want to have an official ED for the spec
03:26:06 [krit]
heycam: does some one disagree?
03:26:22 [krit]
heycam: what about conformance? just published by SVG WG?
03:26:32 [krit]
heycam: can be resolved later
03:26:53 [krit]
RESOLUTION: SVG Streaming can get ED
03:28:05 [shepazu]
04:36:23 [cabanier]
cabanier has joined #svg
04:38:29 [krit]
krit has joined #svg
04:43:44 [ys-uchida]
ys-uchida has joined #svg
04:44:41 [stakagi]
stakagi has joined #svg
04:44:57 [jun]
jun has joined #svg
04:46:25 [heycam]
ScribeNick: heycam
04:46:29 [stakagi]
04:46:30 [heycam]
Topic: global coordinate system
04:46:40 [heycam]
stakagi: I want to respond to your comments about global corodinate systems
04:46:42 [heycam]
… I've prepared this page
04:48:21 [nikos]
nikos has joined #svg
04:48:57 [konno]
konno has joined #svg
04:49:49 [heycam]
heycam: does this differ from the proposal from last time?
04:50:02 [heycam]
stakagi: it is the same, except for the viewBox indicating the global coordinate system
04:50:25 [stakagi]
04:51:12 [heycam]
birtles: in switzerland we went over the global coordinate system proposal
04:51:21 [heycam]
… we were thinking it's not necessary, or might be necessary
04:51:28 [heycam]
… in January this year we decided to focus on the iframe issue first
04:51:38 [heycam]
… so I'm not sure that we said it wasn't necessary
04:51:44 [heycam]
… but there was some confusion
04:51:53 [heycam]
krit: I think it's required to have a reference to a global coordinate system
04:51:56 [heycam]
… or at least know where in the gcs you are
04:52:17 [stakagi]
04:52:38 [heycam]
stakagi: I've listed some issues with SVG's coordinate system here
04:52:48 [heycam]
… orientation of axes is one issue
04:54:00 [heycam]
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?
04:55:44 [shepazutu]
shepazutu has joined #svg
04:55:55 [heycam]
… so if you are using tile data from some provider, how do you know what coordinate system it is in?
05:00:32 [heycam]
birtles: stakagi will think about that issue some more and get back to you
05:01:00 [heycam]
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
05:02:30 [shans__]
shans__ has joined #svg
05:02:53 [heycam]
heycam: these days it's not so fashionable to use a url to identify something like a particular well known coordinate system
05:05:03 [heycam]
… 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
05:05:13 [heycam]
… but maybe a registry of coordinate system keywords would be better than urls
05:05:26 [heycam]
stakagi: I don't mind, these are just possibilities
05:05:53 [heycam]
heycam: I think both a well known coordinate system ID and being able to reference with a #hash could be useful
05:06:34 [heycam]
… 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
05:08:50 [heycam]
… is the axis orientation the only issue that requires a globalCoordinateSystem?
05:08:53 [heycam]
birtles: there are two issues listed there
05:09:05 [heycam]
… one we've talked about before is precision issues
05:09:18 [heycam]
… but we decided that might not have been a big deal, you can work around it with transforms at the top level
05:09:31 [heycam]
… also you want the individual files to be oriented in a particular view when you open the standalone
05:09:50 [heycam]
… but another position when you use them as a tile
05:11:29 [heycam]
heycam: in this proposal do you have to position the iframe explicitly? or does it happen automatically due to the gcs?
05:13:34 [heycam]
birtles: the iframe defines the area in which content will be rendered in the outer document
05:13:41 [heycam]
… (and is also used for automatic loading)
05:13:59 [heycam]
… 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
05:17:33 [stakagi]
05:18:54 [heycam]
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?
05:19:27 [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
05:20:24 [heycam]
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.
05:23:18 [heycam]
heycam: I feel a bit better about the proposal at this iteration. the syntax needs a bit more refinement imo.
05:24:25 [heycam]
birtles: I need to process it a bit more to ensure that the gcs is strictly necessary
05:24:55 [heycam]
birtles: takagi-san things that the parts of the specification have become clearer now, and he'd like feedback
05:25:00 [heycam]
… he doesn't mind what form the feedback takes
05:25:08 [heycam]
… being part of SVG 2 would be ideal; if there are other suggestions, that's ok too
05:25:22 [heycam]
heycam: are there parts apart from gcs and iframe?
05:25:34 [heycam]
birtles: the #svgView
05:25:40 [heycam]
heycam: maybe that's part of the gcs part of the proposal
05:25:53 [heycam]
birtles: takagi-san said this gcs might go in the metadata section of the spec
05:26:11 [heycam]
heycam: I think if it's meant to have behavioural changes it should go in the coordinate systems chapter
05:27:32 [heycam]
heycam: maybe these proposals can remain in a separate module, and if they solidify quickly enough they could go in to SVG 2
05:27:36 [heycam]
… but for the moment stay separate
05:29:27 [heycam]
ACTION: Brian to investigate the issues that require the global coordinate system feature
05:29:27 [trackbot]
Created ACTION-3503 - Investigate the issues that require the global coordinate system feature [on Brian Birtles - due 2013-06-11].
05:30:07 [ys-uchida]
05:30:11 [heycam]
Topic: zoom feature for media queries
05:30:27 [heycam]
ys-uchida: we have two proposals
05:30:33 [heycam]
… first is a zoom feature ofr media queries
05:30:40 [heycam]
… the second is a way to calculate the zoom ratio for the display
05:30:44 [heycam]
… I'll explain the first proposal
05:31:23 [heycam]
… 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
05:31:31 [heycam]
… the wiki page has an example of this
05:31:44 [heycam]
… the content changes its appearance according to its width and height
05:31:52 [heycam]
… it references sub-svg in different scales
05:32:04 [heycam]
… the rendering result shows how this works in current browsers
05:32:31 [heycam]
… 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
05:32:39 [heycam]
… we cannot simultaneously control different content with different sizes
05:32:57 [heycam]
… if we have a zoom feature, we can control different elements with different sizes, using one condition
05:33:13 [heycam]
… for example change to a high resolution version of some content if the scale is doubled
05:33:20 [heycam]
… here we propose to add a zoom feature to css mq
05:33:27 [heycam]
krit: this is something that we cannot decide in the SVG WG
05:33:35 [heycam]
… I think this is something that needs to be discussed along with the CSS WG
05:34:11 [heycam]
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
05:34:27 [heycam]
birtles: it started here because it started as an SVG attribute, and then we decided it would probably be better as a mq
05:34:38 [heycam]
… 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
05:34:45 [heycam]
Cyril: what about the custom mqs that were mentioned yesterday?
05:34:53 [heycam]
… Tab mentioned there was the possibility to define custom mqs
05:35:35 [heycam]
heycam: I think it might need information outside the document, so not sure that would help here
05:36:01 [heycam]
ys-uchida: the scale is defined by the ctm
05:36:09 [heycam]
… it's sqrt(abs(det of ctm))
05:36:34 [heycam]
… 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
05:37:04 [heycam]
krit: this is not related to the zoom property?
05:37:43 [heycam]
heycam: I think this is something different from the zoom property?
05:38:50 [krit]
05:39:07 [heycam]
krit: if it's not related to the zoom property, maybe a different name would be better
05:42:43 [heycam]
heycam: so the values of min/max-zoom are the ratio of scale of the child's root coordinate system to the parent's?
05:47:37 [heycam]
heycam: 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
05:48:24 [heycam]
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
05:49:58 [heycam]
heycam: I think using a plain number in min/max-zoom makes more sense than an absolute length value
05:50:24 [heycam]
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.
05:51:23 [heycam]
heycam: this sounds a bit similar to the responsive images use cases
05:51:31 [heycam]
… not sure if it should be solved the same way or not
05:51:51 [heycam]
… maybe CSS or HTML folks would know more about that
05:52:00 [heycam]
birtles: I feel like they are related but different
05:54:23 [heycam]
… looking at <img srcset>, I'm not sure this covers the same use case
06:00:12 [heycam]
[some discussion about why min-height doesn't work]
06:00:39 [heycam]
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
06:00:52 [heycam]
… that or specifying min-zoom: 0.5 or whatever seems to be equivalent
06:00:57 [heycam]
… not sure which is more convenient
06:03:35 [heycam]
[Tab discusses an idea he has been having for a similar media query feature]
06:06:04 [heycam]
[Tab explains that the use case expressed here isn't possible with current MQs or with his idea]
06:10:20 [heycam]
heycam: let's bring this up at the FXTF meeting tomorrow to see what CSS people think about it
06:10:48 [heycam]
Topic: Progress report of browser implementation for SVG Map
06:11:10 [heycam]
konno: I have two simple issues I want to discuss
06:11:22 [heycam]
… first is to report the progress of the browser implementation of these mapping features
06:11:35 [heycam]
… the second is a proposal to have a externalResourcesRequired-like attribute for dynamic loading
06:11:41 [heycam]
… we know that eRR was removed from SVG 2
06:11:57 [heycam]
… but an alternative is needed for dynamic loading for us
06:12:14 [Cyril]
06:12:18 [heycam]
… we extended Chrome to support the SVG Map features
06:12:22 [heycam]
… this supports SVG <iframe>
06:12:36 [heycam]
… we've started working on an addon for Firefox
06:12:46 [heycam]
[shows demo]
06:14:18 [heycam]
… we've started a native implementation for Firefox
06:14:23 [heycam]
… we tried to support the SVG <iframe> element, btu we haven't finished this yet
06:17:26 [heycam]
… dynamic loading is essential for mapping with tiles
06:17:40 [heycam]
… the tiles that are out of the viewport should not be loaded
06:18:10 [heycam]
… we need to control the loading according to the viewport
06:18:16 [heycam]
… so we need a means to do this
06:18:22 [heycam]
… and for unloading
06:18:32 [heycam]
… there was externalResourcesRequired in SVG 1.1
06:19:14 [heycam]
… to preserve the consistency of the existing specification, we tried to extend that attribute
06:19:29 [heycam]
… I don't have a strong opinion to re-use that attribute
06:19:40 [heycam]
… but this feature is needed for mapping
06:19:46 [heycam]
… to control loading and unloading
06:19:56 [heycam]
Cyril: you want to control loading and unloading?
06:19:57 [heycam]
konno: yes
06:20:05 [heycam]
birtles: the desire is for a hint to the user agent
06:20:21 [heycam]
… 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
06:20:31 [heycam]
… things like MQs, generally UAs fetch all of these things immediately
06:20:49 [heycam]
… 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
06:20:54 [heycam]
Cyril: this reminds me a lot of pictures/srcset
06:20:59 [heycam]
06:21:05 [heycam]
… you don't want to load it if you don't need it
06:21:15 [heycam]
birtles: ideally we want to let the browser do everything
06:21:21 [heycam]
… but does it have enough information to make that decision?
06:21:42 [heycam]
Cyril: I think we should separate the loading from unloading
06:21:52 [heycam]
… in the responsive images requirements, they had a requirement to not use scripting
06:22:10 [heycam]
… they did not want to wait for all the load events to trigger, and then make a separate request for the image
06:22:19 [heycam]
… is that also a requirement here, or can you use JS to do it here?
06:22:30 [heycam]
birtles: you're already declaratively linking to iframes
06:22:36 [heycam]
Cyril: you could create the iframes on the fly
06:22:51 [heycam]
birtles: seems a bit undesirable to have to use script just for this
06:23:26 [heycam]
… I think this is just a hint to know what strategy to employ
06:23:35 [heycam]
… if the browser had unlimited memory it shouldn't need to unload anything
06:23:47 [heycam]
Cyril: what information could you give to help the browser decide?
06:23:56 [heycam]
… when something is out of range, it knows that
06:23:59 [heycam]
birtles: but it would still load it
06:24:07 [heycam]
Cyril: the loading is a separate issue
06:24:13 [heycam]
s/is out/goes out/
06:24:24 [heycam]
birtles: if you're using CSS properties to position these things, they're going to get loaded
06:24:27 [heycam]
… HTML srcset is different
06:24:34 [heycam]
… that actually controls when things get loaded
06:24:54 [heycam]
Cyril: so why don't we use <picture> or srcset? this is the same use case
06:24:57 [heycam]
birtles: I don't think it's the same
06:25:43 [heycam]
TabAtkins: I don't think UAs will be smart enough to not fetch iframe tiles
06:25:50 [heycam]
Cyril: and if you use the picture element?
06:25:51 [heycam]
TabAtkins: same thing
06:26:01 [heycam]
… it doesn't give you lazy loading behaviour. it's for resource selection behaviour.
06:26:09 [heycam]
Cyril: but you could have a <picture> element per tile?
06:26:18 [heycam]
TabAtkins: you usually don't want that in <picture>
06:26:31 [heycam]
Cyril: in <picture> there's a condition to load
06:26:44 [heycam]
TabAtkins: you want a hint that the browser can work around and figure what's best, based on the information it has
06:28:38 [heycam]
heycam: I am a bit concerned that the heuristics are hard to express as hints
06:28:47 [heycam]
… don't want these hints to just be useful for certain kinds of maps
06:28:56 [heycam]
birtles: maybe certain maps you would tend to pan, others you would tend to zoom
06:29:45 [heycam]
[konno shows the eRR extension proposal]
06:34:50 [heycam]
heycam: maybe this attribute should be able to indicate whether the user would likely zoom rather than pan? who knows
06:37:48 [heycam]
konno: I have an example of the use of this attribute in on the wiki page
06:40:00 [heycam]
… two questions: is it acceptable to extend eRR, or if not what would be an acceptable name for this?
06:40:33 [heycam]
heycam: I think eRR is not the right attribute, since it's defined to control when the load event is dispatched
06:41:46 [heycam]
… was thinking maybe display:none vs display:inline could control whether loading happens
06:41:51 [heycam]
… but that doesn't help with discarding
06:43:01 [heycam]
Cyril: I would prefer to use the same mechanism as say <picture>
06:43:06 [heycam]
… maybe the condition needs to become fuzzier
06:44:57 [heycam]
heycam: sounds a bit similar to web pages loading images as you scroll to them
06:45:39 [heycam]
Cyril: if we could introduce fuzzy conditions for media queries, then you would need a <picture> with an <iframe> inside
06:47:31 [heycam]
-- break --
07:04:44 [Cyril]
s/grapical anutations/graphical annotations/
07:04:57 [Cyril]
07:05:26 [Cyril]
s/2) defintions precessing/2) some definitions and associate processing/
07:06:08 [Cyril]
s/defintion of SVG stream, composed junks of data/main definition is SVG stream, composed chunks of data, called Access Units/
07:06:36 [Cyril]
s/HTML%/on HTML 5/
07:07:51 [Cyril]
s/ i wanted to have iterations of loops/I needed to have a duration attribute to enable loop/
07:08:07 [Cyril]
s/ the documetnt/ the document/
07:08:20 [Cyril]
s/Filte formats/File formats/
07:08:48 [Cyril]
07:30:54 [heycam]
heycam: I think someone should look into whether <picture> or srcset="" can work for this use case
07:31:00 [heycam]
TabAtkins: also look at preload="" on <video>
07:33:03 [heycam]
TabAtkins: I don't think you need control on unloading at all
07:35:38 [heycam]
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"
07:36:08 [heycam]
heycam: you always distinguish between display/visibility -- is that important?
07:37:57 [heycam]
TabAtkins: display:none will already suppress loading and maybe throw away the document
07:38:03 [heycam]
heycam: I think the visibility-based one isn't important
07:38:07 [heycam]
konno: we don't have a strong opinion on that
07:38:55 [heycam]
[konno-san will investigate <picture>, srcset, etc., and if these can't work, propose an updated attribute with a better name and values]
07:39:27 [stakagi]
07:42:17 [heycam]
heycam: I agree it makes sense to put all those elements in the one chapter
07:42:25 [heycam]
… it's a bit weird that <image> is in the Structure chapter
07:43:07 [Cyril]
scribe: Cyril
07:43:12 [Cyril]
scribeNick: Cyril
07:43:24 [Cyril]
Topic: Variable Width Stroke
07:43:35 [Cyril]
birtles: I have a strawman proposal about the syntax
07:43:45 [Cyril]
... Tav sent questions on how the feature should work
07:44:00 [Cyril]
... Rik made some research on how illustrator works
07:44:00 [cabanier]
07:44:33 [Cyril]
... I'm not too invested in it
07:44:39 [Cyril]
... I sent something to the list
07:44:48 [Cyril]
... the few people who replied were positive
07:44:57 [Cyril]
... suggested to split the width and position
07:45:09 [Cyril]
... this is good as you can animate separately
07:45:32 [Cyril]
... the rest I'm not sure about, it's a starting point, the @ thing is weird
07:45:38 [Cyril]
Tab: I don't like position type
07:45:45 [Cyril]
... we had the same thing with gradients
07:47:00 [Cyril]
... putting a requirement that you can only used one unit at a time is not good
07:47:07 [Cyril]
... there are ways to fix that
07:47:17 [Cyril]
birtles: good feedback
07:47:28 [Cyril]
... positions would become a series of length
07:47:35 [Cyril]
... don't know how to handle the segment thing
07:47:43 [Cyril]
tab: you can make new units
07:48:00 [Cyril]
heycam: we had the same issue in marker
07:48:07 [Cyril]
... maybe we can solve that in the same way
07:48:22 [Cyril]
birtles: the @ symbol, I don't know what to do with that
07:48:28 [Cyril]
heycam: you can use the word 'at'
07:49:17 [Cyril]
TabAtkins: you could have value position , value position, ... a comma for each pair
07:49:46 [Cyril]
birtles: possible notation for this feature
07:49:53 [Cyril]
... I've also put an asymmetric example
07:50:08 [Cyril]
heycam: have we decided ?
07:50:14 [TabAtkins]
stroke-widths: [<width> <position>]# repeat?
07:50:32 [Cyril]
birtles: no but we wanted to make sure that it was extensible
07:51:16 [Cyril]
TabAtkins: why is stroke width value just a number
07:51:22 [Cyril]
heycam: this will become a length
07:51:28 [Cyril]
birtles: no they are multipliers
07:52:23 [Cyril]
TabAtkins: we should use % instead so that we can do absolute if needed
07:52:39 [Cyril]
... % would be relative to the width value
07:53:01 [Cyril]
birtles: ok
07:53:25 [Cyril]
Tav: it makes the string a bit longer
07:53:43 [Cyril]
birtles: it could start to add up
07:54:38 [Cyril]
TabAtkins: I don't understand why we are minimizing the size of the property
07:54:47 [Cyril]
birtles: fine
07:55:28 [Cyril]
birtles: that's it for syntax
07:55:55 [Cyril]
nikos: what about defining a stroke widht pattern and apply it to multiple paths
07:56:07 [Cyril]
birtles: that's the .hair pattern in the example
07:56:32 [Cyril]
TabAtkins: what does repeat do when you use %
07:57:03 [Cyril]
cabanier: I don't think repeat is really necessary
07:57:09 [Cyril]
... brushes would be better
07:57:27 [Cyril]
birtles: there is also a star example (letter c)
08:00:41 [Cyril]
Cyril: you can't have discontinuity/jump at segment?
08:00:45 [Cyril]
birtles: no you cannot
08:01:03 [Cyril]
... with position you could
08:01:31 [Cyril]
heycam: do the numbers mean points on a Camull-Rom curves or straight lines
08:01:45 [heycam]
08:02:00 [Cyril]
Tab: we are talking about having one smoothing type
08:02:38 [Cyril]
... for the interpolation type
08:02:45 [Cyril]
Cyril: with an additional property
08:02:49 [Cyril]
Tav: why not
08:03:09 [Cyril]
... and there is the question on whether you could change the interpolation type per point
08:03:35 [Cyril]
heycam: I'm not sure you want to embed general path syntax in the property
08:03:46 [Cyril]
... you could use functional notation maybe
08:04:42 [heycam]
stroke-widths-values: curve(10, 20, 10) straight(10) curve(10, 20, 10)
08:05:34 [TabAtkins]
stroke-width-values: 10 c, 20 c, 10 c, 10 s, 10 c, 20 c, 10 c;
08:06:09 [TabAtkins]
stroke-width-values: [[c | s]? && <length>]#
08:06:16 [Cyril]
C 10, 20, 10, L 10 C 20 10 ...
08:07:40 [Cyril]
TabAtkins: what happens at position 0 in the path ?
08:08:01 [Cyril]
... the default should just be 100%
08:08:04 [Cyril]
cabanier: yes
08:08:25 [Cyril]
TabAtkins: this is equivalent to using the base value in animations
08:09:46 [Tav]
08:11:41 [Cyril]
birtles: I think we should have one width per point
08:11:59 [Cyril]
TabAtkins: you wouldn't be able to mix arbitrary position and point-position
08:13:26 [Cyril]
Tav: I posted a link with some experiments with caps and joins
08:13:34 [Cyril]
cabanier: doe sInkscape have that ?
08:13:37 [Cyril]
Tav: partly
08:14:12 [Cyril]
... it's pretty obvious what to do with butt and round
08:14:18 [Cyril]
... not sure about square
08:14:34 [Cyril]
... that's the difference between the blue or black
08:14:44 [Cyril]
... I think the black would be more reasonnable
08:15:20 [Cyril]
heycam: it's the same reasoning as for circle
08:16:22 [Cyril]
Cyril: do we allow negative widths ?
08:16:25 [Cyril]
birtles: no
08:16:52 [Cyril]
birtles: once you have asymmetrical, negative width could be useful
08:18:04 [Cyril]
Tav: do you change the fill ?
08:18:38 [Cyril]
Cyril: according to the rendering model, no
08:19:01 [Cyril]
birtles: there is a lot of added complexity with the asymmetric version
08:19:16 [birtles]
(or more particularly, the negative stroke widths)
08:20:30 [Cyril]
Tav: what do we do with arcs in end caps
08:20:37 [Cyril]
... we have them in line join, not in end caps
08:20:48 [Cyril]
... at first, I thought they would be
08:20:59 [Cyril]
... but I think you can do the same with the last width be 0
08:21:17 [Cyril]
... it's probably not worth the complexity
08:22:37 [Cyril]
... round joins are also a bit complicated
08:22:48 [Cyril]
.... the grey is what you would get from the red lines
08:26:54 [cabanier]
08:32:18 [Cyril]
birtles: still a lot details to work out
08:32:53 [heycam]
ACTION: Brian to update the syntax of the variable stroke width proposal
08:32:53 [trackbot]
Created ACTION-3504 - Update the syntax of the variable stroke width proposal [on Brian Birtles - due 2013-06-11].
08:33:57 [heycam]
Topic: Color interpolation: scaling, etc.
08:34:01 [Tav]
08:34:42 [heycam]
ScribeNick: heycam
08:34:59 [heycam]
Tav: there are still a few problems with lighting filters, but mostly filters handle color interpolation well
08:35:51 [heycam]
… I think there is a bug in Firefox's lighting filters
08:36:02 [heycam]
… all of those on should match the colour inside as outside
08:36:11 [heycam]
… for gradients it is interesting to use linearRGB; it looks better
08:36:35 [heycam]
… the Google I/O logo would've looked better with color-interpolation:linearRGB
08:37:18 [heycam]
krit: we're not planning to do this… not clear if we can implement this in all WebKits
08:37:30 [heycam]
heycam: because you're relying on underlying libraries to do gradients for you?
08:37:44 [heycam]
krit: Skia could implement linearRGB gradients but don't yet
08:38:18 [heycam]
cabanier: wouldn't it be better to specify values in Lab and interpolate in Lab?
08:38:30 [heycam]
TabAtkins: at computed values time it's already converted to rgb
08:39:02 [heycam]
Tav: I think it's not how you define the colours, but how you interpolate them
08:44:18 [heycam]
… next is downscaling
08:44:27 [heycam]
s/down/up and down/
08:46:02 [heycam]
… the 1x1 SVG should match the solid colour below it
08:48:57 [heycam]
heycam: what is your suggested way of doing this? opt in?
08:49:01 [heycam]
Tav: as long as it is an option
08:49:49 [heycam]
heycam: color-interpolation-scaling?
08:49:55 [heycam]
TabAtkins: just use color-interpolation
08:52:10 [heycam]
cabanier: I don't think you want color-interpolation:linearRGB to affect scaling an <image> with a PNG
08:52:16 [heycam]
… it will affect how alpha compositing happens
08:53:24 [heycam]
Tav: what does blending/compositing spec say about color interpolation?
08:53:29 [heycam]
cabanier: doesn't say anything about it
08:53:57 [heycam]
… so it should be in sRGB
08:58:44 [Cyril]
Cyril has joined #svg
08:59:06 [heycam]
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
09:02:47 [Cyril]
RRSAgent, draft minutes
09:02:47 [RRSAgent]
I have made the request to generate Cyril
09:09:03 [heycam]
Tav: 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
09:10:35 [heycam]
cabanier: I think we need to get browsers to care about colour management
09:13:47 [heycam]
ACTION: Tav to draft some wording for recommended scaling techniques in SVG 2
09:13:48 [trackbot]
Created ACTION-3505 - Draft some wording for recommended scaling techniques in SVG 2 [on Tavmjong Bah - due 2013-06-11].
09:13:54 [heycam]
-- finish --
09:15:18 [heycam]
RRSAgent, make minutes
09:15:18 [RRSAgent]
I have made the request to generate heycam
10:27:59 [ys-uchida]
ys-uchida has joined #svg