SVG12: TraitAccess vs DOM Core / Style

Dear Scalable Vector Graphics Working Group,

  From http://www.w3.org/TR/2004/WD-SVG12-20041027/svgudom.html and the
probably more accurate text in JSR 226 are unclear about trait values in
case of style sheets affecting the computed value of properties and the
impact of trait manipulation on DOM Core and DOM Style, starting with
the definition

[...]
  The XML attributes, the getter methods (e.g., getTrait(...),
  getFloatTrait(...)) return the attribute value for the named
  attribute. If the given attribute has a value, then return
  that value;
[...]

contradicting other parts of the specification which state the the trait
value is either the computed base value or the computed value (which are
different in case of animation affecting the computed value). It is in
particular not clear whether and if how setting a trait value causes DOM
methods such as getAttributeNS to return a different value and if it
does whether in a case like setTrait("...", "inherit") getAttributeNS
would return the string "inherit" or a computed base value like "900".

It is also not clear whether implementations are allowed to normalize
attribute value representations if they implement traits, for example,
an implementation that starts out only implementing trait access and
adds other access methods later might behave as if all attributes in
the initial DOM representation are added through trait access thus
loosing information such as relative path commands. It is not clear
whether such an implementation would be conforming.

I am also not sure what getTrait would return for the font-weight
property assuming that SVG 1.2 will adopt the proposed errata for the
property as discussed in the CSS 2.1 Candidate Recommendation as the
property might compute to something that cannot be represented using
one of the nine strings as provided in the trait table. Please change
the draft such that this is clarified.

The draft is also unclear about the apparent fact that setting a trait
might be a no-op as the presentation attribute might be overridden by
style sheets. This needs to be noted explicitly as authors would not
expect that

  e.setTrait("font-weight", "bold");

is really like

  e.setAttribute("font-weight", "bold");

and much unlike

  e.style.setPropertyValue("font-weight", "bold"); // or
  e.ownerSVGElement.getOverrideStyle(e, "").
    setPropertyValue("font-weight", "bold");

considering that

  e.getTrait("font-weight");

is much unlike

  e.getAttribute("font-weight");

and more like

  e.ownerSVGElement.getComputedStyle(e, "").
    getPropertyValue("font-weight");

For example, in

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "TBD">
  <html
     xmlns              = "http://www.w3.org/2002/06/xhtml2"
     xmlns:xsi          = "http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation = "http://www.w3.org/2002/06/xhtml2 TBD"
     xml:lang           = "en"
  >
  <head>
    <title>...</title>
    <style type="text/css">
      ...
      a {
        display: inline;
        ...
      }
      ...
    </style>
  </head>
  <body>
    ...
      <svg ...>
      ...
      <a id="a" ...>
        ...
      </a>
      ...
        a.setTrait("display", "none");
      ...
      </svg>
    ...
  </body>
  </html>

Authors are likely to have a hard time to debug why setTrait does not
work, or why their third-party sXBL component fails. In fact, maybe it
is not such a good design to affect the XML attribute rather than the
override style sheet... Please change the draft such that trait access
is clearly discussed in context of other access methods.

regards.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 27 March 2005 19:27:23 UTC