00:00:22 ... there was a level of zoom requirement item too 00:00:30 ... just put an attribute for minimum/maximum zoom level on any element 00:01:22 CM: the Tiling/Layering will be a separate document, right? 00:01:37 CL: that won't allow you to do the complex/simpler path kind of level of detail though 00:12:19 [discussion of differences between tiling, LoD, auto fetch/discard] 00:13:41 RESOLUTION: We won't include automatic fetch/discard in SVG2. 00:14:04 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control 00:14:17 CM: this one sounds more interesting to me 00:15:38 http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming 00:20:33 RESOLUTION: We will support Level of Detail control in SVG2. 00:21:04 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Templating_for_controls.2Fwidgets 00:21:12 CC: now the one we should go back to is templating for controls and widgets 00:23:07 ED: already resolved earlier this morning 00:23:37 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_transform.3D.22.22_to_.3Csvg.3E 00:23:44 ED: next, transform on svg elements 00:23:55 CL: what does that help with? 00:23:59 ED: nested svg elements 00:25:52 CM: seemed odd to me not to allow transform on svg 00:25:54 ed, you asked to be reminded at this time about something 00:26:09 ... but it might be confusing for authors wrt order of application of transform and viewBox 00:29:22 RESOLUTION: We will allow transform on in SVG2. 00:29:37 ED: next, allowReorder on switch 00:29:38 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Add_.40allowReorder_to_.3Cswitch.3E_for_improved_language-based_switching 00:31:35 CL: this came out of a request from mozilla that switch with requireLanguage is less useful when you have a list of ordered preferred user languages 00:31:47 ... it got added in SMIL3 00:31:50 CM: it has a bad name 00:33:23 RESOLUTION: We will support a mechanism like or the same as allowReorder from SMIL3 in SVG2. 00:33:37 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Allow_referencing_root_external_files_with_.3Cuse.3E 00:33:43 ED: next, allow referencing root external files with use 00:33:56 ISSUE-2238: 00:35:00 DH: with , you get the same animation timeline, vs if you use image 00:35:14 CM: also with events you can distinguish which shadow tree elements was clicked, for example 00:38:07 DH: would this apply to other things that reference external elements, like mask? 00:38:16 ED: maybe wouldn't make sense there 00:38:30 CC: there is the animation element in 1.2T, is that relevant here? 00:38:49 ED: but that only references a whole document anyway 00:39:07 CL: in 1.2T we split it up into for more static images, and for animated ones 00:39:20 ... with you can use the SMIL timing attribtues on it, so you can control its timeline separately 00:39:32 ... but you can't do that with animated SVG referenced from 00:40:02 ... the name animation is confusing though, compared to animate 00:40:15 ... in the end though image was able to point to svg content 00:40:40 ... so we may or may not want to keep , possibly renamed 00:45:13 RESOLUTION: We will relax referencing requirements to particular elements to allow dropping fragments to mean referencing root element, where it makes sense, such as with use, in SVG2. 00:46:30 ACTION: Cyril to investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element 00:46:31 Created ACTION-3157 - Investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element [on Cyril Concolato - due 2011-11-04]. 00:47:11 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Parameters 00:47:15 ED: next, in the Attributes section, is Parameters 00:47:54 CC: we need this 00:49:03 Zakim, code? 00:49:03 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 00:51:24 - +1.650.693.aaaa 00:51:26 -AD 00:51:26 Team_(svg)22:53Z has ended 00:51:28 Attendees were +1.650.693.aaaa, [IPcaller], AD 00:51:29 Zakim, room for 3? 00:51:31 ok, heycam; conference Team_(svg)00:51Z scheduled with code 26631 (CONF1) for 60 minutes until 0151Z 00:51:58 Team_(svg)00:51Z has now started 00:52:05 +Doug_Schepers 00:52:28 + +1.650.693.aaaa 00:53:49 DS: we decided last time that we would not make this general 00:53:50 CC: in what sense? 00:54:01 DS: in the sense that this would not be a CSS thing, it's an SVG thing 00:54:10 ... although people are going to want to pass things in to CSS 00:54:30 ... in CSS embedded in SVG, you would want a legal value to be a param 00:54:52 ... I think we thought it would take too long to get into CSS as well 00:54:57 ... but having it attribute only would have this downside 00:55:03 ... especially if people are using SVG and CSS together more 00:55:51 CM: I would really like to see if we can use CSS Variable as the in-CSS way to reference parameters 00:56:35 DS: maybe we should move ahead with it as a separate spec 00:56:53 CL: Tab is in general happy to add new values to CSS Values 00:57:08 DS: it's effectively like calc, in terms of scope 00:57:20 ... I see param working with calc really well 00:58:12 CC: do we want to allow params to work with presentation attributes, style properties, geometry attributes, SMIL attributes...? 00:58:21 DS: I want it to apply to every SVG attribtue, and maybe property values as well 00:58:42 CC: how about using them in script? 00:58:53 DS: there's the DOM interface that exposes params and their values 01:01:02 ... anything I do with params I would like to decompose a shorthand for Component Model 01:03:00 [discuss some details of Params] 01:04:19 DH: I would be a bit concerned about being gated on CSS work 01:04:33 DS: we could say that for now, it works only in attributes, but that we're open to the CSS WG allowing this in property values 01:04:48 ... and I'd expect there'd be experimental implementations to see if there are any issues with allowing that 01:06:02 CL: we did already talk about this within FX 01:09:17 RESOLUTION: We will have Parameters in SVG2, worked on in a normatively referenced separate spec. 01:09:41 -Doug_Schepers 01:09:42 zakim,list attendees 01:09:43 As of this point the attendees have been Doug_Schepers, +1.650.693.aaaa 01:09:45 - +1.650.693.aaaa 01:09:45 Team_(svg)00:51Z has ended 01:09:47 zakim, list attendees 01:09:47 Attendees were Doug_Schepers, +1.650.693.aaaa 01:09:49 sorry, ChrisL, I don't know what conference this is 01:10:01 Present+ Sairus Patel 01:10:23 RRSAgent, make minutes 01:10:23 I have made the request to generate http://www.w3.org/2011/10/28-svg-minutes.html heycam 01:10:55 Chair: Erik, Cam 01:11:26 Meeting; SVG WG f2f Mountain View 01:12:10 Present: Chris, Erik, Daniel Holbert, Jen, Jun, Takagi-san, Cyril, Vincent 01:12:14 Present: Chris, Erik, Daniel Holbert, Jen, Jun, Takagi-san, Cyril, Vincent, Cameron 01:12:44 shepazu, http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/ 01:12:57 1075 La Avenida 01:12:59 Mountain View, CA 94043 01:13:01 Tel: (650) 693-1005 01:13:03 Building 5 01:13:14 thanks 03:23:58 karl has joined #svg 03:35:31 Zakim has left #svg 03:57:40 jun has joined #svg 04:07:21 ChrisL has joined #svg 16:03:07 RRSAgent has joined #svg 16:03:07 logging to http://www.w3.org/2011/10/28-svg-irc 16:03:09 RRSAgent, make logs public 16:03:09 Zakim has joined #svg 16:03:11 Zakim, this will be GA_SVGWG 16:03:11 I do not see a conference matching that name scheduled within the next hour, trackbot 16:03:12 Meeting: SVG Working Group Teleconference 16:03:12 Date: 28 October 2011 16:03:14 RRSAgent, this meeting spans midnight 16:03:32 Zakim, remind me in 8 hours to quit yammering about SVG 16:03:32 ok, heycam 16:03:58 Meeting: SVG Working Group Mountain View F2F 2011, day 2 16:04:01 Chair: Cameron 16:04:10 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda 16:04:33 jun has joined #svg 16:24:17 cyril has joined #svg 16:24:30 stakagi has joined #svg 16:30:55 ChrisL has joined #svg 16:31:07 Scribenick: ChrisL 16:31:29 Topic: SVG2 Requirements Input 16:31:35 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Custom_data-.2A_attributes 16:31:48 Topic: Custom data attributes 16:31:59 heycam: this is to align with HTML5 16:32:09 jen has joined #svg 16:32:22 ... confusing to not be abletodio this in mixed html5/svg 16:33:10 (general agreement) 16:33:12 zakim, pointer 16:33:12 I don't understand 'pointer', cyril 16:33:21 RRSAgent, pointer 16:33:21 See http://www.w3.org/2011/10/28-svg-irc#T16-33-21 16:33:29 resolution:we willadd data-* attributes in SVG2 to align with HTML5 16:33:43 Topic: randomisation 16:34:06 vhardy has joined #svg 16:34:43 ed: this could be done in script 16:34:52 cc: there is not much of a proposal here 16:35:09 resolution: we will not add declarative randomisation functionality in SVG2 16:35:20 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_certain_HTML_attributes_used_in_microformats 16:36:04 Topic: Consider adding certain HTML attributes used in microformats 16:36:15 ISSUE-2048? 16:36:15 ISSUE-2048 -- Consider adding certain HTML attributes used in microformats -- raised 16:36:15 http://www.w3.org/Graphics/SVG/WG/track/issues/2048 16:37:27 ChrisL: ARIA isalso somethig that should be supported - related 16:38:02 heycam: higher level goal is to bring across globalattributes thatmake sense, ratherthan thesespecific ones 16:38:23 heycam: consider together with aria 16:38:49 resolution: we will align with HTML5 globalsemantic attributes wherethese make sense for SVG 16:39:12 plinss has joined #svg 16:39:16 rrsagent, add spaces wherever i meantto typethem 16:39:16 I'm logging. I don't understand 'add spaces wherever i meantto typethem', ChrisL. Try /msg RRSAgent help 16:39:39 action: ChrisL to look at global attributes 16:39:40 Created ACTION-3158 - Look at global attributes [on Chris Lilley - due 2011-11-04]. 16:39:57 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_relaxing_case_sensitivity_of_presentation_attribute_values 16:40:11 topic: Consider relaxing case sensitivity of presentation attribute values 16:40:42 heycam: there were complaints about this at svgopen 16:41:16 vhardy: the complaint was actually attribute and element names being case sensitive 16:41:45 vhardy: we could deprecate oneset of names and introduce new ones 16:42:05 ChrisL: makes more confusion than it helps 16:42:46 vhardy: example is textPath, cant search for getElementbyTagName 16:43:39 ChrisL: so it does work as long as you spell it consistently 16:44:47 heycam: tested just now, it recognises the statndard spelling but does not recognised the fixed-up name 16:44:57 If you have `...` then you do document.getElementsByTagName("textpath"), it won't find the element 16:45:05 but if you do ...getElementsByTagName("textPath") it will 16:45:52 If you have `...` and you do document.getElementsByTagName("textPath"), it will find it 16:46:23 ChrisL: it only fixes up when parsing, not in script 16:46:44 heycam: wonder about adding magic to getElementsByTagName 16:47:28 cyril: two issues,values and element/attribute names. 16:48:04 heycam: any objections to making property values as attributes case insensitive? 16:48:18 cyril: IDs are case sensitive 16:48:36 erik: all presentation attributes are safe to do this with 16:49:01 resolution: make property values case insensitive 16:49:53 ChrisL: so in the dom the case is preserved? 16:49:57 heycam: yes 16:51:24 ChrisL: sad that the dom is still required to preserve whatever case combination was used each time, in case you ask for it back 16:51:34 ... could this be normalised like we did in udom? 16:51:45 heycam: hellno 16:52:04 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Fluorescent_colours.2Fextended_colour_specifiers 16:52:12 Topic: Fluorescent colours/extended colour specifiers 16:56:25 (chris talks at lemngth and forgets to minute) 16:56:39 http://dev.w3.org/SVG/modules/color/publish/SVGColor.html 16:57:40 action: chris to reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color 16:57:41 Created ACTION-3159 - Reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color [on Chris Lilley - due 2011-11-04]. 16:58:11 http://dev.w3.org/SVG/modules/color/master/SVGColor.html 17:00:17 ChrisL: have several offers of reviews for this. would like to publish, get the review, then go to w3c last call 17:00:32 heycam: should this be normatively required by SVG2 17:04:17 this is something operating systems all do not (but not onmobile) 17:05:30 cyril: name is confusing can we rename to color-management 17:10:13 vhardy has joined #svg 17:14:56 cyril:intro shouldsay it is a supersetof SVG color chapter and of CSS3 color 17:15:05 ChrisL: yes it should state that explicitly 17:15:29 ed: what t do with css3 images and css gradients as they affect paint? 17:28:18 ed: ok with the conformance class that does color managed images 17:28:48 heycam: we can have several conformance clasees in this spec then decide later which ones svg2 requires 17:28:56 ChrisL: happy with that 17:30:26 resolution: svg2 will depend on svg colormanagement subject to deciding the exact conformance classes required 17:30:49 ChrisL: this could be a separte module or it could be a chapter, its written as a drop-in replacement actually 17:32:34 ChrisL: makes more sense to have this as the color chapter in fact 17:32:37 (agreed) 17:33:46 resolution: svg colormanagement becomes a chapter in SVG2 17:34:05 action: ChrisL to edit the svg colormanagemtn spec into a chapter in SVG2 17:34:05 Created ACTION-3160 - Edit the svg colormanagemtn spec into a chapter in SVG2 [on Chris Lilley - due 2011-11-04]. 17:46:21 scribenick: dholbert 17:46:32 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Non-scaling_stroke 17:46:34 topic: non-scaling stroke 17:47:03 CM: lots of people want this, and it's not too hard to implement 17:47:15 CL: Yes 17:47:19 Hi, phone? 17:47:29 zakim, room for 3? 17:47:30 ok, ChrisL; conference Team_(svg)17:47Z scheduled with code 26631 (CONF1) for 60 minutes until 1847Z 17:47:38 resolution: svg2 will include non-scaling stroke 17:47:54 Zakim, code? 17:47:54 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 17:48:49 Team_(svg)17:47Z has now started 17:48:56 + +1.650.693.aaaa 17:48:59 +tbah 17:49:06 zakim, aaaa is tbah 17:49:06 +tbah; got it 17:50:21 tbah: inkscape has non scalingstroke and non scalling patterns 17:50:43 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Non-scaling_rounded_rect_corners 17:50:46 topic: non-scaling rounded rect corners 17:51:09 ED: maybe things in general that are non-scaling could go into another coordinate system 17:51:28 CM: might be interesting to look into other things that you might want to not scale 17:52:05 CC: e.g. rectangle with radius=5 on the corner, you might want to grow the rectangle but not grow the radius of the corner 17:53:06 CC: there's also non-scaling whole objects, e.g. legends in a map 17:53:41 CL: doesn't tiny 1.2 let you do something like that, by saying "this part is in the coordinate system over there"? 17:54:00 CC: we also have the transformBehavior attribute, for video 17:55:02 ref(svg,x,y)? 17:55:30 CC: it has the value 'pinned' which would help with this as well 17:56:06 ED: it'd be nice to hear more about the non-scaling things in inkscape 17:56:20 CL: non-scaling patterns (inkscape option) sounds interesting 17:58:13 CM: perhaps tav can write up a summary of inkscape's non-scaling features 17:58:14 TB: sure 17:58:38 action: tav to write up summary of inkscape's non-scaling features, as possible candidates for svg2 17:58:38 Created ACTION-3161 - Write up summary of inkscape's non-scaling features, as possible candidates for svg2 [on Tavmjong Bah - due 2011-11-04]. 18:00:12 resolution: svg2 should include non-scaling features, aside from non-scaling stroke. (2 separate components: non-scaling part of the object, and non-scaling entire object) 18:00:32 topic: variable stroke-width 18:00:33 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width 18:00:48 CL: we're lacking a fully fleshed-out proposal for this 18:01:59 CL: we don't want to be forced to put stroke-width "stops" only at the nodes 18:02:14