Re: agenda, 16 January 2014 SVG WG telcon

Minutes from the 16 January 2014 meeting are below.

http://www.w3.org/2014/01/16-svg-minutes.html

   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

16 Jan 2014

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0012.html

   See also: [3]IRC log

      [3] http://www.w3.org/2014/01/16-svg-irc

Attendees

   Present
   Regrets
   Chair
          Cameron

   Scribe
          birtles

Contents

     * [4]Topics
         1. [5]removing animateColor from SVG2
         2. [6]Panel session at Graphical Web 2014
         3. [7]Agenda requests for Seattle F2F
         4. [8]percentage on objectBoundingBox relative to the
            bounding box of the object?
         5. [9]Which viewport to use when SVG resource (<pattern>,
            <mask>, ...) and affected element are in two different
            viewports
         6. [10]Background reference boxes in SVG
     * [11]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 16 January 2014

   <scribe> scribenick: birtles

   <scribe> scribe: birtles

removing animateColor from SVG2

   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
   [12]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
   [13]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].

Panel session at Graphical Web 2014

   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> [14]http://graphicalweb.org/2014/

     [14] 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

Agenda requests for Seattle F2F

   <heycam>
   [15]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2013/Age
   nda_proposals

     [15] 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

percentage on objectBoundingBox relative to the bounding box of the
object?

   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
   [16]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>
   [17]http://www.w3.org/mid/7DADDAB2-1EE8-40D5-A697-472ECA7B4078@
   adobe.com

     [17] 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

Which viewport to use when SVG resource (<pattern>, <mask>, ...) and
affected element are in two different viewports

   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> [18]https://bugzilla.mozilla.org/show_bug.cgi?id=866655

     [18] 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
   [19]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> [20]http://www.w3.org/Graphics/SVG/WG/wiki/Agenda

     [20] http://www.w3.org/Graphics/SVG/WG/wiki/Agenda

Background reference boxes in SVG

   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

Summary of Action Items

   [NEW] ACTION: Dirk to create a test case for the test suite
   covering percentage units resolved against the viewport of the
   referencing element [recorded in
   [21]http://www.w3.org/2014/01/16-svg-minutes.html#action04]
   [NEW] ACTION: Dirk to investigate what browsers actually do for
   percentage values for objectBoundingBox with pattern, mask etc.
   [recorded in
   [22]http://www.w3.org/2014/01/16-svg-minutes.html#action03]
   [NEW] ACTION: erik and brian to figure out who gets the action
   [recorded in
   [23]http://www.w3.org/2014/01/16-svg-minutes.html#action01]
   [NEW] ACTION: Erik to remove animateColor from SVG2 [recorded
   in [24]http://www.w3.org/2014/01/16-svg-minutes.html#action02]

   [End of minutes]
     __________________________________________________________

Received on Thursday, 16 January 2014 23:16:13 UTC