W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2011

Minutes 01/12/2011 SVG WG telcon

From: Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>
Date: Thu, 1 Dec 2011 21:43:12 +0000
To: "SVG WG (public-svg-wg@w3.org)" <public-svg-wg@w3.org>
Message-ID: <54EF1DA3171CEE48AD59D7FF0DE043C3D5BCEE@exm01-wvp.cisra.canon.com.au>
Hi SVG fans,

Here are the minutes of today's call:
http://www.w3.org/2011/12/01-svg-minutes.html

and below as text:
W3C
- DRAFT -
SVG Working Group Teleconference
01 Dec 2011

Agenda

See also: IRC log
Attendees

Present
    heycam, +1.408.543.aaaa, Tav, Doug_Schepers, cyril, [IPcaller], ed, ericm, ChrisL
Regrets
Chair
    SV_MEETING_CHAIR
Scribe
    Cyril

Contents

    Topics
        F2F
        SVG 2 Requirements
        white space
        transforms on tspan elements
    Summary of Action Items

<trackbot> Date: 01 December 2011

"the conference is restricted at this time"

<scribe> scribe: Cyril

<scribe> scribeNick:Cyril
F2F

doug: would it be better to meet in California with the other WG ?
... there is a possibility that either Chris or I could attend the F2F
... there was a proposal by the WebApps chairs that the joint sessions in TPAC where useful but not sufficient
... we thought that a mini tpac would be valuable
... WebApps, DAP, SVG , CSS
... maye WebEvents
... the proposal is that it happens in California because of the people in California

cyril: when ?

ed: march was the proposed date
... it could be earlier because if we decide to skip the January F2F it would be too close to may

<heycam> yeah, having SVG meet in january, march and may just seemed a little too much

doug: heycam has mentionned that having both would be problematic

cyril: budget-wise ?

heycam: also time-wise

doug: there is also the matter of it being problematic to have so many meetings for W3C folks

cyril: meeting with other groups is good, but it wont' make us progress on SVG 2

doug: colocating doesn't mean having all meetings together
... things like Component Model is something that we can't do by ourselves
... it's cheaper for me to go to California

chris: same plus cheaper/shorter for me

<TabAtkins> fwiw, I have no preference on meeting locations. They're all the same for me.

doug: I suggest that we go ahead and have the Sydney F2F and that we propose to have a mini-tpac later in the year
... and that each group works towards milestones for the mini-tpac to be more efficient

<ChrisL> sounds like a request for a well-in-advance agenda

doug: for instance the Component model needs to be flushed-out to be more useful for SVG

cyril: and documents submitted in advance

doug: I don't want to substitute California with Bucharest

chris: me neither because of Libre Graphics and the AC meeting
... all meetings are back to back

<TabAtkins> Note that the CSSWG is also meeting in San Diego later in the year, if you want another colocation that's not Bucharest.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#F2F_Meeting_Information

ed: I updated the wiki with this

<ChrisL> lgm weds 2-sat 5

<ChrisL> css and svg sun 6 - sat qw

<ChrisL> ac sun 13-tue 15

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#Upcoming_F2Fs

doug: what would you think if I tried to set up an SVG mini event?
... a half day or evening workshop to get people to meet with us

chris: I don't know what is the community interested in Bucharest

doug: possibly too in Sydney

ed: what dates for Sydney

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012

hecyam: vincent would prefer a 3 day meeting
... monday to friday
... I think 4 days sound like a more reasonnable compromise

chris: tuesday to friday

ed: I'll (probably) be travelling on tuesday

cyril: wednesday to saturday

heycam: i have to be in melbourne on monday, I need a bit of time on the weekend to prepare

doug: the event could be also an evening thing

heycam: as long as people have prepared before the F2F or they will be distracted

erik: the 11th to the 14th ?

RESOLUTION: the next F2F will be in Manly, 11-14/01/2012

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback
SVG 2 Requirements

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback#Use_CSS_.27white-space.27_instead_of_.27xml:space.27

heycam: what are our plans for publishing ?
... do we want to wait until the list is fully reviewed ?

chris: do we publish in the TR space ?
... a wiki is more useful than the TR space but the TR will be looked at by more people

doug: the editor's draft could be the wiki page

heycam: putting the document in good shape for the TR space will require some work
... is it a useful effort ?

<heycam> http://dev.w3.org/SVG/profiles/2.0/reqs/publish/

<heycam> a second pass doing prioritisation sounds like a good idea to me

ed: we will need a second pass on the reqs to prioritize

<heycam> I am concerned that making local decisions about including or not will let us end up with a long list of things we've included

<heycam> I thought the second pass for prioritisation would be a real time thing, like on a telcon.

tav: it'll take weeks to write

ed: yes

<heycam> And obviously the prose writing would be something to do offline.

<heycam> So I'm not sure we could do it at the same time.

doug: I don't think that we need to go into further details in TR than on the wiki

chris: people who have looked at the requirements deeply will probably understand but outsiders will need text to understand the reqs (on the wiki or in the TR space)

doug: I like the idea of farming it out

cyril: on the wiki first

doug: yes

chris: yes

heycam: the proposal is that everyone expands on the wiki each requirements with a paragraph

chris: what about those that we have rejected

tav: it is useful to have it

