SVG Working Group Teleconference -- 12 Jun 2009

<trackbot> Date: 12 June 2009

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Layout

CM: flex box is progressing in css, what about other layout?

CL: there's multi column
... might be dropped in implementations
... there's grid, which is mainly used for asian typography

CM: not intended for big boxes of content in the grid?

CL: no

CM: template too

http://www.w3.org/TR/2009/WD-css3-layout-20090402/

DS: xsl wants areas that text flows in to, and areas that grow to fit the text
... we should make sure that whatever we do for text shape should work for those
... need to gather use cases & reqs for text flow shapes

CM: a good way forward might be for someone to look at the flex layout and see how applicable it is to svg

CL: as for the text flow problem, our flowText from the 1.2 draft is pretty different from what xsl needs

ED: i'm more interested in the graphical content layout problem

DS: i'm still interested in the one way constraints stuff

<shepazu> DS: part of flexbox, as I understand it, is essentially the springs-and-struts model

CM: i feel like high level layout (like flex boxes) plus one way for relative positioning might be a good balance
... the springs can't cross boxes, with flex boxes

DS: if i have a rectangle and i want it to be a particular size, relative to other things around it, with a min height/width, seems like you could do that with the constraints

CM: one way constraints are less useful than i'd thought a while ago

DS: for some things i still want to use calc(bbox(some object) + 5) kind of functionality
... it's possible people would misuse the simple stuff and try to make things that are too complex

CM: also seems bad to require complex implementations to solve simple use cases

CL: for text flow, we limited our 1.2 draft solution to just simple paragraphs
... to avoid arbitrarily complex xsl-like formatting within svg
... want the sweet spot where small amount of functionality gets you lots of use

DS: two problems with canned layout solutions
... one, they each only solve a particular problem
... if there's no underlying model, then it becomes harder to define and to understand how they work together

CM: swing has a unifying model of rectangular components with min/preferred/max width and height

CL: systems can work together fairly easily if you limit them to not work together
... if they're mutually exclusive

DS: things tend to break down to specific syntax for those solutions, then
... so we need an underlying model to make them work together
... and so that people can understand how they work together

CM: i think people will want to use multiple high level layouts together

DS: maybe some you can combine some you can't?
... one thing that would be an easy win:

[doug talks about the "chain font" example]

scribe: so let's just allow shapes flowing along a path
... i think what goes along with that is navigation
... an implicit ordering

CM: so like implicitly determining the nav-* properties

DS: so for this pretty much textPath, but shapePath

ED: i've had cases where i wanted to place images along a path, it's pretty difficult

CL: the trivial case where someone wants the layout and gives a straight line path

DS: how do these shapes become anchored?

JW: two things tied into this shapes on a path
... i'd like percentages on a path

ED: another way of doing it is markers, but they're not easy to use

JW: also you might want minimum distances
... also, places objects on vertices
... like putting objects on each point of a star

DS: so reusing textpath for shapes, many of these things we're thinking of for shapepath could be used in textpath too
... so laying out glyphs and shapes are similar

CL: <shapepath>A b c <rect> <circle> d e f</shapepath>

DS: i've been thinking about how to do connectors, how to connect things to arbitrary points on a shap
... often you want limited connection points
... e.g. for circles, top bottom right and left
... if it's a star, only on the points
... so i want to identify those points through some syntax, or have as a child of that shape, a bunch of <point> elements with their actual positions
... those <point>s could be constrained to be at particular points on the shape
... each could have an id, and you could say that one is the anchor point
... or you might have anchor-x, anchor-y on a shape

CM: it's like setting the baseline for your shape
... if the <point>s are going to be used for other things, like connectors, then would make sense to reuse them
... otherwise, just use the anchor- attributes

[doug draws]

CL: can we do text on a path where each glyph has a constant rotation

JW: there's marker orientation

CM: i want automatically <use>d things along a path

<ed> there's no way to disable the rotation on textpath though, no @orient attribute

CM: to fill up the path
... to do train line like paths

DS: you could have a stroke-dasharray type of mechanism to specify those repeated things
... you could specify like background-repeat

ED: it's also like gradient spread method... reflect, pad, repeat, ...

