Minutes, 5 September 2013 SVG WG telcon

Minutes:

       http://www.w3.org/2013/09/05-svg-minutes.html

And as text below:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

05 Sep 2013

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0080.html

   See also: [3]IRC log

      [3] http://www.w3.org/2013/09/05-svg-irc

Attendees

   Present
          +1.425.373.aaaa, luc, birtles, Doug_Schepers, Rich,
          krit, heycam, ed, Tav, nikos

   Regrets
   Chair
          Cameron

   Scribe
          birtles

Contents

     * [4]Topics
         1. [5]Review comments on css-variables
         2. [6]Replacing feImage's xlink:href with href
     * [7]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 05 September 2013

   <scribe> scribenick: birtles

Review comments on css-variables

   <heycam>
   [8]http://www.w3.org/Graphics/SVG/WG/wiki/Review_comments_on_cs
   s-variables-1_2013-08-29

      [8] http://www.w3.org/Graphics/SVG/WG/wiki/Review_comments_on_css-variables-1_2013-08-29

   heycam: I put together some comments ^
   ... technically comments were due yesterday but Tab said today
   is fine
   ... there wasn't anything we really needed to point out
   ... I wanted to bring attention to how variables in
   SVG-in-OpenType
   ... or at least what's currently in the document
   ... so that's just declaring a UA stylesheet with variable
   names to reflect color palette stuff
   ... I doubt it's a misuse of variables but I just wanted to
   bring it up
   ... secondly, I think it would be good to be able to animate
   the variables
   ... you can't do that yet but I think it's on track for a
   subsequent revision of the spec
   ... but that's all for now

   shepazu: I'll review it shortly but I'm particularly interested
   in being able to pass in parameters
   ... I'm not sure you can do that with css variables
   ... for example, css icon fonts

   <TabAtkins> As shep and I discussed last year, I think it's
   completely reasonable to define a way for variables to be
   initialized from outside data. That way we can completely
   eclipse the functionality of SVG Parameters.

   <shepazu> [9]http://css-tricks.com/examples/IconFont/

      [9] http://css-tricks.com/examples/IconFont/

   shepazu: see the link above ^
   ... say I want to style a button with an icon next to it
   ... I want to be able to position it next to the text
   ... I want to be able to change the color
   ... I want to be able to scale it
   ... based on the font-size
   ... but I can't shadow it like they do on this page
   ... so it's like the problem we have with markers
   ... people want to be able to define a single arrow head and
   use it on any color line and have that color follow through
   ... so while I've been experimenting with SVG icons
   ... I could do a couple of things I wanted to do
   ... I couldn't change the color
   ... I couldn't reference an SVG fragment in the page
   ... I couldn't pass in the color I wanted the SVG to use
   ... which might be the fill or the stroke
   ... this seems like an obvious use case (esp. with retina
   displays)
   ... with CSS variables I would like to have some way of passing
   in a color value or something else
   ... to make a given instance of the SVG take on that style etc.
   ... does that make sense?
   ... can you do that with CSS variables today?

   heycam: I'm not sure what level of detail of comments you want
   to send about that
   ... we could just tack on another bullet point about that
   unless you want to add more detail?

   shepazu: how about "we'd like to be able to send color values
   into an SVG file so they can be used in a similar way to icon
   fonts" + a link to the icon fonts page

   birtles: does context-fill / context-stroke help?

   heycam: I don't think that works for completely separate
   documents
   ... unless we define some mechanism for that
   ... but I think the general case of being able to pass in
   arbitrary values is still worth saving

   shepazu: yes, sometimes you don't know if it's the fill or
   stroke you want to change

   <richardschwerdtfeger> ok. dropping.

   <richardschwerdtfeger> thanks

   shepazu: and you might have multiple objects with multiple
   colors with a simple replace fill / stroke doesn't work

   birtles: so color by number, do we have that for
   SVG-in-OpenType

   heycam: at TypeCon they were having a bit of a discussion about
   that
   ... microsoft brought up a proposal had a facility to have
   palettes within a font
   ... so we've taken that idea on board for SVG-in-opentype to
   have both predefined palettes and also to specify from the
   outside

   <Tav>
   [10]http://tavmjong.free.fr/SVG/BUTTON_TEST/button_test.xhtml

     [10] http://tavmjong.free.fr/SVG/BUTTON_TEST/button_test.xhtml

   Tav: there's probably more to it than just color: stroke width,
   dash-array

   heycam: I think this proposal would allow you to specify
   arbitary paints from the outside
   ... but we haven't really considered other properties

   Tav: the link above is my attempts to re-use a button

   heycam: whatever mechanism we come up with passing variables
   down into a document could be used for fonts as well

   <shepazu> TabAtkins, yes, agreed, just need to sort the details

   heycam: if people are happy with me adding a sentence to my
   review comments about that ability and pointing to the icon
   fonts and saying that's something we wanted to solve with
   reference to parameters then I can send that along today

