SVG 1.2 Comments (Part 1)

SVG 1.2 Comments

Chapter 3

   1. Usage comment on sXBL. The rationale for bindings for SVG differ
      from that for XUL. In the latter case, elements that are included
      are almost invariable new components, and as such as most likely
      to be provided with data bindings via an attribute or element. In
      the case of SVG, however, the content for such entities are far
      more likely to be specifically defined external schemas (for
      instance, the creation of a pie chart from an XML schema holding
      the associated data), and for this particular use case the
      requirements of specifically enveloping such entities within an
      element can be pretty daunting.

      As a consequence, I suspect that making it clear that the intent
      of sXBL bindings within SVG should be seen as being component
      oriented rather than purely transformation should be at least
      hinted at within the specification. Although this moves more into
      a best practices type of scenario, my suspicion is that without
      this stated "hint" in the spec, a lot of people will be working
      with very unoptimized SVG at best, and sXBL could become a
      rallying point for opposition. For this reason, I would recommend
      that the examples being given focus more on the compnent rather
      than data oriented nature of sXBL; as it is right now, the and
      examples do not effectively illustrate this.
   2. Section 3.11, concerning binding of style elements into shadow
      trees bothers me, because of the statement that this restriction
      may be loosened in subsequent releases. There's also the question
      of whether a user agent should throw an error if script within the
      shadow tree alters the stylesheets via DOM. Finally, given that if
      you define a shadow tree using class attributes, such class
      attributes are likely to be characteristics that you need to
      assign within a contained binding, not the calling document,
      though with the ability of the calling document to override
      associated class attributes. As class attributes can serve to
      bundle related stylistic elements in a consistent manner, I see
      this as being something of a concern for component development.

Chapter 4

   1. Recommendation: <flowDiv> and <flowPara> are semantically too
      close, especially given the HTML semantics of <DIV> and <P> 
      respectively. I would recommend that <flowDiv> be renamed to
      <flowBody>.
   2. Last week I became involved in some fairly contentious arguments
      with the CSS proponents, and in the process of trying to work out
      the distinctions between the CSS and SVG models, something
      occurred to me that I'd like to pass on. One of the central issues
      involved in the current argument between the two flow models comes
      down to the question of whether columns should be specified via a
      CSS mechanism in which you specify a given bounding rectangle and
      then subdivide that region into multiple columns, or whether you
      take the SVG proposed approach of mapping one column per bounding
      shape, then map the shapes to the page.

      It occurs to me that there may be some advantage to combining the
      two approaches. In essence, within a <flowDiv> element, you
      include the ability to specify the number of columns that can be
      contained within that DIV, along with some kind of spacing
      property that would let you specify the relative sizes of each
      column. This provides a number of key benefits:
         1. Multicolumn flow characteristics will let you do BIDI
            columns within the flowDiv, so that text will automatically
            flow according to the relevant directional and language
            specifications.
         2. You retain the ability to specify overflow targets as either
            shapes (in SVG) or divisional elements (HTML) without
            needing two different models.
         3. The default case is the same in both cases.
         4. This can be easily extended to the case of floating entities
            in which columnar text needs to flow around the floats.
         5. Shaped binding characteristics for horizontally irregular
            shapes would only affect the edge columns - internal columns
            would retain their rectangular characteristics.

More comments to follow.

-- Kurt Cagle
-- Metaphorical Web