W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2012

minutes, 20 December 2012 SVG WG telcon

From: Rik Cabanier <cabanier@adobe.com>
Date: Thu, 20 Dec 2012 14:45:36 -0800
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <83F37C1A4497B54589EAEDC750D03A941E849FD9FE@nambx09.corp.adobe.com>


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

                               - DRAFT -

                    SVG Working Group Teleconference

20 Dec 2012


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0063.html

   See also: [3]IRC log

      [3] http://www.w3.org/2012/12/20-svg-irc


          +1.415.308.aaaa, ed, birtles, cabanier, krit, heycam,
          Doug_Schepers, nikos, Tav, Rich


         ed, cabanier


     * [4]Topics
         1. [5]mask-type
         2. [6]filter effects feedback
         3. [7]SVG test suite
         4. [8]CSS animation of SVG attributes
         5. [9]SVG font in SVG 2
         6. [10]confs
         7. [11]SVG at ISO
     * [12]Summary of Action Items

   <trackbot> Date: 20 December 2012

   <ed> scribeNick: ed


   ds: we have mask-* properties, would like to add... ...
   shorthand function


     [13] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property

   cm: would apply to mask element, wheterh the mask content
   should be interpreted as ...

   <cabanier> scribenick: cabanier

   heycam: it is a bit confusing if masktype applies to the mask

   ... and the things that get masked

   ... what the mask is describing depending on what it's applied to

  krit: I would like to have in the short-hand

   ... masktype should be consistent

   ,,, the problem is that we have to special case the mask-type

   ... this means that we can't mask a mask

   ... in the future

   birtles: can't we rename mask-type to mask-source-type?

   heycam: so make the one from the shorthand mask-source-type

   ... or we can rename the other one

   krit: that sounds fine with me as well. should we try to make
   it shorter?

   heycam: have the longer one for the one that is used in the

   everyone: that sounds good

   resolution: we'll have mask-source-type property as part of the
   shorthand and leave mask-type property as the one that just
   applies to the mask element

