[whatwg] Spec comments, section 4.8

[Ian Hickson]

On Mon, 17 Aug 2009, Aryeh Gregor wrote:
> 
> It's kind of a nitpick, but I don't think this sentence is accurate: 
> "Another example of an image that defies full description is a fractal, 
> which, by definition, is infinite in complexity."
> 
> First of all, we're talking about describing images here, which are 
> presumably projected onto finite-resolution displays, and which are 
> certainly being processed by finite-resolution retinas.  Visually, it's 
> not possible for anything to have infinite complexity.
> 
> Second of all, mathematically, fractals are rather interesting things, 
> but "infinite in complexity" is not a correct description by any 
> definition of complexity I'm aware of.  Fractals are often generated by 
> very simple definitions or computer programs, so they have low 
> Kolmogorov complexity.  Something like a Sierpinski triangle is very 
> simple to explain, understand, draw, and picture.  You could describe 
> one like this: "An equilateral triangle pointing upward.  A 
> downward-pointing triangle of half the height has been removed from the 
> middle, leaving three upward-pointing triangles each half as tall as the 
> original.  From each of those three, another downward-pointing triangle 
> has been removed, leaving nine quarter-height triangles, and so on ad 
> infinitum."  That's an accurate and precise description.
> 
> I'm not sure fractals are a good example here at all.  But if they are, 
> at least the text ", which, by definition, is infinite in complexity" 
> should be removed.

I've changed "complexity" to "detail". Since the image could be an 
animated SVG continuously zooming into one point, I don't think the 
use of finite-resolution displays prevents the images from being, for all 
intents and purposes, infinite.


> The NETWORK_LOADED state is described (normatively) as "The entire media 
> resource has been obtained and is available to the user agent locally.  
> Network connectivity could be lost without affecting the media 
> playback."  This suggests to me that it would be incorrect for this to 
> be the state of the resource if, during playback of a lengthy video, the 
> user agent began deleting the already-played earlier part of the video, 
> so that the full data was no longer available.  However, the resource 
> fetch algorithm sets NETWORK_LOADED regardless of whether earlier parts 
> of the resource are still available, and nothing I can see ever changes 
> the network state from NETWORK_LOADED to any other state.  This seems 
> contradictory, or at least confusing.

Fixed.


> 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.

You need a better font.


> "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".

Changed to "HTTP range retrieval requests".


> "The user agent cannot be in this state if playback has ended, as the 
> current playback position can never advanced in this case."
> 
> "advanced" -> "advance"?

Fixed.


> "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.

Fixed.


> This isn't really a comment, since it's too late to change it, but I'm 
> curious: why is the default that the author provides controls, instead 
> of the UA?  It seems like it would be simpler for the UA to supply 
> controls unless the author opts out.  Would you expect many authors to 
> manually supply controls?

I do not recall.


> Is "The user agent stops fetching the media data before it is completely 
> downloaded" really a good description for abort?  It can trigger during 
> the NETWORK_LOADED state, can't it?  Also, doesn't it only fire when the 
> load is aborted by the user or a script?

Not sure what you mean. When else would it abort? What other description 
would you use?


> "play" and "playing" have confusingly similar names.

Do you mean the events? If so, then I agree. Not sure what to do about it.


On Tue, 18 Aug 2009, Kevin Benson wrote:
> 
> [...] 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 
> ⌛.),"

I've tried to add something to that paragraph to explain the hourglasses 
more.


> ["HTTP partial range 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"

HTTP 1.1 seems quite inconsistent in its use of terminology here. To 
maximise the chance of readers being able to find the right section of the 
spec, I've just used the term used in the table of contents in HTTP 1.1.


On Tue, 18 Aug 2009, Kevin Benson wrote:
>
> Maybe the symbol being used for the Resource Fetch Algorithm steps, 
> (further down) where it reads "resource fetch algorithm for a media 
> element and a given absolute URL":
> 
> ↪ 'RIGHTWARDS ARROW WITH HOOK' (U+21AA)
> 
> would work better (for marking the "Steps in synchronous sections") as 
> an intermediary pointer symbol that follows the step number and precedes 
> the step description because there is precious little whitespace 
> between, whereas the "resource fetch algorithm" subsections have no 
> numbering scheme to deal with _and_ all whitespace to the left of the 
> steps' descriptions. (ie. Any bulleting symbol would suffice and serve 
> the purpose.)
> 
> Or it could be browser- and font-agnostic enough to even facilitate display
> in IE :)
> Something like, maybe common math symbols such as:
> 
> ≈ 'ALMOST EQUAL TO' (U+2248)
> or
> ± 'PLUS-MINUS SIGN' (U+00B1)
> 
> or whatever. (Just thinking aloud.)

The character isn't critical to the understanding of the section, it's 
just a reminder to the reader. As such, I'd rather it was time-related 
(the hourglass was the most suitable symbol I could find) than that it 
display everywhere today (the hourglass will display everywhere once 
people upgrade to modern fonts).


Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'