16:23:24 RRSAgent has joined #svg
16:23:24 logging to http://www.w3.org/2011/10/27-svg-irc
16:23:26 RRSAgent, make logs public
16:23:26 Zakim has joined #svg
16:23:28 Zakim, this will be GA_SVGWG
16:23:28 I do not see a conference matching that name scheduled within the next hour, trackbot
16:23:29 Meeting: SVG Working Group Teleconference
16:23:29 Date: 27 October 2011
16:24:48 zakim, this will be SVG pre-TPAC F2F day 1
16:24:48 I do not see a conference matching that name scheduled within the next hour, ed
16:25:54 zakim, remind me in 8 hours about something
16:25:55 ok, ed
16:26:36 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
16:26:52 chair: Erik
16:27:17 Scribe: Cameron
16:27:20 ScribeNick: heycam
16:29:08 Present: ED, CM, JF, ST, VH, CC
16:30:06 Present+ JY
16:34:35 Present+ DH
16:34:54 jyu3 has joined #svg
16:36:58 jen has joined #svg
16:37:08 Topic: Editing procedures for SVG2
16:40:41 ED: we discussed before about how to edit the spec and markup the spec, how to review
16:41:00 ... I think the idea with this topic here is to give a quick overview, and then to get jwatt to call in in the afternoon to say a bit more about the procedures
16:41:08 vhardy has joined #svg
16:41:10 ... as a starting point, everyone should know how to check out the specification
16:41:12 stakagi has joined #svg
16:41:14 ... we have a page on the wiki
16:41:34 ... Tav wrote on the mailing list, there's no page on the wiki about checking out the spec
16:41:42 s/checking out/writing/
16:41:45 http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
16:42:00 ... here is the page that shows how to get a clone of the SVG repository for SVG2
16:42:06 ... I think we have two separate repositories that you want to check out
16:42:11 ... the first is svg2, which contains the actual spec
16:42:13 dholbert has joined #svg
16:42:20 ... and then there's svg2-test, which should contain the test suite
16:42:28 ... and then there are some minor other repositories for working with the tools for building the spec
16:42:33 ... usually those are not actually important
16:42:41 ... I think it's enough to check out the test suite and svg2 repos
16:43:07 CM: I think you may need to check out the tools repo to build locally
16:43:14 ED: as a beginner's guide, the wiki page above is not perfect
16:43:21 ... but I just managed to get a checkout from that
16:43:35 ... that's what we have at the moment. I don't think there's a wiki page describing how to do review etc.
16:44:04 s/svg2-test/svg2-tests/
16:45:32 CM: I think we should revisit the decision to review before commit
16:45:44 ... Erik and I are concerned that this is an obstacle for editing work getting done at the moment
16:45:53 ... there are two main areas of spec work that will happen
16:45:58 ... one is the existing spec text refactoring
16:46:04 ... and the other is adding text for the new features/proposals
16:46:11 ... I don't think the latter needs to wait on the former necessarily
16:46:25 ... it will be a little more work for the refactorer to reword the new features if they are written in the old spec style
16:46:31 ... but I don't think it will be a great problem
16:46:44 ... so I anyway think we should free up the process a bit so that people can get in and do the work
16:47:00 ED: currently the spec is just using some pink styling rules to indicate it hasn't been looked at yet
16:47:20 ... I'm not sure whether we would remove the pink if we aren't having review
16:47:32 ... so I think the wiki page should explain how to check out the spec, as well as clear editing instructions
16:47:40 ... but if we don't know the exact editing procedures we can't do the whole page
16:48:10 CM: I think one of us should just write up a page describing the desired procedure and we will agree on that
16:48:17 ACTION: Erik to write up a wiki page on SVG2 editing and procedure
16:48:17 Created ACTION-3152 - Write up a wiki page on SVG2 editing and procedure [on Erik Dahlström - due 2011-11-03].
16:48:33 Topic: Requirements input for SVG2
16:48:38 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
16:48:54 ED: I think the idea is to go through the entire list from top to bottom, for things we can agree on get resolutions for them
16:48:58 ... so that we can start doing the edits in the spec
16:49:06 ... we have a requirements document now being written up
16:49:14 http://dev.w3.org/SVG/profiles/2.0/reqs/publish/
16:49:35 jun has joined #svg
16:50:00 cyril has joined #svg
16:52:15 CM: Erik and I will add to that document for the items we resolve on to include in SVG2, and publish that shortly after TPAC
16:52:32 CC: on the previous topic, we should discuss about which things remain in SVG2
16:52:36 ... for example, Filters should be taken out
16:52:42 ... maybe we should have actions for doing that
16:53:01 CM: I think the people doing general editing/refactoring of the spec should do that as a matter of course
16:53:20 ... I don't think we have resolutions on exactly which items have been split out form SVG2
16:54:00 [some discussion of whether Clipping/Masking should be part of the Filters spec]
16:54:10 ED: I think there was a decision on Seattle to move it to Filters
16:57:14 ACTION: Cyril to start a wiki page on SVG2 spec structure, showing which are split out into modules
16:57:15 Created ACTION-3153 - Start a wiki page on SVG2 spec structure, showing which are split out into modules [on Cyril Concolato - due 2011-11-03].
16:57:38 ED: Let's start in the General category
16:57:43 ... first is "avoid backwards incompatible changes"
16:58:20 CM: I think Olaf's position is a bit extreme
16:58:30 ED: as a general guideline it's good to not break content going forward
16:58:44 CM: so "avoid" is ok, but not never
16:58:59 ED: probably don't need a resolution on this
16:59:07 ED: Next, generating shape data from raw data
16:59:12 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_shape_generation_from_raw_data
16:59:49 CC: it would be good to mention the backwards compat issue in the requirements document though
17:00:38 ACTION: Cameron to add a section to the Requirements document about general approaches
17:00:38 Created ACTION-3154 - Add a section to the Requirements document about general approaches [on Cameron McCormack - due 2011-11-03].
17:01:46 ED: this is a big proposal, RDML from Dr O
17:02:18 ... I haven't read all of this, but I feel it's a bit too big to include in SVG at least
17:02:27 ... it feels like something that could at most be a module, or even apply to other things than SVG
17:03:29 CM: I think it's quite a big feature, and out of scope for SVG2
17:04:13 ... I think it's not clear that everyone would agree this is the right approach for mapping of data to DOMs in the web platform
17:04:33 ED: there are ways you can generate shapes from raw data right now, using XSLT for example
17:04:45 CC: to me it seems linked to sXBL
17:05:21 CM: the Web Components work is looking at script based solutions to begin with
17:05:27 ... and looking at declarative solutions later
17:05:35 ... if anything, it should be looked at as part of that effort
17:05:36 jen has joined #svg
17:05:41 RESOLUTION: We will not include RDML in SVG2.
17:05:59 ED: next, templating for controls and widgets
17:06:00 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Templating_for_controls.2Fwidgets
17:06:31 ED: again I think that's something on top of, or outside of SVG
17:07:24 CM: again I think we should look to Web Components here
17:07:31 ... the work is gaining traction
17:07:38 ... we should ensure though that it solves our previous use cases for sXBL etc.
17:09:07 RESOLUTION: We will not include a templating mechanism in SVG2.
17:09:19 CM: Let's talk with Dmitri next week at TPAC about Web Components.
17:09:44 RRSAgent, pointer
17:09:44 See http://www.w3.org/2011/10/27-svg-irc#T17-09-44
17:09:59 ED: That was all from the general section
17:10:04 ... we don't have everything categorised yet
17:10:08 ... next area is Rendering Model
17:10:14 ... and next topic is z-index
17:10:16 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#z-index
17:10:19 ... I believe we already resolved to include
17:10:33 ... so we don't need to discuss that
17:10:39 ... next, translucency
17:10:41 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Translucency
17:10:55 ... I didn't know exactly what was meant here
17:11:33 CM: I think opacity + blur filters is enough
17:12:08 CC: we don't have a lighting model
17:12:19 VH: from the description, I think we can do it with opacity and filters
17:13:00 RESOLUTION: We will not include translucency support, existing functionality is sufficient.
17:13:08 ED: next, flatten to image
17:13:09 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Flatten_to_image
17:13:25 ED: from the description I wasn't sure how this differed from the buffered-rendering property
17:13:29 ... seemed like the same thing to me
17:13:35 ... it's possible he meant to throw away the DOM tree as well
17:14:22 ... you can kind of lose scalability if you do that
17:14:34 CM: presumably you'd only use the feature where that is acceptable
17:14:41 ED: buffered-rendering does the same thing without throwing away the DOM
17:15:09 CM: if you are able to paint SVG to a canvas, then you could do that manually
17:15:12 ED: I think it's not a bad requirement
17:15:19 ... flattening to a raster is useful and necessary sometimes
17:15:31 ... I don't think we need to be very specific on how to solve it, but we should have it as a requirement
17:16:01 CM: buffered-rendering is a hint, so a bit different
17:16:09 ED: say you had a huge canvas you couldn't allocate
17:16:14 ... that can happen with buffered-rendering too
17:16:20 ... it doesn't mean anything changes in the rendering
17:16:28 CC: I don't hink it's related to buffered-rendering
17:16:41 ... if you put a group with 3 objects, one in the background, two next to each other
17:16:53 ... and put bufered-rendering on the group, you'll still see the object from the background
17:16:58 ED: not sure I follow
17:17:03 [Cyril writes on the board]
17:18:30 seems we skipped one, Cyril was talking about pixel rounding
17:18:43 VH: I agree that we he describes is similar
17:19:05 ... the thing he wants can be supported with libraries like canvg
17:19:13 ... you can render it into an offscreen canvas, then insert that canvas
17:19:51 ... there is work going on to fix the security issue with painting SVG content to canvas
17:19:55 DH: yes
17:20:13 CC: the point is not getting the bitmap, you sometimes want to keep a vector graphics representation in memory, but you want to get rid of the DOM
17:20:23 ED: that's what he's suggesting, not sure that's what you want always
17:20:35 DH: but this proposal is for a bitmap
17:20:53 ED: with buffered-rendering in Opera, updates will update the rendering, but not immediately
17:22:01 CC: I think it's a good requirement
17:22:06 ED: but we can discuss the solution later
17:22:48 RESOLUTION: We will add flatten to image as a requirement.
17:22:55 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Pixel_rounding_methods
17:22:58 ED: next, pixel rounding methods
17:23:14 VH: this is the same issue that Michael Bostock brought up at SVG Open
17:23:19 CC: well known problem
17:23:26 ED: I think we might have several issues/requests for this
17:23:29 ... don't think it's a new thing
17:23:46 CC: the thing I'm wondering about is, can a clever SVG implementation avoid this problem, or is it just incompatible with the rendering model?
17:23:51 .. let's say a dummy implementation makes 2 passes
17:24:04 ... first pass to determine the opacity of each pixel, the second pass it actually uses that to determine if the background is needed or not
17:24:07 ... from bg to fg
17:25:29 DH: what if you had opacity on the rectangles, maybe 99%
17:25:38 ED: Michael Bostock was mentioning FSAA
17:25:45 VH: the way people do that is supersampling on the pixels
17:25:58 ... in the case of the line, you realise you keep hitting the same subpixels and not creating the artifact
17:26:02 CC: but no implementations do that
17:26:24 VH: what you are suggesting is also quite complex
17:26:38 ... even if you have full covereage for the pixel, you have to figure out all the objects contributing to the opacity
17:26:40 ... it's not trivial
17:26:49 CC: I'm just wondering whether it's incompatible with the model
17:26:54 ... why don't we have a single browser doing it at the moment
17:27:02 ED: it solves some simple cases
17:27:06 VH: I think it's not there for historical cases
17:27:16 ... it's true that it's ugly in cases, but few people care about it
17:27:23 CC: I think it has been raised from the beginning
17:27:35 VH: but if you do a powerpoint presentation, or a flow diagram, most of those cases you'll never hit this
17:27:44 CC: I found this problem in flash to svg conersion
17:27:47 s/conersion/conversion/
17:27:48 s/it solves some/the shape-rendering hint solves some of the/
17:27:54 ... in Flash you can have many shapes that share a border
17:28:53 ED: I think what people want is sharp edges
17:29:09 VH: maybe a new rendering hint
17:30:51 DH: it seems like it would be hard in general
17:31:03 ... to do automatic pixel snapping and for that to do what you want
17:36:08 RESOLUTION: We will ensure there is a way to avoid getting seams on adjacent edges of rendered elements in SVG2.
17:54:18 thorton has joined #svg
17:55:29 ed, http://www.w3.org/TR/SVG2Reqs/
17:57:40 ED: next section is Document Structure
17:57:41 Phone number?
17:57:44 ... namespace requirements cleanup
17:57:53 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Namespace_requirements_cleanup
17:58:05 Zakim, room for 3?
17:58:06 ok, ed; conference Team_(svg)17:58Z scheduled with code 26631 (CONF1) for 60 minutes until 1858Z
17:58:28 Zakim, code?
17:58:28 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
17:58:39 Thanks
17:58:57 Team_(svg)17:58Z has now started
17:59:04 +tbah
17:59:17 ok
18:01:16 + +1.650.693.aaaa
18:02:15 ED: we do have a resolution for xlink:href
18:02:23 ... we still have xml:id and other xlink-related things
18:02:28 ... not sure we have a resolution for that
18:03:02 RESOLUTION: We will reconsider use of namespaced things in SVG (xlink, xml:id, etc.).
18:04:45 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#.3Cuse.3E_cleanup
18:04:46 VH: browsers have started to do something re href="" too
18:04:50 ... so we should look at that
18:04:52 ED: next, use cleanup
18:05:37 CM: a bit vague
18:05:59 ... the one issue I can think of is the property inheritance into the shadow tree
18:07:04 CC: when you have a use element that includes a reference to a gradient, you need to duplicate the whole shadow tree each instance
18:08:44 ED: one part might be differences between implementations
18:08:47 ... ensuring things work the same
18:09:05 ... that could require having a second look at the current spec, seeing what's broken and what's differing
18:09:17 VH: I would suggest taking this as a need for a better referencing/cloning mechanism
18:09:34 ... I would accept this as a requirement, since it's a pain point for many people
18:11:01 RESOLUTION: We will require a feature that allows symbol reuse without requiring duplication of shadow trees in SVG2.
18:11:06 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Marker_cleanup
18:11:09 ED: next, marker cleanup
18:11:17 ... we have one resolution already, to add currentStrokePaint etc.
18:11:34 ... for inheriting colours into the marker
18:11:41 ... which seemed to be the thing most people were asking for
18:11:49 ... I think as a requirement, we should probably look a bit wider
18:11:53 ... on how to improve markers
18:12:30 RESOLUTION: We will improve markers for SVG2.
18:12:34 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Shadow_tree_cleanup
18:12:38 ED: next, shadow tree cleanup
18:12:44 ... not sure if that's different from use cleanup
18:12:52 ... I think that could be the same thing
18:13:25 ... next one is "improve the DOM"
18:13:51 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM
18:14:04 ... we have a bunch of different proposals
18:14:11 ... I've collected some of them as subpoints of this item
18:14:14 ... so we could resolve on those
18:14:17 ... it's more contained, simplified
18:14:32 ... first of those is "improve the DOM for SVG Animation"
18:14:32 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM_for_SVG_Animation
18:14:34 VH: yes
18:14:52 ED: I proposed a simple API to grab the current motion animation
18:14:57 ... that's been asked for a number of times
18:15:48 DH: supposing the element itself is transformed, does this take into account all of the element's transforms?
18:15:54 ED: just the transform for the motion animation
18:16:07 CC: we don't have a microdom equivalent for that?
18:16:09 ED: don't think so
18:17:13