- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 5 Sep 2013 14:40:12 -0700 (PDT)
- To: www-svg@w3.org
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:40 UTC