Re: [SVGMobile12] Comments: Document Structure (partial comments)

On Tuesday, May 17, 2005, 9:57:28 PM, Boris wrote:

BZ> 5.1.1

BZ> What happens if an <svg> element contains both SVG and non-SVG
BZ> elements? Do we still have an "SVG document fragment"?

Yes.

BZ> If so, which nodes does it contain? All SVG nodes which have the
BZ> <svg> as ancestor? Or only those nodes that are in a maximal
BZ> SVG-node-only subtree?

This links to and is is fully described in the conformance section,
under 'Conforming SVG Document Fragments'.

BZ> I think using "stand-alone" to describe an XML document that has 
BZ> |standalone="no"| (second example in this section) is somewhat confusing.

Agreed - the XML 'standalone' relates to the infosets obtained when
parsing with and without the external DTD subset, which SVG Tiny 1.2
does not have. We have removed standalone declarations from the
examples.

BZ> "An SVG document fragment can only contain one single 'svg' element,
BZ> this means that 'svg' elements cannot appear in the middle of SVG
BZ> content." -- what happens if they do?

Then they are not conforming.

BZ> 5.1.2

BZ>    For SVG 1.2, the attribute should have the value "1.2".

BZ> That implies that this is optional.

Or rather, that it should have that value, but there can be reasons to
not give it that value and thus, it is not a must.

BZ>   What if it doesn't?

The spec now says "See rules for version processing for further
instructions, notably on handling unsupported values. ", where 'version
processing' links to those rules.

BZ> The <meet> part of the preserveAspectRatio attribute is called
BZ> <meetOrSlice> elsewhere in this specification.

Agreed, we have ensured that it says 'meet' throughout.

BZ> "Indicates if the content can be seeked backwards or not." -- there
BZ> is no past participle "seeked" in the English language and the
BZ> general grammar of this sentence should be fixed (for example, "if"
BZ> is being used where "whether" should be used).

It now says "Indicates whether it is possible to seek backwards. "

