- 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