00:02:52 <Cyril> Cyril has joined #svg
00:05:55 <birtles> [11] Expose animateMotion values in the SVG DOM
00:08:07 <birtles> birtles: is it not exposed in the animated value of the transformed list?
00:08:11 <birtles> all: no it's not
00:08:23 <birtles> krit: shouldn't it be exposed through the OM for CSS Transforms?
00:10:41 <birtles> shanestephens_: it would be better if you can query the animated value per animation effect not just the composite result
00:10:47 <birtles> heycam: yeah, that would be nice
00:10:59 <birtles> shanestephens_: we can add an API for that in Web Animations
00:11:08 <AlexD> AlexD has joined #svg
00:11:11 <birtles> heycam: let's leave it to Web Animations then
00:11:39 <birtles> krit: what about adding a new layer/stylesheet for animation to the cascade?
00:12:49 <birtles> ... it would need to be defined by Web Animations
00:13:17 <birtles> heycam: let's drop it from the requirements list and leave it to Web Animations
00:13:32 <birtles> [12] Make the SVG*List interfaces a bit more like other lists/arrays
00:14:00 <birtles> ed: I think heycam did it
00:14:12 <birtles> heycam: I think I did it when I converted the interfaces to Web IDL
00:14:16 <birtles> ... I guess it's done
00:15:29 <birtles> [13] Make it easier to read and write to attributes in the SVG DOM
00:17:45 <birtles> AlexD: I think the proposal for rect.x.px is nice for developers
00:17:54 <birtles> heycam: it would be pretty easy to add just that
00:18:19 <birtles> ... so should we just do that?
00:18:31 <birtles> all: seems good
00:19:19 <birtles> heycam: should it be base val or a hybrid of anim/base val?
00:19:36 <birtles> all: seems better to just use base val
00:19:51 <birtles> action: Cameron to add length shortcuts to SVG DOM
00:19:52 <trackbot> Created ACTION-3414 - Add length shortcuts to SVG DOM [on Cameron McCormack - due 2013-02-11].
00:21:00 <birtles> heycam: how would you represent calc() etc. in the DOM?
00:21:18 <birtles> ... do you just have to use the CSSOM for that?
00:21:46 <birtles> krit: let's talk about that as part of the CSSOM discussion
00:21:58 <birtles> [14] Improve the SVG path DOM APIs
00:23:43 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Making_Improvements
00:25:06 <birtles> birtles: I made a proposal about creating paths from an array of floats
00:25:26 <birtles> ... it would also be neat to have some constructors for some of the path data types
00:26:00 <birtles> heycam: what about extending the existing methods but allowing them to take a string instead
00:26:11 <birtles> ... let's keep the requirement for now
00:26:45 <birtles> ... we'll go into it when we talk about canvas path proposal later
00:26:51 <birtles> [15] Ensure improved property value access to SVG properties
00:27:16 <birtles> ... CSSOM will fix this, skip it
00:27:22 <birtles> [16] Improve bounding box method APIs
00:27:49 <birtles> [We think we have already added this to the spec, but there is some discussion related to this later in the week.]
00:27:51 <birtles> ... keep it
00:27:56 <birtles> [17] Have a method for <image> to select a part of an image to display, maybe by allowing viewBox on it
00:28:33 <birtles> AlexD: good for DOM spriting
00:28:42 <birtles> heycam: you can do this with media fragments
00:28:50 <birtles> ... do we need a separate feature for this?
00:28:59 <birtles> krit: does that apply to <image> elements too?
00:29:14 <birtles> ... we need to add spec text for that (supporting image fragments)
00:29:48 <birtles> ... and then we run into trouble with SVG sprites etc.
00:29:52 <birtles> heycam: I thought we resolved that
00:29:59 <birtles> krit: we only resolved that for CSS, not for SVG
00:30:30 <birtles> ... (i.e. CSS properties, not xlink:href)
00:30:37 <birtles> ... we need to define how <image> interacts with media fragments
00:30:54 <birtles> [Added to agenda]
00:31:55 <birtles> [18] Allow auto-sized images
00:32:08 <birtles> heycam: no progress there
00:32:35 <birtles> ... it's to do with adding "auto" to <image> element's width and height
00:32:44 <birtles> ... I think we decided they should default to zero
00:32:49 <birtles> ... but it's yet to be added to the spec
00:33:02 <birtles> ... the only issue remaining is just how to reflect auto in SVGLength
00:33:37 <birtles> ... we could just use UNKNOWN
00:33:50 <birtles> ... like we do for transforms
00:35:08 <birtles> krit: but then what would you do for, e.g., <rect>
00:35:13 <birtles> ... since it uses the same property
00:35:28 <birtles> ... you would have to define what it means to have a <rect> whose width is "auto"
00:35:44 <birtles> heycam: we could just make it zero (the initial value)
00:35:50 <birtles> ... let's keep this one
00:36:03 <birtles> action: Cameron to spec auto-sized images
00:36:03 <trackbot> Created ACTION-3415 - Spec auto-sized images [on Cameron McCormack - due 2013-02-11].
00:36:08 <birtles> [19] Support level of detail control
00:36:35 <birtles> birtles: will be covered tomorrow when we discuss <iframe> for SVG
00:36:41 <birtles> heycam: let's keep the requirement for now
00:37:03 <birtles> [20] Be able to display InkML trace groups by some means such as buffered-rendering and variable stroke width , not necessarily varying anything
00:38:50 <birtles> heycam: this is basically variable stroke-width
00:38:58 <nikos1> nikos1 has joined #svg
00:39:02 <birtles> ... which we will discuss later
00:39:56 <birtles> birtles: there's also buffered rendering
00:40:03 <birtles> heycam: which ed already added to the spec
00:40:59 <birtles> [21] Allow transform on the <svg> element
00:41:04 <birtles> ed: done right?
00:41:21 <birtles> krit: yes, since you added <svg> to SVGGraphicsElement
00:41:42 <birtles> ... but we need to specify what happens on the root element
00:42:06 <birtles> ... but CSS Transforms is not supposed to apply to the root element I think...
00:42:14 <birtles> heycam: but what if you apply CSS transforms to the <html> element?
00:42:22 <birtles> krit: I think that should work actually...
00:42:34 <birtles> heycam: I think root <svg> should do that same as <html>
00:42:36 <birtles> ed: I agree
00:43:20 <birtles> ACTION: Dirk to investigate applying CSS transforms to SVG when it is the root element of the document
00:43:20 <trackbot> Created ACTION-3416 - Investigate applying CSS transforms to SVG when it is the root element of the document [on Dirk Schulze - due 2013-02-11].
00:44:17 <birtles> heycam: we need to specify the order in which the transform applies in relation to the viewBox etc.
00:44:25 <birtles> krit: yes, we need to define where it applies
00:45:05 <birtles> RESOLUTION: transforms should apply at the beginning of the transform cascade (as if the transform applied to a group around the <svg> element)
00:45:13 <birtles> [22] Support a mechanism like or the same as allowReorder from SMIL3
00:47:22 <birtles> heycam: still needs to be done
00:47:38 <birtles> ... it would be an easy one to add if someone wants to do it
00:48:14 <birtles> ... if no one wants to add it, skip it for now
00:48:36 <Cyril> http://www.w3.org/Graphics/SVG/WG/track/issues/2238
00:49:34 <birtles> [23] Relax referencing requirements to particular elements to allow dropping fragments to mean referencing root element, where it makes sense, such as with use
00:50:11 <birtles> heycam: makes sense
00:50:47 <birtles> action: Cameron to relax referencing requirements (issue-2295)
00:50:47 <trackbot> Created ACTION-3417 - Relax referencing requirements (issue-2295) [on Cameron McCormack - due 2013-02-11].
00:50:54 <birtles> [24] Normatively reference the SVG Parameters spec
00:51:26 <birtles> heycam: we need to resolve how this interacts with CSS variables before we references it
00:51:29 <birtles> krit: so, not now?
00:52:03 <birtles> ... I don't think we have an editor for it now
00:52:16 <birtles> heycam: so let's not normatively reference it until it's ready
00:52:29 <birtles> [25] Add data-* attributes to align with HTML5
00:52:47 <birtles> heycam: I think we should do that
00:52:50 <glenn> glenn has joined #svg
00:53:28 <birtles> ... might need coordination if it's defined on HTMLElement
00:53:32 <birtles> ... so we can reference it
00:53:48 <birtles> ... it's currently on HTMLElement
00:54:21 <birtles> krit: we could add it to Element
00:54:33 <birtles> ed: where should we add it? SVGElement or Element?
00:55:09 <birtles> heycam: someone should send a mail to whatwg list regarding moving data to Element
00:55:22 <birtles> ACTION: Cameron to mail HTML people about moving data to Element
00:55:22 <trackbot> Created ACTION-3418 - Mail HTML people about moving data to Element [on Cameron McCormack - due 2013-02-11].
00:55:29 <birtles> [26] Align with HTML5 global semantic attributes where these make sense for SVG
00:56:00 <birtles> [this is things about microdata]
00:57:14 <heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#global-attributes
01:00:04 <birtles> [Discussion about classList being on Element and issues around className]
01:00:24 <birtles> heycam: let's discuss the specific attributes later but keep the requirement for aligning with HTML here
01:01:15 <birtles> ACTION: Cameron to follow-up aligning with global HTML attributes in SVG
01:01:16 <trackbot> Created ACTION-3419 - Follow-up aligning with global HTML attributes in SVG [on Cameron McCormack - due 2013-02-11].
01:01:24 <birtles> [27] Make property values case insensitive
01:02:05 <birtles> heycam: I think we should have this one
01:02:28 <birtles> ... this is just about presentation attributes
01:03:33 <birtles> ... they are currently case-sensitive but they shouldn't be
01:05:10 <birtles> [Discussion about camel case attribute names and the CSSOM]
01:05:56 <birtles> [28] Add color management subject to deciding the exact conformance classes required
01:06:25 <birtles> heycam: chris has already done a bunch of changes here
01:07:18 <birtles> [29] Include non-scaling stroke
01:08:17 <birtles> ed: it's implemented but not in the spec yet
01:08:34 <birtles> ACTION: Erik to add non-scaling stroke to SVG2
01:08:35 <trackbot> Created ACTION-3420 - Add non-scaling stroke to SVG2 [on Erik Dahlström - due 2013-02-11].
01:08:46 <birtles> [30] Include non-scaling features (non-scaling part of the object, and non-scaling entire object)
01:09:01 <birtles> birtles: we will cover this on Wed morning
01:09:14 <birtles> [31] Include a way to specify stroke-position
01:09:39 <birtles> heycam: a few years ago I presented a proposal for this
01:10:28 <birtles> ... do we still want this?
01:13:09 <birtles> [Discussion about implementation strategies]
01:13:17 <birtles> birtles: could we defer to SVG3?
01:14:38 <birtles> all: agreed to defer this requirement to SVG3
01:14:43 <birtles> [33] Allow more author control over positions of dashes
01:14:48 <birtles> [32] Specify more precisely stroke dashing
01:15:00 <birtles> heycam: done
01:15:06 <birtles> ... I added wording for this
01:15:16 <birtles> [33] Allow more author control over positions of dashes
01:15:40 <birtles> heycam: would be nice, but I can do without it
01:15:46 <birtles> ed: what kind of control
01:15:57 <birtles> heycam: e.g. stretching dash to corners etc.
01:17:53 <birtles> action: Cameron to add dash control to SVG2
01:17:53 <trackbot> Created ACTION-3421 - Add dash control to SVG2 [on Cameron McCormack - due 2013-02-11].
01:18:17 <birtles> [34] Support hatching without the artefacts that patterns currently impose
01:19:55 <heycam> Tav, are you still on track to adding the hatching proposal to SVG 2?
01:20:05 <heycam> Tav, I think people here are keen for it to go in
01:20:20 <birtles> heycam: we'll assume Tav is taking care of this
01:20:33 <birtles> [35] Support custom filters
01:20:44 <birtles> krit: it's in Filter Effects
01:20:48 <birtles> heycam: we can just reference that
01:20:58 <birtles> [36] Align the style element with the HTML 5 style element
01:21:09 <birtles> heycam: I already have an action for this
01:21:18 <birtles> ... it's about adding scoped etc.
01:21:23 <birtles> AlexD: what about href?
01:21:29 <birtles> ... that's pretty painful
01:22:07 <birtles> heycam: we decided to drop xlink from href everywhere
01:22:30 <shepazu> (not just href… all xlink elements, like title, etc.)
01:23:48 <birtles> AlexD: HTML uses src and this is a real pain point for developers
01:23:57 <birtles> heycam: we should just use 'src' in SVG's style element too
01:24:02 <cabanier> cabanier has joined #svg
01:25:23 <birtles> heycam: so we decided <image> would allow 'xlink:href', 'href' AND 'src'?
01:25:58 <birtles> [seems so, but which one wins?]
01:26:14 <birtles> nikos: there was some discussion at rigi about that
01:26:24 <birtles> heycam: details, we can work that out later
01:26:38 <birtles> [37] Include better bounding-box querying functions
01:26:44 <birtles> dupe, skip
01:26:49 <birtles> [38] Ensure there is a way to specify rotations around particular points and shapes
01:28:01 <birtles> heycam: this may be fixed by transform-origin?
01:28:47 <birtles> Dmitry: I want to rotate two elements around a point together (even though they may already have other rotation)
01:28:55 <birtles> krit: we could make transform-origin a list in the future
01:30:05 <birtles> Dmitry: we also need an origin for scale
01:30:19 <birtles> krit: we could also solve this with a list for transform-origin
01:30:47 <birtles> [This will be resolved in CSS Transforms]
01:30:54 <birtles> [39] Support shared path segments
01:32:13 <birtles> shanestephens_: this would be handy for animation
01:32:23 <birtles> cabanier: I thought we already deferred this
01:33:12 <birtles> ACTION: Cyril to specify shared-path segments
01:33:12 <trackbot> Created ACTION-3422 - Specify shared-path segments [on Cyril Concolato - due 2013-02-11].
01:33:44 <birtles> [40] Include the smooth path between points functionality (Catmull-Rom)
01:34:35 <heycam> shepazu, are you still OK to be assigned to add the catmull-rom stuff to the spec?
01:34:48 <birtles> Dmitry: it's very popular amongst developers
01:34:59 <birtles> birtles: I think the only outstanding issue was the tension property
01:35:03 <birtles> heycam: I'd like to have it as well
01:40:33 <shepazu> heycam, yes, unless someone else wants to do it
02:22:55 <stakagi> stakagi has joined #svg
02:29:21 <Cyril> Cyril has joined #svg
02:29:46 <heycam> shepazu, yes no problem; we're just trying to remove things from the list that aren't realistically going to get done, but if it's still on your radar that's fine
02:33:44 <nikos> nikos has joined #svg
02:34:27 <stakagi> stakagi has joined #svg
02:35:30 <jun> jun has joined #svg
02:40:36 <nikos> scribenick: nikos
02:40:49 <nikos> Topic: Marker knockouts using masking or compositing
02:41:16 <nikos> heycam: I put some half baked proposal into the spec for clipping that takes away part of the stroke so markers can have a hollow section, or a boundary around the edge
02:41:29 <nikos> ... I think what I specced might be difficult to use
02:41:33 <Cyril> https://svgwg.org/svg2-draft/painting.html#MarkerKnockout
02:41:49 <nikos> ... I did it that way to avoid having to do some path geometry opertations
02:41:59 <nikos> ... I think a simpler way to do this would be with masking or compositing
02:42:38 <nikos> cabanier: I think you'll have to special case it for compositing. The shape and the stroke will have to be treated as in a group
02:43:03 <nikos> krit: Are you talking about the markers causing the knockout?
02:43:15 <nikos> heycam: Subway station circle is a common use case
02:44:34 <nikos> heycam draws an example on the whiteboard
02:44:40 <nikos> <marker .... >
02:44:46 <nikos>   <path knockout />
02:44:50 <nikos> <path ....>
02:45:24 <nikos> heycam: I want to specify regions that knock out and regions that don't
02:46:15 <nikos> heycam: I want to knock out the center of the subway station circle
02:46:23 <nikos> nikos: that's not how knock-out works
02:47:49 <nikos> dmitry: the marker could have different masking capabilities, allowing you for example to apply a gradient as a mask
02:48:30 <nikos> krit: I'd have two types of marker - a mask marker and a rendering marker
02:48:39 <nikos> heycam: I'd like it to be part of the one if possible
02:49:54 <nikos> Cameron writes another example
02:50:05 <nikos> <marker marker-mask="url(#a)">
02:50:33 <nikos>   <path />
02:50:38 <nikos> <g id="a">
02:50:50 <nikos> heycam: Ideally we want to keep the mask group and the path together
02:51:13 <nikos> heycam: Does everyone think it's better to do this with masking than anything else?
02:52:49 <nikos> Cyril: We have been trying to remove the use of ids, so following that it's better to have the mask as a child
02:53:38 <nikos> heycam: How about a marker-mask element that is a child of the marker
02:54:12 <nikos> shanestephens_: Having it apply to the first thing up the ancestor chain that is relevant makes sense
02:54:45 <nikos> krit: So you'd always have to have a marker if you want to have a gap?
02:54:50 <nikos> heycam: You could leave it blank
02:56:42 <nikos> heycam: I don't think we should use the name mask for the element, because it would require a special case of the way a mask applies to it's parent
02:56:56 <nikos> heycam draws another example
02:57:56 <shanestephens_> marka mask: http://www.genuineafrica.com/images/Marka/African-Masks/African-Masks-Marka-Mask-32-F.jpg
02:57:57 <nikos> <marker ...><markermask><circle ... r="20" /></markermask><circle ... r="10"/></marker><path d="..." marker-mid="url(#a")
02:58:23 <nikos> krit: I think it would be a common use to mask without wanting to draw anything
02:58:38 <nikos> ... it would require a lot of mark-up to do that
02:59:38 <nikos> heycam: I was originally thinking clipping, but using that wouldn't you have to do a lot of computation?
02:59:46 <Zakim> Zakim has left #svg
02:59:51 <nikos> AlexD: clip-out is a common operation and is fairly simple
03:00:55 <nikos> heycam: If there were two types of marker - drawing and masking, everytime you want to use that pair you have to include two references
03:01:19 <nikos> krit: it would be good to set the order of the two types, first the drawing, then the clipping for example
03:02:08 <nikos> heycam: The marker mask applies to the path though, so you want to apply all the masks then render the markers
03:02:41 <nikos> dmitry: That's the way I'd expect it to work - the marker mask applies to the path and not to the previously drawn markers
03:03:29 <nikos> Cyril: I think we need to consider what all the use cases are, we have only considered the subway station so far
03:03:49 <nikos> heycam: I think this would allow an author to do the other things I have in the spec currently
03:04:16 <nikos> ... one issue I noted in the spec was that if the path is curving where you want to knock-out, you may want to distort the shape of the knock-out
03:05:18 <nikos> ... another question, is whether it would apply to the stroke and the fill, or just the stroke?
03:05:22 <nikos> AlexD: I'd say both
03:05:33 <nikos> cabanier: Just the stroke
03:05:38 <nikos> heycam: I could see cases for both
03:06:50 <glenn> glenn has joined #svg
03:08:16 <nikos> Cyril: the marker position is affected by stroke-position right?
03:08:19 <nikos> heycam: That's a good question
03:09:15 <nikos> ed: if you change the drawing order with paint-order, do you still want to knock out parts that are drawn after the markers?
03:09:33 <nikos> Cyril: The marker mask should mask anything to the left of the marker
03:09:42 <nikos> heycam: I think that's the only way that makes sense
03:10:15 <nikos> ... I like this solution, I think it's far simpler for an author than what is in the spec currently
03:10:52 <nikos> krit: what happens if the marker mask is after the marker graphic element?
03:11:01 <nikos> ... would the mask affect the marker?
03:11:02 <nikos> heycam: no
03:11:17 <nikos> Cyril: if two markers are close, the markers aren't affected by the masks are they?
03:11:32 <nikos> heycam: No, only the stroke is affected
03:12:28 <nikos> krit: I'm not sure about this, you would need to check every mask element to create the mask, it sounds complicated and error prone
03:13:40 <nikos> heycam: I think you have to do all the masking first, you can do it per marker
03:14:10 <nikos> krit: You can when you have the marker and the mask separately. Then you don't need to access the DOM twice
03:14:20 <nikos> heycam: Is it because marker-mask is a child of the marker that it's difficult?
03:14:34 <nikos> krit: Yes, because you have two different rendering contexts. One for each
03:17:06 <nikos> cabanier: How do you combine the masks?
03:17:23 <nikos> heycam: you just combine them all and draw as one
03:17:32 <nikos> krit: If you had gradients in the mask?
03:17:37 <nikos> heycam: You would have to composite them together
03:18:16 <nikos> Cyril: If you had two overlapping markers and each had a left to right gradient. The middle would be lighter
03:18:51 <nikos> heycam: You could specify blend modes and compositing operators on the marker-mask to define how they combine
03:19:42 <nikos> krit: is marker-mask an alpha or a luminance mask? Can you specify one or the other?
03:21:34 <nikos> heycam: good question, not sure
03:22:02 <nikos> heycam: I'm not sure it would be hard to implement. I could try writing something up and send it to the list?
03:25:03 <nikos> heycam: Can you do this masking in hardware?
03:25:19 <nikos> krit: The biggest problem will be the position calculation of the markers
03:25:56 <nikos> dmitry: if you replace masking with clipping does it make it easier?
03:25:59 <nikos> heycam: I don't think so
03:26:07 <nikos> shanestephens_: don't you need to traverse the paths anyway to place the markers?
03:26:21 <nikos> krit: yes, so it doesn't make any difference whether you use clipping or masking
03:26:47 <nikos> heycam: I'll write some examples and some text and we can decide later
03:27:11 <nikos> action: heycam to write up examples and text for marker-mask
03:27:11 <trackbot> Created ACTION-3423 - Write up examples and text for marker-mask [on Cameron McCormack - due 2013-02-11].
03:31:24 <cabanier> http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/
03:31:30 <nikos> Topic: Canvas path proposal
03:31:54 <nikos> cabanier: The canvas spec proposes to allow for a path object to be constructed with SVG path syntax
03:32:07 <nikos> ... and you can combine, stroke, fill, with different winding rules
03:32:24 <nikos> ... it would be good to get the modified path data back out
03:33:02 <nikos> ... Google has implemented some of this
03:33:34 <nikos> Cyril: is it really interoperable? I think in Inkscape, for example, they create an approximation of the path
03:34:04 <nikos> cabanier: how is the quality of what is produced? If you have
03:34:27 <nikos> s/cabanier: how is the quality of what is produced? If you have /cabanier: how is the quality of what is produced?
03:35:03 <nikos> krit: it can be done by the GPU. But you can't get the path data back out
03:35:35 <nikos> cabanier: If you draw using JavaScript and perform operations like a union, you can't get the path data from that
03:35:59 <nikos> heycam: So this is in the spec already? Things like arc and path
03:36:14 <nikos> krit: Some are
03:37:46 <nikos> cabanier: The canvas spec has some problems with strokes interacting with itself
03:40:52 <nikos> heycam: I'd like to solve the problem of multiple strokes on the one element without using vector effects. Like using lists on the element
03:41:16 <nikos> Cyril: Vector effects elements seems to give a way of creating the paths that you can build up with Rik's proposal
03:41:31 <nikos> heycam: With the proposal, can you inspect the path data?
03:41:36 <nikos> cabanier: No, you can only draw it
03:42:19 <nikos> Cyril: To me, there are a lot of similarities between this proposal and vector effects and they should be aligned
03:43:02 <nikos> cabanier: The path just contains segments. It's quite dumb.
03:43:29 <nikos> ... shape contains the final result that you see on the screen. But you can still scale it and maintain quality
03:44:11 <nikos> cabanier: The internal representation is completely different to what you input, so you cannot get the data back out
03:44:57 <nikos> krit draws an example on the whiteboard that shows how 2 drawing operations result in a union of the two
03:45:11 <nikos> cabanier: And you can specify winding rules that affect the geometry that is created
03:46:00 <nikos> ... In the final example you draw two circles, then you union them, then you stroke it
03:46:38 <nikos> heycam: Can you put markers on it?
03:46:48 <nikos> cabanier: The markers would be on the resultant paths created
03:49:18 <nikos> krit: How would you perform the stroking when the path is required to stroke?
03:49:30 <nikos> cabanier: The path is available internally in some form, it's just not exposed in the script
03:51:25 <nikos> krit: If you can get an exact match (as output) for a straight line polygon, then you can specify what would result from curves
03:51:31 <nikos> heycam: I'm happy for the paths not to be exposed to script
03:51:44 <nikos> cabanier: Then you cannot use them in SVG
03:51:50 <nikos> ... as input
03:52:00 <nikos> krit: What outcome do we want from this discussion?
03:52:20 <nikos> cabanier: I just wanted to make you all aware of this. Dirk and I have been discussing it.
03:52:33 <nikos> ... It's more of a Canvas thing, but if people think it's reasonable we will implement it
03:53:10 <nikos> heycam: One way you could bring it into SVG is to set the path data as the output of the JavaScript
03:53:17 <nikos> ed: would that work with scaling ?
03:53:40 <nikos> cabanier: You would have to recalculate the path
03:54:25 <nikos> krit: it can be a specification issue if the browser is required to be pixel perfect
03:54:31 <nikos> ... you could specify that pixel accuracy isn't important
03:55:12 <nikos> Cyril: Would your proposal work with any path, e.g. Catmull-Rom?
03:55:13 <nikos> cabanier: yes
03:55:30 <nikos> heycam: I like the proposal
03:56:32 <nikos> Cyril: Would the paths created by this proposal be useful for CSS exclusions or anything like that?
03:56:41 <nikos> cabanier: JavaScript is required though
03:56:50 <nikos> Cyril: It would be nice if there was a declarative equivalent
03:57:16 <nikos> ... one of the advantages of having it as declarative in SVG would be that you could use it for CSS exclusions
03:58:02 <nikos> heycam: Is it worth thinking about a non declarative way of getting the data into SVG?
03:58:19 <nikos> ... If you could just set the JavaScript object on your path element
03:58:48 <nikos> ... You don't want to allow the path data to be output. You want a way to refer to constructed path
03:59:34 <nikos> Cyril: it's like what I was requesting before. A scalable representation without the full DOM.
04:00:13 <nikos> cabanier: It could be a new way of drawing. Where you draw into an object.
04:00:21 <nikos> heycam: When you do that, would it update the d attribute?
04:00:35 <nikos> ed: as long as the path operators are the same
04:00:49 <nikos> cabanier: There are some differences between the defaults in some cases (e.g. stroking)
04:01:56 <nikos> heycam: If this proposal gets added to the Canvas spec, then we can make any corresponding SVG changes
04:03:30 <nikos> krit: if you create a path object with a CTM in the Canvas context then the transformations will be applied to the internal path data
04:04:06 <nikos> Cyril: if this is accepted, we will have a mechanism for a path element in SVG which has no d element but the path data is set from a shape object.
04:04:13 <nikos> ... do we have a mechanism to go from a declarative path to a shape?
04:04:37 <nikos> cabanier: You can currently input an SVG path string but the stroking, etc are not applied
04:05:17 <nikos> Cyril: So I can create the shape objects, then delete all the other objects and just be left with the shape object with no DOM
04:05:39 <nikos> AlexD: Yes, you have JavaScript objects instead which are even bigger than the DOM representations
04:06:13 <nikos> cabanier: What we could add is to have an optimise method that returns another shape constructed as the intersection of the other objects.
04:07:06 <nikos> ... currently, when you call the add method, it doesn't do anything to the internal path data. It only adds a command to the internal representation
04:09:16 <Cyril_> Cyril_ has joined #svg
04:09:53 <nikos> heycam: Were you thinking that this path objects and it's improvements would remove the need for pathSegList?
04:10:02 <nikos> ... the path object currently doesn't have a way of inspecting individual segments?
04:10:03 <nikos> cabanier: no
04:10:09 <nikos> heycam: is that something you want to add?
04:10:19 <nikos> cabanier: I don't think there's a reason we couldn't
04:10:59 <nikos> Cyril: what if you serialised - you want to get the SVG
04:11:18 <nikos> cabanier: You can't serialise a Shape as you can't get the data out
04:12:03 <nikos> heycam: So we'll wait until this progresses further with the Canvas group?
04:12:11 <nikos> cabanier: Yes,
04:15:15 <nikos> action: Rik to look at how to attach a path or shape object to an SVG path element
04:15:15 <trackbot> Created ACTION-3424 - Look at how to attach a path or shape object to an SVG path element [on Rik Cabanier - due 2013-02-11].
04:33:44 <jun> jun has joined #svg
04:33:45 <Cyril_> Cyril_ has joined #svg
04:38:45 <Cyril> scribe: Cyril
04:38:58 <Cyril> Topic: SVG DOM path improvements
04:39:45 <Cyril> heycam: improving the SVGPathElement APIs
04:39:57 <Cyril> dirk: we resolved something in Zurich
04:40:12 <nikos> nikos has joined #svg
04:44:11 <heycam> http://www.w3.org/2012/09/17-svg-minutes.html#item09
04:44:44 <Cyril> heycam: we have resolutions but no actions
04:47:27 <Cyril> ... some of the resolutions are related to the previous discussion
04:48:22 <Cyril> ACTION: Rik to edit the SVG 2 spec to add the possibility to set the d attribute using a Path object
04:48:22 <trackbot> Created ACTION-3425 - Edit the SVG 2 spec to add the possibility to set the d attribute using a Path object [on Rik Cabanier - due 2013-02-11].
04:50:18 <Cyril> dirk: creating a new path automatically requires creating a move to because of underlying platform code in WebKit
04:50:49 <Cyril> heycam: the resolution from Zurich "add extendPath - which acts as addPath but trims off the initial moveto" is about that right?
04:50:52 <Cyril> dirk: yes
04:51:04 <Cyril> ... Qt creates multiple moveTo
04:51:22 <Cyril> ... sometimes, so you don't know if it's your moveTo or the one from the platform
04:51:47 <Cyril> ... usually it doesn't matter, only if you read back
04:52:09 <Cyril> heycam: can you penalize only the Qt port ?
04:52:15 <Cyril> dirk: maybe, I don't know
04:52:34 <Cyril> dirk: Core Graphics creates automatically a moveTo if the first is a lineTo
04:53:17 <Cyril> ... everything is solvable, but how ? maybe we need to add a layer
04:53:32 <Cyril> heycam: when you're flattening you don't care about the new moveTo
04:53:52 <Cyril> ... only when appending you want to preserve the original path
04:54:33 <Cyril> ACTION: Rik to add the extendPath and addPath methods to the SVG 2
04:54:33 <trackbot> Created ACTION-3426 - Add the extendPath and addPath methods to the SVG 2 [on Rik Cabanier - due 2013-02-11].
04:55:17 <Cyril> heycam: the methods are on the Path object
04:56:29 <Cyril> dirk: d would not be the attribute but the path of the Path object
04:56:39 <Cyril> ... how do you reflect that in the SVG DOM ?
04:57:17 <Cyril> heycam: some the segments in the Path may be different from the SVGPathSegList ones
04:58:54 <Cyril> ACTION: Rik to add new procedural methods for catmull-rom
04:58:54 <trackbot> Created ACTION-3427 - Add new procedural methods for catmull-rom [on Rik Cabanier - due 2013-02-11].
04:59:17 <Cyril> rik: I'd like someone to add the text for Catmull Rom for the XML part, and I'll refer to that
04:59:36 <nikos> nikos has joined #svg
04:59:43 <Cyril> heycam: yes Doug will do that
04:59:58 <Cyril> heycam: for the resolution "add canvas-like arc commands in svg path syntax", Tab is working on that
05:00:41 <Cyril> ACTION-3427: waiting on the action by Doug to do the edit in the SVG syntax
05:00:41 <trackbot> Notes added to ACTION-3427 Add new procedural methods for catmull-rom.
05:01:21 <Cyril> cyril: what about the stringifier
05:01:25 <Cyril> rik: I'll do that
05:01:46 <Cyril> ACTION: Rik to specify the stringifier method for the Path object
05:01:46 <trackbot> Created ACTION-3428 - Specify the stringifier method for the Path object [on Rik Cabanier - due 2013-02-11].
05:02:19 <Cyril> ACTION-3428: waiting for Tab on adding the new arcs command to the SVG path syntax
05:02:19 <trackbot> Notes added to ACTION-3428 Specify the stringifier method for the Path object.
05:03:16 <Cyril> heycam: the next thing is Brian's proposal for taking a list of numbers and making a path of that
05:03:39 <Cyril> brian: you've got an interface of Path for getting an array of floats, one array per subpath
05:04:02 <Cyril> ... but we were stuck with the close command
05:04:20 <Cyril> rik: because it does not look the same if you explicitly close it or not
05:04:41 <Cyril> brian: dealing with the array of floats is faster
05:04:48 <Cyril> ... than to traverse the segment list
05:04:56 <birtles> http://processingjs.nihongoresources.com/bezierinfo/
05:07:00 <Cyril> ... if no one else cares, we can just drop it
05:07:29 <Cyril> ... if we think it's worthwhile we need to find a way to handle the close command
05:08:03 <birtles> previous proposal: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Making_Improvements
05:08:15 <birtles> section "birtles 2012-03-26: ..."
05:08:49 <Cyril> heycam: it seems pretty simple to write
05:09:03 <Cyril> brian: yes, because it's using normalizedPathSegList
05:09:39 <Cyril> heycam: are we extending PathSegList or the new path object ?
05:10:06 <Cyril> ... maybe we should go on Path
05:10:34 <Cyril> rik: do you have an example ?
05:10:39 <Cyril> brian: no
05:12:25 <Cyril> dirk: we should find one solution to solve both problems: JSON and Array v
05:12:32 <Cyril> s/Array v/Array/
05:13:01 <Cyril> heycam: the JSON was meant to be able to express all segment types not normalized
05:14:03 <Cyril> dirk: the Array may be JSONified afterwards
05:14:34 <Cyril> brian: I can spec it and we can drop it if there is not much interest
05:15:36 <Cyril> ACTION: Brian to spec the setting/getting of an array of floats for path handling
05:15:37 <trackbot> Created ACTION-3429 - Spec the setting/getting of an array of floats for path handling [on Brian Birtles - due 2013-02-11].
05:17:27 <Cyril> Topic: prioritization of remaining requirements
05:17:40 <Cyril> Cyril: next one is "Make it simpler to construct regular polygons and stars"
05:17:56 <Cyril> dirk: Tav has an action on it, but we haven't seen yet a proposal
05:18:05 <Cyril> heycam: let him and Doug work on it and see
05:18:27 <Cyril> cyril: next "Make arcs in paths easier"
05:18:34 <Cyril> dirk: that's Tab's action
05:18:49 <Cyril> heycam: I had also the turtle command for rotation
05:19:04 <Cyril> ... to ease the creation of pie charts
05:19:31 <Cyril> dmitry: I don't know the final decision, but next Raphaël adds 3 commands for arcs (oval, arc, arc using 3 points)
05:20:19 <krit> http://raphaeljs.com/arc3.html
05:20:59 <Cyril> dmitry: I chose O and U
05:24:13 <Cyril> (dmitry drawing example on the board)
05:24:31 <Cyril> dmitry: the commands use the previous commands to get the missing parameters
05:25:03 <Cyril> ... like the center, or start and end angles
05:25:32 <Cyril> ... in most cases, the center will remain the same if you draw multiple arcs
05:26:02 <Cyril> ... the basic idea is that the center is derived from the previous command, it is not specified in the current command
05:27:29 <Cyril> ... I decided to use degrees, not radians
05:28:42 <Cyril> dirk: if the center does not change with an arc command but changes with another command, you have 2 store 2 last points
05:29:44 <Cyril> dirk: Canvas arcTo commands are more complex that Dmitry's
05:30:47 <Cyril> dmitry: there is also the arc3 with 3 points
05:30:58 <Cyril> dirk: it is a nice demo but I don't know how useful it is
05:31:12 <Cyril> alex: it is part of HPGL since 40 years
05:32:27 <Cyril> rik: most of the time you want to use the arc segment to be hooked to the previous path
05:32:42 <Cyril> dmitry: it has been heavily requested by the community
05:34:22 <Cyril> heycam: we have one method in SVG, 4 in Canvas, dmitry's ones, that makes 8 different arc commands
05:35:06 <Cyril> cyril: does this go in SVG 2 or in SVG.next ?
05:35:21 <Cyril> rik: Tab should take care of that
05:37:00 <Cyril> resolution: "Make arcs in paths easier" may go in SVG.next unless Tab's actions are done in time for SVG 2
05:37:15 <Cyril> cyril: next "Allow objects to be positioned along a path"
05:37:26 <Cyril> heycam: this is the thing Doug refers to ShapePath
05:37:57 <Cyril> alex: just define each shape as each glyph in a font and use textPath
05:38:07 <Cyril> dirk: SVG fonts are not supported in all browsers
05:38:33 <Cyril> heycam: markers could be used to
05:38:41 <Cyril> s/used to/used too/
05:39:08 <Cyril> alex: it is also using several animateMotion elements with offsets and not moving
05:39:36 <Cyril> resolution: "Allow objects to be positioned along a path" is already solved at least using 2 different ways so no action required
05:39:53 <Cyril> cyril: next "Require automatic text wrapping in arbitrary shapes compatible with CSS"
05:40:12 <Cyril> alex; isn't it implemented in Inkscape and CSS refused
05:40:29 <Cyril> shane: that's why it says compatible with CSS
05:41:04 <Cyril> resolution: Automatic text wrapping will go in SVG.next unless Tav comes with text
05:41:21 <Cyril> cyril: next "Support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties"
05:41:25 <Cyril> alex: don't we have that ?
05:41:38 <Cyril> heycam: using dominant baseline and so on
05:41:49 <Cyril> ... the part about baseline has to be rewritten to use CSS
05:42:26 <Cyril> ACTION: heycam to insure that the text chapter talks about baseline in terms of CSS features
05:42:26 <trackbot> Created ACTION-3430 - Insure that the text chapter talks about baseline in terms of CSS features [on Cameron McCormack - due 2013-02-11].
05:42:41 <Cyril> cyril: next "Clarify the stretch method for textpath"
05:43:07 <Cyril> http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html
05:43:41 <Cyril> heycam: I thought this was more about filling in some wholes about textPath
05:44:02 <Cyril> alex: Tav's stretch is already spec
05:44:05 <Cyril> ... Corel implemented
05:44:18 <Cyril> erick: this is not fully specified
05:44:33 <Cyril> alex: the last examples from Tav's page are not specified
05:45:20 <Cyril> alex: some fonts have copyright issues that don't let you have access to the point data so manipulations of glyphs is not easy
05:45:47 <Cyril> dirk: Canvas is supposed to expose the glyph to JavaScript
05:45:51 <Cyril> rik: but it's not implemented
05:46:04 <Cyril> alex: maybe because of the copyright issue, to avoid ripping fonts
05:46:44 <Cyril> dirk: users should not have access to the glyph data but the impleme
05:46:51 <Cyril> s/but the impleme//
05:47:37 <Cyril> alex: there are flags in the font package that say do not modify me
05:48:11 <Cyril> heycam: do we require the stretch method to have particular behavior
05:48:22 <Cyril> dirk: no, it is already specified in 1.1
05:48:40 <Cyril> heycam: do we add constraints on how the strectch is made
05:48:47 <Cyril> dirk: it could be a separate module
05:49:02 <Cyril> resolution: defer "Clarify the stretch method for textpath" to SVG.next
05:49:16 <Cyril> Cyril: next "Have a way to specify flip-invariant text"
05:49:44 <Cyril> alex: I would use SVG Tiny ref transform to stop the flipping
05:50:58 <Cyril> cyril: we have accepted transformed ref (point 90)
05:51:19 <Cyril> s/transformed ref/transform="ref"/
05:53:18 <Cyril> alex: I think we should add it to the use case list for constrained transforms
05:53:45 <Cyril> resolution: consider "Have a way to specify flip-invariant text" as part of the constrained transforms item
05:54:14 <Cyril> cyril: next "Deprecate the use of xml:space to affect layout and will use the CSS white-space property"
05:54:22 <Cyril> heycam: partially done, I'll do the rest soon
05:54:39 <Cyril> ... there was a discussion of mapping xml:space with whitespace using user style sheet
05:54:50 <Cyril> ... we do that under the hood in Firefox
05:55:26 <Cyril> ... but that creates problems when inheriting the whitespace property of between SVG and HTML
05:55:58 <Cyril> resolution:  "Deprecate the use of xml:space to affect layout and will use the CSS white-space property" is still part of SVG 2
05:56:09 <Cyril> cyril: next "Allow transforms on tspan"
05:56:25 <Cyril> dirk: it is already the case
05:56:33 <Cyril> ... due to the rewrite of the interfaces
05:56:41 <Cyril> heycam: it probably needs an example
05:56:53 <Cyril> resolution: "Allow transforms on tspan" is covered in SVG 2
05:57:05 <Cyril> cyril: next "Support Coons patches"
05:57:16 <Cyril> heycam: Mesh patches are already added by Tav
05:57:48 <Cyril> cyril: I still have an action to look at freeform gouraud meshes
05:57:53 <Cyril> ... but couldn't for this meeting
05:58:08 <Cyril> resolution: "Support Coons patches" is already in SVG 2, we keep it
05:58:22 <Cyril> cyril: "Have a video element in SVG namespace with the same characteristics as the HTML 5 video element"
05:58:33 <Cyril> alex: we have a discussion on this tomorrow
05:58:44 <Cyril> ... I've invited Silvia Pfeiffer to talk about that
05:59:22 <Cyril> cyril: next: "Have stronger requirements for when to display tooltips"
05:59:30 <Cyril> dirk: that was a discussion we had already
06:00:00 <Cyril> dirk: Doug needs to talk Rich
06:00:25 <Cyril> resolution: "Have stronger requirements for when to display tooltips" still goes in SVG 2, pending on Doug and Rich discussion
06:00:34 <Cyril> cyril: next "Support pointer events sensitive to alpha, subject to security constraints"
06:00:58 <Cyril> alex: the use case is for Farmville
06:01:15 <Cyril> ... having a PNG with alpha and do hit testing on the images
06:01:39 <Cyril> dirk: maybe the should use canvas and hit regions
06:03:35 <Cyril> resolution: defer "Support pointer events sensitive to alpha, subject to security constraints" to SVG.next
06:03:51 <Cyril> cyril: next "Support HTML document wide events (including hashchange) apply to SVG documents when they make sense"
06:03:58 <Cyril> heycam: we should still do that, I will do that
06:04:19 <Cyril> erik: that's already implemented in browsers, at least some part of it
06:04:52 <Cyril> heycam: I wouldn't be surprised if the document.addEventListener('hashchange' ... work
06:05:13 <Cyril> dirk: maybe we move these attributes
06:05:26 <Cyril> heycam: they may have moved already to Element
06:05:47 <Cyril> dirk: we can push other specifications to move some to Document or Element
06:06:32 <Cyril> heycam: we need to say SVGElement implement GlobalEventHandlers
06:06:41 <heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlelement
06:07:04 <Cyril> ... or we need to ask to move them to Element instead of HTMLElement
06:07:13 <Cyril> heycam: I'll do that as part of the action
06:07:35 <Cyril> resolution: "Support HTML document wide events" still in scope of SVG 2
06:08:01 <Cyril> cyril: next "(may) Support drag&drop functionality"
06:08:15 <Cyril> erik: I have an action on that but it depends on the eventhandler thing
06:08:34 <Cyril> ... we need only to add the attributes to SVG, the rest is specified in SVG
06:08:42 <Cyril> s/in SVG/in HTML/
06:08:49 <Cyril> ... I could start working on it
06:09:03 <Cyril> heycam: you could do that and leave out the event stuff
06:09:44 <Cyril> resolution: "(may) Support drag&drop functionality" is still in scope for SVG 2, it is a small change
06:10:18 <Cyril> cyril: next "Make it easier to detect if an mouse event is on the stroke or fill of an element"
06:10:25 <Cyril> heycam: done
06:10:34 <Cyril> cyril: next "Allow async/defer on the script element"
06:10:41 <Cyril> heycam: yes we should keep it
06:10:58 <Cyril> ... I remember Boris being worried about a document.write related thing
06:11:07 <Cyril> resolution: "Allow async/defer on the script element" is still in scope for SVG 2.
06:11:24 <Cyril> cyril: "Support for non-negative speed on time containers (if we decide to include time containers)"
06:11:45 <Cyril> brian: we do negative speed in Web animations, only on the root
06:12:01 <Cyril> resolution: "Support for non-negative speed on time containers" is part of Web animations
06:12:10 <Cyril> cyril: "Support path-based animations of pairs of attributes"
06:12:14 <Cyril> brian: I'm not sure about that
06:12:42 <Cyril> heycam: it came from applying x,y attributes from animateMotion and apply it to two elements
06:13:05 <Cyril> brian: the model of Web Animations should support that
06:13:44 <Cyril> brian: given solid use cases, we can add it to the next version of Web Animations
06:14:26 <Cyril> resolution: "Support path-based animations of pairs of attributes" will be added to future Web Animations, pending solid use cases
06:14:44 <Cyril> Cyril: next "Define all explicitly undefined parts of the SVG 1.1 spec (wrt to to-animations)"
06:14:54 <Cyril> brian: that will be covered in SVG integration to Web Animations
06:15:52 <Cyril> brian: to animations in SVG is weird
06:17:15 <Cyril> resolution: "Define all explicitly undefined parts of the SVG 1.1 spec (wrt to to-animations)" will be covered in SVG integration with Web Animations
06:17:28 <Cyril> cyril: "Define all explicitly undefined parts of the SVG 1.1 spec (wrt to to-animations)"
06:17:40 <Cyril> cyril: "Allow CSS-transitions-like animations"
06:17:50 <Cyril> brian: it's about snapshoting
06:19:02 <Cyril> resolution: "Allow CSS-transitions-like animations" is deferred to a further version of Web Animations, pending more details
06:19:12 <Cyril> cyril: "Allow linear interpolation for properties which were previously discrete"
06:19:18 <Cyril> brian: it's about text anchor
06:19:22 <Cyril> ... Chris should be doing it
06:19:36 <Cyril> ACTION-3209
06:19:36 <trackbot> ACTION-3209 -- Chris Lilley to write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly -- due 2012-01-20 -- OPEN
06:19:36 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3209
06:20:38 <Cyril> shane: in CSS this kind of thing doesn't really make senss
06:21:40 <Cyril> ... Tab proposed to snapshot the page in the first and final state and to interpolate everything
06:21:56 <Cyril> ... there is a good chance that CSS will go in this direction
06:22:18 <Cyril> resolution: "Allow linear interpolation for properties which were previously discrete" is deferred to SVG.next, unless Chris comes up with a proposal
06:22:32 <Cyril> cyril: next "Support animation using a transform-list"
06:22:39 <Cyril> brian: that is in CSS transforms
06:22:49 <Cyril> dirk: this is linked to the decomposition of transforms
06:23:10 <Cyril> brian: SVG integration with Web Animation will refer to this decomposition
06:23:34 <Cyril> resolution: "Support animation using a transform-list" is in scope of Web Animations
06:23:45 <Cyril> cyril: next "Support motion animation of a specified speed"
06:24:00 <Cyril> brian: defered in web animations
06:24:12 <Cyril> ... we think we can address that with the model, but not in the first version
06:24:27 <Cyril> resolution: "Support motion animation of a specified speed" is deferred to a future version of Web Animations
06:24:39 <Cyril> RRSAgent, make minutes
06:24:39 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html Cyril
06:25:49 <Cyril> s/resolution:/RESOLUTION:/g
06:25:53 <Cyril> RRSAgent, make minutes
06:25:53 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html Cyril
06:28:01 <Cyril> chair: Mighty Cameron
06:30:16 <Cyril> RRSAgent, make minutes
06:30:16 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html Cyril
07:06:51 <shanestephens_> shanestephens_ has joined #svg
07:09:35 <shanestephens_> shanestephens_ has joined #svg
10:53:02 <birtles> birtles has joined #svg
10:56:18 <birtles_> birtles_ has joined #svg
11:02:18 <birtles_> birtles_ has joined #svg
11:06:28 <birtles_> birtles_ has joined #svg
11:07:49 <krit> krit has joined #svg
11:12:24 <birtles_> birtles_ has joined #svg
11:18:19 <birtles_> birtles_ has joined #svg
11:22:21 <birtles_> birtles_ has joined #svg
11:26:21 <birtles_> birtles_ has joined #svg
11:32:26 <birtles_> birtles_ has joined #svg
11:36:20 <birtles_> birtles_ has joined #svg
11:40:19 <birtles_> birtles_ has joined #svg
12:02:18 <jun> jun has joined #svg
12:12:33 <Tav> Tav has joined #svg
22:12:23 <RRSAgent> RRSAgent has joined #svg
22:12:23 <RRSAgent> logging to http://www.w3.org/2013/02/04-svg-irc
22:12:25 <trackbot> RRSAgent, make logs public
22:12:25 <Zakim> Zakim has joined #svg
22:12:27 <trackbot> Zakim, this will be GA_SVGWG
22:12:27 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
22:12:28 <trackbot> Meeting: SVG Working Group Teleconference
22:12:28 <trackbot> Date: 04 February 2013
22:12:35 <heycam> RRSAgent, this meeting spans midnight
22:12:48 <heycam> Meeting: SVG WG F2F Sydney 2013 Day 2
22:12:58 <ed> chair: erik
22:13:05 <heycam> ScribeNick: heycam
22:14:13 <heycam> Topic: Relation between enable-background and isolation property
22:14:54 <krit> krit has joined #svg
22:15:07 <heycam> krit: we have the enable-background property and the isolation property
22:15:21 <heycam> … two properties with different name but with the same context, they're supposed to do the same thing
22:15:53 <heycam> cabanier: except that isolation has different default values: auto | isolate, enable-background default value is always accumulate
22:16:04 <cabanier> spec for isolation: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#isolation
22:16:50 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#EnableBackgroundProperty
22:17:20 <heycam> krit: the idea is that you can get the background of an element that you want to filter
22:17:24 <heycam> … and have filter operations based on the background
22:17:28 <heycam> … this is useful in blending and compositing
22:17:32 <heycam> … with feBlend and feComposite
22:17:49 <heycam> … the problem is that the relation between enable-background in the past is the same as isolation; that's why we wanted a shorthand
22:18:13 <heycam> … enable-background preserves the background up to the previous enable-background:new regardless of what graphics are in between
22:18:22 <heycam> … this is the default behaviour
22:18:38 <heycam> … similar to z-index, making a new stacking context
22:18:49 <heycam> … isolation in the past did the same thing but with different keywords
22:18:53 <heycam> … the default behaviour now has changed, though
22:19:06 <heycam> cabanier: but you can say enable-background works on filters but isolation works on graphics
22:19:15 <heycam> krit: you could but we shouldn't
22:20:14 <heycam> krit: do we still want to preserve both properties with different behaviours?
22:20:26 <heycam> krit: does it make sense to have two different stackings, one for filters and one for compositing?
22:20:32 <heycam> nikos: they are for different purposes
22:20:45 <heycam> … the reason behind enable-background was an optimisation, if you don't have "new" anywhere then background image isn't available
22:20:58 <heycam> … by setting it to new, you're making a certain region of the document available in the background
22:21:05 <heycam> krit: that's just like in compositing
22:21:22 <heycam> nikos: but they're for different reasons -- for enable-background it's an optimisation, for compositing it's for the effect you want
22:21:46 <heycam> krit: from the implementation pov, there's some cost to implement both
22:21:54 <heycam> … sometimes it's even not possible
22:22:06 <heycam> … if you have overlapping background regions from both properties
22:22:14 <heycam> cabanier: has anyone implemented enable-background for html?
22:22:16 <heycam> krit: no
22:22:58 <heycam> cabanier: we could say that isolation:auto defaults to providing background in svg elements and not in html elements
22:23:44 <heycam> nikos: I think they should be kept separate, but when you apply a filter to a group the group is isolated
22:23:52 <heycam> alex: you have to do it that way anyway
22:23:56 <heycam> nikos: that's what illustrator does
22:23:58 <heycam> cabanier: sometimes...
22:24:14 <heycam> heycam: what is the proposed change?
22:24:24 <heycam> cabanier: we can make enable-background "auto" ...
22:24:31 <heycam> krit: but it would still mean that you'd have two different stacks
22:24:55 <heycam> cabanier: we can just make enable-background and isolation mean the same thing
22:25:35 <heycam> krit: the main thing is that the situation has changed last year… the behaviour of Compositing has changed
22:26:08 <heycam> nikos: they can't influence each other; if you apply a filter to a group makes it isolated
22:26:27 <heycam> krit: if you have enable-background:accumulate isolation:isolate what happens?
22:26:30 <heycam> nikos: [draws]
22:33:44 <heycam> krit: we should have shared text between Filters and Compositing saying you isolate up until the ...
22:34:12 <heycam> Cyril: you can say isolate has two purposes; one is for compositing and one is that it affects filters as if it were enable-background:new
22:34:40 <heycam> Cyril: would need to define what happens if you put isolation:isolate;enable-background:accumulate on an element
22:35:21 <heycam> nikos: if you have enable-background:accumulate;isolation:isolate that's not going to make a difference
22:35:38 <heycam> Cyril: cabanier says isolation takes precedence
22:36:13 <heycam> Cyril: what "auto" in isolation? is that different from "isolate"?
22:36:24 <heycam> cabanier: it's mostly not isolated, unless you have opacity or something that creates a stacking context
22:36:53 <heycam> ed: where should this go?
22:37:02 <heycam> krit: I'd like to share the wording, and reference Compositing from Filters
22:38:13 <heycam> cabanier: if you really wanted enable-background to only to apply to filters and not influence compositing, you couldn't
22:43:21 <Cyril_> Cyril_ has joined #svg
22:43:42 <heycam> krit: Compositing needs to say what stacking is
22:44:13 <heycam> s/Compositing/SVG/
22:44:31 <heycam> ed: jwatt wrote up a z-index proposal, what stacking contexts means -- that might be enough
22:46:15 <heycam> krit: then define how Filters and Compositing/Blending interact with stacking contexts in SVG
22:46:24 <heycam> Cyril: will there be any difference between SVG and HTML?
22:46:25 <heycam> krit: no
22:46:59 <shanestephens_> shanestephens_ has joined #svg
22:47:24 <heycam> cabanier: you might want to blend something with opacity with the background in SVG… which isn't possible in HTML/CSS
22:47:51 <ed> http://lists.w3.org/Archives/Public/www-svg/2009Oct/0042.html (jwatt's z-index proposal)
22:47:54 <heycam> krit: why doesn't isolation have a new value to mean never isolated?
22:49:17 <heycam> Cyril: when you use CSS Transforms on SVG elements it makes a stacking context, but if you use the attribute it doesn't?
22:49:21 <heycam> heycam: that seems bad
22:49:30 <heycam> krit: that's not how it's implemented
22:52:20 <heycam> krit: if you have a transform you should isolate this?
22:52:26 <heycam> alex: this doesn't make sense in HTML
22:58:46 <heycam> krit: I think transforms shouldn't affect blending/compositing in SVG
22:59:59 <heycam> krit: we first need to know if Compositing and background are affected by stacking contexts
23:00:11 <heycam> ed: we could use a new term and maybe make it equivalent to stacking contexts later
23:00:17 <heycam> nikos: "isolated group"
23:00:38 <heycam> cabanier: I think doing that for CSS will be a nightmare
23:00:52 <heycam> krit: transforms being affected by stacking contexts is stupid
23:00:58 <heycam> cabanier: maybe CSS Transforms should be updated?
23:03:00 <heycam> ACTION: krit to ask CSS/FX how blending is supposed to work with transforms
23:03:00 <trackbot> Error finding 'krit'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
23:03:14 <heycam> ACTION: Dirk to ask CSS/FX how blending is supposed to work with transforms, opacity, all properties that create stacking contexts
23:03:14 <trackbot> Created ACTION-3431 - Ask CSS/FX how blending is supposed to work with transforms, opacity, all properties that create stacking contexts [on Dirk Schulze - due 2013-02-11].
23:04:16 <heycam> Topic: iframe proposal
23:04:24 <heycam> stakagi: we have a document
23:04:25 <krit> krit has joined #svg
23:04:39 <stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax
23:05:22 <heycam> birtles: let me summarise
23:05:33 <heycam> … in the Abstract there are three main parts
23:05:45 <heycam> … one is the iframe element; takagi-san has written out spec text to allow iframe in SVG
23:05:54 <heycam> … it's similar to HTML's iframe element
23:06:12 <heycam> … one addition is the second point, the levels-of-detail, and it uses a media query to determine when to show the iframe's contents
23:06:22 <heycam> … it's an attribute on the iframe itself
23:06:37 <heycam> … the third part is the global coordinate system, and there's some discussion about what that is useful for in the issues section
23:06:55 <heycam> Cyril: except for the coordinate system, it looks similar to the <picture> element or srcset
23:07:06 <heycam> … the responsive images, where they want to load one resource or another based on media queries
23:07:21 <heycam> birtles: wrt the media attribute?
23:07:30 <heycam> Cyril: what's the difference between <img> and <iframe> in this case?
23:07:59 <heycam> heycam: it's meant to be just like an HTML <iframe> here
23:08:19 <heycam> krit: I thought some WebKit engineers were unhappy with <iframe>
23:08:25 <heycam> … and maybe they would not like it in SVG
23:08:44 <heycam> birtles: I've heard the opposite feedback, that <iframe> is the way forward, and people shouldn't use <object> and <embed>
23:08:53 <heycam> … for example we have seamless and sandbox on iframe now
23:08:59 <heycam> krit: for security concerns
23:09:05 <heycam> birtles: yes to make it better
23:09:12 <heycam> … so this proposal would allow those attributes on <iframe> in SVG too
23:09:24 <heycam> nikos: this doesn't talk about the difference between seamless or not
23:09:33 <heycam> birtles: it's not in this document, but we have discussed it
23:09:40 <heycam> … I'm not sure how much we need to say
23:09:49 <heycam> … the behaviour would be the same as in HTML, in how you inherit styles
23:09:51 <heycam> … that's all common
23:09:56 <heycam> … one area of difference is do you have a border
23:10:01 <heycam> … that does need to be defined
23:10:08 <heycam> Cyril: what's the difference between <iframe> and <img>?
23:10:16 <heycam> ed: iframe has interactive, img is static
23:10:56 <heycam> birtles: there used to be a difference where <image> in SVG was static as in not animated, but that's changed to allow animation now
23:11:08 <heycam> alex: so iframe is like the old <animation> element
23:11:19 <dino> dino has joined #svg
23:11:56 <heycam> ed: this is basically how we implemented Tiny's <animation> element -- as an <iframe>
23:12:48 <heycam> ed: the first thing then is do we want to have an iframe element and in SVG 2?
23:13:25 <heycam> heycam: we should write down somewhere how foreignObject requires HTML to be rendered etc.
23:14:15 <heycam> krit: so this proposal has an addition?
23:14:22 <heycam> birtles: yes that's the next part of it
23:14:29 <heycam> krit: does it make sense to allow that on original <iframe>?
23:14:39 <heycam> birtles: first question is whether we should allow <iframe> directly in SVG
23:14:49 <heycam> … second is whether to have media="" just on SVG's <iframe> or on HTML's too
23:15:21 <heycam> Cyril: I think the <animation> element had good points, but maybe too many in the same element, e.g. control of timeline
23:15:27 <heycam> … and the linking to SVG content
23:15:31 <heycam> … maybe it's a good idea to split these
23:15:39 <heycam> birtles: this isn't about controlling the timeline
23:15:46 <heycam> Cyril: that's why I'm saying it's a good idea to split these two
23:16:01 <heycam> Cyril: we should have a common solution across responsive images
23:16:15 <heycam> krit: should we use <iframe> in SVG directly instead of inventing it again?
23:16:27 <heycam> birtles: yes it would be kind of like a shortcut in SVG without <foreignObject>
23:16:48 <heycam> … it would be in the SVG namespace, just for convencience
23:16:59 <heycam> … it's not reinventing iframe, but importing it and smoothing over the gaps
23:17:11 <heycam> Cyril: now in respimg they are talking about srcset in <img> or a new <picture> element
23:17:15 <heycam> … which are both only for static things
23:17:30 <heycam> … if you have a map that's interactive you couldn't use <picture>
23:17:37 <stakagi> First of all for with responsive images compatibility, I introduced media attribute.
23:18:15 <heycam> heycam: maybe srcset or whatever could apply to <iframe>
23:18:32 <heycam> birtles: srcset is more about selecting from alternatives, here <iframe media> is about when to turn the element on or off
23:19:11 <stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#5.11.1_Additional_Media_features
23:19:21 <heycam> heycam: could you use scoped style sheets instead media=""?
23:19:33 <nikos> nikos has joined #svg
23:19:35 <heycam> birtles: media queries will fetch all of the matched things, but in this case we don't want to load everything at once
23:19:48 <heycam> Cyril: same thing for respimg
23:20:20 <stakagi> Especially, i think  'close-viewport' is unique feature
23:21:51 <heycam> birtles: within that media="" attribute, there's a proposal for some additional media queries
23:21:55 <heycam> … there are two
23:22:01 <heycam> … zoom and close-viewport
23:22:22 <heycam> … they're additional tests to define when the resources are loaded; one is the zoom factor, and the other is how close the tile is to the viewport
23:22:35 <heycam> Cyril: close as in nearby
23:22:47 <heycam> birtles: you give a radius around the tile, once the viewport overlaps with this region load this resource
23:22:55 <heycam> nikos: why would you let the author set that?
23:23:02 <heycam> birtles: one view is to let the UA choose that to optimise
23:23:32 <heycam> alex: if you pan the map you'll want to prefetch the tiles you're about to see
23:23:49 <heycam> birtles: even if we were to use srcset, these additional media queries could still be useful in that context
23:24:01 <heycam> Cyril: this is touching a lot of areas, CSS, HTML...
23:24:20 <heycam> … I am not sure how we can proceed in the SVG WG, coordinate with the other groups?
23:24:24 <heycam> birtles: there are different routes
23:24:33 <heycam> … pointer-events was something that was in SVG initially and then later was adopted more widely
23:24:39 <heycam> … we could say this media="" stuff only applies in SVG
23:24:44 <heycam> … and I think it has more relevance in SVG
23:25:08 <heycam> Cyril: we shouldn't give the impression that we're modifying <iframe> unilaterally
23:25:44 <heycam> birtles: the thing to decide today is do we want to pursue a native <iframe> in SVG, and what direction would we like to do with media=""
23:26:14 <heycam> krit: this is somehow in conflict with the discussion of how to allow all HTML elements directly in SVG
23:26:47 <ed> -- 15 min break --
23:49:46 <shanestephens_> shanestephens_ has joined #svg
23:51:18 <krit> krit has joined #svg
23:52:46 <jun> jun has joined #svg
23:54:37 <AlexD> AlexD has joined #svg
23:55:05 <krit> scribeNick: krit
23:55:12 <krit> topic: HTML in SVG
23:55:45 <heycam> ScribeNick: heycam
23:55:56 <heycam> krit: the problem is that HTML uses the CSS box model
23:56:10 <heycam> … all HTML elements have this CSS layout
23:56:36 <heycam> … one problem is that SVG has coordinate based drawing, CSS/HTML has layout based
23:56:54 <heycam> … I suggested on whatwg to use something other than <foreignObject>
23:57:19 <heycam> … we could create a shortcut for this, it just takes a width/height and position and everything inside is HTML
23:57:22 <heycam> … inside that you have the CSS box model
23:57:25 <heycam> … that would be one way to do it
23:57:40 <heycam> Cyril: I taught SVG this winter to a group of students, they were mixing SVG/HTML with foreignObject, body, etc.
23:57:45 <heycam> … they knew how to do it easily
23:57:53 <heycam> krit: it's a lot of code that you waste
23:58:09 <heycam> … you have to specify <foreignObject>, html namespace, body
23:59:28 <heycam> heycam: I thought we wanted to try to avoid having a wrapper element
00:00:36 <heycam> Cyril: are you switching parser in the middle? if you have XML on the outside and you get to this new element, would you switch to HTML parsing?
00:00:37 <heycam> heycam: no
00:00:44 <heycam> … that couldn't work
00:01:05 <heycam> cabanier: in HTML don't you switch to SVG parsing when you get <svg>?
00:01:11 <heycam> heycam: it's switching mode within the HTML parser, not switching parser
00:01:39 <heycam> Cyril: when you have a <foreignObject> with HTML inside, does it have to be XML-compliant HTML?
00:01:42 <nikos> nikos has joined #svg
00:02:12 <heycam> heycam: yes
00:02:53 <heycam> Cyril: can you have a <video> self closed tag?
00:02:55 <heycam> heycam: in XML? yes
00:03:23 <heycam> cabanier: if you have an HTML file with inline SVG, and inside that you have <foreignObject> how is that parsed?
00:03:39 <heycam> heycam: that's still HTML
00:04:20 <heycam> Cyril: <foreignObject> needs an HTML namespace?
00:04:26 <heycam> heycam: on the children of <foreignObject>, say the <body>
00:04:44 <heycam> Cyril: you just want to replace <foreignObject> with <html>?
00:04:49 <heycam> krit: in addition, not replace
00:06:30 <heycam> heycam: I don't think you can make HTML elements inside <svg:html> automatically get parsed into the HTML namespace if we're being parsed as XML
00:07:11 <heycam> ed: that wouldn't allow us to have <iframe> directly as a child of other SVG elements
00:07:21 <heycam> … <iframe> is a bit special in that it defines a rectangular region, just like <foreignObject>
00:07:39 <heycam> krit: you cannot just put an HTML element in SVG context
00:09:43 <konno> konno has joined #svg
00:10:23 <heycam> heycam: we could make it so that the namespace URI, whether it is SVG or HTML, doesn't matter
00:10:51 <heycam> … thus you could have <g><div></div></g>, and <div> would be in the SVG namespace, but that wouldn't matter -- it would behave the same as an HTML namespaced <div>
00:16:15 <heycam> heycam: Tab also suggested at one point having no namespace, so <svg> as the root, no xmlns
00:16:24 <heycam> … and then all the SVG- and HTML-named elements could be in no namespace
00:16:33 <heycam> … but you would still get SVGCircleElement, HTMLDivElement objects created for them
00:20:16 <heycam> heycam: one problem with <iframe> as a direct child of <g> is how to specify the position of the iframe
00:22:01 <nikos> nikos has joined #svg
00:22:51 <heycam> … you could use style="top: …; left: …" or style="transform: translate(…)"
00:23:26 <heycam> … SVG has a bunch of global attributes like transform="", presentation attributes, etc.
00:23:38 <heycam> … should these be allowed on the <iframe>-as-a-child-of-<g>?
00:24:40 <heycam> … I feel like we should have <iframe> functionality in SVG
00:24:45 <heycam> … without having to have intervening HTML
00:25:21 <heycam> birtles: <iframe> has some features which would be useful in SVG as well, like seamless for applying styles across nested browser contexts
00:25:21 <heycam> … and sandbox as well
00:28:31 <heycam> heycam: I am a bit worried about these extra attributes on SVG's <iframe>
00:28:36 <heycam> … if later we want to unify it and HTML's
00:30:46 <heycam> … if we allow x="" and y="" and transform="" and display="" on our <iframe>, and later we have a plan to allow all HTML elements as direct children of SVG elements, it would be bad if they stopped working if the element was in the HTML namespace
00:30:52 <heycam> … I'd like much the same behaviour across both namespaces
00:31:05 <heycam> … (x and y might be ok to have not work in HTML namespace, since you want to rely on CSS for layout)
00:33:02 <heycam> Cyril: what about for HTML <video>?
00:33:08 <heycam> birtles: that raises the same issues
00:35:12 <heycam> birtles: with x and y, I wonder if you could define those to only make sense/apply in SVG contexdt
00:35:19 <heycam> … and reuse that for both iframe and video
00:35:41 <heycam> … x and y would mean "the SVG offset", and by definition wouldn't work in HTML
00:36:06 <heycam> … the next step, when we try to expand integration further, we could decide if we wanted those on <div> and <p>, but that's a separate question
00:41:53 <heycam> [some talk about the difference between width/height properties and attributes on canvas/video/img]
00:42:48 <jun> jun has joined #svg
00:42:51 <heycam> ed: to me it seems all of these HTML elements that have width/height, it's a separate problem from all the other HTML elements like p/div
00:43:00 <heycam> … I think those that have width/height already would be easier to take in as they are, more or less
00:43:08 <heycam> … the qn is whether to do that first, or consider the whole set of elements
00:46:16 <Zakim> Zakim has left #svg
00:48:45 <Zakim> Zakim has joined #svg
01:02:55 <heycam> [discussion of which spec iframe would go in to, SVG 2 or another; takagi-san prefers SVG 2, but whatever is quicker]
01:04:46 <heycam> ed: I think it makes sense to do all of video, canvas, iframe at once
01:04:53 <heycam> … I wouldn't mind it being in SVG 2
01:05:37 <heycam> heycam: what to do with all the presentation/global attributes that would otherwise be on SVG elements?
01:05:43 <heycam> ed: just allow x/y to begin with?
01:05:48 <heycam> heycam: I think that is safest
01:14:17 <heycam> RESOLUTION: SVG 2 will have iframe, canvas, video in the SVG namespace and with the same behaviour as HTML's, but allowing global SVG attributes on them
01:16:29 <heycam> RESOLUTION: iframe, canvas, video will also have x="" and y="" attributes in SVG, which eventually will be presentation attributes for the new 'x' and 'y' properties
01:17:23 <heycam> ACTION: stakagi to edit SVG 2 to add the iframe, canvas, video elements
01:17:23 <trackbot> Created ACTION-3432 - Edit SVG 2 to add the iframe, canvas, video elements [on Satoru Takagi - due 2013-02-12].
01:18:10 <heycam> birtles: the next thing is the media="" attribute
01:19:59 <heycam> heycam: I think the specs should say whether media="" means fetch up front or only once it starts matching
01:20:20 <heycam> … I'd like it not to be different from media="" on style, link, but I can see that preventing resource fetching is important for tiles/maps
01:21:01 <heycam> birtles: in the proposal media="" acts like a conditional processing attribute
01:21:11 <heycam> … so it should prevent processing of elements altogether
01:21:15 <heycam> … maybe it needs a different name
01:29:59 <heycam> … the reason for choosing media="" was to match the <picture> element
01:33:38 <ed> -- lunchbreak --
01:59:15 <ys-uchida> ys-uchida has joined #svg
02:18:16 <shanestephens_> shanestephens_ has joined #svg
02:33:41 <stakagi> stakagi has joined #svg
02:42:40 <cabanier> cabanier has joined #svg
02:53:22 <krit> ScribeNick: krit
02:53:31 <krit> topic: HTML5 video element in SVG
02:53:55 <silvia> silvia has joined #svg
02:53:59 <jun> jun has joined #svg
02:54:06 <Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2Multimedia
02:54:15 <krit> Cyril: Questions related to this topic.
02:54:38 <krit> Cyril: We decided to use HTML5 video element instead of tiny video. I implemented it and have quesions
02:54:55 <krit> Cyril: what about bollean attributes without values?
02:55:11 <krit> Cyril: What about self closing tags
02:55:31 <krit> krit: they shoulld be closeable
02:55:57 <krit> heycam: yes, the parser should ignore that and not closing tags should be able to have closing tags
02:55:59 <krit> Cyril: ok
02:56:07 <krit> Cyril: checked with tiny waht we miss
02:56:12 <krit> Cyril: tiny has a timeline
02:56:27 <krit> Cyril: they are in webanimations, but will they be in media elements?
02:56:44 <krit> birtles: we discuss it next week and have ideas
02:56:56 <krit> silvia: i like the idea of timelines
02:57:05 <krit> Cyril: timeline is on doc for tiny
02:57:14 <krit> Cyril: pause on element you don't care
02:57:31 <krit> Cyril: how do we have this feature in SVG?
02:57:40 <krit> birtles: talk about it that next week
02:57:57 <krit> birtles: we didn't get put the mechnaics now
02:58:12 <krit> Cyril: you need to be careful of timelines between groups
02:58:26 <krit> shanestephens_: we should take care of it
02:58:36 <krit> shanestephens_: if we don't, the media controler should provide it
02:58:43 <krit> shanestephens_:but we want to make it work
02:59:08 <krit> Cyril: do you wat to control the doc timeline (start timeline on load)
02:59:18 <krit> birtles: yes, we define what 0 line is on a documen
02:59:20 <krit> t
02:59:40 <krit> silvia: you could have the media group under the timeline
02:59:50 <krit> silvia: every media element has a videocontroler
03:00:13 <krit> silvia: media controlers are objects that can be shared?
03:00:36 <krit> s/shared\?/shared(\?)/
03:01:00 <krit> Cyril: animation element whcih has 2 features
03:01:13 <krit> Cyril: link to animation, control the timeline, how in webanimations
03:01:14 <krit> ?
03:01:25 <krit> birtles: webanimations has timing groups
03:01:32 <krit> birtles: <par> and <seq>
03:01:54 <krit> birtles: animations can poiint to a external document
03:02:03 <krit> s/birtles/Cyril/
03:02:26 <krit> birtles: I would modify media controler to have a timeline. Seems better
03:02:32 <krit> s/birtles/shanestephens_/
03:02:55 <krit> Cyril: image with ref to image… no timeline. video would have with resource restrictions
03:03:41 <krit> Cyril: video should point to svg content to control timeline on this svg content
03:03:48 <krit> Cyril: image does not have any control
03:03:56 <krit> Cyril: no MediaElements interface
03:04:09 <krit> Cyril: I would not expect a video to run script
03:04:21 <krit> Cyril: cartoons are one example
03:04:30 <krit> Cyril: come back to streaming later
03:04:47 <krit> silvia: should be in HTML first
03:04:50 <krit> birtles: right
03:05:08 <krit> Cyril: yes, commen problem: spec features between html and svg
03:05:21 <krit> Cyril: how can i run and stop video declaritly
03:05:32 <krit> Cyril: in html you need scripts and events
03:05:42 <krit> birtles: ah, needs to be expressed in webanimations
03:06:04 <krit> Cyril: svg document and html document differ and both do not have timeline
03:06:18 <krit> birtles: all documents have a timelien
03:06:27 <krit> shanestephens_: embedding does not worry me
03:06:52 <krit> shanestephens_: when you use css svg then this will introduce a timline given by WebAnimation
03:07:06 <krit> shanestephens_: html will have a timeline
03:07:15 <krit> birtles: so you want 10s after document load?
03:07:18 <krit> Cyril: yes
03:07:26 <krit> birtles: you can do that with svg animation already
03:07:38 <krit> birtles: but you can not do with nesting animation yet
03:07:46 <krit> birtles: we need to think about a declaritive way
03:08:09 <krit> birtles: might be different to pass it through WG.
03:08:14 <krit> shanestephens_: don't think so
03:08:39 <krit> Cyril: css animtions trigger when style attached. This was not possible to synchronize
03:08:44 <krit> Cyril: how to fixx that
03:08:59 <krit> birtles: intentionally it will be fixed magically
03:09:07 <krit> birtles: e.g. time groups are one way
03:09:21 <krit> birtles: no absolute time in CSS yet, but could be added
03:09:30 <krit> birtles: helps synchronizing
03:09:39 <krit> birtles: more work on CSS side needed
03:10:03 <krit> shanestephens_: there is more that we need to discuss with the CSS WG
03:10:50 <krit> shanestephens_: we should work on appro. to sync CSS to the CSS WG
03:11:01 <krit> Cyril: in tiny we had transformable attribute
03:11:43 <krit> Cyril: transforms like scale could be defined that it just had an affect on the position
03:12:23 <krit> krit: so CTM gets transformed but just affects the position?
03:12:26 <krit> Cyril: basically
03:13:12 <krit> Cyril: do same restrictions apply? do we still need that?
03:13:21 <krit> Cyril: if so, it should be in CSS Trnasforms?
03:13:24 <krit> AlexD: maybe
03:13:38 <krit> shanestephens_: we should come up with a unified model for transforms
03:13:53 <krit> heycam: like trnasform-behavior: normal and position?
03:14:04 <krit> Cyril: yes, where you transform CTM, or just a point
03:14:39 <krit> Cyril: where is transform on text?
03:14:57 <krit> Cyril: not in CSS transforms,
03:14:58 <krit> ?
03:15:04 <krit> AlexD: no, we do that
03:15:12 <krit> Cyril: synchMaster and tolerance
03:15:19 <krit> Cyril: nother point in SVG tiny
03:15:25 <krit> Cyril: what if one point is lacking
03:15:57 <krit> Cyril: then you can define if you do not care if audio and video are in synch or not. It was possible to allow a tolerance
03:16:18 <krit> shanestephens_: mediaControler does it, but no master
03:16:56 <krit> birtles: webanimation it is sometimes hard to do simple things
03:17:24 <krit> shanestephens_: spec of tiny is very hard to understand and read
03:17:30 <krit> Cyril: but the model is simple
03:18:14 <krit> shanestephens_: is the spec not easy enought ridden or the spec not good enough?
03:18:18 <krit> AlexD: former
03:18:43 <birtles> (we decided in web animations not to address sync tolerance initially, but just to have strict synchronisation)
03:18:55 <krit> birtles: we won't allow tolerance in the first version
03:20:06 <krit> Cyril: RTP is not used much, so it might not a valid use case, but people use multiplex streams, they won't like
03:20:32 <krit> Cyril: but hybrid cases, different streams from different media, sounds interesting
03:20:56 <krit> shanestephens_: yes, there are things that ususally separate video and audio stream for example
03:21:11 <krit> silvia: in html it is regarded as quality of browser
03:21:32 <krit> silvia: html allows implementation to decide about the tolerance level
03:22:03 <krit> silvia: if i am web dev, and have 4 medias. Then I want them come in enought speed, so that they can displayed together
03:22:25 <krit> silvia: let browser decide how to get quality for streamed media
03:22:38 <krit> Cyril: yeah, but sometimes it depends on one master
03:22:43 <krit> Cyril: but ok for now
03:23:12 <krit> Cyril: what baout visibility? start from 10s of video, should it display one fray for this 10s?
03:23:16 <krit> heycam: Can you do that?
03:23:21 <krit> silvia: it always does that
03:23:23 <Zakim> Zakim has left #svg
03:23:46 <krit> silvia: either give it a poster, or it will give the first frame. not described in html, but the way it works
03:23:58 <Zakim> Zakim has joined #svg
03:24:04 <krit> Cyril: basic interface of media seems to be the same
03:24:15 <heycam> Zakim, remind me in 4 hours that we should have already gone to dinner
03:24:15 <Zakim> ok, heycam
03:24:20 <krit> Cyril: did not lost anything to tiny
03:24:50 <krit> birtles: media attribute on iframe
03:24:58 <krit> topic: media attribute on iframe
03:25:13 <stakagi> stakagi has joined #svg
03:25:22 <krit> silvia: is this about media queries?
03:25:25 <krit> all: yes
03:25:51 <krit> Cyril: iframe is one way to get HTML things into SVG
03:26:09 <krit> (see minutes of morening)
03:26:26 <Cyril> s/morening/morning/
03:26:27 <krit> birtles: usecase: map and you want control when resources are loaded and displayed
03:26:57 <krit> birtles: media attribute defines (with media queries), when this will happen
03:27:56 <krit> birtles: media for attribute with two different behvaiors (we meean dont load, don't show) but we want don't show but load if you like
03:28:04 <krit> birtles: maybe we rename it to sth. else
03:28:11 <stakagi> The srcset attribute : An HTML extension for adaptive images : http://drafts.htmlwg.org/srcset/w3c-srcset/
03:28:20 <stakagi> The picture element : An HTML extension for adaptive images : http://picture.responsiveimages.org/
03:28:38 <krit> silvia: there is also reload audio/video and so on
03:28:42 <krit> silvia: this is related
03:28:58 <krit> silvia: means load if you can
03:30:44 <krit> birtles: media on iframe don't show this resorese and preload can allow to allow or disallow pre loading
03:31:08 <krit> heycam: would it be fine to turn of poss of iframe to laod and show of iframe?
03:31:26 <krit> heycam: or think of media attribute as controlling multiple things (?)
03:33:22 <krit> Cyril: would our iframe prop. interesting as usecase for <picture> and srccset discussion?
03:33:26 <krit> silvia: no, differetn
03:33:37 <krit> silvia: media queries specify range of conditions
03:33:51 <krit> silvia: in this size use this, this for another screen size?
03:33:56 <krit> silvia: what is it on iframe?
03:34:03 <krit> silvia: how do you define the range?
03:34:09 <krit> silvia: would make a lot more senese
03:34:22 <krit> silvia: especially for going to the picture element
03:34:29 <krit> silvia: what is the use case?
03:34:45 <krit> birtles: SVG conditional prpoposing attr.
03:35:02 <krit> birtles: it is choosing between possibilieties like <switch>
03:35:10 <krit> birtles: common case you wouldn't
03:35:19 <krit> silvia: don't think that is going to work
03:35:40 <krit> silvia: rather embed frame with iframes in there and only one is chosen according criterias
03:36:00 <dmitry> dmitry has joined #svg
03:36:01 <krit> birtles: how is that working on tiling in the mapping use case?
03:36:10 <krit> birtles: you have a lot offrames with same query
03:36:27 <krit> silvia: is it a use case to turn of tiles?
03:36:36 <krit> Cyril: maybe on details
03:36:44 <krit> Cyril: as more you zoom in, as more details
03:37:01 <krit> birtles: you zoom in and get new tiles for this level?
03:37:15 <krit> birtles: don't you think this is accepted?
03:37:30 <krit> heycam: if you could use <switch> in HTML....
03:37:51 <krit> silvia: you getting SMIL back to live once per peace
03:38:08 <krit> silvia: do you have an example
03:38:12 <krit> birtles: yes
03:38:39 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#7.10_Establishing_a_new_viewport
03:40:31 <krit> Cyril: in this case you just want to conrol loading
03:40:35 <krit> birtles: yeah, ok
03:40:44 <krit> Cyril: smae problem as on resp images
03:41:43 <krit> Cyril: use cases might be different enough. I  your case all tiles will have the same queries on all tiles
03:41:59 <Cyril> s/I your/In your/
03:42:23 <Cyril> s/on all tiles/on a given layer/
03:42:48 <krit> birtles: waht about extensions to media queries regarding to zooming
03:43:06 <krit> ed: maybe a topic of FX TF or CSS WG
03:44:33 <krit> ACTION: birtles to discuss iframes with media queries with CSS WG
03:44:33 <trackbot> Created ACTION-3433 - Discuss iframes with media queries with CSS WG [on Brian Birtles - due 2013-02-12].
03:44:41 <krit> topic: streaming of SVG
03:45:34 <Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVGStreaming
03:45:38 <krit> Cyril: In Seattle F2F I made wiki page
03:45:48 <krit> Cyril: had an action a concrete guideline
03:45:58 <krit> Cyril: put it on my web site for now
03:46:00 <Cyril> http://perso.telecom-paristech.fr/~concolat/SVG/streaming/
03:46:19 <krit> Cyril: some times you want to stream SVG content
03:46:26 <krit> Cyril: discussed few use cases
03:46:31 <krit> Cyril: defined terms
03:46:48 <krit> Cyril: what is SVG stream, what is a part of it, how do you access a part of this stream
03:47:10 <krit> Cyril: tries to brdidege a proposal mp4 together with TTML
03:47:25 <krit> Cyril: defines a concept how to map sources
03:47:35 <krit> Cyril: use cases are cartoons
03:48:02 <krit> Cyril: you jump in at any time 24/7
03:48:19 <krit> Cyril: would be good to make broadcasting of cartoons
03:48:45 <krit> Cyril: popcorn js does similar things
03:48:58 <krit> Cyril: things are not meant to be streamed
03:49:04 <krit> Cyril: live stream not easy
03:50:09 <krit> Cyril: use cases are valid in web content
03:50:17 <krit> Cyril: in multi media player as well
03:50:50 <krit> Cyril: I started what we have now (progressive rendeirng without control yet).
03:51:11 <krit> Cyril: communication between client and server missing
03:51:18 <krit> Cyril: do not forward referecnes
03:51:35 <krit> Cyril: element of the future not there, so no content, you are stock
03:52:01 <krit> Cyril: on progressive rendering you want content be synchronized in painting
03:52:19 <krit> Cyril: you can add scripting as well
03:52:39 <krit> Cyril: for simple things the guideline help you
03:52:44 <krit> Cyril: but often you want more
03:52:58 <krit> Cyril: correct displaying on jumping
03:53:10 <krit> Cyril: used access units, generiv term
03:53:33 <krit> Cyril: SVG document is cut into parts and defines and start access units
03:53:54 <krit> Cyril: on concatenating, the peaces get a valid document
03:54:04 <krit> Cyril: a cartoon would cut into frames
03:54:13 <krit> Cyril: you seek into this stream
03:54:27 <krit> Cyril: you need to look at the points when you jump
03:54:47 <krit> Cyril: I defined svg stream header.
03:55:05 <krit> Cyril: helps on seeking
03:55:24 <krit> Cyril: it helps to simulate playing from the beginning on cut in peace stream
03:56:18 <krit> Cyril: to hget a valid state in a stream, you need to care of haveing a valid DOM, scoped stylesheets and maybe JS in a correct state on every position
03:56:31 <krit> heycam: is this an authoring requirement?
03:56:50 <krit> Cyril: author defines a state that you would like to have
03:57:02 <krit> heycam: so browser must allow you that
03:57:04 <krit> Cyril: yes
03:57:09 <nikos> nikos has joined #svg
03:57:14 <krit> Cyril: seeking in an SVG stream
03:57:31 <krit> Cyril: in the future where you don't have the data
03:57:42 <krit> Cyril: you need to know what you want to fetch
03:58:03 <krit> Cyril: hte SVG stream header indicates this
03:58:10 <krit> heycam: do you have an header
03:58:16 <krit> Cyril: different ways to do that
03:58:24 <krit> Cyril: in a container, separate file
03:58:31 <krit> Cyril: like WebVTT
03:59:20 <krit> Cyril: WebVTT give you the time offsets
03:59:34 <krit> Cyril: I descirbe how you might use this in HTML5
04:00:01 <krit> silvia: when you asked to put SVG as source files for Video, is that waht you asked for.
04:00:04 <krit> Cyril: yeah
04:00:15 <krit> silvia: this gives you a bunch of restrictions
04:00:20 <krit> silvia: it needs a timeline
04:00:25 <krit> Cyril: there is already a timeline
04:00:44 <krit> silvia: 2s into the file must be the same for every person
04:00:49 <krit> Cyril: I think this is the case
04:00:57 <krit> birtles: yes, you can synch this
04:01:07 <krit> Cyril: if you start storing
04:01:19 <krit> Cyril: container will give you duration
04:01:35 <krit> Cyril: author needs to give duration and can be used to loop
04:01:51 <krit> Cyril: mp4 file does not need to be video, can cntain everything
04:02:25 <krit> silvia: <video> can already point to mp4, even with these things embeded into mp4
04:02:29 <krit> Cyril: right
04:02:41 <krit> Cyril: waht is SVG in HTML track?
04:02:48 <krit> Cyril: discussed this in the proposal
04:05:46 <krit> Cyril: I'd like to publish and get feedback
04:06:05 <krit> birtles: how much is required of UA, servers and authors
04:06:06 <krit> ?
04:06:26 <krit> Cyril: as UA, you feed stream to preprocessor
04:06:41 <krit> Cyril: don't think there is much to change in browser to support this
04:06:49 <krit> Cyril: for servers there is nothing to change
04:06:54 <krit> Cyril: they do mp4 already
04:07:01 <krit> Cyril: mime type is different
04:07:18 <krit> Cyril: to clarify that a container has a SVG inside
04:07:25 <krit> Cyril:but is not SVG
04:07:39 <krit> silvia: webM is not a generic container
04:07:51 <krit> silvia: just for audio and video maybe WebVTT
04:08:04 <krit> Cyril: is it a valid use case for WebM
04:08:05 <krit> ?
04:08:10 <krit> silvia: not at the moment
04:08:44 <krit> silvia: webm doesn't support it and UA's won't support it anyway, since they would need to parse it. don't find a browser that can handle this
04:09:15 <krit> Cyril: authors need define Cartoon and then access points + packaging
04:10:25 <krit> silvia: has consequences to put markup data into container that is used to work on pixel data
04:11:01 <krit> silvia: things like Canvas assume to get pixel data on video
04:12:14 <krit> birtles: what baout tools?
04:12:27 <krit> Cyril: we have an svg player and a tool to create container files
04:12:44 <krit> birtles: isn't there a lot of potential to get it wrong?
04:13:00 <krit> Cyril: Haven't make the tool for reconstructuring
04:14:05 <krit> Cyril: where can I put it?
04:14:21 <krit> silvia: feels like it does to much
04:14:26 <krit> s/to/too
04:14:33 <krit> s/to/too/
04:14:44 <krit> silvia: sounds more like 10 specs
04:15:06 <krit> Cyril: put it into different sections
04:15:26 <krit> silvia: sounds that some parts would be specified by MPEG
04:15:45 <krit> Cyril: yeah, maybe we do it at MPEG or W3C
04:17:38 <nikos> nikos has joined #svg
04:18:39 <krit> RESOLUTION: Cyril will upload this document for further discussion in this group
04:18:53 <ed> -- 15min break --
04:43:55 <jun> jun has joined #svg
04:50:53 <shanestephens_> shanestephens_ has joined #svg
04:52:21 <stakagi> stakagi has joined #svg
04:53:12 <birtles> scribenick: birtles
04:53:14 <birtles> topic: Glyph selection and positioning; associating text with graphics
04:54:31 <birtles> heycam: I want to see if anyone has a proposal for this, or how important it is
04:54:38 <birtles> ... regarding the glyph positioning in SVG
04:54:52 <birtles> ... a way of selecting and positioning *glyphs* as opposed to *characters*
04:55:06 <birtles> cabanier: isn't this already possible?
04:55:26 <birtles> krit: no that's just unicode, not glyph id
04:55:35 <birtles> ed: the only way I know of is to use altGlyph with an SVG font
04:55:47 <birtles> heycam: altGlyph as a name attribute and you can select glyph by name
04:55:51 <birtles> ed: I think it's by id
04:55:59 <birtles> ... although there might be a name as well
04:56:12 <ed> http://www.w3.org/TR/SVG11/text.html#AltGlyphElement
04:56:19 <birtles> krit: nowadays a lot of people icon fonts
04:56:26 <birtles> ... is that the use case?
04:56:46 <birtles> heycam: now, it's more for things like converting PDF to SVG
04:56:47 <birtles> ... you want to position glyphs exactly
04:56:59 <birtles> ... so you want predictable glyph selection
04:57:19 <birtles> AlexD: the solution in XPS is to have both a character string plus a list of glyph IDs
04:57:24 <birtles> ... and the package includes the font
04:57:30 <birtles> ... so you're guaranteed to have the glyphs
04:58:15 <birtles> heycam: I also want to be able to have some graphics with a text string associated with it
04:58:29 <birtles> cabanier: are you trying to emulate PDF CID fonts
04:59:34 <birtles> [explanation of what that means... it just has single offset, works in one direction, so you don't have to specify x,y every time]
04:59:54 <birtles> ... it also includes an n-to-m mapping so you can say this set of glyphs represents this set of characters
05:00:01 <birtles> heycam: altGlyph also has this
05:00:36 <birtles> [some discussion about how altGlyph's addressing works]
05:01:19 <birtles> ... so are people interested in solving this in the SVG2 timeframe?
05:01:19 <birtles> cabanier: how does this work in pdf.js?
05:01:34 <birtles> heycam: it renders to canvas and creates hidden spans over the text so you can highlight it
05:01:57 <birtles> cabanier: so doing it with canvas sounds problematic. it sounds like we need to solve this
05:03:45 <birtles> ... identity encoded fonts are so easy
05:04:01 <birtles> heycam: one thing about altGlyph is that you can use it in the middle of other text too
05:04:47 <birtles> ... e.g. <text>abc<altGlyph glyphRef="100">de</altGlyph></text>
05:05:03 <birtles> ... "abc" will use usual layout and font-fallback
05:05:15 <birtles> ... but "de" might, in this case, be represented by a single glyph 100
05:05:33 <birtles> ... but what if the text direction differs?
05:05:48 <birtles> ... what does it mean to have absolute positions in this case since the whole thing can be shuffled around?
05:06:03 <birtles> cabanier: so you're mixing absolute positioning with default positioning
05:06:12 <birtles> ... it would be easier if you switch modes when you have glyph IDs
05:06:21 <birtles> ... so maybe you need <idText> or <cidText>
05:06:27 <birtles> heycam: <glyphs>?
05:06:30 <birtles> cabanier: something like that
05:06:48 <birtles> heycam: do you still like the idea of having glyph IDs and character data
05:06:56 <birtles> ... would a list be better
05:07:04 <birtles> ... not one altGlyph per glyph
05:07:14 <birtles> AlexD: yeah, a comma-separated list would be better
05:08:06 <birtles> cabanier: you might want to define the mapping up-front
05:08:10 <birtles> heycam: is that how CID fonts work?
05:08:16 <birtles> cabanier: not CID, but PDF
05:08:27 <birtles> heycam: so you define a table up-front?
05:08:29 <birtles> cabanier: yes
05:09:49 <birtles> heycam and ed: but for SVG we want to have the unicode text there as well as a fallback
05:10:04 <birtles> ... not just a series of glyph IDs and a table
05:10:33 <birtles> heycam: so CID is either horizontal or vertical and then just offsets?
05:10:43 <birtles> cabanier: yes, you start with the CTM and then just offsets
05:10:57 <birtles> ... and it's always LTR or top-to-bottom
05:11:11 <birtles> ... and the default just uses the default width
05:11:35 <birtles> heycam: I'd prefer to have something like altGlyph but *outside* a <text> element
05:11:58 <birtles> ... so you're not mixing text layed out by the browser and author-positioned text
05:12:08 <birtles> cabanier: but then you'd need the font
05:12:38 <birtles> heycam: if you're missing the font or some glyphs aren't there use a box or the undefined glyph
05:12:48 <birtles> cabanier: there's also entity text
05:13:13 <birtles> ... where you want to map some particular characters to something else
05:13:30 <birtles> ... not sure what the use case is
05:13:36 <birtles> ... but it's in InDesign for the Asian market
05:13:49 <birtles> heycam: I'm not sure I'm keen on the table idea
05:14:03 <birtles> ... it's nice to have all the character data in the DOM itself
05:14:09 <birtles> ... for AT tools etc.
05:14:18 <birtles> cabanier: it just gets bigger that's all
05:14:47 <birtles> heycam: so in PDF, when you select between horizontal and vertical is that something you do on the command that draws the text or is it when you select the glyph
05:15:00 <birtles> cabanier: it's the encoding, it's either horizontal or vertical
05:16:34 <birtles_> birtles_ has joined #svg
05:16:46 <birtles_> scribenick: birtles_
05:16:50 <Cyril_> Cyril_ has joined #svg
05:16:55 <nikos1> nikos1 has joined #svg
05:17:00 <birtles_> ... but writing-mode also does top-to-bottom right-to-left
05:17:33 <birtles_> ... can all the font formats that can currently be referenced in the web content, do they all identify glyphs by integers?
05:17:35 <birtles_> cabanier: I believe so
05:17:38 <birtles_> ed: but not SVG fonts
05:17:45 <stearns_> stearns_ has joined #svg
05:18:03 <ys-uchida> ys-uchida has joined #svg
05:18:28 <birtles_> heycam: ok, so numbers are probably ok
05:18:39 <birtles_> ... we just need to come up for a name for the element and the attribute
05:19:01 <birtles_> cabanier: and if you want an n-to-m mapping table you need somewhere to put that
05:19:10 <birtles> scribenick: birtles
05:19:22 <birtles> heycam: I don't think we need that
05:19:30 <birtles> cabanier: I just think it's going to get verbose
05:19:57 <birtles> ... so what if you have several glyphs
05:20:29 <birtles> heycam: it looks like <___ ids="10,1">ab</___>
05:20:41 <birtles> cabanier: and then you would have offset="20, 40" ?
05:21:14 <birtles> heycam: I'd rather use x,y,dx,dy for that
05:21:38 <birtles> cabanier: you shouldn't have to specify *all* the offsets, just the ones where you are tweaking them
05:21:47 <birtles> ... the default spacing should be fine for most cases
05:22:05 <birtles> heycam: so maybe you want <tspans> for that?
05:22:13 <birtles> cabanier and ed: no we don't want tspans
05:22:21 <birtles> heycam: what if you want differently coloured text in the middle?
05:22:26 <birtles> ed: break it up
05:22:43 <birtles> heycam: but what about selection and hit-testing
05:22:59 <birtles> ... if you have to have separate elements for different formatting you'd lose the ability to know that it's the same text run
05:23:21 <birtles> AlexD: I want a javascript function that just gets the text run, I shouldn't have to piece it together
05:23:31 <birtles> heycam: I think we can easily add a tspan-like element in the middle
05:24:08 <birtles> ... which would also mean you don't have to do <___ dx="0 0 0 0 3 0">...</___> to tweak the position of just a few characters
05:24:27 <birtles> ... typically when you have a font family do they tend to have the same glyph ids?
05:24:35 <birtles> cabanier and AlexD: they can be all mixed up
05:24:46 <birtles> heycam: well, you have to know the font when you author it anyway
05:24:58 <Cyril> s/http:\/\/perso.telecom-paristech.fr\/~concolat\/SVG\/streaming\//http:\/\/dev.w3.org\/SVG\/modules\/streaming\/index.html/
05:24:59 <birtles> AlexD: that's right, that's part of the authoring exercise
05:25:30 <birtles> heycam: since selections in the document are represented as a DOM selection using a range
05:25:36 <Cyril> RRSAgent, draft minutes
05:25:36 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html Cyril
05:25:44 <birtles> ... you couldn't do that if you didn't have the character IDs and only had IDs
05:27:18 <birtles> AlexD: the problem is that if you have a <____> and you have 10 ids and 10 characters, you still can't match up ids to characters for text selection since we don't have the mapping
05:27:34 <birtles> heycam: so you could only select the whole lot at once
05:28:31 <birtles> ... we could assume some default
05:28:41 <birtles> ... in firefox you can select half a ligature
05:28:49 <birtles> ... can we use something like that as a default
05:28:59 <birtles> ... and then also provide a mechanism if you want something more accurate
05:29:29 <birtles> AlexD: I think you'll run into all the same problems that face SVG fonts not coping with shaping
05:29:36 <birtles> heycam: so we need the table
05:30:14 <birtles> AlexD: the mapping table works better, it's a simple lookup
05:30:23 <birtles> ... and that gives you delineated glyph boundaries that you can use for selection
05:30:32 <birtles> heycam: so if you have 3 characters mapping to one glyph
05:30:42 <birtles> ... then when you select that glyph you get back those 3 characters
05:32:00 <birtles> birtles: how do you do the reverse look-up if you have different characters mapping to the same glyph?
05:32:10 <birtles> AlexD: that doesn't normally happen, but it can
05:32:26 <birtles> heycam: what does PDF do?
05:32:47 <krit> krit has joined #svg
05:38:07 <birtles> [discussion about the complexities of an n-to-m mapping where one glyph/grapheme cluster can be used for multiple characters and one character/string of characters can be mapped to different glyphs depending on context/author preference]
05:38:47 <birtles> krit: what if you have an SVG-in-opentype font you might want to select the SVG one or not
05:38:59 <birtles> cabanier and heycam: they have the same ID, you can't do that
05:39:10 <birtles> heycam: normally in the DOM the character data is the actual text
05:39:21 <birtles> ... and I think various things expect that to be the case
05:39:28 <birtles> cabanier: even if the element name is different?
05:39:30 <birtles> heycam: yeah
05:39:43 <birtles> ... I'm pretty sure AT tools walk the DOM and find character data to read out
05:39:55 <birtles> cabanier: so we should try to keep those tools happy?
05:40:02 <birtles> heycam: not only that, but also the DOM selection stuff
05:41:24 <birtles> cabanier: but if we put it there we cannot do selection
05:41:40 <birtles> heycam: we can if we resolve how to look up the mapping
05:42:40 <birtles> AlexD: you can have the table separate and then you don't need the IDs next to the character data
05:42:47 <silvia> silvia has joined #svg
05:42:56 <birtles> cabanier: what do the AT tools use
05:43:05 <birtles> heycam: they just walk the DOM as far as I am away
05:43:11 <birtles> ... but that was only one concern
05:43:17 <birtles> ... if you select some text with the mouse
05:43:46 <ed> ed has joined #svg
05:43:57 <birtles> ... there's a corresponding DOM range that's indexed by character
05:44:09 <birtles> ... if there's no character data in the DOM, what are you referring to?
05:44:21 <birtles> ed: you could construct some kind of shadow tree dom ;)
05:44:51 <birtles> heycam: is there a method on the text selection that gets the character data?
05:45:18 <birtles> krit: what are use cases?
05:45:27 <birtles> all: representing PDF in SVG?
05:49:17 <birtles> birtles: how far does CSS Fonts' font-feature-settings get us with this use case?
05:50:41 <birtles> ... when you want to select a particular variant, use a <tspan> with the appropriate feature?
05:51:15 <birtles> heycam: it's conceivable but there may be issues if some browsers don't support all the layout features of the given font
05:54:08 <birtles> heycam: I'd like to have think about how we can still have character data directly in the DOM but have reliable selection of glyphs corresponding to a selection of characters in the DOM without having duplicated information in the table as well as in the character data of the element
05:54:36 <birtles> action: Cameron to think about glyph selection and positioning
05:54:37 <trackbot> Created ACTION-3434 - Think about glyph selection and positioning [on Cameron McCormack - due 2013-02-12].
05:55:08 <heycam> ScribeNick: heycam
05:55:10 <heycam> Topic: global coordinate system
05:55:12 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#GlobalCoordinateSystem
05:55:29 <heycam> birtles: I'm not sure if I can summarise this well
05:55:43 <heycam> … you can see that it's about establishing how different tiles map to one another's coordinate systems
05:56:02 <heycam> … is this useful?
05:56:08 <heycam> … there are some alternatives listed there
05:56:42 <heycam> … there are different ways you could use a viewBox, and different ways you could use the coordinates of the child content for the same effect
05:57:15 <heycam> … you could say that all child content used in the one document is the same coordinate system
05:57:28 <heycam> … and in the child content if it wanted to represent the data in a different coordinate system it could have its own viewBox
05:58:38 <heycam> birtles: three different options on how you could author this
05:58:44 <heycam> … they each have advantages/disadvantages
05:58:45 <nikos> nikos has joined #svg
05:58:57 <heycam> … for example if you say everything is in a global coordinate system, you introduce a coupling between the child tiles and the parent
06:00:21 <heycam> … the proposal here is that because each of these 3 alternatives have disadvantages, we should use a globalCoordinateSystem element
06:00:58 <heycam> … it's also mentioned further on that this would allow different kinds of coordinate systems; ones which are useful for connection diagrams, or one for building plans
06:02:56 <heycam> alex: the only thing is that <globalCorodinateSystem> applies to siblings, it's different from SVG usually where it would apply such a transform to a group
06:04:39 <stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#7.13_.27Global_coordinate_systems.27_.28Add_new_section.29
06:05:46 <stakagi> formula: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#7.13.2_Coodrdinate_Transformation_and_Viewport_Establishment
06:06:52 <AlexD> AlexD has joined #svg
06:10:28 <heycam> heycam: why not just have tiles wrap their local coordinate space data in a viewBox or transform that transforms it into the agreed-upon global coordinate system?
06:10:37 <heycam> heycam: then you don't need a new <globalCoordinateSystem> element
06:10:51 <heycam> heycam: is there a disadvantage to this?
06:16:09 <krit1> krit1 has joined #svg
06:17:23 <shepazu> shepazu has joined #svg
06:17:48 <stearns> stearns has joined #svg
06:19:07 <nikos> nikos has joined #svg
06:19:30 <heycam> alex: you need to know in the outer document what the position and size of the tile is, so you can avoid loading it unless it is in view
06:19:53 <heycam> … this is not possible if you position all of your child iframes at 0,0, with the child content all in the same global coordinate system
06:21:43 <heycam> heycam: we'll continue discussing this later
06:21:48 <heycam> RRSAgent, make minutes
06:21:48 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html heycam
06:22:30 <heycam> Chair: Erik
06:22:37 <heycam> Scribe: Various
06:22:45 <heycam> Meeting: SVG WG F2F Sydney 2013 Day 2
06:22:46 <heycam> RRSAgent, make minutes
06:22:46 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html heycam
06:23:28 <heycam> Scribe: heycam
06:23:32 <heycam> Chair: Erik
06:23:33 <heycam> Meeting: SVG WG F2F Sydney 2013 Day 2
06:23:35 <heycam> RRSAgent, make minutes
06:23:35 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html heycam
06:24:13 <heycam> ScribeNick: heycam
06:24:15 <heycam> Chair: Erik
06:24:16 <heycam> Meeting: SVG WG F2F Sydney 2013 Day 2
06:24:17 <heycam> RRSAgent, make minutes
06:24:17 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/04-svg-minutes.html heycam
06:24:19 <ys-uchida> ys-uchida has joined #svg
06:30:12 <krit> krit has joined #svg
07:11:46 <ys-uchida> ys-uchida has joined #svg
07:24:15 <Zakim> heycam, you asked to be reminded at this time that we should have already gone to dinner
08:21:55 <silvia> silvia has joined #svg
08:22:36 <dmitry> dmitry has joined #svg
10:11:06 <dmitry> dmitry has joined #svg
10:13:02 <Zakim> Zakim has left #svg
10:14:49 <dmitry> dmitry has left #svg
10:15:09 <jun> jun has joined #svg
10:47:26 <jun> jun has joined #svg
11:04:20 <cabanier> cabanier has joined #svg
11:59:37 <jun> jun has joined #svg
13:20:03 <AlexD> AlexD has joined #svg