- From: Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>
- Date: Thu, 2 Feb 2012 21:39:51 +0000
- To: "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <54EF1DA3171CEE48AD59D7FF0DE043C3567C05BA@exm02-wvp.cisra.canon.com.au>
Hi SVG fans, Please find the minutes from today's SVG WG conference call: http://www.w3.org/2012/02/02-svg-minutes.html and as text here: - DRAFT - SVG Working Group Teleconference 02 Feb 2012 Agenda<http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0050.html> See also: IRC log<http://www.w3.org/2012/02/02-svg-irc> Attendees Present Regrets heycam, Rik, Dirk, Vincent Chair ed Scribe Cyril Contents * Topics<http://www.w3.org/2012/02/02-svg-minutes.html#agenda> * currentColor change in CSS<http://www.w3.org/2012/02/02-svg-minutes.html#item01> * SVG Requirements<http://www.w3.org/2012/02/02-svg-minutes.html#item02> * line-increment<http://www.w3.org/2012/02/02-svg-minutes.html#item03> * text-align<http://www.w3.org/2012/02/02-svg-minutes.html#item04> * vector-effect<http://www.w3.org/2012/02/02-svg-minutes.html#item05> * constrained transformations<http://www.w3.org/2012/02/02-svg-minutes.html#item06> * better bounding box definitions<http://www.w3.org/2012/02/02-svg-minutes.html#item07> * SVG Tiny 1.2 Paths<http://www.w3.org/2012/02/02-svg-minutes.html#item08> * Basic Shapes<http://www.w3.org/2012/02/02-svg-minutes.html#item09> * new text features<http://www.w3.org/2012/02/02-svg-minutes.html#item10> * editable attribute<http://www.w3.org/2012/02/02-svg-minutes.html#item11> * scrolling and editable text<http://www.w3.org/2012/02/02-svg-minutes.html#item12> * textArea<http://www.w3.org/2012/02/02-svg-minutes.html#item13> * tbreak<http://www.w3.org/2012/02/02-svg-minutes.html#item14> * video, transformBehavior and overlay<http://www.w3.org/2012/02/02-svg-minutes.html#item15> * the animation element<http://www.w3.org/2012/02/02-svg-minutes.html#item16> * Summary of Action Items<http://www.w3.org/2012/02/02-svg-minutes.html#ActionSummary> ________________________________ <trackbot> Date: 02 February 2012 <scribe> scribe: Cyril <scribe> Scribenick: cyril currentColor change in CSS <ed> http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0041.html CL: I sent an email looking for tests that would be affected ... we have quite a bit of tests affected as we used 'inherit' all over the place for testing ... but how much content would be affected ... that's less clear ed: were you checking the 1.1 test suite cl: yes ed: we may have some more in the Tiny 1.2 test suite cl: the reason why they want to change the behavior ... the color of underlying is not affected by child elements ... so they want to use currentColor to define how it works ... my main concern is that ew say that it's the current animated value, as long as it's stays like that I' ok ... but if we change that, that would be a major change cc: how many implementations implement that correctly <ChrisL> http://www.w3.org/Graphics/SVG/Test/20110816/status/implementation_matrix.html <ChrisL> $ grep -l currentColor *.svg <ChrisL> animate-elem-41-t.svg <ChrisL> animate-elem-78-t.svg <ChrisL> animate-elem-84-t.svg <ChrisL> animate-elem-85-t.svg <ChrisL> animate-pservers-grad-01-b.svg <ChrisL> color-prop-01-b.svg <ChrisL> color-prop-05-t.svg <ChrisL> filters-light-05-f.svg <ChrisL> painting-fill-02-t.svg <ChrisL> pservers-grad-18-b.svg <ChrisL> struct-group-03-t.svg <ChrisL> struct-use-05-b.svg <ChrisL> styling-inherit-01-b.svg CL: that is a list of tests using currentColor, but not a list of tests that would be affected CC: I remember a test in the Tiny test suite explicitly testing the currentColor inheritance <krit> There is one in SVG 1.1SE as well CC: has the CSS WG considered other options? Is it the only option they have ? <krit> (Just partly attending to view comments) Tav: we discussed that currentColor would have two values? CL: no currentColor is a value not a property CC: we discussed currentFill, currentStroke, ... <ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects currentColor currentFillPaint currentStrokePaint useColor useFillPaint useStrokePaint CL: I wasn't proposing to change currentColor Tav: CSS could use useColor? CL: I suppose they could ... actually,' I'm not so sure for their use case CC: they could add a new keyword for their use case CL: that's true <ChrisL> tab's email describes their use case http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0064.html text-emphasis-color CC: the property they seem to need this for is text-emphasis-color ... we should ask the CSS WG to see if they can't use the useColor keyword for that case CL: it would help if Tab was on the call <ChrisL> I suspect he is either travelling or on vacation prior to the CSS meeting next week <scribe> ACTION: Chris to ask Tab about the use of useColor keyword for the text-emphasis-color use case [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action01] <trackbot> Created ACTION-3232 - Ask Tab about the use of useColor keyword for the text-emphasis-color use case [on Chris Lilley - due 2012-02-09]. <ChrisL> I willbe there, i can ask him SVG Requirements http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#line-increment line-increment CL: does it apply to textArea <ChrisL> This property applies to the 'textArea' element, and to child elements of the 'textArea' element. CL: and to tspan as children of text area RESOLUTION: SVG 2 will not add line-increment as it is linked to textArea <ChrisL> text-align Applies to: textArea elements text-align http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#text-align ed: same resolution as line-increment Tav: we are going to have whatever CSS has for text alignment CL: yes that's the plan RESOLUTION: SVG 2 will not add text-align as it is linked to textArea vector-effect http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#vector-effect CL: I suggest that we keep it <ChrisL> a new shorthand keyword: stroke-below-fill CL: I like Erik's suggestion http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Stroke_position RESOLUTION: SVG 2 will have the vector-effect property CC: I think there is no other CSS-related modifications CL: we might want to make a check ... I think it's better to do when we have a spec more stable ed: we already backported a lot of the new text from 1.2T to 1.1SE ... there might be some things still in 1.2 ISSUE: Make sure that all relevant improved from 1.2 Tiny is backported to SVG 2 <trackbot> Created ISSUE-2434 - Make sure that all relevant improved from 1.2 Tiny is backported to SVG 2 ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2434/edit . constrained transformations http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Constrained_Transformations ed: is that transform=ref CL: yes but not just that ... there is a lot of things on transform stack ... we might want to keep that as explanatory for people who don't have much graphics background <scribe> ACTION: Chris to review the Transform chapter of SVG Tiny 1.2 to see what needs to be ported to SVG 2 or the FX Transform spec [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action02] <trackbot> Created ACTION-3233 - Review the Transform chapter of SVG Tiny 1.2 to see what needs to be ported to SVG 2 or the FX Transform spec [on Chris Lilley - due 2012-02-09]. ed: transform ref is down to raise issues on the merged transform spec ... I don't know how much we want to have on transform in the SVG spec ... or if we want to point to that merged spec only CC: if some transform behavior is only applicable to graphics and less meaningful for HTML Tav: I think transforms in general are pretty basic and should be in SVG 2 CL: transform ref is about keeping some aspects in the current transformation system and some aspects in an earlier one ... that is hte use case and that is what it does ... another use case is when you have labels and you don't want them to rotate ... you can't do it correctly with script ... the interaction and the script are fighting each other Tav: it's an important something to have ... in a map you have a swamp, with a pattern indicated trees,... with a symbol being repeated, and you change the scale and you want to have the symbol remain the same size ... suppose you have a hatching ... you want that hatching to not scale RESOLUTION: SVG 2 will have constrained transformations based on SVG 1.2 Tiny better bounding box definitions http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#More_precise_definition_of_bounding_box Tav: how is tiny better than 1.1 ed: it explains tight bounding box and so on, it's much more precise Tav: bounding box does not include stroke related properties ed: yes we already agreed to improve that too Tav: Inkscape has the notion of geometry bounding box that includes the stroke RESOLUTION: SVG 2 will improve the bounding box text based on SVG Tiny 1.2 SVG Tiny 1.2 Paths CC: any change compared to 1.1 ? CL: maybe the BNF ed: maybe CC: BNF = grammar for path syntax <scribe> ACTION: Erik to check if any changes in the path syntax BNF in 1.2 Tiny need to be ported in 1.1 [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action03] <trackbot> Created ACTION-3234 - Check if any changes in the path syntax BNF in 1.2 Tiny need to be ported in 1.1 [on Erik Dahlström - due 2012-02-09]. Basic Shapes CC: any change CL: I don't think so ed: I remember we discussed where stroke begins and ends ... I don't know if it was backported <ChrisL> Within the current user coordinate system, stroking operations on a circle begin at the point (cx+r,cy) and then proceed through the points (cx,cy+r), (cx-r,cy), (cx,cy-r) and finally back to (cx+r,cy). For stroking operations, there is only one line segment which has its beginning joined to its end. <scribe> ACTION: Chris to check if any change in the basic shapes chapter need to be ported to SVG 2 [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action04] <trackbot> Created ACTION-3235 - Check if any change in the basic shapes chapter need to be ported to SVG 2 [on Chris Lilley - due 2012-02-09]. new text features CL: The SVG Tiny 1.2 text is better and I'm keen on having it in 2 RESOLUTION: SVG 2 will include the improved text from SVG Tiny 1.2 on characters and glyphs, text layout, text selection, text search <scribe> ACTION: Chris to add the SVG Tiny 1.2 text on characters and glyphs, text layout, text selection, text search to SVG 2 [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action05] <trackbot> Created ACTION-3236 - Add the SVG Tiny 1.2 text on characters and glyphs, text layout, text selection, text search to SVG 2 [on Chris Lilley - due 2012-02-09]. editable attribute http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_editable_attribute CL: we should have the feature ... but not this attribute ... HTML has a different way to do it ... contentEditable ed: I agree RESOLUTION: SVG 2 will have the HTML content editable feature http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_scrolling_to_editable_text scrolling and editable text CL: In 1.2 Tiny it was only applicable to wrapping text ... but content editable could potentially go anywhere ... on a path for instance ... even if the meaning is not clear ... In 1.2 tiny we had textArea ... and if you would edit it and put too much text ... you might not be able to see it ... so the scrolling was needed ... but now it becomes moot <ChrisL> about prior decision on text flow, see http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Text_flow_to_arbitrary_shapes DS: we should define how the combination of properties such as scroll, content editable ... should work on a text area CL: I agree ISSUE: for content editable text, we should consider the effects with overflow scroll <trackbot> Created ISSUE-2435 - For content editable text, we should consider the effects with overflow scroll ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2435/edit . DS: back on content editable ... we should consider whether content editable is applicable to other elements than text ... on a path ... does it show the points and you can move them around ... maybe the decision is no ... but we should consider it CC: yes we should define it since we agreed to define all undefined behavior DS: it could be a good way to have SVG editing in browser CL: it's a bit naive ISSUE: Define behavior for content editable on non-text elements <trackbot> Created ISSUE-2436 - Define behavior for content editable on non-text elements ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2436/edit . textArea http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_textArea_element <ChrisL> about prior decision on text flow, see http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Text_flow_to_arbitrary_shapes tbreak CL: I'm trying to work out whether tbreak would work only in textArea CC: yes ed: yes CL: it could be a short hand for x=inherit and dy=font-size+line-spacing CC: we might then add alignement on different baselines and so on. DS: we could define it ... I'm not saying it's super useful, but might be useful and wouldn't be too hard ... once we have text wrapping people will start using that and not tspans <ChrisL> i am no longer arguig for tbreak DS: so tbreak is just an optimization at this point ... we should not have it now and reconsider if people complain about it RESOLUTION: SVG 2 will not have the tbreak element unless compelling use cases are provided video, transformBehavior and overlay CL: that's 3 spearate questions ... the audio/video issue is already resolved <ChrisL> first resolution here http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Video.2Faudio_on_demand http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Cvideo.3E_element_with_the_.27transformBehavior.27_attribute_and_the_.27overlay.27_attribute CL: the transformBehavior is interesting ... not restricted to video CC: I agree but we should propose it to the merge spec ... but if it is not accepted in the merge spec, do we want it in SVG only CL: maybe RESOLUTION: SVG 2 will have the transformBehavior feature in its spec or as part of the merged transform spec CC: the overlay attribute? CL: again I think it is useful ... in particular combined with full screen ... it is a convenient way to pop things up DS: does it make sense if there is a full screen api? CL: does it take the thing out of the rendering order ? DS: in some sense, yes it does ... if I have a video occluded but a rectangle and full-screen the video, you would only see the video ed: it is related to the z-index that we resolved to have CC: I suspect that this overlay attribute should be discussed with the CSS WG ed: do we think there we have other features that cover the same thing DS: the main use case for overlay were create modal dialogs and do full screen videos CL: modal dialog was not the first use case ed: overlay is an attribute on the video element, not a property CL: it was added because of video-centric people DS: I suggest that we drop it ... it simplifies things RESOLUTION: SVG 2 will not add the SVG Tiny 1.2 overlay attribute because the Fullscreen API combined with the z-index property will cover the same use cases the animation element http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Canimation.3E_element CL: the reason that we added the element is because we noted too late that SMIL defines image for static images ... and animation is for animated vector graphics, that's why it's called animation ... but every one is confused because image cannot point to animated SVG ... we certainly want to have one thing point to non-scripted content ... and another one to point to full-fledged content ... it might be an attribute on image and does not need to be an 'animation' element <ChrisL> i think the element name 'animation' has proved to be confusing for authors ed: It would be a good idea to look at the features around this ... I don't think the element in itself is that useful CC: the fact that it's a timed element is important CL: yes ed: yes CC: we could have an element with the HTMLMediaElement API on it but for vector graphics <ChrisL> my regrets next week, css f2f meeting RESOLUTION: SVG 2 will add the features of the SVG Tiny 1.2 animation element but not the element itself Summary of Action Items [NEW] ACTION: Chris to add the SVG Tiny 1.2 text on characters and glyphs, text layout, text selection, text search to SVG 2 [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action05] [NEW] ACTION: Chris to ask Tab about the use of useColor keyword for the text-emphasis-color use case [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action01] [NEW] ACTION: Chris to check if any change in the basic shapes chapter need to be ported to SVG 2 [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action04] [NEW] ACTION: Chris to review the Transform chapter of SVG Tiny 1.2 to see what needs to be ported to SVG 2 or the FX Transform spec [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action02] [NEW] ACTION: Erik to check if any changes in the path syntax BNF in 1.2 Tiny need to be ported in 1.1 [recorded in http://www.w3.org/2012/02/02-svg-minutes.html#action03] [End of minutes] ________________________________ Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> version 1.136 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>) $Date: 2012/02/02 21:32:38 $ ________________________________ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/> Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/where/were/ Succeeded: s/tests affected/tests affected as we used 'inherit' all over the place for testing/ Succeeded: s/work/works/ Succeeded: s/textAreq/textArea/ Succeeded: s/lot of the new text/lot of the new text from 1.2T to 1.1SE/ Succeeded: s/HHTML/HTML/ Succeeded: s/ha// Succeeded: s/to hard/too hard/ Found Scribe: Cyril Inferring ScribeNick: cyril Found ScribeNick: cyril WARNING: No "Present: ... " found! Possibly Present: CL ChrisL DS Doug_Schepers IPcaller ISSUE Scribenick Tav aaaa cc cyril ed joined karl krit svg thorton trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: heycam Rik Dirk Vincent Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0050.html Found Date: 02 Feb 2012 Guessing minutes URL: http://www.w3.org/2012/02/02-svg-minutes.html People with action items: chris erik [End of scribe.perl<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> diagnostic output] The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 2 February 2012 21:40:31 UTC