See also: IRC log
<trackbot> Date: 02 February 2012
<scribe> scribe: Cyril
<scribe> Scribenick: cyril
<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
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#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
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
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 .
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
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
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].
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].
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].
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
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 .
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
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
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
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
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
<ChrisL> you could send the pointer to the wg
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/ 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 Default Present: Doug_Schepers, [IPcaller], ed, +33.9.53.77.aaaa, Tav, ChrisL, +29805aabb, cyril Present: Doug_Schepers [IPcaller] ed +33.9.53.77.aaaa Tav ChrisL +29805aabb cyril 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 diagnostic output]