DS: currently text has an interesting property where later glyphs are drawn on top of earlier glyphs
... perhaps we want to allow painting glyphs in reverse order
... or maybe an arbitrary order
... painting order
... maybe you want to allow specifying multiple shape repeat patterns that get drawn over each other

<scribe> ACTION: doug to write up a shape path proposal [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action01]

<trackbot> Created ACTION-2616 - Write up a shape path proposal [on Doug Schepers - due 2009-06-19].

<shepazu> should also think about potential join points, might apply to fonts, depends on how complex it did it

<shepazu> ... for patterns

DS: there's a problem with tspan and the semantics of a word
... would be useful to define that tspan does not affect the underlying semantics of the text, it's just the positioning
... you can have multiple tspans that comprise a single word
... only a space in english defines a separate word

ED: we should define how collapsed whitespace is assigned to particular text elements

CL: <text font-size='50'>a[space]<tspan font-size='10'>[space]</tspan></text> -- how big is the single collapsed space?

<jwatt> JW: I'd say the smaller of the two

<ed> raised ISSUE-2280

CL: you can consider the shape-flowing-to-variable-width-path as a displacement map problem
... the path defines a complex gradient
... which you use as the displacement map

<scribe> ACTION: cameron to play with css flex box to see how applicable it could be to svg [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action02]

<trackbot> Created ACTION-2617 - Play with css flex box to see how applicable it could be to svg [on Cameron McCormack - due 2009-06-19].

Simple keywords

CM: i was thinking about vector-effect='strokeBelowFill'

ED: or filter='drop-shadow'

<scribe> ACTION: chris to add a strokeBelowFill canned vector effect [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action03]

<trackbot> Created ACTION-2618 - Add a strokeBelowFill canned vector effect [on Chris Lilley - due 2009-06-19].

DS: i want to make sure that large stroke on text, where the stroke is behind the fill, works. where the stroke around the individual glyphs doesn't overlap.

CL: yes that's possible with vector effects

<shepazu> http://chapelhillcomics.com/sample/TOP-LOGO.jpg

<ed> (discussion on vector-effects)

ISSUE-2042 - Consider adding adding non-NS linking syntax

xlink:href

ISSUE-2042?

<trackbot> ISSUE-2042 -- Consider adding adding non-NS linking syntax -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2042

CL: at one point i suggested combining the thing that holds the IRI and the thing that holds the type into one attribute
... so <image> would have src, and <a> would have href
... and have a generic category for other

DS: so define it in terms of xlink

CL: we'd define the mapping to xlink for the subset of xlink that we use
... xlink would have had a network effect if a bunch of specs used it, but they didn't
... what xlink was going to be changed mid-design

[explains what xlink was meant to be and what it ended up as]

scribe: so xlink:type="" doesn't tell you what to do (refer, embed); instead it's just a hint to the xlink processor
... so xlink gives you some generality, but not full generality
... it has enough generality to get in the way, though
... the promise of serving domain specific xml has been lost

DS: for backwards compat and existing UAs we've still held on to xlink:href

CL: you could come up with new attributes and deprecate xlink:href
... UAs need to support both, new content targetting new browsers can just use the new attrs, content supporting both needs both, etc.
... i propose svg 2 prefer a new xlink-less syntax that does just what we need
... and say what's the mapping of the new way to the old way

DS: this is also applicable to svg in text/html

JW: we need to decide which takes precedence
... we don't implement xlink, but we don't take some notice of some of the xlink attrs
... if we take the href attribute instead of xlink:href, should it then ignore all the other xlink attrs? or should the href override all of the xlink attributes?

CL: suppose we had src, and it means xlink:type=embed.

ED: the only two that are used are xlink:title and xlink:href

CL: i've never seen xlink:role used in the wild

JW: we pay attention to xlink:show

<scribe> ... new or replace

CM: like target

CL: all the implementations took target in preference to xlink:show anyway

JW: if the target attr is empty or not specified, it will look at xlink:show
... if href overrides xlink:href, should we then ignore xlink:show?

CL: my off the cuff response to that is that when you find the new attribute, it overrides all xlink attrs

DS: title and xlink:title are two different things
... xlink:title is the title of the linked to thing, and title is the title of the element it's on

CL: we shouldn't force people to type xlink:type just to do that

