SVG Working Group Teleconference -- 20 Dec 2012

<trackbot> Date: 20 December 2012

<ed> scribeNick: ed

mask-type

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

<krit> 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 element

… 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 shorthand

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

<heycam> 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 http://www.w3.org/2012/12/20-svg-minutes.html#action01]

<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

… 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 http://www.w3.org/2012/12/20-svg-minutes.html#action02]

<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 repository

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 reftest

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

<scribe> ACTION: heycam follow up that scripted tests can go in repository [recorded in http://www.w3.org/2012/12/20-svg-minutes.html#action03]

<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 twice

… 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 right.

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 important.

… 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 webkit

… 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 today

… 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 graphics

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

<heycam> 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 http://www.w3.org/2012/12/20-svg-minutes.html#action04]

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

confs

shepazu: Josh Davis will talk at w3conf

<shepazu> http://openvisconf.com

… ??? asked me to submit a paper on accessibility of data visualisation

… 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

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 governments)

… 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 features

- DRAFT -

SVG Working Group Teleconference

20 Dec 2012

Attendees

Contents