BZ> Why is the string "playbackOrder", used three times in this paragraph, linked
BZ> once, and in blue twice (including the time it's linked)?  Please be consistent
BZ> with this!

It happens to be styled blue because the markup is
<span class="attr-name">playbackOrder</span>
we have ensured that this is consistent now.

BZ> The acronym "UI" which is used here is not defined anywhere.

We have expanded it inline to 'user interface'.

BZ> "An SVG document should include a viewBox attribute on the 'svg'
BZ> element of the referenced document." -- which referenced document?
BZ> What if it doesn't? It's not clear to me what this sentence means.

Due to this and other comments on this section, it now reads

  Content produced by illustration programs originally targeted at print
  often has a fixed width and height, which will prevent it scaling for
  different display resolutions. The first example below has a fixed
  width and height in pixels, and no viewBox.

  Normally, SVG content is designed to be scalable. Such content must
  include a viewBox attribute on the 'svg' element. This describes the
  region of world coordinate space (the initial user coordinate system)
  used by the graphic. This attribute thus provides a convenient way to
  design SVG documents to scale-to-fit into an arbitrary viewport.

  The second example is scalable, using a viewBox rather than a fixed
  width and height.

BZ> The phrase "world coordinate space" is not defined anywhere that I
BZ> can see.

It has its normal computer graphics meaning, but we clarified this with
a parenthetical note, as you can see above.

BZ> The examples "width-height.svg" and "viewBox.svg" tell me absolutely
BZ> nothing about what specifying the viewBox actually does. The correct
BZ> behavior for these examples should probably be described.

One of them declares a coordinate system and is scalable, the other does
not, has a fixed width and height and is not scalable.

BZ> 5.2.1

BZ> It's not clear whether the <g> element itself is painted, and if so
BZ> how.

It is not clear how a 'g' element *could* be painted.

BZ> 5.4

BZ> The terms "simple duration" and "active duration" are used in this
BZ> section without having been defined anywhere. Please link to their
BZ> definitions.

These now link to their definitions in SMIL 2.0

BZ> What does "The removal operation acts as if the method removeChild
BZ> was called on the parent of the target element" mean?

This now says

  The 'discard' element has an implicit simple duration of 'indefinite'.
  As soon as the element's active duration starts, the user agent
  discards the element identified by the 'xlink:href' attribute. The
  removal operation acts as if the method removeChild were called on the
  parent of the target element with the target element as parameter. The
  user agent must remove the target node as well as all of of its
  attributes and descendants. If the attribute is not specified, the
  effect is as if a value of "0s" were specified. This indicates that
  the target element should be discarded immediately.

'removeChild' links to its definition. Its the normal DOM operation. The
child is removed.

BZ>  Note that it's
BZ> not clear whether this means |parent.removeChild()|,
BZ> |parent.removeChild(child)|, or |removeChild(parent)|.

The text above should clarify that it is parent.removeChild(child)

BZ>  Also, should
BZ> the relevant DOM events fire?

Yes (if you mean DOM mutation events)

BZ> Should it be possible, via DOM, to reinsert the discarded content
BZ> elsewhere in the document tree? If so, what should happen?

Only if you already have a copy of it - otherwise, its gone.


BZ> 5.5

BZ> "where the description is text-only" -- what if it's not?

We now say

  This description is typically text, but can be content in other markup
  languages (see foreign namespaces).

BZ> What is the difference between <desc> and <title>? Why are both
BZ> present here?

Because desc is more like HTML longdesc, while title is more like HTML
title. Except that both are elements, as recommended by the I18n folks.

BZ> "If user agents need to choose among multiple 'desc' or 'title'
BZ> elements for processing (e.g., to decide which string to use for a
BZ> tooltip), the user agent shall choose the first one." This should
BZ> probably be a "must", not a "shall".

Both shall and must are RFC2119 keywords.

BZ> 5.6

BZ> What does "contents of the referenced element" mean? Does it include
BZ> the referenced element itself? Example 05_13.svg seems to imply that
BZ> it does, but this is not clearly stated anywhere.

It does, yes. We have clarified this and now the text says

  The 'use' element has optional attributes x and y which are used to
  place the referenced element and its contents into the current
  coordinate system.

BZ> The term "deeply cloned child of the 'use' element" is used
BZ> repeatedely without being defined. I'm not quite sure what it means.

BZ> The term "instance tree" is used without being defined. I'm not
BZ> quite sure what it means.

We now say

  Any 'g' or graphics element is potentially a template object that can
  be re-used (i.e. "instantiated") in the SVG document via a 'use'
  element, thus creating an instance tree. The 'use' element references
  another element and indicates that the graphical contents of that
  element is to be included and drawn at that given point in the
  document.

and

   The effect of a 'use' element is as if the SVG element contents of
   the referenced element were deeply cloned into a separate non-exposed
   DOM tree which had the 'use' element as its parent and all of the
   'use' element's ancestors as its higher-level ancestors. Because the
   cloned DOM tree is non-exposed, the SVG Document Object Model (DOM)
   only contains the 'use' element and its attributes. The SVG DOM does
   not show the referenced element's contents as children of 'use'
   element. The deeply-cloned tree, also refered to as the shadow tree,
   is then kept in synchronization with the contents of the referenced
   element, so that any animation or DOM manipulation occurring on the
   referenced element are also applied to the 'use' element's
   deeply-cloned tree.

Hopefully this is clearer.

BZ> The example using "visibility" should probably talk about computed
BZ> values, not specified values.

Yes. We have fixed this to refer to the computed values on the
referencing elements. We retained 'specified' on the referenced
elements, since it is the process of inheritance that is being
described; to refer to the computed value, which might be inherited,
would be circular and would leave it unclear where it was inherited from.

BZ> What happens if the <use> references an element that is not an SVG
BZ> element? Is the same procedure applied?

It then creates an empty shadow tree. Note the use of 'SVG elements' in
the definition above.


Thanks for your detailed comments. Please let us know shortly if they do
not respond to your comment.



-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Saturday, 12 November 2005 03:30:49 UTC