See also: IRC log
<trackbot> Date: 16 January 2014
<scribe> scribenick: birtles
<scribe> scribe: birtles
ed: I raised the topic because I
recently filed a patch to remove animateColor from blink
... I don't think there's any reason to keep it around in SVG2
any longer since you can do everything animateColor can do with
animate anyway
krit: we kept it just because of
legacy reasons
... but we agree that there's no need for it
ed: the reason we decided to remove it from blink is that the usage is very low
krit: the problem with the usage
counters is we don't know how much SVG is used
... but we deprecated animateColor in SVG 1.1 so I have no
problem with removing it from SVG2
... but we will probably keep it around in WebKit, maybe for
the short-term
ed: so are we ok with removing it from SVG2?
shepazu: I guess so
... I understand that it is redundant
... but my only concern is existing content, but there's
probably very little content
krit: I think we deprecated in 1.1 not 1.1SE right?
ed: yes
krit: then we can probably remove it
s/1.1SE not 1.1/
heycam: what sort of usage numbers did you get?
ed: less than 1 usage per week? a lot less than 1% anyway
shepazu: but we don't know how
that compares to usage of SVG in general
... so it's really guess from intuition
... how much is animate used
ed: a lot since libraries use it to test for SMIL support
shepazu: how about
animateTransform?
... but I think we're going to remove it anyway
ed: it's very easy to work around by just aliasing to animate using javascript
heycam: have you already landed the patch to remove it?
ed: yes
shepazu: let's just remove
it
... we already deprecated it right?
ed: yes
shepazu: are we going to leave any mention of it?
heycam: I don't think we need to
shepazu: but we should mention it somewhere, like the changes appendix
heycam: we can mention it there
RESOLUTION: We will remove animateColor from SVG2 (and mention it in the changes appendix)
<krit> ACTION: erik and brian to figure out who gets the action [recorded in http://www.w3.org/2014/01/16-svg-minutes.html#action01]
<trackbot> Created ACTION-3557 - And brian to figure out who gets the action [on Erik Dahlström - due 2014-01-23].
<scribe> ACTION: Erik to remove animateColor from SVG2 [recorded in http://www.w3.org/2014/01/16-svg-minutes.html#action02]
<trackbot> Created ACTION-3558 - Remove animatecolor from svg2 [on Erik Dahlström - due 2014-01-23].
heycam: I got email from Michael
Neutze and David Dailey about updating the w3c page to refer to
the Graphical Web
... for this year's conference since we were still pointing to
last year's conference
... and they were also asking whether we had plans to meet at
the conference and if we want to present a panel session
... so do you want to present a session?
<heycam> http://graphicalweb.org/2014/
krit: do you mean a working group session like in previous years?
heycam: yes
krit: well then, why not?
... we should actually look at who will host the next
meetings
heycam: we should. For September
it's more open since we might not meet out in Winchester
... but for the next one...
krit: we (Adobe) are hosting for Seattle but not for the next one
(some discussion about arrangements for April)
heycam: so can we say we will do a panel session?
krit, shepazu: yes
heycam: Mozilla may be a host if we don't mind meeting in London at that time
shepazu: we could also have an
open day where people from the conference can come and meet
with people from the WG
... and attend the F2F
... David Storey from Microsoft are organizing a session
between CSS and SVG WG meetings, a hacker meetup
heycam: on the Tuesday night? Wednesday night?
shepazu: yes
... David asked me to present at the little meet-up. Anyone
else is also welcome to present
heycam: Tues or Wed?
shepazu: Wed I think
... you can present about anything SVG/CSS related
... keep it in mind. I'll do a quick SVG accessibility
talk
... the theme is "CSS and Web Graphics"
... they'd like a presentation on "What's coming up in
SVG2?"
... so if you can point me to any slidedecks on this
heycam: I'll try to find my slides from a talk several years ago
birtles: I could do the animation demo from SVGOpen if needed
<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2013/Agenda_proposals
krit: I'd like to add a few agenda requests
heycam: go ahead and add
them
... I'd just like to remind people to add items
... it's been quite a short time between F2Fs, maybe there's
not so much to add, but if we have remaining time we can use it
for spec editing
shepazu: I think I will have the demo version of the annotation thing going on the web audio spec so I could possibly demo that
krit: so you have things like
<mask>, <pattern> etc. and for the content you can
switch between objectBoundingBox or userSpaceOnUse
... for objectBoundingBox you can use numbers from 0..1 or
percentages but I'm not really sure what percentages actually
mean
heycam: my naive understanding was 100% = 1 but I guess that's not the case
krit: yes, it doesn't seem to
be
... I would interpret the spec text as percentages of the
viewport but I don't think that is a good idea
heycam: I think making them viewport-relative would be confusing
krit: I was hoping someone would know what browsers are actually doing?
<scribe> ACTION: Dirk to investigate what browsers actually do for percentage values for objectBoundingBox with pattern, mask etc. [recorded in http://www.w3.org/2014/01/16-svg-minutes.html#action03]
<trackbot> Created ACTION-3559 - Investigate what browsers actually do for percentage values for objectboundingbox with pattern, mask etc. [on Dirk Schulze - due 2014-01-23].
krit: I posted this question on the mailing list...
<heycam> http://www.w3.org/mid/7DADDAB2-1EE8-40D5-A697-472ECA7B4078@adobe.com
heycam: so this is percentages
within the content of the pattern etc.
... and it says they get resolved against the viewport
... and objectBoundingBox doesn't establish a new viewport
right?
krit: no they don't, but they can
heycam: from your email it looks
like something should change
... does anyone else have an opinion about whether it is a good
idea that percentages apply against the viewport if we defined
what that is?
... and which viewport would that be?
krit: that's the next item on the agenda
shepazu: should we deprecate symbol?
Tav: it's implemented and used in maps etc.
krit: it's not implemented correctly thought
shepazu: <symbol> is actually useless
krit: it has an implicit visibility:hidden
shepazu: but you don't need it
heycam: does <symbol> have the same sizing behavior as <svg>?
??: yes
krit: Illustrator exports
<symbol> so deprecate ok, but not removing
... we could add a note saying authors don't need to use it
shepazu: I suggest we define it
in terms of <svg>
... just sugar for <svg>
heycam: I wonder if there is
scope for improving the functionality of <symbol>
... if there are use cases surrounding re-using graphics
shepazu: let's add that to an agenda sometime
heycam: please it add it to the F2F agenda
krit: so it is quite clear that
in these cases that viewport is that of the referencing
element
... according to the spec
... but none of the browsers implementations do that
... the only implementations that do that are Opera (Presto),
Inkscape and Batik
heycam: what is the incorrect behaviour?
krit: if you have a path element
in one viewport and a pattern in the other
... the pattern should use the viewport of the path element for
resolving sizes like percentages
... but browsers take the viewport of the pattern (or mask
etc.) element instead
... which doesn't really make sense but that's what browsers
do: IE, Chrome, Firefox, Opera
heycam: I suspect what the spec says may be more useful
krit: it might be useful
... but reality is that none of the browsers are following the
spec but are still interoperable
... the browsers are aware of the bug (or at least Robert
Longson identified it in Firefox)
<krit> https://bugzilla.mozilla.org/show_bug.cgi?id=866655
krit: it is also known in
WebKit
... but it was too difficult to fix it
... not worth the effort
heycam: so are you suggesting we just spec what the browsers are currently doing?
Tav: I don't agree. If it's more useful to do it as currently specced then we should do that
heycam: yeah, I think I agree
krit: from the specification
point of view it doesn't matter since we have at least two
implementations of each alternative
... if we keep the current spec, it might take sometime before
browsers come into line
heycam: we could add tests to the suite for this
krit: I can do that
heycam: if you can construct an example where it is actually useful, that would help
krit: but when are percentages resolved relative to the viewport ever useful?
heycam: if you have a grid pattern and shapes that should be aligned with the grid pattern?
krit: I think you would use
absolute values in this case
... it's an edge case
<scribe> ACTION: Dirk to create a test case for the test suite covering percentage units resolved against the viewport of the referencing element [recorded in http://www.w3.org/2014/01/16-svg-minutes.html#action04]
<trackbot> Created ACTION-3560 - Create a test case for the test suite covering percentage units resolved against the viewport of the referencing element [on Dirk Schulze - due 2014-01-23].
<krit> http://www.w3.org/Graphics/SVG/WG/wiki/Agenda
krit: What affect has a reference
box (padding-box, content-box, border-box, margin-box) to a
basic shape in SVG i.e. clip-path: circle() margin-box?
... HTML has the concept of a content box
... what we would call the object bounding box
... then it has a padding box which we don't have in SVG
... then border box and margin box neither of which we have in
SVG
... we do have stroke however (similar to border box)
Tav: I had to look at this with
regards to text wrapping
... and in SVG I think we need separate values
krit: I'd rather avoid adding extra keywords
Tav: I think that's confusing from an author's point of view
krit: in any case we need to define what these keywords mean
Tav: there's the viewport, bounding box (fill + stroke versions)
heycam: these keywords change how
the values in the property get interpreted
... so if you use one of these basic-shape functions in the
value these keywords change how they get interpreted
... I think it will be common that people will want to do
things relative to the stroke bounding box of the shapes
... so if we were to line it up with these keywords then
border-box seems like a possible candidate but I think
border-box has a very specific meaning
krit: anyway I just wanted to introduce the issue, we can continue on the mailing list
<Tav> I got cut off and the conference is now restricted....
heycam: no telcon next week since
some people will be travelling by then
... next time we meet is the F2F in Seattle
... if you have outstanding issues on the mailing list, please
add them to the agenda for the F2F
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/1.1SE not 1.1// Succeeded: s/get rid of it/remove it/ Succeeded: s/you email/your email/ Found ScribeNick: birtles Found Scribe: birtles Inferring ScribeNick: birtles WARNING: No "Present: ... " found! Possibly Present: Doug_Schepers IPcaller P2 Rich_Schwerdtfeger Tav birtles cabanier ed glenn heycam https joined krit richardschwerdtfeger scribenick shepazu stakagi svg trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0012.html Found Date: 16 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/16-svg-minutes.html People with action items: brian dirk erik[End of scribe.perl diagnostic output]