Minutes, SVG Nuremberg Face-to-Face Day 3, Sunday 23 August 2008

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