chris: having the rationale is useful
... I'm suggesting that we update the current wiki page

doug: maybe instead of publishing in the TR space, we make a link to the Wiki page

<scribe> ACTION: heycam to copy text from the current reqs document and add placeholders for people to fill in [recorded in http://www.w3.org/2011/12/01-svg-minutes.html#action01]

<trackbot> Created ACTION-3179 - Copy text from the current reqs document and add placeholders for people to fill in [on Cameron McCormack - due 2011-12-08].
white space

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback#Use_CSS_.27white-space.27_instead_of_.27xml:space.27

<ChrisL> we already decided this

doug: authoring tools will be shoving out the old xml thing

chris: I noticed the there is an effort in the Inkscape community to clean up the output
... they could remove xml thing

RESOLUTION: SVG 2 will deprecate the use of xml:space to affect layout and will use the CSS white-space property

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback#Allow_.40transform_to_apply_to_.3Ctspan.3E_elements
transforms on tspan elements

cyril: it's linked to http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback#Consider_adding_transform.3D.22.22_to_.3Csvg.3E

chris: I don't think adding transform on every element makes sense (e.g gradient stop)

tav: what happens if you transform a tspan to the next tspan

doug: the next tspan wouldn't be affected

chris: unlike dx and dy,
... we should be careful about making the difference clear

doug: I think a transform should not affect things like dx, dy

<Tav> I can't call in...

tav trying connecting with the regular code

<Tav> o

<ChrisL> i'm in 7841

ed: I agree, transform should not affect text like dx and dy, taking up space and so on, it's purely a visual effect

heycam: the transform could apply after the text layout has been applied

chris: aaa tspan bbb tspan ccc

<heycam> <text>aa<tspan>bb</tspan>cc</text>

chris: if the tspan had a transform, it would not affect the position of cc
... we need to think about nested tspans with transforms

tav: do we have use cases for that ?

"<tspan> doesn't seem to apply the effects of a transform attribute. Doing so would make it easier to keep passages of text together for readability/searchability while still adjusting the position of style effects."

<ChrisL> yes but what is it for?

doug: I'm happy with Chris's suggestion

<ChrisL> is it for animating,so text jiggles around?

cyril: doesn't this complexify the implementation: two passes ?

<ChrisL> tspan:hover {transform: translate(10,10) }

tav: I'd be happy to add it if I had one useful example

<ChrisL> elusive text

<ed> a scale transform would be more useful

doug: when you are editing text

chris: the major use cases could be in dynamic
... you don't want it to affect the other text
... we should be sure it adds value before pushing it forward

heycam: the cost for us will not be extremely hard

doug: we should have a model for getting the computed geometry
... the computed style is the style while all the changes have been made
... the analog of that would be the geometry aside all the transforms applied to it

cyril: we need to explain about bounding boxes, glyph data (text api)

<ChrisL> how does this affect text ona path?

doug: what about skew, does it apply ?

ed: doug had a point that it could be nice to have a consistent to be able to specify transforms everywhere
... but I'm not sure it's worth the cost

heycam: the transform on the text is a transform on the whole text
... if you could a DOM method on a text element on some of the children

<heycam> so at the moment with <text transform="...">abc<tspan>...</tspan></text> all the glyphs are within the same coordinate space

<ChrisL> do we also have transform on <a> inside text and if so, isn't this exactly the same as tspan?

<heycam> this proposal would change that, so we do need to decide how that affects calling dom text positioning methods on the containing <text> element

<heycam> ChrisL, nice question, I wonder what implementations do there

heycam: I'm slightly in favor of adding it

<ed> data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><text y="40"><a transform="rotate(25)">link</a> outside link</text></svg>

<ChrisL> data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><text y="40"><tspan transform="rotate(25)">link</tspan> outside link</text></svg>

<ChrisL> ok so we should bring tspan into line with a here

RESOLUTION: SVG 2 will allow transforms on tspan

the next F2F will be in Manly, 11-14/01/2012

<ed> 9-11 May for css, 9 is fx day

RSSAgent, make minutes

I've edited the requirements page
Summary of Action Items
[NEW] ACTION: heycam to copy text from the current reqs document and add placeholders for people to fill in [recorded in http://www.w3.org/2011/12/01-svg-minutes.html#action01]
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/12/01 21:38:33 $
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/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/CC:/cyril:/
Succeeded: s/ed: I'll be travelling on tuesday/ed: I'll (probably) be travelling on tuesday/
Succeeded: s/RT/RT/
Succeeded: s/RT/TR/
Succeeded: s/should not affect dx and dy/should not affect text like dx and dy, taking up space and so on, it's purely a visual effect/
Found Scribe: Cyril
Inferring ScribeNick: cyril
Found ScribeNick: Cyril
Default Present: heycam, +1.408.543.aaaa, Tav, Doug_Schepers, cyril, [IPcaller], ed, ericm, ChrisL
Present: heycam +1.408.543.aaaa Tav Doug_Schepers cyril [IPcaller] ed ericm ChrisL
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0096.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 01 Dec 2011
Guessing minutes URL: http://www.w3.org/2011/12/01-svg-minutes.html
People with action items: heycam


[End of scribe.perl 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, 1 December 2011 21:43:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 December 2011 21:43:52 GMT