- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 24 Jul 2014 07:06:47 -0700 (PDT)
- To: www-svg@w3.org
Minutes:
http://www.w3.org/2014/07/24-svg-minutes.html
as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
24 Jul 2014
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0018.html
See also: [3]IRC log
[3] http://www.w3.org/2014/07/24-svg-irc
Attendees
Present
krit, [IPcaller], birtles, Smailus, heycam, stakagi,
Doug_Schepers, Tav, ChrisL, nikos__
Regrets
Chair
Cameron
Scribe
birtles
Contents
* [4]Topics
1. [5]x and y properties on SVGTextPositionElement
2. [6]Where to add the new x,y,cx,cy,rx,ry,r CSS
properties?
3. [7]London F2F
4. [8]Dev night in London
* [9]Summary of Action Items
__________________________________________________________
<trackbot> Date: 24 July 2014
Zakim who is on the call?
<scribe> scribe: birtles
<scribe> scribenick: birtles
x and y properties on SVGTextPositionElement
s/SVGTextPoitionElement/SVGTestPositioningElement/
krit: the issue we had in the past was that x/y on most
elements just have one value
... but for <text> and <tspan> it is a list of length values
... question is: should we really try to make x attribute of
elements be stylable as well
... or just attributes
<krit> <text x=“0 10 20 30”> vs <rect x=“20" />
krit: should we allow them to take a list of values?
... we could still allow x/y to be properties
... but not allow them to take a list of values
... if x is a property, then because <text> etc. already takes
a list of lengths, the property would also have to take a list
... and we'd have to define what to do if a list was set on
other elements
... my proposal is to make x/y properties just accept one value
... and to have x/y on <text> *not* be presentation attributes,
just attributes
<ChrisL> zero specificity
heycam: if you have x/y applied to text as a property and you
also set x/y on the <text> what happens?
... if the attribute is *not* a presentation attribute how do
you define the processing there
krit: one possibility is that we create an auto value for this
purpose
... if the computed value is still auto then you use the value
of the x/y attributes
ChrisL: that would work but it's adding yet another way of how
properties/attributes combine
... let's step back for a minute
... we have a bunch of attributes that are per-element
... and that was fine since we could animate attributes or
properties
... but now we're doing this in order to make these things
animatable with CSS animations that only work with properties
... but is this still necessary now we have a model that covers
both?
... this seems to introduce a lot of clashes/complexity
krit: if you look at twitter, a lot of things are animated with
CSS that could be animated with SVG animation
... so people would need to learn SVG animation in order to
animate properties
shepazu: the other argument (aside from animation) is that more
people are familiar with CSS than SVG
... and they feel more comfortable using CSS than SVG
ChrisL: understood, but the set of things they are using were
designed from the start to be attributes
... not properties
... properties are designed to be general and now we're taking
attributes that are designed to be more specific and making
them properties
krit: most attributes we can turn to properties, but x/y are
different because they are used differently on <text> elements
ChrisL: another way to do that--if we're going to break things,
we can choose what we break
... we could break the name mapping, e.g. call the text x/y,
tx/ty
krit: I don't think we need to break anything
... (by turning attributes into properties)
... based on experience in Blink/WebKit
Tav: is that the case already in Blink/WebKit
krit: there are some exceptions in Blink, but mostly
shepazu: some authoring tools use multiple values in x/y, but
I've never seen code besides that using that functionality
krit: for <text> it's quite common
... so we can't break it
shepazu: is it that common?
krit: not for manual editing, but for authoring tools it's
common
shepazu: I think most SVG is actually generated by d3
... and d3 doesn't use x/y in that way
Tav: we use x/y like that in Inkscape
shepazu: I don't think this proposal breaks this though right?
krit: no, it doesn't
shepazu: we already have a distinction between attributes and
properties, e.g. regarding units
krit: actually in CSS3 syntax, presentation attributes are
allowed to omit units
ChrisL: a presentation attribute is one syntactic form of a
property
... I see this mixed up a lot
... code which used to spit out PDF tends to use x/y on every
character in the string
... since internally that's how they do tracking/kerning/etc.
... each character has its own positioning data
... it's very fragile unless you have a downloadable font
... it's also a bit of a hack now that fonts have better
kerning thanks to OpenType features
<ChrisL> not in hand authored content though
ChrisL: I agree with Dirk that you see this usage of x/y alot
shepazu: I agree, but I don't think that what Dirk is proposing
breaks that
krit: it doesn't
... x/y for <tspan> definitely has a different syntax that for
every other element
... <text> is special, how do we deal with it?
... one possibility is we make x/y a list for every element
... one is that we say x/y for <text> is not a presentation
attribute
... one way is to introduce "auto" as I suggested before
... but as ChrisL mentions, it does complicate the interaction
of these things
heycam: none stand out to me as a clear winner
Tav: the third seems best
<ChrisL> web animation makes this less necessary, yes
Tav: although I tend to agree with ChrisL that this is not
really necessary for animation
... I don't think we need to handle lists
heycam: all seem to have downsides
krit: I can put forward all three options on the mailing list
... and we can try to get a resolution next week
heycam: I get the feeling from ChrisL and Tav's comments that
they are less enthusiastic about the whole
attribute-to-presentation enterprise
Tav: it's not a strong feeling, I won't object to it
ChrisL: I won't object either, but I think we're doing this for
the wrong reasons, it just moves the pain around
heycam: I tend to agree but I did see web developers doing
responsive SVG and coming up against obstacles because SVG's
geometry attributes couldn't be used
krit: from a code point of view it actually makes the code
simpler
Tav: I thought you were initially against making attributes
into presentation attributes
krit: I'm not sure I was
heycam: in Gecko, every element pays storage price for
additional properties even if they don't apply to that element
... we do group properties together
... so if you don't set any of those properties it's only one
pointer
... but it does mean that some memory is used up for every
element
krit: I think the cost is still not that big
heycam: maybe, but if the document is large enough, it might
not have that much effect
... but then the CSSWG doesn't seem to be concerned about
adding new properties so maybe it's not such a big deal
... I think width/height are easy to convert because those
properties already exist
krit: from a memory/implementation point-of-view?
heycam: more from an aesthetics/spec point of view
... those things already exist so it's an easy decision to make
... for the rest, they're new properties, there are name
mismatches etc.
krit: the other properties I was thinking about are r/cx/cy
etc.
... these don't have conflicts except dx/dy with regards to
<rect>/<text>
heycam: there are two classes of issues
... are there real conflicts across elements
... and are there conflicts with existing properties that mean
we can use the same name
... with this limited set of properties we don't run into the
second class of issues
... so it's of lesser concern, although the naming is still
unusual
... having thought of the options you presented before, I think
I agree with Tav
... that is, use the new property value
... to decide between using the computed style or the attribute
value
krit: that sounds good to me
heycam: does anyone else want to take this to the list?
ChrisL: I'd like to see this summarised so I can be sure
heycam: krit can you please summarise and send to the list?
krit: sure
Where to add the new x,y,cx,cy,rx,ry,r CSS properties?
krit: we have different sections in the SVG spec, where do I
add them?
heycam: at the moment we have an obvious section for defining
the attributes that apply to individual elements
krit: and we still need that?
heycam: yes, I think that makes sense since that's where people
will look
krit: width/height we still need to define as presentation
attributes on the element
ChrisL: I think you need a new section where you define all
these properties
... and then you need the existing sections
... and you need to link from them to the new section
krit: if we do this, won't that change the numbering?
ChrisL: are people quoting sections by numbers?
heycam: I don't think you should worry about changing the
numbering
krit: so you're fine with adding a new section?
heycam: what would be in that new section?
krit: layout properties
heycam: perhaps a section in the styling chapter that
summarises all of the geometry properties
... i.e. refers to width/height in CSS then defines the other
ones
... then in the other sections referring to that
krit: I would agree with that
heycam: you might have to think about how to present that
... since we only put attributes in the little grey box at the
moment
... I'm sure you can come up with something
krit: sure
s/suyre/sure/
heycam: did you say you have patches for doing this already?
krit: yes
London F2F
Tav: will there be a join meeting with CSSWG at TPAC?
heycam: I think so
<heycam>
[10]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Age
nda_proposals
[10] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda_proposals
ChrisL: I believe we will be able to have a join meeting with
CSSWG in Sydney at the start of 2015
krit: I don't think TPAC is a good time for a joint meeting
heycam: normally we encroach on their time, but I think we
should try to have a joint meeting at TPAC and Sydney
... as ChrisL mentioned, please think about agenda items for
the London F2F
Dev night in London
shepazu: this came about from a web platform docs meeting
... apparently there are a lot of design agencies in London
that Adobe has connections with and many of them don't know
much about SVG
... but they're good at making assets etc.
... so if people are going to be in London for SVG, we should
try and connect
... it occurred to me that there will be a lot of people in
London who are designers and might be interested in SVG but
don't know about the Graphical Web
<ChrisL> +1
shepazu: if we wanted to have a dev night, perhaps hosted by
Mozilla, similar to how we've done before
... we could have a few presentations
... ChrisL could do one on fonts etc.
<ChrisL> svg+
shepazu: it doesn't have to be just SVG
... London has quite a lot of font activity
ChrisL: yes, I would be interested
shepazu: anyone else interested in doing a talk?
... perhaps 3 presentations, ~20min each = 1hr, then an open
session
<ChrisL> wish some other browsers besides firefoxc would
implement the CSS3 Font opentype stuff that my talk is about
shepazu: would be good to have someone from W3C
ChrisL: or even getting a local designer coming along
... so it's not just us talking
... we should be open to that
shepazu: if we scoped it to people to doing stuff with SVG
... that might be good
<ChrisL> +1 to svg lightning talks
shepazu: we could have an open mic/lightning talk session
around what people are doing with SVG
... I'd like you to think about it
<ChrisL> we need to announce asap or it will be too late
shepazu: would be good to hear from implementors
... I'd like to get names to put on the bill other than just
W3C folks
<ChrisL> I have tow existing svg-and-font talks, one on css3
fonts and one on SVG Glyphs in OpenType
<nikos__> might be premature, but wouldn't mind talking about
diffusion curves and getting input from artists
<ChrisL> its not like its the capital or anything
shepazu: if anyone is interested in doing a presentation, let
me know
krit: might be interested
<nikos__> but yeh I'd be happy to talk a little about diffusion
curves. I'm keen to hear from people how they might use them
krit: to talk about SVG and photoshop
<ChrisL> who is hosting? is it at moz london?
heycam: did you have a date in mind?
<nikos__> Tuesday night we'll need to head to Winchester
<ChrisL> friday
<ChrisL> monday is a holiday
shepazu: probably Friday is best
... heycam can you check if Mozilla can host?
heycam: sure
<krit> Simon
<ChrisL> simon sapin
RRSAgent: make minutes public
RRSAgent: make minutes
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [11]scribe.perl version
1.138 ([12]CVS log)
$Date: 2014-07-24 14:02:06 $
__________________________________________________________
[11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[12] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [13]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
FAILED: s/SVGTextPoitionElement/SVGTestPositioningElement/
Succeeded: s/suyre/sure/
FAILED: s/suyre/sure/
Succeeded: s/mox/moz/
Found Scribe: birtles
Inferring ScribeNick: birtles
Found ScribeNick: birtles
Default Present: krit, [IPcaller], birtles, Smailus, heycam, stakagi, Do
ug_Schepers, Tav, ChrisL, nikos__
Present: krit [IPcaller] birtles Smailus heycam stakagi Doug_Schepers Ta
v ChrisL nikos__
Agenda: [14]http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep
/0018.html
Found Date: 24 Jul 2014
Guessing minutes URL: [15]http://www.w3.org/2014/07/24-svg-minutes.html
People with action items:
[14] http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0018.html
[15] http://www.w3.org/2014/07/24-svg-minutes.html
[End of [16]scribe.perl diagnostic output]
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 24 July 2014 14:07:24 UTC