See also: IRC log
<trackbot> Date: 01 December 2011
"the conference is restricted at this time"
<scribe> scribe: Cyril
<scribe> scribeNick:Cyril
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
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].
<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
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
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]