- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 01 Sep 2008 14:53:40 -0400
- To: SVG WG <public-svg-wg@w3.org>
http://www.w3.org/2008/08/23-svg-minutes.html
Or as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Face to Face Day 3
23 Aug 2008
See also: [2]IRC log
[2] http://www.w3.org/2008/08/23-svg-irc
Attendees
Present
Anthony, Cameron, Doug, Erik
Regrets
Chair
Erik
Scribe
anthony, Erik
Contents
* [3]Topics
1. [4]discussion of contentmodel for the title element
2. [5]Layout module
3. [6]2.5D
4. [7]Element Traversal
* [8]Summary of Action Items
_________________________________________________________
<shepazu> trackbot, start telcon
<trackbot> Date: 23 August 2008
<ed> scribe: anthony
<ed> scribeNick: anthony
<ed> scribe: Erik
<ed> scribeNick: ed
discussion of contentmodel for the title element
[summarize the discussion from last night's dinner]
DS: title and desc should only have text as content, not structured
content (like XML)
... XML should be restricted to metadata
CM: title, desc and metadata are already restricted to text in the
1.2T RNG
DS: currently the spec says you can put arbitrary elements as
children of title, desc and metadata (and the spec is normative when
there's a conflict between RNG and spec language)
... I would like to restrict the content model for title and desc to
be just text
CM: there's an example in the spec using some elements
DS: propose to remove that example, and to use only text
... and to use an algorithm proposed by Jeff Schiller for how to
decide which title applies to which piece of the document
... and additionally put stronger language about how to display that
... how it should be handled by the UA
... specificially as a tooltip (where possible)
... or statusbar
CM: does it suggest desc to be used in tooltip?
DS: no
CM: [reads out spec wording for recommendations for handling
tooltips]
DS: i'll replace that with a more rigorous handling, to be able to
get interop
... this impacts the tooltip in 1.2 full
... AG suggested to use the 'role' attribute on the desc, and to
distinguish between the kinds of desc(riptions) by using aria-roles
"description" and "tooltip"
CM: that would be good to have for text elements too
DS: yes, which is why we should add the 'role' attribute to SVGT12,
because it's already implemented
... in browsers
<heycam> ACTION-2151?
<trackbot> ACTION-2151 -- Cameron McCormack to change paced
animation of scale to use Euclidian distance formulae -- due
2008-08-29 -- OPEN
<trackbot> [9]http://www.w3.org/Graphics/SVG/WG/track/actions/2151
[9] http://www.w3.org/Graphics/SVG/WG/track/actions/2151
<heycam> ACTION-2153?
<trackbot> ACTION-2153 -- Cameron McCormack to add "list of
coordinate" and "list of number" to the paced animation table, with
the same distance formula as "list of length" -- due 2008-08-29 --
OPEN
<trackbot> [10]http://www.w3.org/Graphics/SVG/WG/track/actions/2153
[10] http://www.w3.org/Graphics/SVG/WG/track/actions/2153
RESOLUTION: we will add the 'role' attribute to SVGT12
... we will change the content model of the title and desc elements
to be text
<scribe> ACTION: DS to add 'role' attribute (and informative
reference to XHTML Role attribute module) and to change the content
model of the title and desc elements to be text [recorded in
[11]http://www.w3.org/2008/08/23-svg-irc]
[11] http://www.w3.org/2008/08/23-svg-irc
<trackbot> Created ACTION-2164 - Add 'role' attribute (and
informative reference to XHTML Role attribute module) and to change
the content model of the title and desc elements to be text [on Doug
Schepers - due 2008-08-30].
Layout module
CM: we need to decide what type of layout functionality we want to
include
... two classes, one is very general like springs/constraints to
make gridbased layouts, and the other is to have some highlevel
constructs in the language itself to make elements align themselves
... did some experiments
... you want to avoid having to set up lots of constraints
... a combination of highlevel and lowlevel would be good
... but if we want to start with something it should be the
highlevel things
AG: would it be attributes on containers or new elements?
DS: we should first discuss what functionality we want
... but attributes would probably be easier for authoring
... elements would be svg-specific, but attributes could be
properties and be reusable
CM: XUL has properties for doing the layout
... have been looking at various markup languages and widgets
... the layouts that I found were similar
... aligning elements to borders and boxes, and aligning them to
lines and grids
DS: svg has a need for graphs or charts, lines and boxes, node-edge
connectors
CM: with routing?
DS: first thing is to do just straight lines, or constrained
straight lines
... other things I've seen is people using textpath with custom
svgfonts to create for example a chain or a railway or something
like that
... symbols
... the ability to put arbitrary symbols on a path
CM: we need to work out how bboxes and such work for these cases
DS: and where to connect graph nodes to each other
... could improve the marker functionality
... one of the problems is that markers is part of the path or line
itself, so you can't e.g catch events on the end-marker
ED: you could connect two nodes by making a line and using markers
in both ends for the nodes
DS: true, but you still couldn't determine clicks on each node
CM: boxes divided into regions and boxes like with springs or struts
for dividing space between boxes
... grids are a bit more specific
... flow layout is a bit different because of linewraps
DS: flow layout is about arranging objects along a path
... both for boxmodel and textpath-style layout
CM: and absolute-position (which is waht svg already has)
... I like being able to use the baseline for alignment
DS: each element should be able to have an anchor point
CM: agree
DS: anchorX anchorY in the coord system of the element
CM: if you want to align by the baseline then you could have a
default of the bottom of the bbox
... it might be an idea to have arbitrary connection points between
elements
DS: if you have a circle for example
... [draws example with connecting two circles]
ED: might need to take into account stroke-width
DS: and the connection isn't on the center, it's on the edge of the
circles
... markers don't fully do the job
... I want to have specific connection points that it defaults to
along the stroke
... so allowing percentages of the pathlength for the connectors
... a commawsp of lengths or percentages, so if I had a rect and
only wanted to connect on the middle of each of the sides
CM: like the idea of named connectionpoints
DS: like box-right-middle?
CM: yes
... there should be some predefined values like that
... we could separate the widgets layout and the diagramming layout
DS: being able to position things relative to one another depending
on states
... when we're talking layout and routing you're talking about two
different things
... the node position is one thing, and how to connect the nodes
another
... and we shouldn't aim for making the connetions in general
CM: graph layout is usually an optimization problem
DS: there are different line styles as well
... [draws circles connected with straight, and rounded-rect-like
lines]
... so it could be corners-rounded
... for connector-shapes
CM: curves, straight lines
DS: block
CM: connector routing is too complex
DS: but we should have a connector shape (the line between two
nodes)
... arc, or round, straight, curved
CM: what's the advantage of the speciail connector objects over a
path where you can specify connection points?
DS: two things: we can have predefined connectors that meet common
needs, second the styling could be different
... and the script interfaces on the connectors would be different
for connectors than paths
... how would you do the 'd' attribute?
CM: you could do a combination of relative lengths or variables in
the syntax
DS: I like the idea of them being semantically a connector
CM: but how many other elements like that should we add?
DS: right, but graphs is a common usecase
CM: when you generalize graphs they usually come down to nodes and
edges
DS: another aspect is automatic sizing, like depending on font-size
CM: XAML can easily put graphics inside layout containers
AG: it's designed to do that, and does flowing text etc
CM: for placing things inside layout containers, I was thinking to
open a new viewport so that you could position things relative to
that viewport
... another way is to have the children get an automatic transform
put on them
... a simpler expression than the CSVG stuff that I've presented
before
... because it was too complex
... it was a bit verbose
... i'd be happy with some way of specifying expressions inside
attributes for creating the constraints/layout
DS: we should have a DOM method like getLayoutPosition or similar
that could fetch the layout data
CM: yes, because it's not CTM, and it's not the bboxes
DS: like the semantic construct for connector
... for a subway-map, you'd perhaps want to have control over how
the paths look
... but still get automatic connectors
... we might introduce a point element that could be animated and
could affect the shape of connectors
CM: for putting a marker on some point
... the point would be invisible, but could be used for other
things, like maps and layout
DS: we might even use the SVGPoint DOM interface for it
CM: though you may want to access the animval etc
... the thing I haven't looked at yet is diagramming tools
... they're likely to have different layout functionality
DS: like the idea of doing widget layout, but I fear that we'd
overlap and have conflict with CSS and HTML
CM: wonder if XUL or FLEX could be adapted or if we need to do our
own thing
DS: we could try to do it in a non-svg-specific way
... and coordinate with other WG:s
... lay groundwork for app framework
... [talks about min-width,max-width etc and spring layout]
CM: we should consider the springs model
... not sure it's useful to be able to get at the lowlevel details
DS: if it was consistent and easy to implement that might be worth a
slight pain for authoring
...requirements: easily interoperable and performant
CM: if you had one-way constraints you could use those two influence
the layout structure
DS: with aria, connectors and nodes could have those categories
... or repeatnode, or documentnode
... for different flowcharts
... if you have a subway map
... and you're at a stop, only stops connecting from that stop would
be navigatable
... so that the aria roles would define how navigation works
... even for non-AT
AG: SCXML could also do something like change the colors of the stop
etc
2.5D
AG presents 2.5D/3D
DS: I know you can do a flip with -1, -1
... but it's not intuitive
... we should add something like Flip
AG: Could do something like a flip about an angle perhaps?
<scribe> ACTION: ed to add a 1.1 errata item for having xml:space on
tspan elements to align with 1.2T (split out from ACTION-2048)
recorded in [12]http://www.w3.org/2008/08/23-svg-irc]
[12] http://www.w3.org/2008/08/23-svg-irc
<trackbot> Created ACTION-2165 - Add a 1.1 errata item for having
xml:space on tspan elements to align with 1.2T (split out from
ACTION-2048) [on Erik Dahlström - due 2008-08-30].
<heycam> ACTION: Cameron to Make all references to TRs use dated
URLs recorded in [13]http://www.w3.org/2008/08/23-svg-irc]
[13] http://www.w3.org/2008/08/23-svg-irc
<trackbot> Created ACTION-2166 - Make all references to TRs use
dated URLs [on Cameron McCormack - due 2008-08-30].
<heycam> ACTION: Cameron to ensure lacuna values are specifically
mentioned for all default attribute values [recorded in
[14]http://www.w3.org/2008/08/23-svg-irc]
[14] http://www.w3.org/2008/08/23-svg-irc
<trackbot> Created ACTION-2167 - Ensure lacuna values are
specifically mentioned for all default attribute values [on Cameron
McCormack - due 2008-08-30].
<heycam> ACTION: Cameron to write some tests, propose some changes
for
[15]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/016
1.html recorded in [16]http://www.w3.org/2008/08/23-svg-irc]
[15]
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0161.html
[16] http://www.w3.org/2008/08/23-svg-irc
<trackbot> Created ACTION-2168 - Write some tests, propose some
changes for
[17]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/016
1.html [on Cameron McCormack - due 2008-08-30].
[17]
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0161.html
<heycam> <a href='[18]http://www.w3.org/TR/blah'>BlahML</a>
[18] http://www.w3.org/TR/blah'>BlahML</a>
<heycam> <a
href='[19]http://www.w3.org/TR/blah'><cite>BlahML</cite></a> <a
href='refs.html#ref-BLAH'>BLAH</a>]
[19] http://www.w3.org/TR/blah'><cite>BlahML</cite></a>
Element Traversal
<anthony> DS: We should normatively reference element traversal
<anthony> ... because it'll be in REC by the time we go to LC
<anthony> RESOLUTION: We will use the Element Traversal
specification instead of our interface
<anthony> ACTION: Erik to Take out current element traversal
interface and a reference to the Element Traversal spec [recorded in
[20]http://www.w3.org/2008/08/23-svg-irc]
[20] http://www.w3.org/2008/08/23-svg-irc
<trackbot> Created ACTION-2169 - Take out current element traversal
interface and a reference to the Element Traversal spec [on Erik
Dahlström - due 2008-08-30].
Summary of Action Items
[NEW] ACTION: Cameron to ensure lacuna values are specifically
mentioned for all default attribute values [recorded in
[21]http://www.w3.org/2008/08/23-svg-irc]
[NEW] ACTION: Cameron to Make all references to TRs use dated URLs
recorded in [22]http://www.w3.org/2008/08/23-svg-irc]
[NEW] ACTION: Cameron to write some tests, propose some changes for
[23]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/016
1.html recorded in [24]http://www.w3.org/2008/08/23-svg-irc]
[NEW] ACTION: DS to add 'role' attribute (and informative reference
to XHTML Role attribute module) and to change the content model of
the title and desc elements to be text [recorded in
[25]http://www.w3.org/2008/08/23-svg-irc]
[NEW] ACTION: ed to add a 1.1 errata item for having xml:space on
tspan elements to align with 1.2T (split out from ACTION-2048)
recorded in [26]http://www.w3.org/2008/08/23-svg-irc]
[NEW] ACTION: Erik to Take out current element traversal interface
and a reference to the Element Traversal spec [recorded in
[27]http://www.w3.org/2008/08/23-svg-irc]
[21] http://www.w3.org/2008/08/23-svg-irc
[22] http://www.w3.org/2008/08/23-svg-irc
[23]
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0161.html
[24] http://www.w3.org/2008/08/23-svg-irc
[25] http://www.w3.org/2008/08/23-svg-irc
[26] http://www.w3.org/2008/08/23-svg-irc
[27] http://www.w3.org/2008/08/23-svg-irc
[End of minutes]
_________________________________________________________
Received on Monday, 1 September 2008 18:54:16 UTC