W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2014

Minutes, 24 July 2014 SVG WG telcon

From: Brian Birtles <bbirtles@mozilla.com>
Date: Thu, 24 Jul 2014 07:06:47 -0700 (PDT)
To: www-svg@w3.org
Message-ID: <1553637554.8415288.1406210807577.JavaMail.zimbra@mozilla.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:19 UTC