Re: [whatwg] Spec comments, section 4.8
On Wed, 2 Sep 2009, Aryeh Gregor wrote: > On Wed, Sep 2, 2009 at 6:17 PM, Ian Hickson wrote: > >> "The user agent stops fetching the media data before it is completely > >> downloaded" implies that 1) it cannot occur after the media is > >> completely downloaded, > > > > Correct. > > Okay, then I was reporting the wrong part of the contradiction. It says > "networkState equals either NETWORK_EMPTY or NETWORK_LOADED, depending > on when the download was aborted." I believe NETWORK_LOADED should be > NETWORK_LOADING. The same is probably true for the error event. Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec comments, section 4.8
On Wed, Sep 2, 2009 at 6:17 PM, Ian Hickson wrote: >> "The user agent stops fetching the media data before it is completely >> downloaded" implies that 1) it cannot occur after the media is >> completely downloaded, > > Correct. Okay, then I was reporting the wrong part of the contradiction. It says "networkState equals either NETWORK_EMPTY or NETWORK_LOADED, depending on when the download was aborted." I believe NETWORK_LOADED should be NETWORK_LOADING. The same is probably true for the error event. > I've added a mention that this is not an error condition. Does that work? Yes, that's clearer.
Re: [whatwg] Spec comments, section 4.8
On Fri, 28 Aug 2009, Aryeh Gregor wrote: > On Thu, Aug 27, 2009 at 10:23 PM, Ian Hickson wrote: > >> > >> 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? > > "The user agent stops fetching the media data before it is completely > downloaded" implies that 1) it cannot occur after the media is > completely downloaded, Correct. > and 2) it will fire if the user agent stops for any reason, e.g., if the > network connection fails or the server closes the connection. I've added a mention that this is not an error condition. Does that work? > As far as I'm reading the normative portion of the spec, neither of > those points is true. How so? (I've made the section explicitly non-normative.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec comments, section 4.8
On Thu, Aug 27, 2009 at 10:23 PM, Ian Hickson wrote: > You need a better font. Well, it's the default Ubuntu sans-serif font, I think. I guess I'm better off than the people viewing in IE6. :) >> 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? "The user agent stops fetching the media data before it is completely downloaded" implies that 1) it cannot occur after the media is completely downloaded, and 2) it will fire if the user agent stops for any reason, e.g., if the network connection fails or the server closes the connection. As far as I'm reading the normative portion of the spec, neither of those points is true. (Actually, this sentence also seems to be normative? At least, I don't see it set off as informative by anything.)
Re: [whatwg] Spec comments, section 4.8
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
Re: [whatwg] Spec comments, section 4.8
On Tue, Aug 18, 2009 at 10:34 AM, Aryeh Gregor > wrote: > On Tue, Aug 18, 2009 at 6:45 AM, Kevin Benson > wrote: > > Their purpose is described later in 4.8.10.5 Loading the media > > resource at step 20: > > Yes, but maybe a different character could be chosen, if this one > doesn't consistently display in browsers. Agreed. 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.) > > > 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) > > But ends with a colon, which together with "the following" suggests a > list of some sort was meant to come after it. Yeah, I missed that colon, but the features _are_ listed after these sentences. It just doesn't stand out as _a list_ . > > > > Sentence #3 Recommends unobtrusive implementation of UI features (for > > client's sake). > > Which duplicates sentence #1, even though that was only two sentences > before. So again it looks to me like there was originally something > in between that made this look less redundant. As it stands it > definitely reads strangely to me, anyway. > > (I looked in the version history, but it didn't explain much. The > paragraph was added as-is in r678 commented out, then uncommented in > r697.) > I agree that the intent was probably superseded by the result. I almost get the sense that the pairs of sentences were originally reversed (or the alternating sentences were). Anyways, words and sentences can _always_ be condensed and combined. Clarity remains the objective and redundancy the enemy. -- -- -- -- ô¿ô¬ K e V i N /¯\
Re: [whatwg] Spec comments, section 4.8
On Tue, Aug 18, 2009 at 6:45 AM, Kevin Benson wrote: > Their purpose is described later in 4.8.10.5 Loading the media > resource at step 20: Yes, but maybe a different character could be chosen, if this one doesn't consistently display in browsers. > 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) But ends with a colon, which together with "the following" suggests a list of some sort was meant to come after it. > Sentence #3 Recommends unobtrusive implementation of UI features (for > client's sake). Which duplicates sentence #1, even though that was only two sentences before. So again it looks to me like there was originally something in between that made this look less redundant. As it stands it definitely reads strangely to me, anyway. (I looked in the version history, but it didn't explain much. The paragraph was added as-is in r678 commented out, then uncommented in r697.)
Re: [whatwg] Spec comments, section 4.8
On Mon, Aug 17, 2009 at 8:27 PM, Aryeh Gregor 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." "playingEvent 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 /¯\
[whatwg] Spec comments, section 4.8
In 4.8.2.1.9: 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. In 4.8.10.4: 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. 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. "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". In 4.8.10.7: "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"? 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. 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? In 4.8.10.12: 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? "play" and "playing" have confusingly similar names.
