02:01:28 <jet> jet has joined #svg
04:15:54 <krit> krit has joined #svg
04:49:11 <jet> jet has joined #svg
06:06:49 <shepazu> shepazu has joined #svg
06:56:09 <jet> jet has joined #svg
14:07:57 <RRSAgent> RRSAgent has joined #svg
14:07:57 <RRSAgent> logging to http://www.w3.org/2012/07/24-svg-irc
14:07:59 <trackbot> RRSAgent, make logs public
14:08:01 <trackbot> Zakim, this will be GA_SVGWG
14:08:02 <trackbot> Meeting: SVG Working Group Teleconference
14:08:02 <trackbot> Date: 24 July 2012
14:08:02 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:08:18 <birtles> birtles has joined #svg
14:15:35 <cabanier> cabanier has joined #svg
14:19:13 <ed> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
14:19:24 <ed> Chair: ed
14:21:24 <Tav> Telephone?
14:21:58 <heycam> Zakim, room for 4?
14:21:59 <Zakim> ok, heycam; conference Team_(svg)14:21Z scheduled with code 26631 (CONF1) for 60 minutes until 1521Z
14:22:04 <heycam> Zakim,code?
14:22:04 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
14:22:44 <Zakim> Team_(svg)14:21Z has now started
14:22:51 <Zakim> + +1.206.675.aaaa
14:23:51 <birtles> scribenick: birtles
14:23:58 <birtles> Topic: Marker proposal review
14:24:00 <TabAtkins_> TabAtkins_ has joined #svg
14:24:02 <ChrisL> ChrisL has joined #svg
14:24:15 <ChrisL> scribenick: ChrisL
14:24:18 <Zakim> +Tav
14:24:19 <birtles> https://svgwg.org/svg2-draft/painting.html#Markers
14:24:20 <Zakim> - +1.206.675.aaaa
14:24:22 <Zakim> + +1.206.675.aaaa
14:25:23 <ChrisL> zakim, this meeting spans midnight
14:25:23 <Zakim> I don't understand 'this meeting spans midnight', ChrisL
14:25:29 <birtles> CM: I want to go through the marker part of the spec
14:25:32 <ChrisL> rrsagent, this meeting spans midnight
14:25:34 <jen> jen has joined #svg
14:25:38 <birtles> ... some might need changing
14:25:56 <nikos> nikos has joined #svg
14:25:58 <birtles> ... I've rewritten that hold section using fewer words
14:26:03 <birtles> .... I've defined different types of markers
14:26:10 <birtles> ... four kinds: (1) vertex markers
14:26:14 <birtles> ... you can do this currently
14:26:21 <birtles> ... (2) segment markers, this is a new one
14:26:28 <birtles> ... they place markers at the centre of the path segment
14:26:32 <birtles> ... (3) repeating markers
14:26:43 <birtles> ... specify a pattern like a dash to repeat markers at fixed distances along the patah
14:26:44 <ed> scribenick: birtles
14:26:47 <birtles> ... (4) position markers
14:27:00 <birtles> ... use markers as a child of a path element
14:27:10 <birtles> ... at fixed positions
14:27:11 <heycam> https://svgwg.org/svg2-draft/painting.html#MarkerSegmentProperty
14:27:41 <birtles> ... this is (2), similar to marker-mid
14:27:47 <birtles> ... but in the middle of the edge
14:27:54 <birtles> ED: what happens if you have a zero-length segment
14:27:56 <birtles> ?
14:28:17 <birtles> CM: I think it's defined but I would expect it to paint
14:28:24 <birtles> DS: what about a zero-length path?
14:28:31 <birtles> CM: I think it won't pint
14:28:39 <birtles> s/pint/paint/
14:28:52 <birtles> CM: marker-mids render on zero-length segments right?
14:29:03 <birtles> ... so in keeping with that you'd do the same here
14:29:09 <birtles> ... and render even for zero-length segments
14:29:27 <birtles> DS: what does that mean?
14:29:41 <birtles> ... so in order for it to render you have to have at least one segment of non zero-length?
14:29:55 <birtles> ... so an empty path doesn't render
14:29:57 <birtles> CM: right
14:30:21 <birtles> ... someone pointed out they'd prefer not to have a discontinuity as segments get shorter and shorter
14:30:30 <birtles> ... they shouldn't suddenly disappear
14:30:45 <birtles> ED: what about only rendering if the segment length is longer than some length?
14:30:52 <birtles> CM: that's an interesting idea
14:30:57 <birtles> DS: could be a property
14:31:22 <cabanier> cabanier has joined #svg
14:31:27 <shepazu> shepazu has joined #svg
14:31:49 <birtles> CM: apart from that marker segments aren't too complicated
14:31:59 <birtles> ... but marker patterns (3) are more interesting
14:32:01 <heycam> https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers
14:32:16 <birtles> ... in Hamburg we discussed this
14:32:33 <birtles> ... talked about having a feature where you could say "skip to the next vertex"
14:32:42 <birtles> ... but after thinking about that it didn't seem that useful to me
14:32:54 <birtles> ... and if you want things on edges and vertices then you can use the other properties
14:32:59 <birtles> TA: looks good to me
14:33:10 <birtles> CM: one thing you may want to do
14:33:23 <birtles> ... is stretch out the marker pattern so that it's an even number of markers along the path
14:33:35 <birtles> ... perhaps the pathLength attribute could affect the distances in the marker pattern?
14:33:50 <birtles> ... like with dash arrays
14:34:02 <birtles> ... so we should get that for free by using pathLength
14:34:26 <Zakim> +mdyck
14:34:29 <birtles> ... the lengths you specify in this property would be proportions of the pathLength if you specify that property
14:36:40 <birtles> DS: what's the big difference between marker and marker-pattern
14:36:48 <birtles> CM: the existing markers can only be positioned on the vertices
14:36:56 <birtles> ... but this lets you put them by distance along the path
14:37:14 <birtles> DS: if I click on one of this markers what happens?
14:37:28 <birtles> CM: these ones (1)-(3) are the same, you can't click on them
14:37:43 <birtles> ... that don't have a unique ID
14:37:55 <birtles> ... so you won't know which one you clicked on
14:38:39 <birtles> ... but the positioned markers (4) do allow you to do that
14:38:53 <birtles> s/this markers/these markers/
14:39:14 <heycam> https://svgwg.org/svg2-draft/painting.html#MarkerElement
14:39:15 <birtles> CM: there is an example of positioned markers in the element section
14:39:22 <birtles> ... at the end of that subsection
14:39:27 <birtles> ... below the attribute definitions
14:40:17 <birtles> ... you could use this for putting arbitrary patterns on a path
14:40:52 <birtles> ... the item marked "the cross" in example 1 in the spec
14:40:58 <birtles> ... in this example there are some marker children
14:41:35 <birtles> ... and the reason they are positioned markers and not regular markers using the referencing scheme discussed yesterday is the position attribute
14:41:55 <birtles> ... as well as the position attribute I've added an href attribute
14:42:04 <birtles> ... since you might want to reference some existing marker definition
14:42:09 <birtles> ... rather than duplicating it
14:42:29 <birtles> ... in that example, there's <marker href="#Square" ... />
14:42:38 <birtles> DS: why no just use <use>?
14:42:47 <birtles> CM: because then how do you know it's a marker?/
14:43:04 <birtles> ... I used a calc since we should be allowing calc wherever we allow lengths
14:43:11 <birtles> ... that is, we should be allowing CSS lengths
14:43:22 <birtles> CC: how does this work this the proposal we discussed yesterday
14:43:34 <birtles> ... where marker children become regular markers?
14:44:35 <birtles> CM: well, a marker could serve both purposes
14:45:10 <Zakim> -mdyck
14:45:24 <birtles> ... a child marker could simultaneously by referenced from marker-mid, marker-segment
14:45:33 <birtles> ... as well as being a positioned marker by having a position attribute
14:45:58 <birtles> ... whether it is a positioned attribute or not is dependent solely on whether or not it has a position attribute
14:48:19 <birtles> RC: so a marker that doesn't have an href, has no refX, refY?
14:48:27 <birtles> CM: there is a default value
14:48:48 <birtles> ... 0,0
14:49:06 <birtles> ... my example there should have a refX
14:50:33 <birtles> ... the thing with the positioned markers is that you can put event listeners on those markers
14:50:41 <birtles> CL: it would be worth calling that out
14:50:48 <birtles> CM: yes, I have an issue to do that
14:50:55 <birtles> DS: I like it
14:51:11 <glenn> glenn has joined #svg
14:51:39 <krit> krit has joined #svg
14:51:55 <birtles> CM: re clipping, the problem was we wanted to specify parts of the underlying path to knock out
14:52:14 <birtles> ... e.g. so it doesn't appear around the edge of the arrow head
14:52:36 <birtles> ... so I tried to make it easier to compute a single clipping path to apply when rendering the whole path element
14:53:36 <Tav> http://tavmjong.free.fr/blog/
14:53:37 <birtles> TB: I think it would work better if you specify relative to the marker
14:53:43 <birtles> ... I have some examples of that
14:54:16 <birtles> ... you define the marker and you define a clipping path relative to that
14:54:19 <birtles> s/specify relative/specify a clipping path relative/
14:54:48 <birtles> CM: clipping paths normally specify the part you preserve rather than the part you remove
14:54:53 <birtles> DS: I'd like to revisit that
14:55:02 <birtles> CM: one issue is if you have a bunch of markers that overlap
14:55:24 <birtles> ... it would be nice if you could in the implementation, treat it as a clipping path you apply before painting
14:55:32 <birtles> ... if each clipping path specifies the area you want to remove
14:55:41 <birtles> ... the implementation has to compute the inverse of that
14:55:54 <birtles> ... which might tricky but probably possible
14:56:11 <birtles> DS: do you want the author or implementation to calculate it?
14:56:22 <birtles> ... it makes sense for the implementation to do it for simple cases
14:56:29 <birtles> ... but for complex cases it doesn't
14:56:39 <birtles> CM: I'm ok with the author specifying the clip pth
14:56:56 <birtles> s/pth/path/
14:57:10 <birtles> CC: Figure 13, with knock out
14:57:17 <birtles> ... you have two paths joining
14:57:24 <birtles> ... and you specify marker start and end
14:57:32 <birtles> ... how many line segments do you have in these examples?
14:57:36 <birtles> CM: 1
14:57:41 <birtles> DS: these are shapes being cut out
14:57:48 <birtles> ... each of these labelled sections is a path
14:57:54 <birtles> ... and there's a knockout for those
14:58:40 <birtles> CM: to make it easy to calculate intersection of shapes
14:58:47 <birtles> ... I limited it to some simple shapes
14:59:03 <birtles> ... it makes the computation easier for calculating intersections
14:59:15 <birtles> ... so I specified the two halves of the shape you're knocking out separately
14:59:30 <birtles> CL: can left and right be different?
14:59:32 <birtles> CM: yes
14:59:37 <birtles> CC: what is the syntax
14:59:41 <birtles> CM: it's underneath
15:00:02 <birtles> DS: why can't the path in the mask be the clipping-path?
15:00:11 <birtles> CL: I think that's common, e.g. the path plus 3px
15:00:26 <birtles> CM: I think that's common but also I think these shapes are useful
15:00:47 <birtles> TB: how does this affect the fill on the path
15:00:59 <birtles> CM: I haven't quite worked that out yet
15:01:04 <Zakim> -Tav
15:01:21 <birtles> ... but you could either have this knockout the fill or not or make it controllable
15:03:10 <Zakim> +TimMills
15:03:49 <ChrisL> zakim, code?
15:03:49 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), ChrisL
15:04:33 <Zakim> -TimMills
15:05:41 <birtles> DS: can Tav's proposal also solve the problem?
15:05:58 <birtles> CM: yes
15:06:12 <birtles> CC: it would be nice to have more drawings in the spec about how the triangle etc. are drawn
15:06:35 <birtles> DS: if I clicked on one of these knockout areas what happens?
15:06:59 <birtles> CM: I assume we do the same as clip-path, i.e. it doesn't hit the element
15:07:07 <birtles> DS: ok, we should make that explicit
15:07:29 <birtles> CM: if we allow the author to specify arbitrary paths for the area you want to remove
15:07:34 <birtles> ... or the area to include from the marker
15:07:44 <birtles> ... what you need to end up with is a clipping path as we currently have it
15:07:52 <birtles> ... that you can apply before painting
15:08:10 <birtles> ... if you do that manually you need a big rect to cover the bbox
15:08:18 <birtles> ... plus a reverse path for the section you want to remove
15:08:22 <ed> would be nice to have an example like this: ->>-
15:08:37 <birtles> ... you have to get the clipping path in that form
15:08:49 <birtles> ... unless you want to turn it into a mask (which would be slower)
15:09:12 <birtles> ... so you need to get the clipping path in that form (everything included except some bit)
15:09:23 <birtles> ... but you don't want the author to have to specify that
15:09:32 <birtles> ... since, for a start, the author doesn't know how big the path will be
15:09:49 <birtles> ... so you could allow the author to just specify the bit to remove
15:09:58 <birtles> ... or they specify the bit they want to include
15:10:10 <birtles> ... and the implementation computes the reverse shape
15:10:24 <birtles> ... and I'd rather not require implementations compute the reverse shape
15:10:49 <birtles> ... to make it easiest for the author you want them to specify some part of the shape
15:10:58 <birtles> ... but the implementation has to calculate the overall clipping path
15:11:11 <birtles> ... and that's what I was trying to help with by using these predefined shapes
15:11:20 <birtles> ... makes it easy for the implementation to do intersection detection
15:11:34 <birtles> DS: so you can calculate it rather than asking the graphics library
15:11:44 <birtles> CM: it's a lot simpler than bezier curves
15:11:56 <birtles> ... I'm not sure if this is the best way
15:12:59 <birtles> DougS: what if I don't want to specify a knockout shape
15:13:18 <birtles> ... would the default be the bbox of the shape?
15:13:32 <birtles> s/DS: so/DirkS: so/
15:13:44 <birtles> CM: bbox would work for some things like arrows
15:13:50 <birtles> ... but not for many other things
15:14:03 <birtles> DougS: I think for other cases you use the knockout shapes
15:14:29 <birtles> ... but having a default be bbox it takes the burden off authors from having to specify anything at all
15:14:34 <birtles> ... perhaps "auto" = bbox ?
15:14:37 <ChrisL> q+ to consider a keyword that takes the stroke width
15:15:23 <Cyril> q+
15:15:34 <krit> q+
15:15:57 <ChrisL> ack ChrisL
15:15:57 <Zakim> ChrisL, you wanted to ask about child(n) and to consider a keyword that takes the stroke width
15:16:03 <birtles> CL: I was wondering if would be useful to have a keyword that means the width of the stroke
15:16:15 <birtles> ... since I think that would be one of the most common knockout cases
15:16:29 <birtles> CM: that's the most you need to clip out is up to the width of the stroke
15:16:53 <birtles> DougS: yes, that might be more common than bbox
15:18:01 <birtles> CM: if you're clipping out a square that is exactly the height of the stroke
15:18:20 <birtles> ... you need to be careful that you do actually do cover the whole stroke
15:18:55 <birtles> ... if you specify the clipping path you have the be careful you don't run into precision issues
15:20:08 <birtles> DougS: what happens if the stroke comes back again under the marker
15:20:15 <birtles> ... what happens to that new bit of stroke?
15:20:42 <birtles> CM: I think unless you want to split up the path into multiple sections
15:22:08 <birtles> ... if you set up a single clipping path before you draw the path
15:22:12 <birtles> ... you'll have problems
15:22:38 <birtles> ... at least, if you the area you're knocking out goes beyond the marker shape
15:25:01 <birtles> DirkS: paths are 1-D, so you apply the clipping path to the whole path
15:25:24 <birtles> CM: if you want overlapping behaviour, like the overlapping road example, you have to split the path
15:26:00 <Zakim> disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)14:21Z
15:26:02 <Zakim> Team_(svg)14:21Z has ended
15:26:02 <Zakim> Attendees were +1.206.675.aaaa, Tav, mdyck, TimMills
15:27:15 <birtles> DirkS: should the knockout area for a marker on a curved part of the stroke also follow the curve?
15:27:39 <birtles> CM: good questions
15:27:46 <birtles> s/questions/question/
15:28:06 <birtles> ... I think there are cases where the marker should be distorted and cases where it shouldn't (e.g. subway circle)
15:28:25 <birtles> ... if the marker is empty and you just want to remove some part of the path
15:28:50 <birtles> ... then you probably do want the knockout area to be curved
15:29:25 <birtles> CC: this knockout property seems to make a different between left and right
15:29:33 <birtles> ... but so far markers don't make that distinction
15:29:45 <birtles> CM: the shape of your marker might not be symmetrical
15:30:07 <birtles> ... so you might want to knockout out different shapes on different sides when the marker is in the middle of the path
15:30:18 <birtles> ED: is the rendering order defined?
15:30:22 <birtles> CM: yes, it's defined
15:30:42 <birtles> ... marker-start, alternating, segment vertex, marker-patterns, children etc.
15:30:50 <birtles> TA: why left / right?
15:30:57 <birtles> ... start / end?
15:31:01 <birtles> CM: sounds good
15:31:05 <ed> ah, found it... https://svgwg.org/svg2-draft/painting.html#MarkerAlgorithm
15:32:33 <birtles> CM: when we publish the spec, is it ok to keep this part in?
15:32:38 <birtles> All: yes, leave it in
15:33:04 <birtles> Break time, 15mins
15:49:46 <krit> nickScribe: krit
15:50:20 <krit> scribeNick: krit
15:50:44 <birtles> Topic: Revised text layout proposal
15:50:44 <krit> heycam: Wanted to reduce the amount tha I presented in Hamburg
15:50:46 <jen> jen has joined #svg
15:50:53 <ed> http://people.mozilla.org/~cmccormack/temp/text.pdf
15:51:01 <krit> heycam: I want to give the proposals and let people say yes or no
15:51:15 <krit> heycam: one: make it easier to integrate text layout
15:51:31 <krit> heycam: text is chucked on abs. pos. at the moment
15:51:42 <krit> heycam: each chuck is independent for shaping
15:51:59 <krit> heycam: each chunk almost a different text element
15:52:13 <krit> heycam: (has presentation on slides)
15:52:18 <ChrisL> relevant CSS work - line layout module http://dev.w3.org/csswg/css3-linebox/
15:52:58 <krit> heycam: chunking affects how ordering happens, make it more difficult to reuse text layout
15:53:18 <krit> heycam: text elements should be blocks and  child elements as spans
15:53:40 <krit> heycam: chunks won't stop shaping accross elements
15:53:53 <krit> heycam: absolute pos. happens once you got text layout
15:53:56 <ChrisL> also writing modes module http://dev.w3.org/csswg/css3-writing-modes/
15:54:11 <krit> heycam: SVG allows specifying it by each glyph at the moment
15:54:29 <krit> AS what happens when you have liguaritures 
15:54:51 <krit> heycam: there are rules in the spec how to apply chars into a glyph
15:54:56 <krit> heycam: and how to ignore
15:55:32 <krit> heycam: We still need to solve the char to glyph mapping before applying chunks
15:55:51 <krit> heycam: evrything should happen across a text element as a whole
15:56:16 <krit> heycam: what happens if you specify some pos. but other glyphs don't have a pos?
15:56:47 <krit> heycam: I think we should specify that glyphs without pos should be relative positioned to previous glyph
15:56:59 <krit> fi n a l exampl
15:57:03 <krit> fi ligurature
15:57:59 <krit> x="100 1550 200"
15:58:04 <krit> fi 100
15:58:09 <krit> n 150
15:58:15 <krit> a 200
15:58:29 <krit> sorry wrong
15:58:36 <krit> fi 100
15:58:40 <krit> n 200
15:58:57 <krit> a = 212
15:59:03 <krit> l = 224
15:59:16 <krit> AS: luguature should break in roman text
16:00:56 <krit> Cyril: I miss the explaination why 150 is not used
16:01:07 <krit> heycam: that is what spec says currecntly, skip it
16:01:20 <Tav> telephone?
16:02:32 <ChrisL> we need to allow the flexibility of per-font defaults for discretionary ligatures
16:02:45 <ChrisL> note that this changed recently in css3 fonts
16:02:53 <ChrisL> zakim, room for 3?
16:02:54 <Zakim> ok, ChrisL; conference Team_(svg)16:02Z scheduled with code 26631 (CONF1) for 60 minutes until 1702Z
16:03:25 <Zakim> Team_(svg)16:02Z has now started
16:03:32 <Zakim> + +1.206.675.aaaa
16:03:32 <krit> no
16:03:41 <Zakim> +Tav
16:04:33 <krit> heycam: I think it might make sense
16:05:15 <krit> ChrisL: don't disallow positioning ligatures
16:05:24 <krit> heycam: what is the default value?
16:05:29 <krit> ChrisL: do what the font says
16:05:46 <krit> ChrisL: we agreed not to overwrite it
16:06:06 <krit> ChrisL: or switch them of
16:06:40 <krit> ChrisL: svg says, if chars have a pos, glyphs shouldn't ligatures
16:07:20 <krit> heycam: if more than one pos, is specified you get behavior questional ligatures won't be formed
16:07:40 <krit> ChrisL: should say may not formed, dependent what the font says
16:07:49 <krit> AS: it is up to the font
16:08:24 <krit> AS: I would not expect to form ligatures, but think ChrisL is right. It depends on the font
16:08:40 <krit> heycam: do the CSS layout first
16:08:55 <krit> heycam: for the x positions you can not really say how it affects the font
16:08:59 <ChrisL> see http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
16:09:15 <krit> AS: right, so you can't rely on the ligature forming
16:09:25 <krit> AS: We shouldn't let it to the font to decide
16:09:27 <ChrisL> Initial: 	normal 
16:09:38 <ChrisL> A value of ‘normal’ implies that the defaults set by the font are used. 
16:09:48 <glenn> glenn has joined #svg
16:09:57 <krit> ChrisL: we have to see what the font syas
16:10:10 <krit> ChrisL: initial value is normal - do what the font says
16:10:29 <krit> heycam: pos should not influence if ligatures should be formed
16:10:34 <krit> ChrisL: AS: agree
16:10:48 <krit> ChrisL: It gives you more flexibiity
16:11:08 <krit> heycam: you can't know as an author which chars get a glyph
16:11:40 <krit> heycam: after positioning anchoring 
16:11:54 <krit> heycam: I won't change how anchoring worsk
16:12:50 <krit> heycam: the current behavior stays, fi and nal get anchored 
16:13:03 <krit> heycam: at 100 and 200
16:14:11 <krit> ed: end anchoring might be difficult
16:14:27 <krit> ed: basically wondering what happens
16:14:36 <krit> heycam: text-anchor is end
16:14:43 <krit> heycam: you got 2 chunks
16:14:51 <krit> heycam: first chung single glyph
16:15:34 <krit> heycam: you should look at all glyphs within a chunk, and look at the very right or left chunk (dependent on ltr) and shift it from there
16:15:40 <ed> <text x="100 200" text-anchor="end">ABCDE</text> (and the same with BIDI)
16:16:15 <krit> heycam: ltr text
16:16:59 <krit> heycam: right edge of A would be 200, BCD on its's left  Eat 200
16:17:05 <heycam> Zakim, room for 3?
16:17:05 <heycam> s/would be 200/would be 100/
16:17:06 <Zakim> ok, heycam; conference Team_(svg)16:17Z scheduled with code 26632 (CONF2) for 60 minutes until 1717Z
16:17:27 <krit> ed: browsers don't do the same think
16:17:41 <krit> heycam: I think the spec is clear about that
16:18:08 <krit> ed: what if text was rtl
16:18:23 <krit> heycam: you would have the left edge of the A at 100
16:19:01 <krit> s/at 100/at 200/
16:19:17 <krit> heycam: you look at the left edge of all glyphs
16:19:22 <krit> heycam: A is on the most left
16:20:54 <krit> heycam: x should give you exactly the anchor position
16:21:06 <krit> Cyril: for my understanding: ltr example
16:21:18 <krit> Cyril: step one apply CSS layout?
16:21:20 <krit> heycam: yes
16:22:15 <krit> heycam: lets say fi is a ligature
16:22:26 <krit> heycam: then the described behavior is what UAs are doing
16:22:46 <krit> heycam: in simple cases it gives you same results
16:23:50 <krit> heycam: I show more complicated cases
16:25:11 <krit> <text x="300 100">1nab</text>
16:25:27 <krit> heycam: 1. perfm css layout and find glyph pos
16:25:36 <krit> heycam: n 1 a b
16:25:43 <krit> heycam: 20,10,20,32
16:27:27 <krit> ChrisL: what you show is the backing store \
16:27:40 <krit> heycam: mark up is visual order
16:27:56 <ChrisL> alef and bet are the two letters, btw - see http://en.wikipedia.org/wiki/Hebrew_alphabet
16:28:56 <krit> heycam: normal position
16:29:42 <krit> n and 1 are hebrew
16:30:05 <krit> heycam: 2. preform CSS layout and find glyph pos
16:30:17 <krit> heycam: n is at 200
16:30:24 <krit> heycam: 1 is at 100
16:30:34 <krit> heycam: a at 110
16:30:41 <krit> heycam: b at 122
16:31:05 <glenn> glenn has joined #svg
16:33:02 <krit> heycam: a and b calculated according to pref pos
16:33:10 <krit> heycam: 1  ab  n
16:34:25 <krit> heycam: old behavior 1ab    n
16:34:39 <krit> heycam: I want to change SVG behvaior
16:35:13 <krit> AS: 1 and n are rtl
16:35:36 <krit> AS: ab would be pos to the right of n
16:37:20 <krit> heycam: I think my proposal makes it possible just to look at last char in memory
16:40:18 <krit> Cyril: english hebrew english
16:40:30 <krit> Cyril:  ——> <—— ------>
16:40:49 <krit> Cyril: english he___brew english
16:41:12 <krit> Cyril: don't want to have second english word pos between hebrew chunks
16:43:12 <krit> krit: I think positioning of glyphs is stupid
16:43:21 <krit> krit: we should deprecate it
16:43:29 <krit> heycam: well, it is complicated
16:43:39 <krit> heycam: at least my proposal is simple to implement
16:43:57 <krit> heycam: look from left to right, shift all position
16:44:32 <cabanier> slide deck: http://people.mozilla.org/~cmccormack/temp/text.pdf
16:46:49 <krit> heycam: Opera renders the example correctly according to the current spec
16:46:58 <krit> krit: can we deprecate it?
16:47:01 <krit> heycam: yes
16:47:19 <krit> heycam: but we need to specify how the deprecated feature is supposed to work
16:47:25 <krit> krit: :P
16:48:16 <krit> heycam: have no strong feeling disabling anchoring all together
16:48:48 <krit> heycam: propably not important
16:49:20 <krit> ChrisL: you have a backing store of glyphs and order them in rendering order
16:49:35 <krit> ChrisL: where does text-anchor: middle go
16:50:26 <ChrisL> s/middle/none/
16:51:04 <ChrisL> the slides are confusing the source display and the backing store order - slides could be improved for clarity there
16:51:23 <krit> heycam: have to check anchoring: none, but I think it is an unimportant case
16:53:47 <krit> heycam: undefined behavior in the spec t the moment: <textPath>…</textPath>TextAfterTextPath
16:53:54 <krit> heycam: where should it ogo?
16:57:16 <krit> heycam: the bottom left of the text path should be relevant for positioning text after textpath
16:57:32 <krit> heycam: we should relax some restictions and allow x,y on textpath
16:58:07 <krit> heycam: it just translates the content by transforming the space of the text path
16:58:16 <krit> heycam: we should also allow textpath in tspan
16:59:51 <krit> heycam: summary, di what CSS is doing and apply SVG on top of it
17:03:49 <krit> shepazu: Can we have a resolution to make textPath element as top level element (not surrounded by text element)?
17:03:58 <krit> general agreement to do so
17:04:31 <krit> RESOLUTION: textPath must not surouned by text element anymore.
17:04:58 <krit> s/surouned/surrounded/
17:05:44 <ed> https://svgwg.org/svg2-draft/text.html#WhiteSpace
17:06:34 <krit> ChrisL: I edded the  section about white space handling
17:06:42 <krit> s/edded/edited/
17:07:37 <krit> s/RESOLUTION: textPath must not surouned by text element anymore./RESOLUTION: textPath not needed to be surrounded by text element anymore.
17:07:59 <krit> s/RESOLUTION: textPath must not surouned by text element anymore./RESOLUTION: textPath not needed to be surrounded by text element anymore./
17:08:33 <krit> Cyril: I think I am fine with the proposal
17:08:53 <krit> Cyril: but am concerned about the complexity of the basic thing
17:09:06 <krit> Cyril: Is it still from the same complexity as before?
17:09:18 <krit> heycam: depends on you implementation of the text rendering
17:10:09 <krit> heycam: I don't think that you need to implement all the CSS now
17:10:21 <krit> heycam: it is quite unprecise in some cases anyway
17:11:03 <ChrisL> it is the linebox and writing-modes and text modules of CSS3
17:11:18 <ChrisL> see http://dev.w3.org/csswg/ for links to those
17:15:50 <krit> heycam: you don't have to worry about the whole CSS box model. And the CSS text layout isn't much greater than it is currently
17:16:07 <krit> krit: CSS is a requirement anyway
17:16:17 <krit> Cyril: I am thinking about the coast to implement it
17:16:25 <Cyril> s/coast/cost/
17:16:45 <krit> ChrisL: It does things for browsers easier, but for sure more complicated fot viewers without CSS engine
17:17:41 <krit> heycam: I can put current proposal into the spec and ask if it makes sense.
17:17:56 <krit> heycam: I tried to make it simple
17:18:08 <krit> heycam: I think it is easy to implement it
17:18:35 <krit> heycam: I can ask Mozilla people as well
17:19:35 <krit> RESOLUTION: Add Camerons proposal to spec and ask for wider feedback
17:19:51 <krit> topic: white spaces edits in SVG
17:20:05 <Zakim> -Tav
17:20:06 <ChrisL> https://svgwg.org/svg2-draft/text.html#WhiteSpace
17:20:39 <krit> ChrisL: previously whitespace was notgood and complicated
17:20:47 <krit> ChrisL: we removed tests from test suite
17:20:52 <krit> ChrisL: I kept it in
17:20:58 <krit> ChrisL: for legacy
17:21:12 <krit> ChrisL: white space handling is using whitespece-property now
17:21:22 <krit> ChrisL: added it to the spec
17:22:00 <krit> ChrisL: added a third section for old and new whitespaces 
17:22:06 <krit> ChrisL: and how to do both
17:22:26 <krit> ChrisL: I felt it needs to be adressed
17:23:02 <krit> heycam: not hane any XML white space behavior and use property to select whitespace behavior
17:23:11 <krit> heycam: there are still differences
17:23:33 <krit> heycam: but should be mostly the same, inore differences and switch over to white-space: normal and pre
17:24:16 <krit> heycam: I have implemented it using a UI style sheet rule
17:24:40 <krit> shepazu: we are not talking about word breaking
17:24:51 <krit> heycam: ChrisL: yes we are
17:25:02 <krit> s/word breaking/collapsing/ ?
17:25:05 <Zakim> disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)16:02Z
17:25:07 <Zakim> Team_(svg)16:02Z has ended
17:25:07 <Zakim> Attendees were +1.206.675.aaaa, Tav
17:25:37 <krit> ChrisL: I think we want pre-wrap
17:26:25 <krit> heycam: CSS people already splitting out whit space collapsing
17:27:30 <krit> heycam: If white space is normal I would like to wrap if the width attribute is specified on the text element
17:27:42 <krit> heycam: width attribute is new for text
17:28:51 <krit> TabAtkins_: how far do we want to go? We want to have <p> in SVG anyway
17:28:59 <krit> krit: use cases might be different
17:29:03 <krit> ChrisL: that is right
17:30:18 <krit> http://dev.w3.org/csswg/css3-text/#white-space
17:30:21 <ChrisL> http://dev.w3.org/csswg/css3-text/#soft-wrap-opportunity
17:30:35 <glenn> glenn has joined #svg
17:31:19 <krit> ChrisL: it is just using space collapsing
17:31:59 <krit> ChrisL: I think we agree that we want to remove things from the XML ns. 
17:32:27 <krit> action: ChrisL to work out things on removing XML ns stuff on text and figure things out with the CSS WG
17:32:28 <trackbot> Created ACTION-3323 - Work out things on removing XML ns stuff on text and figure things out with the CSS WG [on Chris Lilley - due 2012-07-31].
17:33:46 <ChrisL> action-3323?
17:33:46 <trackbot> ACTION-3323 -- Chris Lilley to work out things on removing XML ns stuff on text and figure things out with the CSS WG -- due 2012-07-31 -- OPEN
17:33:46 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3323
17:34:07 <ed> -- 15 min break --
17:54:48 <cabanier> scribenick: cabanier
17:54:56 <ChrisL> scribenick: ChrisL
17:55:18 <ChrisL> scribenick: cabanier
17:55:51 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
17:56:22 <ed> topic: SVG in Web IDL
17:56:23 <cabanier> topic: SVG in Web IDL
17:56:42 <cabanier> CM: I propose to redo the SVG idl
17:56:52 <cabanier> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
17:57:28 <cabanier> …turn "stylable", "locatable" and "transformable" in actual element
17:57:45 <cabanier> …SVGtransformable is inherited the most
17:59:29 <cabanier> WebIDL doesn't support multiple inheritance
17:59:56 <cabanier> …there is nothing too contraversial
18:00:14 <cabanier> …I do propose to get of the SVG namespace. move away from XML lang
18:00:34 <cabanier> …there is only a couple of elements that you can't use the properties on
18:01:01 <cabanier> …if you use xml lang on animate, it's not going to have any effect
18:01:20 <cabanier> TA: it negotiates fonts.
18:01:30 <cabanier> …for different languages
18:01:55 <cabanier> BB: ElementTimeControl
18:01:56 <cabanier> will it disappear all together?
18:02:02 <cabanier> CM: yes
18:02:24 <cabanier> BB: this is how I test for SMIL support. We might break content if we remove interfaces
18:02:42 <cabanier> … gecko and webkit support it. Opera doesn't
18:03:09 <cabanier> CM: I can leave it in.
18:03:40 <cabanier> BB: not sure if there's content that relies on it
18:04:15 <cabanier> .. I can change my content
18:04:58 <cabanier> CC: in some case you remove multiple inheritance by merging. In others they implement. I don't understand how you made the decision
18:05:37 <cabanier> CM: take SVGFitToViewBox. SVGSVGElement needs it and a couple of others.
18:06:25 <cabanier> …SVGSVGElement we want to be able to transform but not SVGMarker
18:08:00 <cabanier> CC: the solution to multiple inheritance
18:08:58 <cabanier> DS: why not multiple inheritance?
18:09:09 <cabanier> CM: because JavaScript doesn't support it
18:09:59 <cabanier> …there is a difference between 'implements' and 'inherits'
18:10:18 <cabanier> … implements is a new copy of the function while inherits is the same
18:12:24 <cabanier> … the reason SVGGraphicsElement and SVGDefinitionElement are introduced because it's a good place to hang the mixed in interface instead of the more specific
18:12:57 <cabanier> from the spec: "Having these two interfaces gives us a place to mix in other common interfaces (like SVGTests) without having to do it on each sub-interface."
18:13:14 <cabanier> … this is how we might reorganize the interfaces
18:13:18 <thorton> thorton has joined #svg
18:13:31 <cabanier> … Jen, don't you use WebIDL directly
18:13:37 <cabanier> J: not sure about that
18:13:46 <cabanier> CM: any questions?
18:13:51 <cabanier> All: no
18:14:59 <glenn> glenn has joined #svg
18:15:03 <cabanier> resolution: we will adopt Cameron's proposal for Proposals/IDL interface reorganization
18:16:37 <cabanier> CM: let's move SVGStylable up to the SVGElement
18:16:47 <cabanier> All: agreed
18:17:02 <cabanier> BB: so get rid of stylable element?
18:17:05 <cabanier> all: yes
18:17:09 <cabanier> BB: that's great
18:17:44 <cabanier> resolution: we will get rid of SVGStylableElement
18:18:04 <cabanier> action: Cameron to do all this interface stuff (Proposals/IDL interface reorganization)
18:18:04 <trackbot> Created ACTION-3324 - Do all this interface stuff (Proposals/IDL interface reorganization) [on Cameron McCormack - due 2012-07-31].
18:18:31 <cabanier> CM: can we get rid of externalresourcesrequired?
18:18:39 <cabanier> all: what's it for?
18:19:14 <cabanier> BB: it should line up with DOMContentLoaded
18:19:17 <cabanier> all: yes
18:19:39 <cabanier> CL: people wanted that if one resource doesn't load, nothing should load
18:22:42 <cabanier> CC: externalresourcesrequired was more granular since it worked per group and we especially helpful for fonts
18:23:01 <cabanier> … but I don't think anyone implements or use it
18:23:15 <cabanier> DS/ED: we believe that is true
18:23:21 <cabanier> ED: it doesn't see much use
18:24:07 <cabanier> DS: are there cases where this is useful?
18:24:10 <ed> s/it doesn't see much use/Opera implements it, but eRR isn't used much
18:24:29 <cabanier> BB: if that's true, we should do it for HTML as well.
18:27:49 <cabanier> resolution: remove ExternalResourcesRequired from the spec
18:28:47 <cabanier> CM: That's all for the IDL talk
18:30:31 <cabanier> BB does a demo of an animation application written in SVG
18:34:15 <cabanier> BB: having viewbox as a property would be very helpful in conjunction with media queries
18:34:57 <cabanier> CM: is viewbox the CSS name?
18:35:49 <cabanier> css syntax:
18:36:11 <cabanier> svg { viewbox: 0 0 240px 240px; }
18:36:39 <ed> ick, why the units?
18:37:00 <ChrisL> because CSS
18:37:11 <cabanier> CM: does it make sense to non-svg?
18:37:29 <cabanier> DS: such as iframe
18:37:43 <ChrisL> can the units be optional?
18:37:54 <cabanier> TA: yes, just iframe establishes a viewport 
18:38:10 <ed> if we allow units, then we should allow units in the viewbox attribute too, but sure, that follows from making it a presentation attribute I guess...
18:38:23 <heycam> ed, agreed
18:38:23 <cabanier> fixed CSS syntax: svg { view-box: 0 0 240px 240px; }
18:38:23 <ed> calc too?
18:39:19 <heycam> of course
18:41:08 <ed> people are probably already writing "viewbox" in html-with-inline-svg, and "viewBox" in svg... and then "view-box"?
18:41:17 <cabanier> DS: this seems to be a very nice feature in combination with auto scaling
18:42:49 <cabanier> …there is a question with auto
18:43:27 <cabanier> … what happens when things move around? content will start growing/shrinking
18:43:49 <cabanier> DirkS: then you should absolute coordinates
18:44:56 <cabanier> …should we apply to HTML as well?
18:45:33 <cabanier> TA: HTML and iframe create a viewbox
18:47:20 <cabanier> resolution: convert viewbox to a property and give it an 'auto' characteristic
18:48:01 <cabanier> action: Tab Atkins to take HTML and Iframe view-box property to the CSS working group
18:48:01 <trackbot> Created ACTION-3325 - Atkins to take HTML and Iframe view-box property to the CSS working group [on Tab Atkins Jr. - due 2012-07-31].
18:51:05 <cabanier> action: brian birtles to write up a proposal for view-box property for SVG
18:51:05 <trackbot> Created ACTION-3326 - Birtles to write up a proposal for view-box property for SVG [on Brian Birtles - due 2012-07-31].
18:51:37 <ed> topic: Quick question about mask: <funciri> auto
18:52:31 <cabanier> BB: in the case you have a mask property, let the mask decide what it is: luminance or alpha
18:53:12 <birtles> current syntax proposal: [ <funciri> | child | element(<compound-selector>) | none ] [ luminance | alpha | auto ]? 
18:53:51 <cabanier> … auto means do what the mask says
18:54:18 <cabanier> … but if you point it to an image, what should it be?
18:56:19 <ChrisL> you need to be able to choose either
18:56:34 <cabanier> RC: it seems that you should get luminance
18:56:43 <cabanier> DirkS: I think it should be alpha
18:57:34 <cabanier> CL: people that want alpha point to a grayscale. I have a feeling that it should be alpha
18:59:58 <ChrisL> alpha alpha alpha, ra ra ra
19:00:11 <glenn> glenn has joined #svg
19:01:02 <cabanier> resolution: alpha is chosen when selection 'auto'  is set and mask is pointed to an image
19:01:26 <cabanier> resolution: the property alpha/luminosity wins when pointing to a mask element
19:01:56 <ed> Zakim, end telcon
19:01:56 <Zakim> I don't understand 'end telcon', ed
19:01:58 <ChrisL> rrsagent, make minutes
19:01:58 <RRSAgent> I have made the request to generate http://www.w3.org/2012/07/24-svg-minutes.html ChrisL
19:07:08 <jet> jet has joined #svg
19:12:15 <nikos> nikos has joined #svg
20:02:30 <krit> <!DOCTYPE html>
20:02:31 <krit> <html lang="en">
20:02:31 <krit> <head>
20:02:31 <krit> </head>
20:02:31 <krit> <body>
20:02:31 <krit> <svg>
20:02:33 <krit> <rect width="100%" height="100%" fill="green"/>
20:02:35 <krit> </svg>
20:02:38 <krit> </body>
20:02:39 <krit> </html>
20:03:25 <krit> http://jsfiddle.net/FcQVn/
20:08:13 <krit> http://jsfiddle.net/FcQVn/
20:10:24 <krit> http://jsfiddle.net/WFCZz/
20:10:36 <jen> jen has joined #svg
20:10:39 <krit> http://jsfiddle.net/WFCZz/
20:12:42 <jet> jet has joined #svg
20:13:39 <krit> http://jsfiddle.net/j9zJw/
20:14:49 <krit> http://jsfiddle.net/Mym5r/
20:29:09 <jen> jen has joined #svg
20:33:41 <krit> http://jsfiddle.net/FcQVn/1/
20:33:41 <krit> http://jsfiddle.net/WFCZz/1/
20:33:41 <krit> http://jsfiddle.net/j9zJw/1/
20:33:41 <krit> http://jsfiddle.net/Mym5r/1/
20:45:11 <heycam> shepazu, http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
21:05:42 <jet> jet has joined #svg
22:39:33 <glenn> glenn has joined #svg
22:40:36 <nikos> nikos has joined #svg
22:40:40 <nikos> http://en.wikipedia.org/wiki/Magic_Roundabout_%28Swindon%29
22:54:39 <jet> jet has joined #svg
23:41:07 <jet> jet has joined #svg
23:44:25 <krit1> krit1 has joined #svg
00:15:24 <glenn> glenn has joined #svg
01:10:15 <jet> jet has joined #svg
01:47:06 <jet> jet has joined #svg
03:07:23 <krit> krit has joined #svg
04:04:05 <shepazu> shepazu has joined #svg
05:29:18 <jet> jet has joined #svg
06:18:41 <jet> jet has joined #svg
07:33:55 <jet> jet has joined #svg
12:07:12 <Tav> Tav has joined #svg
12:09:29 <stakagi> stakagi has joined #svg
12:10:54 <stakagi> stakagi has left #svg
12:45:32 <krit> krit has joined #svg
12:52:54 <ChrisL> ChrisL has joined #svg
13:01:45 <ChrisL> action chris to rewrite the SVG2 Concepts chapter to make more sense in 2012
13:01:45 <trackbot> Created ACTION-3327 - Rewrite the SVG2 Concepts chapter to make more sense in 2012 [on Chris Lilley - due 2012-08-01].
13:35:32 <stakagi> stakagi has joined #svg
13:35:46 <stakagi> stakagi has left #svg
13:49:00 <Cyril> Cyril has joined #svg
13:49:06 <ed> going for coffee now, back in 15min
14:10:52 <birtles> birtles has joined #svg
14:11:23 <krit> krit has joined #svg
14:12:59 <heycam> trackbot, start telcon
14:13:01 <trackbot> RRSAgent, make logs public
14:13:03 <trackbot> Zakim, this will be GA_SVGWG
14:13:03 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:13:04 <trackbot> Meeting: SVG Working Group Teleconference
14:13:04 <trackbot> Date: 25 July 2012
14:13:11 <heycam> Chair: Cameron
14:13:14 <heycam> ScribeNick: heycam
14:13:17 <heycam> Topic: Mapping update
14:16:35 <birtles> http://www.slideshare.net/brianskold/web-maps
14:16:41 <jen> jen has joined #svg
14:16:56 <heycam> BB: I want to give a little update with where we're at with mapping
14:16:57 <cabanier> cabanier has joined #svg
14:17:05 <heycam> … I spoke to Takagi-san from KDDI last month
14:17:07 <nikos> nikos has joined #svg
14:17:11 <heycam> … I want to summarise some of the materials he sent me
14:17:16 <heycam> … some of it we looked at in Sydney in January
14:17:23 <heycam> … some of it is new
14:17:38 <heycam> … I also spoke to some folks at Mozilla last week, and we have some thoughts about what we think the next steps are
14:18:19 <heycam> … he suggests that maps are as fundmanetal to the web as video, just another data type
14:18:29 <heycam> … he expects that that usage will grow, especially with mobile computing
14:18:40 <heycam> … and also the fact that Apple is entering the maps space
14:18:44 <heycam> … suggesting it's an important area
14:18:54 <heycam> … that said, it's already possible to do maps on the web, there are mapping services already
14:18:59 <heycam> … why do we need to do anything more?
14:19:23 <heycam> … Takagi-san's concern is current systems are closed, and you're at the mercy of the mapping service to do local storage of map data, ad hoc sharing, mashing up  data with other providers
14:19:43 <heycam> … wrt offline access, that seems to be particularly important in the wake of the disasters in Japan last year, where internet access was unreliable during relief work
14:20:10 <heycam> … there was a recommendation from ITU-T that SVG mapping be pursued as a possible technology to assist in disaster relief situations, especially for the offline access but also ad-hoc sharing, taking map data from one source
14:20:25 <heycam> … for example the base data comes from OSM and extra regional data, relief centres for example, that you would overlay
14:20:45 <heycam> … also Takagi-san argues that the web should be decentralised, and current mapping services are very much run by one server
14:20:52 <heycam> … there's not really a facility for sharing data
14:21:54 <heycam> … if the processing is done more on the client side, the user is in more control
14:22:18 <heycam> CC: for offline usage you need navigation logic to be stored locally, right?
14:22:19 <heycam> BB: yes
14:22:33 <heycam> … it's not that offline access is completely impossible, I think Google Maps offline is available
14:22:37 <heycam> NA: there's Off Maps on the iPhone
14:22:42 <heycam> BB: but you're at the mercy of the mapping service
14:22:47 <ChrisL> q+
14:22:55 <heycam> … if there was client side technology, there would be guarantees that you could cache that data
14:23:22 <heycam> CL: that ties in with the approach with the Linked Open Data people, instead of everyone uses my mapping service, everyone publishes data and can use them together
14:23:36 <heycam> BB: it's not entirely impossible with current services, with Google maps you can take KML files from different sources
14:23:46 <heycam> … but you are at the mercy of the service as to what services are available
14:23:53 <heycam> … what would be needed to achieve the model that Takagi-san is promoting?
14:24:18 <heycam> … the main piece of it is the Tiling and Layering feature
14:24:22 <heycam> … I want to go into that a littble bit
14:24:31 <krit> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping
14:24:35 <heycam> … we looked at this in January, basically you have container files that reference other SVG filtes
14:24:38 <heycam> s/filtes/files/
14:24:44 <heycam> … and you can cascade those container files
14:25:09 <heycam> [example shown using <animation> elements, and <globalCoordinateSystem>]
14:25:22 <heycam> … in SVG, the <image> element is static, it's basically just converted into four channel image data
14:25:28 <heycam> … <animation> from 1.2T allows dynamic content
14:25:40 <heycam> … that's why he used that here, but he's open to using some different element
14:25:53 <heycam> … the other main piece is the <globalCoordinateSystem>, and we talked about that a lot in January
14:26:38 <heycam> … that's a mapping from the coordinate system of the tile's SVG file to a global coordinate space, and then you have the same element in the container file so that you can transform into the coordinate space of the container file
14:26:51 <heycam> Dirk: it's a 2D coordinate system?
14:27:00 <heycam> BB: I think it's a standard cartographic coordinate system
14:27:39 <heycam> … the x/y/width/height on the <animation> indicates which tiles you need to load, and it also does clipping
14:27:57 <heycam> … the other feature of T&L is layering, where you put the pieces on top of each other
14:28:14 <heycam> … not sure how that bit works
14:28:57 <heycam> … there's also the min/max zoom thing, which tells you at which points to show and hide any element, but typically applied to a tile
14:29:05 <heycam> … that's the basic features of the Tiling & Layering spec
14:29:15 <heycam> … it has lots of applications beyond maps, Takagi-san had a list of them
14:29:30 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Use-cases_of_SVGTL
14:29:52 <heycam> … on that page are a list of places you could use T&L
14:30:03 <heycam> … that's the main piece of what Takagi-san is proposing
14:30:30 <heycam> … some other pieces we discussed last time, non-scaling-stroke which I think is implemented widely now
14:30:44 <heycam> … shared paths is something which we agreed was good but there's no commitment from anyone to write that up for SVG2
14:31:00 <heycam> … that's especially useful for borders between countries, where you want the same line to be shared between different shapes, and stroked just once
14:31:23 <heycam> … fixed size objects, we talked about reintroducing transform-ref from 1.2T, but that seems to be at risk too
14:31:28 <heycam> … non-linear transformations we've rejected
14:31:38 <heycam> … UI features, we knocked back built-in map controls
14:32:27 <heycam> … we also rejected the idea of programming-less geolocation, e.g. centre the map on my location
14:32:48 <heycam> … I am not sure what we have decided on SVG views with geographic coords, but there's no commitment to have that in SVG2
14:33:41 <heycam> …  API features for smooth transitions of zooming/panning, but I think we didn't understand what that was about
14:33:55 <heycam> … if we do support global coordinate systems, then it makes sense to have an API for that
14:34:06 <heycam> … but that's assuming we have the <globalCoordinateSystem> element
14:34:28 <heycam> … finally, if we were to introduce some sort of <tile> element then it needs to have contentDocument, contentWindow for accessing the contents
14:35:02 <heycam> … I want to present a summary of the discussions I had with Mozilla folks last week
14:35:25 <heycam> … basically, one of the things we discussed was that map UIs are very complicated, for example they can do all sorts of things like if the label is close to the edge of the viewport, you shift it so that it's readable
14:35:32 <heycam> … Google Maps has integration with WebGL
14:35:45 <heycam> … so it seems hard to imagine you could standardised a set of map features that would be competitive with existing map services
14:35:58 <heycam> … you obviously can't get UAs to implement all the features of Google Maps
14:36:20 <heycam> … so we thought it would be better to agree on a standard markup for maps, and then have at least one open source app that consumes that data
14:36:32 <heycam> … so it's still client side, and the user is in control, but without requiring UAs to implement the mapping features
14:36:34 <krit> q+
14:36:56 <heycam> … in response to that, Takagi-san agrees that complex mapping services should still be realised as web apps with JS, but he would like to see some sort of minimum subset as a UA native implementation
14:37:31 <heycam> … I think his argument is that then you would have some guarantees that the map data is independent from the mapping services
14:37:46 <ChrisL> q-
14:38:47 <jarek> jarek has joined #svg
14:39:13 <heycam> … Takagi-san believes there are good reasons for implementing a base set of features in UAs
14:39:23 <heycam> … he'll be at the next F2F so can explain better at that point
14:39:39 <heycam> Dirk: I don't see anything that can't be done with current markup that we have
14:39:52 <ChrisL> q+
14:39:52 <heycam> … we can still provide some microformats, just introduce some name conventions
14:40:01 <heycam> … at the end you still need an application that knows about all these terms
14:40:08 <heycam> BB: that's basically the Mozilla position
14:40:48 <heycam> … with the exception of the next piece, we think tiling is generally useful beyond maps, and are interested in some sort of iframe-like element in SVG
14:40:54 <heycam> CL: I didn't understand the relationship between those two
14:41:02 <heycam> … I didn't understand why you would then use iframe
14:41:24 <heycam> BB: the idea would be to add something along the lines of <animation> element, which allows embedding SVG, also in combination with that having a load on demand facility
14:41:35 <heycam> … so that those items wouldn't be loaded when they're not in the viewport, or some heuristic like that
14:41:43 <heycam> … that's one way you could realise tiling
14:41:50 <heycam> Dirk: what about using <use>?
14:42:07 <heycam> … if you want to have tiling as well, you could surround it with <svg> inline element, because they act as clipping region
14:42:13 <heycam> BB: that's worth investigating
14:42:26 <heycam> … I think iframe is attractive because it gives some features like sandboxing, although that might not be important in this case
14:42:30 <heycam> … something of that nature anyway
14:42:39 <shepazu> shepazu has joined #svg
14:42:53 <heycam> Dirk: we'll eventually <iframe> in SVG anyway
14:43:12 <heycam> CL: one obvious use case is high res imaging, medical or photography
14:43:29 <heycam> … being able to just specify "here's a high res source" and have it automatically bring in low res things on demand, is useful general functionality
14:43:37 <heycam> … with DOM support too, but without needing script for base level functionality
14:44:15 <shepazu> q+ to tile
14:44:24 <ChrisL> q-
14:44:29 <krit> q-
14:44:37 <heycam> CM: I think one reason for suggesting iframe was to avoid introducing a new element that does the just the same thing as an existing element
14:45:03 <heycam> Doug: we've talked about tiling in two different ways this week
14:45:21 <heycam> … there's the tiling as decorative, taking a preexisting resource and repeating it in different permutations
14:45:34 <heycam> … and there's also tiling as in fetching external resources on demand, and not repeating them
14:45:41 <ChrisL> the first one is the css background tiling
14:45:46 <heycam> … we should somehow converge those two if it's useful
14:46:13 <heycam> CL: I think it's better to use different terminology, since they're mostly different things
14:46:24 <heycam> … one is replication of an image
14:46:40 <heycam> Doug: one area where they might be related, the superpath where you want to join different tiles up
14:46:48 <heycam> … a road doesn't end one tile
14:47:00 <heycam> … so there is the matching of edges aspect, so that might be related on both
14:48:00 <heycam> BB: as to the minimum subset that is needed, Takagi-san identified two things
14:48:10 <heycam> … one is the T&L feature, and the other is zooming & panning
14:48:18 <glenn> glenn has joined #svg
14:48:23 <heycam> … (browser native UI to zoom and pan the image)
14:48:35 <heycam> CL: in SVG 1 we said that all UAs had to have that feature, and the first round of UAs did have that
14:48:40 <heycam> … but they all did it differently
14:49:01 <heycam> … the second generation of implementations in browsers either ignored it completely, or just gave you scroll bars which is not ideal
14:49:09 <heycam> … and suggested that authors use script to do this
14:49:38 <heycam> Doug: as an author, I've run into situations where I did and didn't want users to zoom/pan
14:49:55 <heycam> … if we're not going to provide UI controls, which I think is a shame, we should at least provide a rich API for panning and zooming
14:50:01 <heycam> … for example "zoom to a particular rectangle"
14:50:06 <heycam> … "zoom centered around a particular point"
14:50:33 <heycam> … maybe we could have a zoom to rect, zoom at point API
14:50:36 <heycam> … and something for panning as well
14:51:29 <heycam> CM: I think that is in line with what we've previously resolved, to not have native UI but to make it easy for script to implement zoom/pan
14:52:27 <heycam> DS: I would like to see browsers implement native zoom and pan controls
14:52:30 <heycam> s/DS/Doug/
14:52:37 <heycam> … maybe they could be turned on or off in preferences
14:53:20 <heycam> BB: so today I'm not aiming for particular resolutions, I'm just summarising where we're up to
14:53:30 <heycam> … in Zurich Takagi-san can present his thoughts and concerns
14:53:44 <heycam> … perhaps the most concrete thing that could come out of this is to investigate some sort of use/iframe element for this sort of thing
14:54:24 <heycam> … one thing I realised for <iframe> is that it has has seamless
14:54:32 <heycam> Dirk: you have to maybe specify inherit as the property value
14:54:38 <heycam> s/inherit/fill:inherit/
14:54:46 <heycam> Doug: one problem with iframe is that it has its own coordinate system embedded in it
14:54:50 <heycam> … that might be a good thing or a bad thing
14:54:59 <heycam> … you might want to have a coordinate system in the tile
14:55:04 <heycam> … but you probably want it relative to the other tiles
14:56:07 <heycam> … we need to write down use cases and requirements for exactly what is required for T&L
14:56:14 <heycam> BB: right
14:56:42 <heycam> Doug: do you really expect to have dozens of iframes how is that going to affect performance?
14:57:12 <heycam> BB: I don't think there's any particular performance concern
14:57:16 <heycam> Doug: what about overlaps?
14:57:28 <heycam> BB: I don't know exactly how it works in the proposal Takagi-san has put forward, but there are a lot of ways to realise that
14:57:42 <heycam> Doug: there would be some metadata that says "I am this portion of this other document"
14:57:51 <heycam> … if you have a raster that you've tiled and you're zooming in on an x-aray
14:57:54 <heycam> s/aray/ray/
14:58:02 <heycam> … each segment knows what part of the larger image it is
14:58:16 <heycam> … also, are these things injected into the dom automatically, and removed?
14:58:22 <heycam> … or is it more like a <use> where there's a shadow tree?
14:58:34 <heycam> … does each tile actually have an element, or is there something weird going on?
14:58:39 <heycam> BB: I think all that stuff needs to be worked out
14:58:54 <heycam> … you would probably have contentDocument on the DOM node, especially if it's an iframe that would be the obvious way to approach it
14:59:07 <heycam> … wrt the load on demand facility, you might say that when it goes out of view the contentDocument becomes null
14:59:31 <heycam> Doug: currently if you have a <use> or an <image> which it hasn't retrieved it, it doesn't give you an indication that there's something missing
15:00:07 <Cyril> q+
15:00:17 <heycam> … I think we need something that shows the missing image, maybe a pseudo class
15:00:33 <heycam> … and then you could style it yourself
15:01:28 <heycam> BB: I think we need a concrete proposal for what is required
15:02:17 <heycam> … we need to investigate further the load on demand for zoom levels
15:02:45 <heycam> … that would be a step towards the T&L spec, but not necessarily committing to do the whole thing
15:04:06 <heycam> BB: that's it
15:05:04 <heycam> … I think we need a specific proposal for an element like animation/iframe that can contain the SVG
15:05:18 <heycam> Doug: I'd like to know how it would be like iframe
15:05:38 <heycam> … it has a particular DOM interface, features
15:06:39 <heycam> CM: I think Mozilla's view is that rather than come up with a new element that has substantial overlap with an existing one, that we extend the existing one for the new features (like load on demand)
15:06:55 <heycam> Dirk: we've been discussing this topic for nearly a year now, but we still don't have a proposal
15:07:00 <heycam> … it doesn't seem like we're making progress
15:07:33 <heycam> BB: I guess Mozilla is saying that we're not interested in implementing the proposal as it stands, but we're intersted in pulling off one of the features of it and implementing that
15:07:52 <heycam> … the feature where you can include another SVG or raster image and have load on demand control
15:08:12 <heycam> Dirk: can't you already do that? <foreignObject><iframe>?
15:08:18 <heycam> BB: it's not iframe specifically, it's the load on demand feature
15:08:25 <heycam> … it might be possible with a <use> element, if so great
15:08:42 <heycam> … but the automatic loading of subresources based on zoom level and viewport is the part we're interested in
15:08:58 <heycam> CM: what is the next concrete step?
15:09:41 <heycam> BB: someone to come up with a proposal for an element for pulling in subresources on demand with zoom level control
15:09:46 <heycam> Dirk: should it work with other formats?
15:09:50 <heycam> BB: yes, definitely raster images too
15:10:07 <heycam> … it needs to do more than SVG, but it can't do less than dynamic SVG
15:10:16 <heycam> … as opposed to the <image> element
15:10:26 <heycam> … but also should allow raster graphics as well
15:11:36 <heycam> CC: is it really zoom level control? or bit rate control?
15:11:39 <heycam> CL: it's more zoom level control
15:12:06 <heycam> CC: I was thinking in terms of bit rate control. does it have to be inside SVG, or could we have some indirection level where you first get some resource which describes other resources and you get one of them?
15:12:17 <heycam> … when I was talking about the adaptive streaming that's how it behaves
15:12:32 <heycam> … not suggesting to use exactly that, but having that extra level of indirection might be useful
15:13:06 <heycam> Dirk: how does the dynamic stuff work? so you zoom in and this makes the document load?
15:13:18 <heycam> … it still sounds very specific
15:13:25 <heycam> … I'm just wondering if it's better to write a JS library to do it
15:13:46 <heycam> BB: I think for say a medical image you would want that to happen automatically, browsers could optimise the prefetching
15:14:03 <heycam> NA: you can also use that kind of feature for handling small screens
15:15:18 <heycam> Doug: maybe media queries would be good for this
15:15:23 <heycam> CM: yes I keep thinking of media queries too
15:15:26 <heycam> CC: what about switch?
15:15:37 <heycam> Doug: MQ is friendlier than switch, with switch you have to use a specific document structure
15:15:41 <ChrisL> q+ to make a concrete proposal
15:15:54 <heycam> BB: MQs don't currently take into account the transforms you apply for zooming in, it's just the viewport you render into
15:16:08 <heycam> … the T&L spec has this min/max zoom attributes, and that may be one way to do it
15:16:25 <heycam> Dirk: with MQ you can just put the details or want or not want in classes, and then just not display them, for a certain viewport size
15:16:49 <heycam> BB: when you have the cascading style you need to control specific tile loading some levels deep
15:17:04 <Cyril> q-
15:17:06 <ChrisL> q?
15:17:17 <heycam> ack
15:17:18 <shepazu> q-
15:17:20 <heycam> ack
15:17:27 <ChrisL> http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires
15:17:41 <heycam> CL: there's a concrete proposal
15:18:10 <heycam> … it did have a fully specced out way of doing this, not saying it's a good idea, but it's something to look at
15:18:23 <heycam> … Kodak demoed an implementation in Batik at one point
15:18:48 <heycam> TA: HTML is doing srcset
15:19:20 <heycam> … you specify several urls with an alternate resources giving the pixel ratio
15:19:45 <heycam> BB: that's only a single level though
15:20:13 <heycam> CC: I agree the solution should not be specific to SVG
15:20:21 <TabAtkins_> TabAtkins_ has joined #svg
15:20:23 <heycam> CL: see how this multires proposal has minpixelsize and maxpixelsize
15:20:26 <TabAtkins_> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset
15:20:47 <heycam> … however it's still not great because you've got explicit markup, you have to do this slicing yourself
15:21:14 <TabAtkins_> TabAtkins_ has joined #svg
15:21:15 <heycam> … take an image, slice it into four, take those and slice it into four, inventing a naming scheme for tile files
15:21:23 <heycam> CM: I think Takagi-san's proposal requires that too
15:21:33 <heycam> BB: but these subresources could also use multiimage, so that would support the cascading
15:21:38 <heycam> … I think the cascading is an important feature
15:21:51 <heycam> Dirk: I still think it's too tied to the markup and it should be done in script
15:22:15 <heycam> s/cascading/cascading or recursion/
15:22:42 <heycam> BB: so I think what's missing is what's needed is someone to work on this
15:24:20 <heycam> … maybe the thing then is to bring this up in Zurich, I can't find the time before then to work on this
15:24:27 <heycam> … so we should bring it up when Takagi-san is present
15:25:48 <heycam> CL: would be useful to get feebdack from Alex Danilo on the problems he found when implementing it for his player
15:32:10 <jet> jet has joined #svg
15:36:17 <glenn> glenn has joined #svg
15:44:25 <jen> jen has joined #svg
15:45:12 <heycam> Topic: buffered rendering and image flattening
15:45:25 <heycam> CC: I have ACTION-2863
15:45:30 <Cyril> https://www.w3.org/Graphics/SVG/WG/track/actions/2863
15:45:47 <heycam> … the action is quite generic, investigate how to improve buffered-rendering for SVG2
15:45:52 <heycam> … I tried to think about it and look at the requirements so far
15:46:02 <heycam> … we have another requirement called "flatten to image"
15:46:08 <heycam> … to keep an image as pixels and not as a dom structure
15:46:18 <heycam> … if you look at it, buffered-rendering has 3 values: auto, static, dynamic
15:46:36 <heycam> … dynamic is a hint that the content of the group will change, so it's not worth caching it
15:46:41 <heycam> … static means it might not change, so it might be worth caching
15:46:45 <heycam> … auto means do whatever you want
15:46:48 <heycam> … but it's just a hint
15:47:01 <heycam> … I'd like to discuss the possibility to have not a hint, but something normative with conformance statements
15:47:17 <heycam> … where if you put the value say "static", the browser is allowed to keep the object cached without the associated dom structure
15:47:25 <heycam> … thereby reducing the memory required to store the object
15:47:33 <heycam> … it does not need to be a pixel representation, it could be a vector representation
15:47:38 <heycam> … it could be controlled by the rendering hints
15:47:55 <heycam> … the idea would be to have something a bit like canvas, where you just give JS calls and the result is an object in memory that you can reuse
15:48:04 <heycam> … in this case you don't use JS calls but you describe it with the dom
15:48:14 <heycam> … when it's loaded, if it's a clip art for instance you know you won't animated it or script it
15:48:26 <heycam> … it won't change, so the browser can keep it efficiently in its cache
15:48:29 <heycam> Dirk: but still vectors?
15:48:35 <heycam> CC: I think it should, but we could discuss it
15:48:42 <heycam> RC: is that a problem with keeping the dom around?
15:49:01 <heycam> … if you still have a vector representation...
15:49:34 <heycam> Dirk: you might have dom access during a rendering
15:50:33 <heycam> … if we have a dom tree and a render tree, you could even throw away some render tree and just keep say the cairo context with its path
15:50:56 <heycam> CC: why would you not always have an efficient render tree?
15:50:59 <heycam> s/CC/RC/
15:51:12 <heycam> CC: marshalling things between the DOM and the render tree is expensive
15:51:25 <heycam> Dirk: if nothing changes, you don't need the dom
15:51:29 <heycam> CC: the DOM consumes memory right?
15:51:59 <heycam> CM: I think that's what cyril is worried about
15:52:21 <heycam> BB: if you get rid of the dom, there are things in there that describe how to scale for example, and once you set static you won't have enough implementation to rerender properly
15:52:36 <heycam> ED: I don't think it would be a problem to define this as getting a snapshot
15:52:51 <heycam> CC: when an html image element points to an svg, are you optimising that?
15:53:15 <heycam> BB: they can be animated, so we keep the dom around
15:53:24 <heycam> … even for things like percentage lengths they'll change if you drop the dom
15:53:32 <heycam> ED: the question is whether that's acceptable
15:53:35 <heycam> BB: I'm dubious
15:53:39 <heycam> Dirk: what about hit testing?
15:55:25 <heycam> CM: this seems very dependent on how implementations are currently written
15:55:43 <heycam> Dirk: each render tree object is associated with a dom object
15:55:56 <heycam> … in WebKit when you destroy a DOM object the render object is destroyed
15:56:22 <heycam> CC: what happens when you have a canvas?
15:56:26 <ed> hit testing should work just fine assuming the UA keeps the vector representation around
15:56:28 <heycam> … you don't have a dom, but you have a render tree?
15:57:13 <heycam> Dirk: for a canvas you always need the dom object
15:57:29 <heycam> CC: if you have a group with this property set to static, the whole tree could be collapsed to one object
15:57:49 <heycam> Dirk: I think that is what Rik was suggesting
15:58:03 <heycam> CC: so with SVG you have a big DOM, with JS you have a bunch of JS, maybe there's a way in between
15:58:13 <heycam> Dirk: we need to specify how hit testing works
15:58:24 <heycam> … if WebKIt decides not to implement for example, hit testing would still apply
15:58:33 <heycam> … wouldn't want the behaviour to be different from implementations that do do it
15:58:39 <heycam> JY: what's the advantage of html img?
15:58:51 <heycam> … if you have a static svg file, browsers could just optimise it themselves couldn't they?
16:00:03 <heycam> BB: I think percentage lengths is something that's difficult
16:00:11 <heycam> … you could have a rectangle that is 300 high, 80% wide
16:00:16 <heycam> … the aspect ratio is going to depend on the viewport
16:00:22 <heycam> … it's fine to say take a snapshot, but when?
16:00:31 <heycam> … if that's in an html document and you reflow, the aspect ratio would hcange
16:00:40 <heycam> … what you would get depends on when you take the snapshot
16:00:50 <heycam> JY: what is the expected behaviour when you set it to static?
16:01:04 <heycam> BB: maybe in one browser it happens to snapshot just after a font is loaded?
16:01:15 <heycam> CC: can't you just resize the object? you have to resize individual parts?
16:01:18 <heycam> … indeed that's a problem
16:01:44 <heycam> RC: I think the buffered-rendering hint works fine, the auto thing can detect if something changes
16:02:40 <heycam> CC: I think having a hint is useless, it's better not having a hint
16:02:51 <heycam> … if browsers don't use the hint, then authors will use the hint in the wrong situation
16:02:58 <heycam> … browsers will then have to ignore it anyway
16:03:01 <heycam> CM: I agree
16:03:11 <heycam> RC: it cannot really know, it can't know what the JS user is going to do
16:05:47 <Cyril> q+
16:05:57 <Cyril> ack
16:06:23 <Cyril> q?
16:06:48 <Cyril> q?
16:07:09 <heycam> ack
16:07:22 <heycam> CC: I agree there are problems, if we go in this direction we'd need to specify when the snapshot is taken
16:07:27 <heycam> … and how it behaves for picking and so on
16:07:43 <heycam> … we could say when the full document is loaded, or when the tree is loaded, when DOMContentLoad is generated
16:07:53 <heycam> … or if we don't know exactly, we could go for an API
16:07:58 <heycam> … call .flattenTree()
16:08:34 <heycam> BB: I think you'd need to require a viewBox, so you don't end up with inconsistent sizes
16:08:38 <heycam> … so you have a fixed aspect ratio
16:09:02 <heycam> CC: this is for a subtree
16:09:16 <heycam> BB: that wouldn't help then, unless you require a viewBox on the top
16:09:51 <heycam> CC: when you have flattened the tree, you should be able to rescale and keep good quality, but the result shouldn't be that you rescale text only horizontally for example
16:10:05 <heycam> … the example about percentages or ems, should not be allowed
16:10:20 <heycam> Dirk: I think it doesn't really help if the size should always be in the same ratio
16:10:27 <heycam> … because you would get pixellation if you scale a lot
16:10:31 <heycam> BB: but this is a vector snapshot
16:11:15 <heycam> CC: I think this would bridge the performance gap between canvas and svg
16:12:03 <heycam> ED: from our experience, traversing trees is a big cost
16:12:29 <heycam> CM: if you are traversing a render tree isn't it that same?
16:13:18 <heycam> ED: it's quicker for us to traverse the render tree compared to the dom tree
16:13:33 <heycam> CC: I just want a single render object with a sequence of drawing commands
16:14:10 <heycam> CM: this would be a lot of work for us
16:14:25 <heycam> Dirk: also for us it wouldn't help with performance much
16:15:23 <jarek> jarek has joined #svg
16:16:07 <heycam> CC: I think there is a gain in performance and memory here
16:16:13 <heycam> … if you don't have to traverse the dom
16:16:17 <heycam> Dirk: we don't traverse the dom
16:17:28 <nikos> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Flatten_to_image
16:18:15 <heycam> [some discussion about implementation internals]
16:22:17 <heycam> JY: big files coming from inkscape or illustrator, you can just reference that with an <image>
16:22:37 <heycam> … then browsers can optimise that themselves
16:22:40 <heycam> … or for large things generated by script, if you want you can render that to canvas yourself
16:22:53 <heycam> NA: we have the flatten to image requirement from the SVG2 list
16:23:03 <heycam> … this is not exactly the same as cyril's thing, but maybe that approach would be better
16:23:14 <heycam> BB: there's drawElement on canvas
16:25:45 <heycam> CM: I think relying on the browser's on optimisation for <image> elements is fine here
16:26:04 <heycam> BB: animations run in HTML <img>
16:26:31 <heycam> … in firefox/chrome/safari/opera
16:26:41 <heycam> … but I think the <image> element in SVG is static
16:27:12 <heycam> ED: in opera we support animated png in SVG <image>
16:27:17 <heycam> … so why forbid svg animations in there
16:28:19 <heycam> CM: what about buffered-rendering?
16:28:21 <heycam> ED: that's already in the spec
16:28:27 <heycam> … but I think this action was about exploring other things
16:28:38 <heycam> … I think it's still useful, for some devices
16:28:43 <heycam> CC: in an interoperable way?
16:28:49 <heycam> ED: whether it's there or not doesn't make a difference
16:30:27 <heycam> BB: firefox allows animations in SVG <image>
16:30:34 <heycam> Doug: let's just change the spec
16:30:43 <ed> s/for rendering it doesn't matter if BR is specified or not, it should produce an identical rendering result/
16:31:01 <ed> s/whether it's there or not doesn't make a difference/for rendering it doesn't matter if BR is specified or not, it should produce an identical rendering result/
16:31:16 <heycam> RESOLUTION: SVG <image> will allow declarative or frame-based animated images
16:31:55 <shepazu> s/SVG <image> will allow declarative or frame-based animated images/SVG <image> will allow declarative or frame-based animated images, but not scripted animations/
16:33:06 <heycam> RESOLUTION: SVG2 won't have a flatten to image feature
16:33:51 <heycam> Topic: HTML5 drag and drop
16:33:52 <Cyril> rrsagent, pointer
16:33:52 <RRSAgent> See http://www.w3.org/2012/07/24-svg-irc#T16-33-52
16:34:00 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/SVG_DragAndDrop#Proposal_for_adding_the_HTML5_dnd_attributes_to_svg
16:34:16 <heycam> ED: this is a proposal to add all of the drag and drop attribtues and events to svg
16:34:27 <heycam> … currently HTML5 specifies that drag and drop attributes only apply to html elements
16:34:37 <heycam> … you can have svg inside html, but currently it's not specified to do anything for svg elements
16:34:41 <heycam> … so this proposal is to add those
16:34:53 <heycam> … there's a list here of changes that would be needed to be made
16:35:03 <heycam> … a list of events that html has, the event attributes like ondrag
16:35:10 <heycam> … two attributes, one could draggable, one called dropzone
16:35:13 <heycam> … to all svg elements
16:35:27 <heycam> … then the question is how much would need to be repeated in the spec, how much can we depend on html to define this
16:35:38 <heycam> … I'd like to hear what people think about this
16:35:38 <shepazu> q+
16:35:49 <Cyril> q-
16:35:55 <ChrisL> q-
16:36:00 <heycam> CM: I think it would be good to have on SVG
16:36:01 <krit> what about moving drag and drop to DOM from HTML?
16:36:39 <heycam> Doug: there is widespread dislike for html's drag and drop
16:36:47 <heycam> CL: if there are better things why aren't they in the spec then?
16:36:52 <heycam> Doug: there's nothing better implemented
16:37:20 <heycam> … I agree in general it's better to align with html, but let's not fool ourselves that's it's a good solution
16:38:14 <krit> again, what about moving it to DOM4?
16:38:42 <heycam> ED: I have seen lots of people ask how to drag html elements into svg
16:38:56 <heycam> … things like files from the desktop, too
16:39:48 <heycam> … I don't think this helps with the problem of getting mouse event coordinates in the right coordinate space
16:40:05 <ChrisL> OH: steaming pile of bovine manure
16:40:24 <heycam> ED: I don't think we should come up with something new SVG specific
16:40:27 <heycam> s/ED/Doug/
16:40:33 <heycam> Doug: should do it in webapps or whereever
16:40:55 <ed> s/… I don't think this helps with the problem of getting mouse event coordinates in the right coordinate space/Doug: I don't think this helps with the problem of getting mouse event coordinates in the right coordinate space
16:41:37 <heycam> Doug: you can't just let things be draggable, you have to use script to do it
16:43:49 <heycam> … maybe we should contact jquery ui guys and ask them whether we should ignore this api for now or come up with something new
16:43:59 <heycam> ED: I think though with SVG inline in HTML people would expect it to work on SVG elements
16:44:56 <heycam> … specifically I've heard people wanting to drag and drop images into svg, but also with compound documents dragging elements between html and svg and having things draggable and droppable
16:46:12 <heycam> CM: may as well just allow it to work on svg elements
16:48:53 <heycam> RESOLUTION: SVG elements will support the HTML drag & drop API
16:49:07 <heycam> CM: I'd prefer for us to copy as little text defined in HTML as possible
16:49:21 <krit> heycam: Did someone even consider moving it to DOM?
16:49:33 <heycam> ED: referencing HTML is fine?
16:49:35 <heycam> CL: I think so
16:49:45 <heycam> krit, I am not sure
16:49:50 <krit> :(
16:50:22 <heycam> ED: I am not sure if it makes sense, especially if it depends on markup
16:50:27 <ChrisL> s/think so/think so, they will likely be at CR by the time we get to CR/
16:50:36 <heycam> … (moving it to DOM that is)
16:52:34 <heycam> ACTION: Erik to add the drag & drop functionality to SVG2
16:52:34 <trackbot> Created ACTION-3328 - Add the drag & drop functionality to SVG2 [on Erik Dahlström - due 2012-08-01].
16:53:20 <heycam> Topic: SVG 2 section signoff for publication
16:54:41 <heycam> https://svgwg.org/svg2-draft/text.html#WhiteSpace
16:54:47 <heycam> CM: first thing is the white-space changes Chris has made
16:54:56 <heycam> … sounded like everyone was ok with that
16:55:37 <heycam> CM: next is https://svgwg.org/svg2-draft/text.html#TextElementWidthAttribute
16:56:16 <heycam> https://svgwg.org/svg2-draft/text.html#TextOverflowProcessing
16:56:20 <heycam> … which Erik has added
16:56:21 <cabanier> cabanier has joined #svg
16:58:00 <heycam> CM: next is painting chapter changes
16:58:16 <heycam> … most things after the introduction
16:58:18 <heycam> https://svgwg.org/svg2-draft/painting.html
16:58:24 <heycam> https://svgwg.org/svg2-draft/painting.html#SpecifyingFillPaint
16:58:28 <heycam> … I rewrote that section
16:58:57 <heycam> https://svgwg.org/svg2-draft/painting.html#StrokeShape
16:59:03 <heycam> … is that new section useful?
16:59:05 <ChrisL> I made changes to the fonts chapter, but didn't put in the class for the changes sorry
16:59:07 <ChrisL> https://svgwg.org/svg2-draft/fonts.html
16:59:46 <heycam> ED: I think it's useful
17:00:46 <heycam> CL: I changed the introduction to the Fonts chapter to talk about woff, remove css2 references
17:00:50 <heycam> … and moved around the order of the chapter
17:00:54 <heycam> … i put the svg fonts at the end
17:00:58 <heycam> … so the first thing is @font-face
17:01:10 <heycam> … I haven't yet trimmed down the section on fonts so it just describes tine fonts
17:01:13 <heycam> s/tine/tiny/
17:01:20 <heycam> … but there's a purple box to say we'll do that
17:01:51 <heycam> CM: are we keeping the <font-face> elements?
17:01:54 <heycam> CL: we could discuss that
17:02:01 <heycam> … I would fine with removing it
17:02:11 <heycam> … and I think we should be encouraging @font-face
17:02:14 <heycam> … they're equivalent
17:02:19 <heycam> … not sure if all implementations do both, though
17:02:52 <heycam> JY: we don't do the <font-face> elements, but we do do @font-face
17:06:28 <heycam> CM: maybe we can drop top-level <font-face>, but keep it as a child for <font> for implementations that do SVG Fonts
17:06:54 <heycam> RESOLUTION: SVG2 will drop support for top-level <font-face> in favour of @font-face, but keep <font-face> child of <font> for SVG Fonts
17:07:12 <heycam> ACTION: Chris to remove support for top-level <font-face> for external font referencing support
17:07:12 <trackbot> Created ACTION-3329 - Remove support for top-level <font-face> for external font referencing support [on Chris Lilley - due 2012-08-01].
17:09:23 <heycam> Doug: we haven't discussed: html has <!DOCTYPE> as a switch
17:10:25 <heycam> CM: rewritten section in color chapter
17:10:26 <heycam> https://svgwg.org/svg2-draft/color.html
17:10:34 <heycam> https://svgwg.org/svg2-draft/color.html#ColorProperty
17:10:40 <heycam> CM: that's to remove the definition of color in SVG
17:11:42 <heycam> … is it too much removed?
17:12:01 <heycam> CL: for white-space I still included the blue property definition table, but pointed to the other spec for the definitions of the values
17:12:17 <heycam> … the property table is fairly concise
17:12:33 <heycam> … also our table has whether the property is animatable, which the css one doesn't
17:12:42 <heycam> … so I'm tending to say to include the property definition table
17:13:07 <heycam> ACTION: Cameron to add back property definition tables
17:13:07 <trackbot> Created ACTION-3331 - Add back property definition tables [on Cameron McCormack - due 2012-08-01].
17:13:34 <heycam> https://svgwg.org/svg2-draft/pservers.html#MeshGradients
17:13:37 <heycam> CM: Tav's gradient mesh work
17:14:39 <heycam> https://svgwg.org/svg2-draft/masking.html#MaskElementMaskTypeAttribute
17:14:44 <heycam> CM: Brian's maskType attribute addition
17:14:52 <heycam> BB: I haven't marked it yellow yet
17:15:16 <heycam> … I reworked parts of the introduction as well
17:15:24 <heycam> … but I'm yet to add things about referencing mask elements
17:15:48 <heycam> CM: but ok to publish?
17:15:49 <heycam> BB: yes
17:18:10 <heycam> CL: Tuesday 21st August for publication?
17:18:12 <heycam> CM: sounds ok
17:18:43 <heycam> https://svgwg.org/svg2-draft/filters.html
17:19:29 <heycam> CL: what about compositing?
17:21:05 <ed> http://www.w3.org/TR/SVG11/render.html#ParentCompositing
17:21:07 <heycam> … we need to review chapter 14 whether we can remove things in favour of the compositing chapter
17:21:51 <heycam> … we need a resolution to publish compositing
17:22:47 <heycam> RESOLUTION: SVG WG agrees with publishing the Compositing spec
17:23:58 <heycam> ACTION: Nikos to add notes to SVG2 referencing Compositing, and remove any duplicated text if that can be done before publication
17:23:58 <trackbot> Created ACTION-3332 - Add notes to SVG2 referencing Compositing, and remove any duplicated text if that can be done before publication [on Nikos Andronikos - due 2012-08-01].
17:24:30 <heycam> https://svgwg.org/svg2-draft/masking.html#ObjectAndGroupOpacityProperties
17:25:09 <heycam> https://svgwg.org/svg2-draft/script.html
17:25:56 <heycam> CM: I removed contentScriptType and contentStyleType
17:26:03 <heycam> https://svgwg.org/svg2-draft/animate.html#Introduction
17:26:51 <heycam> CL: do we still want to point to web animations instead of SMIL here?
17:27:01 <heycam> BB: I want to drop the whole chapter and reference Web Animations specs
17:28:29 <heycam> CM: also I removed all mention of DTDs
17:28:55 <heycam> RESOLUTION: We will publish SVG2 FPWD mid August
17:30:32 <heycam> ACTION: Cameron to remove eRR from SVG2
17:30:32 <trackbot> Created ACTION-3333 - Remove eRR from SVG2 [on Cameron McCormack - due 2012-08-01].
17:32:44 <Cyril> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0152.html
17:33:56 <heycam> ACTION: Cameron to define "default object size" so that css3-images <image> works for SVG paints
17:33:56 <trackbot> Created ACTION-3334 - Define "default object size" so that css3-images <image> works for SVG paints [on Cameron McCormack - due 2012-08-01].
17:33:58 <TabAtkins_> http://dev.w3.org/csswg/css3-images/#default-object-size
17:34:31 <heycam> ACTION-3344: http://dev.w3.org/csswg/css3-images/#default-object-size
17:34:31 <trackbot> Sorry... adding notes to ACTION-3344 failed, please let sysreq know about it
17:37:03 <TabAtkins_> heycam, you also need to add <image> to the definition of <paint>.
17:43:11 <heycam> right
17:47:28 <krit> heycam: If you need something, ping me at any time
17:48:21 <heycam> ACTION: Cameron to work out whether to add a new repo for all new modules, or a new repo for each
17:48:21 <trackbot> Created ACTION-3335 - Work out whether to add a new repo for all new modules, or a new repo for each [on Cameron McCormack - due 2012-08-01].
17:50:10 <jet> jet has joined #svg
17:53:38 <krit> heycam: wait
17:54:05 <krit> 1406@137.194.5.208
17:54:14 <krit> heycam: --^
17:59:15 <heycam> Topic: SVG/HTML integration
17:59:20 <heycam> BB: I don't have anything to sa
17:59:23 <heycam> s/sa/say
17:59:26 <heycam> … where are we up to?
17:59:40 <heycam> … at hamburg we talked about both including HTML elements in SVG directly, without having to wrap them in <foreignObject>
17:59:56 <heycam> … and we also talked about the opposite direction, including SVG elements directly in HTML without wrapping them in <svg>
18:00:06 <heycam> … I was just wondering what the next step is there, because I think it sounds good
18:00:56 <heycam> … is this something we should be pushing for? does it have any connection svg2?
18:00:59 <heycam> … how can we drive it forward?
18:01:20 <heycam> Doug: make an experimental implementation
18:01:25 <heycam> … that will help point out flaws
18:02:33 <heycam> BB: I agree that sounds good
18:02:43 <krit> shepazu: in JS? :D
18:02:43 <heycam> … just curious if people think that this would never happen
18:02:58 <krit> heycam: It will happen
18:03:01 <heycam> TA: henri is against it
18:03:10 <krit> heycam: might take till next year :)
18:03:20 <heycam> … the svg wg didn't want an explicit list for the parser
18:03:27 <heycam> Doug: SVG Integration was meant to have that list
18:03:44 <heycam> … we didn't want HTML5 to white list what SVG elements are allowed
18:04:16 <heycam> Doug: but i would be happy with whitelisting the svg2 elements for now
18:04:27 <heycam> TA: there are four conflicting elements
18:04:34 <heycam> … style, script, a, font
18:04:47 <ChrisL> a is changing to a href
18:04:57 <ChrisL> the other difference is svg a can next
18:05:06 <heycam> CL: SVG's <a> can nest, but HTML's doesn't
18:05:30 <heycam> CM: I think that is just enforced by the parser
18:06:13 <heycam> … the behaviour is still defined though because you can do it in teh dom
18:06:15 <heycam> s/teh/the/
18:06:29 <heycam> Doug: I think it's not a big deal if in text/html you can't nest them
18:06:51 <heycam> TA: Hixie is against unifying SVG and HTML script, because SVG script is sane and HTML is not
18:07:02 <heycam> … but Henri argued for unifying
18:07:16 <heycam> Doug: innerHTML and document.write aren't allowed in SVG script
18:07:24 <ChrisL> hooray
18:07:45 <thorton> thorton has joined #svg
18:08:44 <heycam> TA: several people are opposed to having chameleon HTML/SVG namespaces
18:08:59 <heycam> … the final element conflict is <font>
18:10:12 <heycam> CM: I would fine with requiring wrapping <svg> around <font> if that solves the problem
18:11:02 <heycam> TA: I'm still not entirely sure why chameleon namespaces are problematic
18:11:17 <heycam> … on a related note, we have two element conflicts with MathML
18:11:25 <heycam> … it's in semantic MathML which nobody implements
18:11:43 <heycam> … <image> and <set>
18:13:04 <ChrisL> where 'nobody' means 'no browsers, jst mathematical software'
18:13:13 <heycam> BB: seems like most people are generally in favour of that direction
18:13:37 <heycam> TA: Hixie's largest argument against embedding SVG directly in HTML, is that embedding a <rect> into a <p> doesn't gain you much
18:13:46 <heycam> … that might not be true if you are doing a path to do a star, for example
18:13:59 <heycam> … and if you are embedding a <g> you may as well embed an <svg>
18:14:04 <ChrisL> I agree with Hixie there (shock, horror)
18:14:22 <heycam> CM: Brian's <mask> children would be good to support too
18:14:36 <heycam> Dirk: it's just another thing for authors to learn
18:15:17 <birtles> Some single elements do give you quite a lot of value, e.g. <animate>
18:16:04 <heycam> JY: it is a bit strange to have to wrap say <filter>, but for rendering things it's not as useful
18:17:41 <heycam> Dirk: should these elements have a CSS layout box? I think they should, but we don't have anything defined in the spec to handle this
18:17:51 <heycam> TA: if you have a <path> as a child of a flex box, what does that do?
18:19:45 <heycam> TA: for embedding HTML in SVG I can write that up, that's easy
18:19:52 <heycam> … embedding SVG in HTML is more controversial
18:20:01 <heycam> … we need to convince hsivonen, dbaron and maybe abarth
18:20:15 <heycam> … and have us all agree on what the correct solution for this problem is
18:20:54 <heycam> … I will work on the proposal for HTML in SVG
18:21:58 <heycam> BB: maybe we can just allow <mask>, etc. as children in HTML
18:22:26 <heycam> JY: there's also the question of whether people would put that directly in their document, or reference an external file
18:22:33 <heycam> TA: being able to reduce external requests is a nice thing
18:22:58 <heycam> ED: there are some complications, percentages depending on the viewport
18:24:05 <heycam> … if a mask has a maskWidth="50%" what do you resolve that against
18:24:09 <heycam> … solvable of course but not defined
18:24:19 <heycam> Dirk: we have that in filters too, we use the bounding client rect of the element
18:24:45 <ed> s/maskWidth/mask @width/
18:24:46 <ed> http://www.w3.org/TR/SVG11/masking.html#MaskElementWidthAttribute
18:24:49 <heycam> BB: depends on maskUnits, whether it resolves against the thing being masked or the viewport the <mask> element is in
18:25:57 <heycam> ED: what if you have <mask> with text inside?
18:26:04 <heycam> TA: you can just put display:none on it
18:26:31 <heycam> TA: I will look at the selected SVG elements in HTML too
18:27:31 <heycam> Topic: SVG DOM improvements
18:27:38 <heycam> TA: how do we improve the SVG DOM without a big red switch?
18:27:54 <heycam> CM: we are a bit limited in the improvements we can do without a big switch
18:28:16 <heycam> Dirk: with turning every attribute into a property, do we still need the SVG DOM?
18:28:42 <heycam> TA: a lot of the benefit disappears when you can the CSS OM
18:30:14 <heycam> rect.x.px += 20
18:30:33 <heycam> CM: that is no worse than using CSS OM
18:30:58 <heycam> TA: in CSS OM it would convert it into the current unit you're using
18:31:11 <heycam> … if you are using percentages, and you add 20px, it would convert the result into %
18:32:26 <thorton> thorton has left #svg
18:32:29 <thorton> thorton has joined #svg
18:33:05 <heycam> … if throwing the CSS OM on top lets us ignore animVal/baseVal, that would be good
18:35:01 <heycam> CM: should I just write up a concrete proposal for the x.px thing?
18:35:03 <heycam> CL: yes
18:35:14 <heycam> BB: this is not going to help with say path interfaces, so we definitely need something there and can't rely on CSS OM
18:36:08 <heycam> ACTION: Cameron to propose SVGAnimatedLength improvements
18:36:08 <trackbot> Created ACTION-3336 - Propose SVGAnimatedLength improvements [on Cameron McCormack - due 2012-08-01].
18:36:37 <TabAtkins_> ScribeNick: TabAtkins_ 
18:37:53 <TabAtkins_> heycam: We've decided we're meeting just after svgopen - the mon-wed directly afterards. Sep 17-19.
18:38:07 <TabAtkins_> heycam: Andreas asked if we want to meet something in the mountains rather than the svgopen conference venue.
18:38:16 <ed> topic: SVGOpen F2F meeting
18:38:50 <TabAtkins_> krit: I have to leave at noon on wednesday.
18:39:10 <TabAtkins_> heycam: But that means you'll miss all of wednesday anyway.
18:39:16 <TabAtkins_> heycam: Continuing, andreas says there are hotels in the mountains with meeting rooms we can use.
18:39:31 <heycam> Schuders
18:39:56 <cabanier> cabanier has joined #svg
18:39:56 <TabAtkins_> heycam: And there is one place, Schuders, that is a 2hr train ride from Zurich.
18:40:26 <TabAtkins_> Cyril: My parents are an hour or two away from Zurish, so I was planning on commuting from them sometimes.
18:41:05 <TabAtkins_> heycam: Prices are between $50 and $75 swiss franks, which includes breakfast.
18:41:30 <TabAtkins_> shepazu: The frank is about 1-1 with the dollar, so that's cheap and beautiful.
18:41:47 <cabanier1> cabanier1 has joined #svg
18:41:51 <heycam> www.postschuders.ch
18:43:03 <ChrisL> looks like a fun place
18:43:17 <ChrisL> i won't be hiking anywhere though
18:45:16 <TabAtkins_> Cyril: Let's get Tav's opinion as well.
18:45:43 <TabAtkins_> ChrisL: We can still decide now.
18:47:16 <heycam> RESOLUTION: We will meet at Andreas's suggested Swiss mountain town.
18:47:36 <heycam> ACTION: Cameron to set up a wbs for SVG Open F2F and let Andreas know
18:47:36 <trackbot> Created ACTION-3337 - Set up a wbs for SVG Open F2F and let Andreas know [on Cameron McCormack - due 2012-08-01].
18:50:05 <TabAtkins_> ed: Any plans for the next meeting after that?
18:50:12 <TabAtkins_> Cyril: I can offer Paris any time.
18:50:22 <TabAtkins_> heycam: you don't want to go to australia or nz?
18:50:34 <TabAtkins_> Cyril: That would be fine too. ^_^
18:51:03 <TabAtkins_> heycam: Okay, so we get Alex Danilo to arrange it for us.
18:51:44 <TabAtkins_> nikos: Or maybe Canon.
18:53:30 <TabAtkins_> Cyril: So, dates?  Sometime in January?
18:54:09 <TabAtkins_> Cyril: week starting with the 21st is no good for me.
18:54:13 <TabAtkins_> Cyril: Conflicting meeting.
18:55:47 <ed> feb 4 - 8, 2013
18:59:30 <heycam> january 14 - 17 is better
19:00:46 <heycam> RESOLUTION: We will meet January 14 - 17, 2013 in Sydney.
19:01:11 <heycam> good idea to meet with CSS in Tokyo in April which it sounds like they might be
19:06:40 <nikos> nikos has joined #svg
21:10:07 <ed> trackbot, make minutes
21:10:07 <trackbot> Sorry, ed, I don't understand 'trackbot, make minutes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
21:10:13 <ed> rrsagent, make minutes
21:10:13 <RRSAgent> I have made the request to generate http://www.w3.org/2012/07/24-svg-minutes.html ed
22:18:49 <jet> jet has joined #svg
23:02:51 <vhardy_away> vhardy_away has joined #svg
23:07:07 <thorton> thorton has joined #svg
00:27:10 <shepazu> shepazu has joined #svg
02:43:50 <krit> krit has joined #svg