Replacing feImage's xlink:href with href

   <krit> [11]http://dev.w3.org/fxtf/filters/#feImageElement

     [11] http://dev.w3.org/fxtf/filters/#feImageElement

   <glenn_> random input from IRC: blink folks propose removing
   tref functionality;
   [12]https://groups.google.com/a/chromium.org/forum/#!topic/blin
   k-dev/vnpLfBOsZf4

     [12] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vnpLfBOsZf4

   <glenn_> svgers might wish to comment on that thread

   krit: the question is: do we want to replace href with
   xlink:href? deprecate xlink:href?

   heycam: I think we want to do what we're doing elsewhere
   (although it's not in the spec yet)
   ... which is to allow both so that existing content work but
   when both are specified href (without namespace) wins

   krit: so do we deprecate xlink:href?

   shepazu: what is the proposal?

   krit: we keep both but deprecate the one with the prefix

   shepazu: we wrote up proposals in the past and went through the
   use cases... is this different?

   <nikos> See
   [13]http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSe
   p/0211.html

     [13] http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0211.html

   krit: no

   heycam: you should do what we resolved there

   nikos: I think we talked about it at rigi, see the link above

   krit: do we fully support xlink:href or do we want to deprecate
   it?

   shepazu: I think we should deprecate it but user agents still
   need to support it
   ... users shouldn't do it
   ... we have a resolution

   <shepazu> [14]http://www.w3.org/Graphics/SVG/WG/wiki/Href

     [14] http://www.w3.org/Graphics/SVG/WG/wiki/Href

   shepazu: see the above ^
   ... we need to transition away from xlink:href
   ... I think you can already drop it in IE9
   ... so, from a deployment point of view, if it's already in IE
   the timeframe before it's possible to drop xlink:href is not so
   long

   heycam: I've checked and you don't need xlink in IE10 at least

   shepazu: if we can get the other browsers to do barename href
   soon then I'd be comfortable with making the authoring
   requirement for not using xlink:href a SHOULD
   ... my proposal is to deprecate xlink across the board
   ... say browsers MUST support it
   ... and authors SHOULD NOT use it
   ... and decide which takes precedent

   birtles: should barename href should win

   heycam: that seems to be what happens in IE
   ... in the previous attribute we decided to allow the src
   attribute for script etc.
   ... do we want that on feImage
   ... and as well as or instead of href?

   shepazu: in some browsers image is replaced with img and if you
   give it a src if follows that
   ... and then src wins over href

   heycam: someone came up with a way for doing fallback that
   browsers that don't do svg
   ... using the fact that an element that is named image is
   interpreted differently in html / svg

   <heycam> [15]http://lynn.ru/examples/svg/en.html

     [15] http://lynn.ru/examples/svg/en.html

   shepazu: so does that mean we should or should not replace href
   with src?
   ... we should support src which takes precedence over href...

   heycam: it would have to be the opposite in order for this
   technique to work

   shepazu: yes, that's right
   ... then if someone wants to use this as a fallback they can
   ... since src will be overwritten in newer browsers
   ... so href would have to win over src

   heycam: but I don't know how many people are using this

   shepazu: but it would help people get over the pain of using
   SVG
   ... let people have their fallback

   heycam: anyone else have any views here?

   birtles: so href > xlink:href > src ?

   shepazu: I think we want people to use href
   ... we are introducing href because it will be easier and it
   will be the default
   ... we are allowing xlink:href for legacy content
   ... and we are allowing src not as the preferred option but as
   a fallback for browsers that don't support SVG

   krit: what about feImage?

   shepazu: it doesn't matter

   heycam: prior to this article about fallback
   ... we were going to encourage authors to use src
   ... and make it the primary option

   shepazu: I agree with that rationale
   ... however I think this is new information
   ... that shows that we are suggesting a change in behavior
   which I think is a bad idea
   ... and it gets rid of a clever fallback hack
   ... that we get for free

   krit: I'm not sure this technique is actually useful
   ... who is actually putting an image in an inline SVG like
   this?

   shepazu: if you want to make a fallback image for browsers that
   don't support SVG

   krit: but this is only a fallback for really old versions of IE
   ... especially by the time we publish SVG2

   heycam: the whole point of this technique is to support either
   a PNG or an SVG image depending on whether the browser supports
   SVG or not

   (discussion about this fallback technique and how useful it is)

   shepazu: let's take this to email

   heycam: I just want to bring up the ordering of attributes
   ... I think we can still support this technique whilst still
   suggesting that src is the way forward
   ... there's nothing in this technique that requires that
   authors prefer one attribute or the other

   shepazu: as I recall, we liked the idea of using src
   ... but there were also problems with it?

   heycam: the resolution indicates src, but doesn't specify an
   ordering

   shepazu: we need to sort out the different use cases based on a
   matrix of different cases of browser support
   ... by the way, there's a lot of content made for ASV that
   doesn't work in current browsers since current browsers require
   the SVG namespace declaration
   ... if we dropped that requirement we would enable a bunch of
   existing content

   heycam: anyone want to take the action for looking at href etc.
   and emailing the list?
   ... I'll do it

   <scribe> ACTION: Cameron to investigate the xlink:href, href,
   and src ordering in terms of fallback behavior and mail the
   list [recorded in
   [16]http://www.w3.org/2013/09/05-svg-minutes.html#action01]

   <trackbot> Created ACTION-3523 - Investigate the xlink:href,
   href, and src ordering in terms of fallback behavior and mail
   the list [on Cameron McCormack - due 2013-09-12].

   anyone able to help send the minutes?

Summary of Action Items

   [NEW] ACTION: Cameron to investigate the xlink:href, href, and
   src ordering in terms of fallback behavior and mail the list
   [recorded in
   [17]http://www.w3.org/2013/09/05-svg-minutes.html#action01]

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [18]scribe.perl version
    1.138 ([19]CVS log)
    $Date: 2013-09-05 21:34:36 $
     __________________________________________________________

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] 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 [20]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

     [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/heycam: I think/shepazu: I think/
Found ScribeNick: birtles
Inferring Scribes: birtles
Default Present: +1.425.373.aaaa, luc, birtles, Doug_Schepers, Rich, kri
t, heycam, ed, Tav, nikos
Present: +1.425.373.aaaa luc birtles Doug_Schepers Rich krit heycam ed T
av nikos
Agenda: [21]http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep
/0080.html
Found Date: 05 Sep 2013
Guessing minutes URL: [22]http://www.w3.org/2013/09/05-svg-minutes.html
People with action items: cameron

     [21] http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0080.html
     [22] http://www.w3.org/2013/09/05-svg-minutes.html


   End of [23]scribe.perl diagnostic output]

     [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 5 September 2013 21:40:46 UTC