W3C home > Mailing lists > Public > www-smil@w3.org > July to September 2001

Comments for PR-smil-animation-20010719

From: Susan Lesch <lesch@w3.org>
Date: Tue, 31 Jul 2001 22:55:29 -0700
Message-Id: <p0510030bb78d49d20e69@[]>
To: www-smil@w3.org
Belated congratulations on your SMIL Animation Proposed Recommendation
[1]. Here are a few comments; some are things I missed at Last Call.

In the style sheet, the TOC background would benefit from padding:
/* Table of contents styles */
div.toc { background-color: #ccccff; border: none;
           margin-right: 5%; padding: .75em; }

If you want blue headings, use the h1, h2, h3 color in the REC style
h4, h5, h6 { ... color: #005a9c; }

These three images are marked up 323x191 and are distorted:
DiscreteGraph.png is 313x184.
LinearGraph.png is 321x183.
PacedGraph.png is 315x185.
Also, AccumGraph.png is marked up 471x88 and is 469x82.

The headings "This section is normative" and "This section is
informative" are there sometimes, and sometimes not. An easy way to be
consistent would be to omit them. At least, the heading for the 'dur'
attribute in 3.2.1 needs clarifying; right now 'dur' is informative.

I didn't find a conformance section; one should really be an item in
the TOC. After one read-through it wasn't clear what is required of
either a SMIL Animation user agent or author. Section 3.6.8 especially
struck me as a lot of prose without delineated conformance points. (I
did see your notes on host languages in section 5.)

It would be a lot of work perhaps, but helpful, if all elements and
attributes were marked up <code> or some colored class, to
differentiate them from running text. (Now, the reserved words in SMIL
Animation seem to drift back and forth from plain text to marked up.)

Are you using the key words "MUST", "MUST NOT", "REQUIRED", "SHOULD",
"SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" as described in RFC
2119? If you are, the spec should say so and give the RFC as a
reference, and if you are not, explain why.
See http://www.rfc-editor.org/rfc/rfc2119.txt.

Globally, Bezier should read Bézier.

Below, a section number is followed by a quote and then a suggestion.

Status of this document par. 7
also), these may
also); these may

3.1 target attribute (twice)
XMLNS prefix
xmlns or <code>xmlns</code> prefix

3.1 target element
href = uri-reference
href = URI-reference

Also, as you do for IDREF, you could say:
    For a formal definition of "URI-reference", refer to RFC 2396
and then add that RFC as a reference.

3.2.1 begin
semi-colon separated


3.2.1 Handling negative offsets for begin
"This section is informative" comes before dur.

to to

3.3.2 end
a "endElement()"
an "endElement()"

When an element restarts, certain state is "reset":
(Not sure what that means.)

play, will be
play will be

It is modeled on the HTML accessKey support.
It is modeled on the HTML accesskey support.

Similarly, Instance times
Similarly, instance times

INDEFINITE and UNRESOLVED can be marked up <code>.

Before "Available at:" I think you want punctuation in [DATETIME],
[DOM-Level-2], [DOM2CSS], and [DOM2Events].

[1] http://www.w3.org/TR/2001/PR-smil-animation-20010719/

Best wishes for your project,

Susan Lesch - mailto:lesch@w3.org  tel:+1.858.483.4819
World Wide Web Consortium (W3C) - http://www.w3.org/
Received on Wednesday, 1 August 2001 01:55:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:23 UTC