W3C home > Mailing lists > Public > www-svg@w3.org > February 2012

minutes, February 2 2012 SVG WG Telcon

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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:50 GMT