<ed> <a href="foo" title="bar" xlink:href="foo" xlink:title="bar"/> but should be possible to just do <a href="foo" title="bar"> in new content

CM: hreflang exists, you could have hreftitle

ED: seems like we all prefer new xlink-less attrs to override xlink ones

JW: i'm not sure about that
... say now someone sticks xlink:href and href on the content
... the behaviour will be that impls follow the href

DS: href and src

CM: i'd rather align with html's attr names

DS: i propose href to outgoing links and src for incoming links

CL: not sure what you mean by incoming links

DS: i mean for embedding type elements, like <image>

CL: i don't think they all fall in to two different categories
... e.g. xlink:href on gradients
... what type is that?
... one aspect is whether it's embedded, one aspect is whether it's user actuated

DS: the ability for us to adopt href and src for some of our elements, where the align, has a clear case
... i'd like to propose we resolve to, where there's a clear mapping to html, that we use the same attr name

JW: i see the academic argument for distinct attr names

ED: but it's confusing since it's not the same as in html

JW: it's confusing because people are used to typing xlink:href for everyone
... two reasons to consider doing them with different names
... one is for recognition that they're different types of links
... the other one is consistency
... with html, specifically

DS: html doesn't have some of these kinds of links, like gradient links

CM: they have <label for>, but it's not a url

<ed> break for lunch

ed++

<ed> back for more of xlink

<ed> ACTION: CL to research where svg uses links, and make a proposal for how to resolve ISSUE-2042 [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action04]

<trackbot> Created ACTION-2619 - Research where svg uses links, and make a proposal for how to resolve ISSUE-2042 [on Chris Lilley - due 2009-06-19].

New DOM syntax

<ed> ISSUE-2044?

<trackbot> ISSUE-2044 -- Consider improving the SVG DOM interfaces for attribute access -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2044

CM: so ecmascript allows host objects to do that
... rectElement.x = 20; is just implemented with a custom [[Put]] on the SVGRectElement host object

JW: not sure if xpcom will allow you to do that

ED: it's just in the dom, just forwarding on the assignment
... in my quick test, just depending on the type of value you're assigning, you either use .baseVal.value or .baseVal.valueAsString

CM: in html there's already something like this, window.location
... it's a Location object, but you can assign a string to it
... getting the values is a bit harder
... you can define [[DefaultValue]] on the SVGAnimatedLength
... that works ok for most types, but not for SVGAnimatedBoolean
... since ToBoolean in ecma-262 doesn't use [[DefaultValue]]

JW: it's probably not feasible to throw away the current SVG DOM
... unless we come up with something exceptionally good, we'll need to stick with it

ED: we should try to make it more useful as we can, though
... maybe deprecate some parts going forward

DS: is it possible to make this in such a way such that we can also make it work for canvas?

ED: i thought about it, it's not that simple
... it's not easy to generate something that would make any sense if you record all the drawing commands

DS: we could make jquery-like or kevlin's createCircle()
... and allow dot syntax with that object

CM: so maybe getContext('svg') then canvas drawing commands gets you an svg tree

<scribe> ACTION: doug to write up a proposal for joint canvas/svg api, ISSUE-2044 [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action05]

<trackbot> Created ACTION-2620 - Write up a proposal for joint canvas/svg api, ISSUE-2044 [on Doug Schepers - due 2009-06-19].

ED: for all of the list types, it feels very unnatural to use getItem() and getNumberOfItems()
... it's very un-javascript like

JW: you already can use []-indexing on list objects

ED: it's not in the spec though

JW: it might be in DOM spec

CM: but SVG doesn't say it

<ed> would prefer .length and [i] instead of .numberOfItems and .getItem(i)

CM: instead of or in addition to?

ED: the hard one is the numberOfItems one

CM: we could always just have .length as well
... also, SVGNumber is a bit sucky
... why not just have floats in an SVGNumberList
... you could do the same thing as with SVGLength, and have SVGNumber have a [[DefaultValue]] that turns it into a Number

ED: another silly aspect is that you have to get the SVGSVGElement
... to create SVG types
... most of the times they're not inserted until later
... so having a constructor would be nice for the basic types

JW: i think that works already in mozilla

http://dev.w3.org/SVG/proposals/type-constructors/type-constructors.txt

