SVG Working Group Teleconference -- 05 Sep 2013

<trackbot> Date: 05 September 2013

<scribe> scribenick: birtles

Review comments on css-variables

<heycam> 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> 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> 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> http://dev.w3.org/fxtf/filters/#feImageElement

<glenn_> random input from IRC: blink folks propose removing tref functionality; 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 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> 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> 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 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?

- DRAFT -

SVG Working Group Teleconference

05 Sep 2013

Attendees

Contents

Review comments on css-variables

Replacing feImage's xlink:href with href

Summary of Action Items

Scribe.perl diagnostic output