SVG Working Group Teleconference -- 24 Jul 2014

<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: 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> 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

- DRAFT -

SVG Working Group Teleconference

24 Jul 2014

Attendees

Contents

x and y properties on SVGTextPositionElement

Where to add the new x,y,cx,cy,rx,ry,r CSS properties?

London F2F

Dev night in London

Summary of Action Items

Scribe.perl diagnostic output