CM: i didn't propose constructors PathSegItem interfaces
... not sure how useful they would be
... but probably just improving SVGPathSegList would be better

ED: so we want to move forward on these?

CM: yes i think we could put these in a blank SVG 2.0 spec

<scribe> ACTION: update template directory with build scripts [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action06]

<trackbot> Sorry, couldn't find user - update

<scribe> ACTION: cameron update template directory with build scripts [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action07]

<trackbot> Created ACTION-2621 - Update template directory with build scripts [on Cameron McCormack - due 2009-06-19].

<scribe> ACTION: cameron add these dom suggestions to a new svg 2.0 spec [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action08]

<trackbot> Created ACTION-2622 - Add these dom suggestions to a new svg 2.0 spec [on Cameron McCormack - due 2009-06-19].

Test suite

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0218.html

<ed> ACTION-2385?

<trackbot> ACTION-2385 -- Anthony Grasso to make an XSLT to change the template of the 1.1 tests to the new one -- due 2008-12-25 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2385

CL: dbaron explained reftests to us at csswg f2f

JW: i demoed them to svgwg last f2f
... the important thing for us is that you can do pixel-perfect testing
... and thus automated testing
... i've written up some short docs on it

CL: we use image patches, which are like ref tests
... but more for compensating for bugs in batik, to generate the reference png

JW: it's very important for interop
... the references should be in svg, i think
... don't need a harness, implementors can write their own
... and have by-hand harnesses for people to use (not automatic test suite running)
... not sure if there's the need for a raster fallback

CM: what's in the baseline?
... paths?

JW: depends on the test

<ChrisL> benefir of a reftest is that the set of fonts, the anti-aliasng, are the same for the reference and the test (both run on same machine)

JW: you might want to start off with testing a rectangle with a fill, for example
... from that level you would build up from it
... so some tests depend on functionality tested in previous tests
... we call the basic ones "sanity tests"
... whatever assumptions you make in the reference for a test, make sure there are tests for those basic functionality in the test suite
... resolution independence is pretty much the only reason not to use raster reference images, for simple things like testing <rect>
... my further plans, as well as technical issues like test format, there are social issues and political issues around getting implementors to agree on things
... especially implementors allowing you to have automated ways of running the test suite in the browser
... organisation of tests, naming, how detailed they should be, should each test do one feature, or many features in one
... a few other things i was working on; how to structure the tree of tests so that different implementors could mark things as 'we fail this"
... e.g. if moz sends all their tests to opera, a bunch will probably faily
... you want to mark them as known fails, so that if they suddenly start passing they notify you
... but wouldn't keep the tree red
... this is one of the places where ref tests falls down, it doesn't support multiple implementors tagging this

DS: danc says he's been interested in it for a while
... plh was really interested

CL: related to passing tests around is the licence
... currently w3c licence is fairly restrictive
... the aim was to prevent vendors from grabbing a test suite, fiddling with it, then saying they pass the test
... but more important is to give ppl the freedom to modify the tests for their purposes
... so you can now licence them under a modified MIT licence
... i propose we use this in the future

JW: i'd rather creative commons zero licence
... it's essentially public domain
... it frees people up for snippets of code etc.
... MIT requires you to have a header
... and say who the contributors were
... it's a very open licence, but is still a licence, and has these requirements

CL: the advantage of doing it with the modified MIT licence is that it's currently allowed by w3c

DS: i was skeptical there was a reason to push for CC0, and thought that there were useful aspects to a licence that requires attribution etc.
... if everyone wants to go for CC0, then that's fine

JW: i'm happy with having provenance information in comments or metadata in the document
... but it's not a licence

<ChrisL> So CC Attribution 3.0 Unported looks good to me

<ChrisL> http://creativecommons.org/licenses/by/3.0/

JW: to me, whether it's a licence or not, the point is that we don't want people to propagate modified tests

DS: that's the non-malicious case
... what if a group want to remove some features from a test suite that they don't want, and distribute that?

ED: i wonder if there's a licence that fits out of the box

<ChrisL> actually this one is better

<ChrisL> http://creativecommons.org/licenses/BSD/

<ChrisL> and arguably more applicable to markup (code)

CL: a three-clause bsd licence

JW: that's what the current test suite is under

