Re: Comments for PR-smil-animation-20010719

Chris,

You should fix these bugs as you are the staff contact for this document.


----- Original Message -----
From: "Susan Lesch" <lesch@w3.org>
To: <www-smil@w3.org>
Sent: Wednesday, August 01, 2001 7:55 AM
Subject: Comments for PR-smil-animation-20010719


> 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
> sheet:
> 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
>     [RFC2396].
> and then add that RFC as a reference.
>
> 3.2.1 begin
> semi-colon separated
> semicolon-separated
>
> semi-colon
> semicolon
>
> 3.2.1 Handling negative offsets for begin
> "This section is informative" comes before dur.
>
> 3.3.1
> to to
> to
>
> 3.3.2 end
> a "endElement()"
> an "endElement()"
>
> 3.3.6
> When an element restarts, certain state is "reset":
> (Not sure what that means.)
>
> 3.6.3
> play, will be
> play will be
>
> 3.6.7
> It is modeled on the HTML accessKey support.
> It is modeled on the HTML accesskey support.
>
> 3.6.8
> Similarly, Instance times
> Similarly, instance times
>
> INDEFINITE and UNRESOLVED can be marked up <code>.
>
> 8.
> 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 06:52:18 UTC