See also: IRC log
<shepazu> trackbot, start telcon
<trackbot> Date: 23 August 2008
<ed> scribe: anthony
<ed> scribeNick: anthony
<ed> scribe: Erik
<ed> scribeNick: ed
[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> 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> 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 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].
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
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 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 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 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 http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0161.html [recorded in http://www.w3.org/2008/08/23-svg-irc]
<trackbot> Created ACTION-2168 - Write some tests, propose some changes for http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0161.html [on Cameron McCormack - due 2008-08-30].
<heycam> <a href='http://www.w3.org/TR/blah'>BlahML</a>
<heycam> <a href='http://www.w3.org/TR/blah'><cite>BlahML</cite></a> [<a href='refs.html#ref-BLAH'>BLAH</a>]
<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 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].