<ChrisL> is it really iunder that?

JW: i want people to be able to take snippets out of the test slides too
... and reuse them at will

DS: can we have the individual tests under once license, and the test suite as a whole under another?

CL: for the new template, i'd like a link to this licence
... not the wall of capital letters

<ChrisL> lets just have a link to W3C 3-clause BSD License in the test harness

ED: i think it would be good to move to the bsd licence

CM: will other implementors want to contribute with w3c 3-clause bsd licenced tests?
... or would they be unhappy with anything but something like public domain / cc0

JW: are we still open to discussion on using other licences in the future?

DS: yes

RESOLUTION: We will move the SVG test suite to the new W3C 3-clause BSD licence

<scribe> ACTION: erik to convert the test suites to use the 3-clause bsd licence [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action09]

<trackbot> Created ACTION-2623 - Convert the test suites to use the 3-clause bsd licence [on Erik Dahlström - due 2009-06-19].

<ed> http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/script/f11_1st_2_f11_2nd.pl

ED: we'll wait for anthony to finish the test suite conversion script, then convert it and check it
... there are some 1.1 tests that need review

<scribe> ACTION: erik to go through the test suite to see which ones need reviewing, and put that list on a wiki page [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action10]

<trackbot> Created ACTION-2624 - Go through the test suite to see which ones need reviewing, and put that list on a wiki page [on Erik Dahlström - due 2009-06-19].

Mailing minutes to www-svg

JW: i propose that we CC the minutes to www-svg

ED: i don't disagree with that, but they should still be on public-svg-wg

DS: charter says we have to send to public-svg-wg at least

ED: i'm concerned conversations will fork

CM: i don't think that forking is a problem
... i'd be happy with doing technical discussion on www-svg

DS: we can't just CC the mail
... we could send to www-svg and bcc public-svg-wg
... we should have a disclaimer about the minutes being sent out
... when this was mentioned to chris yesterday (sending minutes to www-svg) he was concerned about that as a policy and i suspect that his concern may in part have been that the minutes are not clear if you weren't there
... and also that it might generate a lot of noise, feedback before our ideas are fully baked
... but that's just my guess on his concern is

CM: personally i'm happy if people can see our half baked ideas

JW: i suggest some disclaimer text

<jwatt> DISCLAIMER: The SVG Working Group provides these minutes, unedited, in the interest of timely openness. The lack of editing may make them difficult to understand or subject to misinterpretation outside of context. If you find that to be the case, polite requests for clarification are welcome.

DS: i think it's a worthwhile experiment to see if the policy causes problems
... i'll note that this is how we operate in the Web Apps WG, and it has caused a lot of discussion, but not problems
... work with the dom has generated helpful input

JW: if everything is done out of public view, and presented all at once, you get a flood of comments
... which is hard to deal with
... if you send the minutes gradually, it heads off a whole swamp of upset people
... by giving them a chance to voice their concerns at an earlier stage

DS: before we've put too much work in to a solution that has problems

CM: we had the thread on style/script in text/html on www-svg
... that worked ok

DS: since the svg wg has shown that we are trying harder towards being better integrated into the web architecture, open web platform, i think people are less prone to jump to bad conclusions

JW: one thing not in the disclaimer is about new ideas here not being final
... often discussion about embryonic ideas
... and many of them could be thrown away

DS: or may not be the solution we settle on

JW: i'd like to keep the disclaimer short

DS: we should send something to www-svg before we start doing this, signalling our intentions/concerns/...
... brainstorming
... "we were encouraged by recent conversations on www-svg and we want to see as an experiment if working completely in the open works for us"

RESOLUTION: We will send minutes to www-svg as well as public-svg-wg as a first step

<scribe> ACTION: doug to send mail to www-svg with explanation of what we'll be doing with minutes sending [recorded in http://www.w3.org/2009/06/12-svg-minutes.html#action11]

<trackbot> Created ACTION-2625 - Send mail to www-svg with explanation of what we'll be doing with minutes sending [on Doug Schepers - due 2009-06-19].

<ed> trackbot, make minutes

<trackbot> Sorry, ed, I don't understand 'trackbot, make minutes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

- DRAFT -

SVG Working Group Teleconference

12 Jun 2009

Attendees

Contents