filter effects feedback


     [14] http://lists.w3.org/Archives/Public/www-svg/2012Dec/0059.html

   heycam: we should have someone to review his comments

   krit: I didn't read it yet

   heycam: are these new features?

   krit: I think they're additions

   nikos: angle for dropshadow seems useful

   <scribe> ACTION: Dirk to review filter effects proposal
   [recorded in

   <trackbot> Created ACTION-3404 - Review filter effects proposal
   [on Dirk Schulze - due 2012-12-27].

SVG test suite

   heycam: we need a plan so we can migrate the exisitng tests
   into the new test suite

   ...and make sure that they're still valid and in the right format

   ... for a lot of them, we can just split them out

   ... and make them reftests. The problem is creating the reference

   krit: some things like masking is hard to test as a reftest

   heycam: yeah. maybe we can do simple paths with raster images

   ...or we can a couple of manually inspected test for these things

   ... with reftests, there is always the problem that very basic
   primitives are hard to write tests for

   ... maybe we should have visually inspection

   krit: yes, at some point we will have to do that

   heycam: yes

   krit: We should have a day on our F2F to talk just about

   ... testing is very important for the specification

   heycam: for our exisitng test, would people object that they
   are assigned a block of test?

   ...not for detailed review, but just to check

   ... and then at a later date, write reftests for those

   heycam: we can get started on that while we're in Sydney

   krit: yes

   ... first review and then ref tests

   heycam: I will look into what's needed to make the format right

   <scribe> ACTION: heycam to allocate chunks of the test suite
   for different people to review [recorded in

   <trackbot> Created ACTION-3405 - Allocate chunks of the test
   suite for different people to review [on Cameron McCormack -
   due 2012-12-27].

   heycam: I would like to know where to put test in the

   krit: the CSS WG just puts everyting in a folder

   ... with support for testharnass.js

   ... you write the test and put it in the same folder as the

   <heycam> [17]http://wiki.csswg.org/test/scripttest

     [17] http://wiki.csswg.org/test/scripttest

   <scribe> ACTION: heycam follow up that scripted tests can go in
   repository [recorded in

   <trackbot> Created ACTION-3406 - Follow up that scripted tests
   can go in repository [on Cameron McCormack - due 2012-12-27].

   krit: Peter Linss can help us write a real test suite

   heycam: yes, we need to figure out how to run shepard

CSS animation of SVG attributes

   krit: I restarted the thread on www-style.

   ...authors would like to use this.

   ... I will bring it up on the FX tast force

   heycam: I'm not surprised that there was no response

   ... I think it's a difficult topic. It's a major thing

  krit: that might be

   ... I would like to start with just a couple of properties just
   as x and y

   ... to make it easier

   heycam: patrick had a list

   krit: I saw that

   ... we still need to figure out with attributes that are used

   ... and we might need new names

   ... We should start by agreeing with new names

   <TabAtkins> That info was laid out in one fo the old threads.

   shepazu: I don't agree that we need new name

   <heycam> TabAtkins, this has all been discussed before, you are

   krit: right now some attributes depend on the element such as
   x, y on text or a rectangle

   shepazu: I prefer that each element can have its own behavior

   ... I'm unsure where the group is on different names such as
   rectX, etc

   ... does anyone think that width height in SVG than it is in CSS

   heycam: I don't think so

   ... It depends on the pattern of renaming that we will use

   ... if we use longer descriptor names, it might make sense.
   Otherwise no

   shepazu: does it make sense to not add cx, cy to a circle and
   stick to x and y?

   krit: the CSS WG doesn't even want x and y

   <TabAtkins> We don't want x and y because those are on the
   "used in two different ways with different grammars" list. ^_^

   krit: (reading Tab's irc)

   <heycam> It could be just as easy as saying "rect { x: 10px
   20px }" is treated just like 10px

   <heycam> if we wanted to use the same syntax

   <heycam> not sure how much of a problem it really is

   shepazu: maybe we can say that x/y is treated differently

   heycam: we can talk about boxes in SVG

   krit: that is a totally differnt topic
   ... I would like to see circles directly in HTML and <p>
   directly in SVG
   ... at that point we need to decribe the boxing model

   ... but it's still not working. we need 2 different properties

   <TabAtkins> (I'm fine with x/y as just being properties used by
   the SVG layout model, and <text> exposing some
   differently-named property for its x/y stuff.

   <krit> would work as well, again, just an edge case that we
   need to resolve on later

   shepazu: the HTML WG is becoming more modularized

   ... we could write a new module that descibes SVG in HTML

   ... and have bare SVG elements

   krit: it doesn't have to be a new module

   shepazu: yes. but how would we do this?

SVG font in SVG 2

   krit: we are not working on SVG fonts

   ... and a lot of things are not implemented and FF and IE are not
   going either

   ... so I would like to remove from SVG2

   heycam: we agreed to have a separate module

   ... I do agree with your point to have a separate module.
   However, I don't know how good use of a time it is

   krit: it's already in its own module, so we can split it off

   heycam: yes, but it's in the SVG 1.1 spec, so they can still
   implement it

   ed: I think we have actions. Chris has an action to create a
   new font module

   ... I have an action to move the tiny font

   heycam: you will move the chapter of the tiny spec into the
   main spec?

   ... do you still agree that we should do that

   ed: whatever's easiest. as long as it's a required part

   heycam: it's very unlikely that we will implement that

   ... I don't know if that matters.

   shepazu: I think it does.

   ... getting consensus on if a feature is part of the language is

   ... otherwise authors will have a bad time

   ... even if it's a module, we should say if it's required or not

   krit: I'd say the fonts module is not part of the core

   Tav: I think the SVG fonts are serving a different purpose. For
   instance decorative purposes

   shepazu: I agree with you

   ... how, today the inkscape output does not render in FF, IE or

   ... this harms every authoring tool

   Tav: inkscape doesn't support svg fonts today :-0)

   shepazu: so this proves my point

   ...you and Eric say that they want to keep SVG fonts, but they've
   never been properly supported

   krit: yes, WebKit only had a small part of fonts implemented

   shepazu: also, there will be SVG fonts inside of OpenType

   ... that is one way

   ... for instance, groovy text is very hard to use with SVG fonts

   ... we should look at what features we want from SVG text

   <ed> clarification: I do want to keep SVG *Tiny* fonts, the SVG
   1.1 full fonts are just underspecified - and would need much
   more detail (the same applies to svg-in-opentype as well)

   <heycam> +1 to what doug just said about associating text with

   tav: this solution, would you be able to select the text?

   krit: SVG in opentype can do a lot more than SVG fonts

   ... animation for instance

   shepazu: that's not quite true

   ... however, we're talking about adding features. We're not
   talking about dropping features

   heycam: I think with Doug

   ... marking graphics with a title/description

   ... would be a good idea

   ... It would be a good idea that you could select the box and
   copy the text

   shepazu: I think that sounds great and especially if it can be
   implemented easily

   heycam: I agree that what's in the spec is what we want people
   to implement

   shepazu: yes, that is the goal of SVG2

   Tav: it would be good if there's an alternate way to get access
   to the content (inside the glyph)

   heycam: I recently heard that some people had troubles with
   outlined text


     [19] http://lists.w3.org/Archives/Public/www-svg/2012Dec/0070.html

   shepazu: regardless of our decision on font, I would like to
   push forward with groovy text

   ... it would be nice that you can aggregate strings

   heycam: yes, that's why I want to define the selection area

   shepazu: maybe having them as seperate elements will do that

   heycam: yes. I would like to think about a feature like this

   <ed> that looks similar to altGlyph

   <ed> (which isn't part of svgfonts)

   <heycam> good point ed

   <heycam> we should look at what altGlyph affords us now

   shepazu: krit, why do you want SVG fonts to drop?

   heycam: because we think SVG fonts are not the right direction

   krit: ???
   ... we won't drop exisitng support because of legacy reasons

   shepazu: is your point that ie and ff not implementing, is
   doing more harm than good?

   krit: yes

   heycam: we can discuss this more during the F2F
   ... does anyone have remarks on the groovy text proposal?
   ... I will come up with a more concrete proposal

   krit: yes, how you use it, where, etc

   <scribe> ACTION: heycam make a concrete proposal for
   associating text with graphics [recorded in

   <trackbot> Created ACTION-3407 - Make a concrete proposal for
   associating text with graphics [on Cameron McCormack - due


   shepazu: Josh Davis will talk at w3conf

   <shepazu> [21]http://openvisconf.com

     [21] http://openvisconf.com/

   ... ??? asked me to submit a paper on accessibility of data

   ... if anyone is interested in making some examples

   ... I would love that

   ... this conference is in May

   richardschwerdtfeger: I have some material that you can reuse

   shepazu: and talk about connector and ARIA

   ... if anyone knows anything other conference where we can
   promote SVG

   topic SVG at ISO


   shepazu: W3C can have its specs rubber stamped

   ... we want to get an SVG ISO spec

   ... are we planning on making a SVG 1.1 version 3?

   heycam: no

   shepazu: SVG 2.0 is not ready in 2013

   ... if a spec is an iso spec, it can be used by more people (ie

   ... it comes down to, having more people using your technology

   cabanier: don't we lose rights to our own documents if we
   submit to ISO?

   shepazu: no. The W3C worked out a special deal. ISO can't
   change or owns the spec

  ... people can buy the specs from ISO but there is a link on the
   ISO URL where you can download the spec from the W3C

   shepazu: so, if we give them something this year, it should be
   SVG 1.1 second edition

   richardschwerdtfeger: what state do we expect SVG2.0 to be by
   the end of 2013?

   heycam: CR hopefully

   richardschwerdtfeger: this would mean that epub would pick it
   up for 3.1

   heycam: that could be good since epub is picking up all the CSS

Summary of Action Items

  [NEW] ACTION: Dirk to review filter effects proposal [recorded
   in [22]http://www.w3.org/2012/12/20-svg-minutes.html#action01]
   [NEW] ACTION: heycam follow up that scripted tests can go in
   repository [recorded in
   [NEW] ACTION: heycam make a concrete proposal for associating
   text with graphics [recorded in
   [NEW] ACTION: heycam to allocate chunks of the test suite for
   different people to review [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [26]scribe.perl version
    1.137 ([27]CVS log)
    $Date: 2012-12-20 22:43:08 $

     [26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [27] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 20 December 2012 22:46:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:16 UTC