W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2009

[whatwg] Spec comments, section 4.8

From: Kevin Benson <kevin.m.benson@gmail.com>
Date: Tue, 18 Aug 2009 06:45:29 -0400
Message-ID: <7c7658460908180345h18c6b37w990b4bced28c12ec@mail.gmail.com>
On Mon, Aug 17, 2009 at 8:27 PM, Aryeh Gregor<Simetrical+w3c at gmail.com> wrote:
> In 4.8.10.5:
>
> There are some Unicode characters (U+231B? an hourglass?) here that
> are showing up as white boxes for me at the beginning of some of the
> list elements.
>

Their purpose is described later in 4.8.10.5 Loading the media
resource at step 20:

"(Steps in synchronous sections are marked with ?.)"

and noted again in 6.5.4.2 Processing model at step 4:

"Note: Steps in synchronous sections are marked with ?."

but the potential for confusion could be further mitigated with an
earlier reference to their purpose... perhaps in "4.8.10.5 Loading the
media resource" at step 9 with an addition to this phrase:

"This algorithm is always invoked synchronously,"

that instead reads something like:

"This algorithm is always invoked synchronously (see steps marked with ?.),"


> "HTTP partial range requests" sounds odd to me, and "partial range" is
> redundant.  Maybe just "HTTP range requests"?  The HTTP spec uses
> "range retrieval requests".
>

I suspect this type of phrasing is born of human desire to shorten
technical jargon into more "familiar" terms for frequent usage. My
examination of the terminology most commonly used in RFC 2616 (related
to what Ian's s trying to convey) suggests (to me) this simple change:

"HTTP partial content range requests"

>
> In 4.8.10.10:
>
> "If the attribute is absent, then the user agent should avoid making a
> user interface available that could conflict with an author-provided
> user interface. User agents may make the following features available,
> however, even when the attribute is absent:
>
> "User agents may provide controls to affect playback of the media
> resource (e.g. play, pause, seeking, and volume controls), but such
> features should not interfere with the page's normal rendering. For
> example, such features could be exposed in the media element's context
> menu."
>
> This doesn't make a lot of sense to me.  I would have expected a list
> of features after the first quoted paragraph, but instead there's
> another paragraph that partially repeats the content of the first
> paragraph.  It reads like it originally said something different, and
> then something was chopped out and not patched up properly.
>

My reading of those paragraphs (two pairs of sentences) suggests (to
me) that some _do_ share purpose (unobtrusive implemetation) or target
(for _whose_ sake) but each seems to "make sense" (to me):

Sentence #1 Recommends unobtrusive implementation of UI features (for
author's sake).
Sentence #2 Permits override of boolean attribute for implementation
of UI features. (for UA's sake)

Sentence #3 Recommends unobtrusive implementation of UI features (for
client's sake).
Sentence #4 Illustrates how implementation of UI features can be both
unobtrusive and avoid interrupting page rendering. (for UA's sake)

---

Perhaps a simple clarification could be effected by changing:

"may make the following features available"

to something like:

"may make the features in this subsection available"


> In 4.8.10.12:
>
> "play" and "playing" have confusingly similar names.
>

I see (only) the unavoidable shared similarity of description (common
to this _Dispatched when..._ column) which Ian currently addresses
through word variations such as "begun" vs. "started"):

"play	Event	Playback has begun."
"playing	Event	Playback has started."

In combination with the additional information shown in their
respective  _Preconditions_ columns, there shouldn't be too much
confusion by the consumer. It doesn't seem any different than:

"load" vs. "loadend"  _or_ "seeking" vs. "seeked"

-- 
-- 
   --
       --
       ????
    K e V i N
   /?????????\
Received on Tuesday, 18 August 2009 03:45:29 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:15 UTC