[whatwg] Kinds of Content
Hi, All elements currently defined to be in the heading content category (h1-h6 and header) are also included within the flow content category. It seems that it would be easier and more consistent to state the definition of heading content that: All heading content is also flow content. Any content model that expects flow content also expects heading content. And then remove Flow content from category lists for those elements, as it would be implied by Heading content. Additionally, to improve readability, it would be useful to add a note to the definition of flow content that it includes all of heading content, phrasing content and embedded content; and a similar note in the definition of phrasing content that it includes embedded content. Finally, it would be useful if the spec eventually included some kind of diagram that illustrated the relationships between each of the categories. http://www.whatwg.org/specs/web-apps/current-work/#kinds-of-content -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Terminate a Worker algorithm
1) The algorithm assumes that a WorkerGlobalScope exists, and doesn't specify what happens if it is invoked before WorkerGlobalScope is created (e.g. if the script is still being loaded, or the scope is being created, but Worker.terminate() is called from JS). I think that the right behavior is to re-invoke the algorithm after the scope is created, because it may be too late to prevent its creation. 2) Events in WorkerGlobalScope event queue are dropped when terminating a worker, but messages posted to Worker are not. I think that the expected behavior is that after calling Worker.terminate(), no messages will be dispatched to worker's event listeners. 3) If there are any events in the queue of events other than the close event that this algorithm just added, discard them without dispatching them. - I don't see where the close event is added for terminate algorithm, and this looks like a copy/paste mistake, because the event won't be dispatched anyway. - WBR, Alexey Proskuryakov
Re: [whatwg] Deprecating small , b ?
On Mon, 17 Nov 2008 15:26:22 +0100, Smylers [EMAIL PROTECTED] wrote: In printed material users are typically given no out-of-band information about the semantics of the typesetting. However, smaller things are less noticeable, and it's generally accepted that the author of the document wishes the reader to pay less attention to them than more prominent things. That works fine with small. No, it doesn't, and you explain why yourself here: User-agents which can't literally render smaller fonts can choose alternative mechanisms for denoting lower importance to users. If the point isn't to literally render smaller fonts, you shouldn't indicate that you want the fonts rendered smaller either. What you want is to semantically indicate that the text wrapped inside the element is of less significance than the surrounding text, e.g. a negative 'strong' or 'em'. Just as 'b' isn't equal to 'strong', 'small' isn't equal to what we're trying to express here. What we need is a new element that can capture this semantic. Denoting particular text as being of lessor importance is quite different from choosing the overall base font size (or indeed typeface) for the page, or the colour of links or headings -- that's merely expressing a preference for how graphical user-agents should render particular semantics, but the semantics themselves are conveyed to _all_ user-agents (a, h3, etc). Which is why we need to capture this as semantic and not as presentational sugar. Indeed you can't. And nor can you if you were reading printed text with some words in bold. Why does printed text set the standard for what we are able to express with a markup language? Does e.g. PDF in any way direct what should be possible with HTML? However, you would appreciate that the author had wished for some particular words to stand out from the surrounding text. That's a job for the style sheet, whether it's provided by the author or by the user agent. Using the same element would in most circumstances yield the same presentation. Isn't that what you want? However, you can only notice this if the words have been distinguished in some way. With b, all user-agents can choose to convey to users that those words are special. They are only special for sighted users, browsing the page with a rather advanced user agent. They are not special to blind users or to users of text-based user agents like Lynx. If you want to express semantics, then use a semantic element. Expressing semantics through presentation only is done in print because of the limitations in the printing system. If the print was for a blind person, printed with braille, one could imagine (had it been supported) that letters with a higher weight could be physically warmer than others, or with a more jagged edge so they could stand out. Such effects would have been impossible if the document was only tagged with presentational markup. The same applies to other mediums than print -- you need to know the underlying reason of why something is presented the way it is to transfer that presentation to another environment. And for that you need the semantics. -- Asbjørn Ulsberg -=|=-[EMAIL PROTECTED] «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] Deprecating small , b ?
Asbjørn Ulsberg writes: On Mon, 17 Nov 2008 15:26:22 +0100, Smylers [EMAIL PROTECTED] wrote: In printed material users are typically given no out-of-band information about the semantics of the typesetting. However, smaller things are less noticeable, and it's generally accepted that the author of the document wishes the reader to pay less attention to them than more prominent things. That works fine with small . No, it doesn't, and you explain why yourself here: User-agents which can't literally render smaller fonts can choose alternative mechanisms for denoting lower importance to users. I don't see how that explains why small is an inappropriate tag to use for things which an author wishes to be less noticeable. If the point isn't to literally render smaller fonts, you shouldn't indicate that you want the fonts rendered smaller either. Indeed. font size=-1 would be bad to use for this. What you want is to semantically indicate that the text wrapped inside the element is of less significance than the surrounding text, e.g. a negative 'strong' or 'em'. Yes. And I reckon than small works for that. English has the idiom of 'small print', roughly meaning text written by the legal department rather than the marketing department. But 'small print' doesn't literally have to be typeset with a smaller font; it's a figure of speech. 'small' isn't equal to what we're trying to express here. What we need is a new element that can capture this semantic. If we were starting from scratch then indeed small may not be the best name to choose for this element. But, unfortunately, we aren't. small has existed for some time, and people are already using it. If one currently wants to denote lessor importance small is the best element to pick. Further, existing browsers know what to do with small; if we introduce a new element then content that uses it will have a sub-optimal rendering in current browsers, whereas small already does something appropriate. So I still think small works for denoting that something is of smaller importance. Indeed you can't. And nor can you if you were reading printed text with some words in bold. Why does printed text set the standard for what we are able to express with a markup language? It doesn't set the standard. But it's useful in some comparisons. And most of the time humans cope perfectly well with inferring typographic conventions without having them spelt out. However, you would appreciate that the author had wished for some particular words to stand out from the surrounding text. That's a job for the style sheet, whether it's provided by the author or by the user agent. The style-sheet can only pick out particular words if those words have been marked-up as special in the document, so it doesn't solve the problem of how to mark them up. Further, this isn't using b because the house style is to have all text in a bold weight (that can be done by style-sheets, and if the style-sheet is missing all the content is still there); it's using b to convey _some_ semantics: namely that those particular words are in some way special. So if the mark-up is span class=brand_name or similar and the distinguishing presentation added with CSS then users without style-sheets are completely unaware that the author identified those words as being special. Whereas with b, everybody gets to know. However, you can only notice this if the words have been distinguished in some way. With b , all user-agents can choose to convey to users that those words are special. They are only special for sighted users, browsing the page with a rather advanced user agent. They are not special to blind users or to users of text-based user agents like Lynx. Not true. Any user-agent can choose to convey that words marked in b are somehow different from the surrounding words. Lynx does this. If you want to express semantics, then use a semantic element. That's begging the question. If we define b to be semantic, then it is! Expressing semantics through presentation only is done in print because of the limitations in the printing system. Well, yes. If the print was for a blind person, printed with braille, one could imagine (had it been supported) that letters with a higher weight could be physically warmer than others, or with a more jagged edge so they could stand out. Yup -- and an HTML-to-braille converter could choose to do that with words marked in b, whereas it couldn't with span class=BrandName. Such effects would have been impossible if the document was only tagged with presentational markup. To some extent, yes: not knowing whether a letter is where it is on the page because it's a start of a paragraph or a heading, or just because the previous line is full, hampers doing that. And similarly for typefaces. The same applies to other mediums than print -- you need to know the underlying reason of why
Re: [whatwg] Deprecating small, b ?
Nils Dagsson Moskopp wrote: The small element represents small print [...] The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance [...] Both definitions seems rather presentational (contrasting, for example, the new semantic definition for the i element) and could also be realized by use of span elements. To me these look like the last remnants of the font element. So why are these elements retained ? This issue has been discussed in depth in the past; most significantly on public-html around May 2007. http://lists.w3.org/Archives/Public/www-html/2007May/thread.html#msg3 (I think most of the releant discussion is in the Cleaning House thread) I have added an entry to the FAQ detailing the rationale for including these elements, and have previously written an article about the issue too. http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F http://lachy.id.au/log/2007/05/b-and-i http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Deprecating small , b ?
On 2008/11/24 16:19 (GMT) Smylers composed: So I still think small works for denoting that something is of smaller importance. I do too, but I don't believe less importance can be the only inference. One could simply want smaller text, without expecting that inference. e.g., just because fine print legalese is called what it is doesn't doesn't necessarily make it unimportant or less important. I'm for keeping small in the spec. -- Love is not easily angered. Love does not demand its own way. 1 Corinthians 13:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/
Re: [whatwg] Deprecating small , b ?
Felix Miata writes: On 2008/11/24 16:19 (GMT) Smylers composed: So I still think small works for denoting that something is of smaller importance. I do too, but I don't believe less importance can be the only inference. One could simply want smaller text, without expecting that inference. If you just want something to be smaller stylistically and there's nothing special about that portion of the text then I think using small for it would be as bad as using h1 just to make text bigger; CSS is a better choice. e.g., just because fine print legalese is called what it is doesn't doesn't necessarily make it unimportant or less important. It's less important in the sense that it isn't the point of what the author wants users to have conveyed to them; it's less important to the message. (Of course, to users any caveats in the small print may be very important indeed!) Smylers
Re: [whatwg] media elements: Relative seeking
I don't think you mean 'relative' here, which I would take to be go forward 10 seconds, but 'proportional', please go to 60% of the way through. IF we are to do this, I would have thought it would be by adding units to the where to seek to argument: * go to this time in NPT (normal play time, which runs from 0 to media duration) * go to this SMPTE time code * go by this relative distance in NPT times * go to this proportional time * go to this proportional byte distance * go by this relative byte distance Note that proportional distances are not well defined for some streams (e.g. indefinite ones). We'd have to define what bytes are counted and what aren't, especially if a URL offers a set of sub-streams only some of which a client would normally choose to have sent to it for playing. At 17:08 +0100 23/11/08, Maik Merten wrote: Hello, currently seeking in the media elements is done by manipulating the currentTime attribute. This expects an absolute time offset in seconds. This works fine as long as the duration (in absolute time) of the media file is known and doesn't work at all in other cases. Some media formats don't store the duration of the media file anywhere. A client can only determine the duration of the media file by byte-seeking near the end of the file and finding a timestamp near/at the end. This isn't a problem whatsoever on local files, but in remote setups this puts additional load on the server and the connection. If one would like to avoid this, meaning no duration is known, seeking in absolute time cannot work. While getting the absolute duration is often a problem retrieving the length of the media file is is no problem. I propose seeking with relative positions, e.g. values between zero and one. This way the client can determine if to seek in absolute time (if the duration is known) or to just jump into to a position of the bytestream (if the length in bytes is known). - make currentTime readonly, still have it report playback position in absolute time. This information should be available in all media formats due to timestamps in the stream. - introduce a seek() method, taking a relative value ranging from zero to one. This allows both accurate seeking if the duration is known and less precise seeking otherwise if only the length of the file is known in storage units. This is still way better than not being able to seek at all. - make duration report either the duration in absolute time (if known) or the length of the file in storage units. This enables computation of a relative playback position even when no duration is known, if the byte position of the stream is known (low precision fallback - still better than nothing at all). - introduce a readonly storagePosition attribute. Meant to compute a relative position if the duration is only known in storage units. Maik -- David Singer Multimedia Standards, Apple Inc.
[whatwg] MetaExtensions wiki page
Hello, I guess this is more a cosmetic remark, but I thought I'd bring this up anyway. I've noticed that the paragraph on the MetaExtensions wiki page[1] still lists the Microformats process as the only way to get a keyword approved. The equivalent paragraph on the RelExtensions page[2] had been changed to ... or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. some time ago. Shouldn't both paragraphs be identical, or are @rel and meta values really handled differently? Cheers, Philipp Serafin [1] http://wiki.whatwg.org/wiki/MetaExtensions [2] http://wiki.whatwg.org/wiki/RelExtensions
Re: [whatwg] Deprecating small , b ?
On Mon, 24 Nov 2008 17:19:44 +0100, Smylers [EMAIL PROTECTED] wrote: I don't see how that explains why small is an inappropriate tag to use for things which an author wishes to be less noticeable. I was thinking mostly about the tag's current usage on the web, which is a crazy mix between the HTML4 and HTML5 definition of the element. HTML4 defines it purely presentational, HTML5 mostly semantical. In that context, I believe small is inappropriate. However, as you write and as HTML5 defines it, there is nothing wrong with small per se, and I agree that as an element indicating smallprint, it works just fine. Since my initial reply might have been a bit too colored by the HTML4 definition of the element and its current usage on the web, I hereby withdraw my comment and conclude that I mostly agree with you. :-) -- Asbjørn Ulsberg -=|=- [EMAIL PROTECTED] «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] media elements: Relative seeking
- Original Message Da: Eric Carlson lt;[EMAIL PROTECTED]gt; To: Silvia Pfeiffer lt;[EMAIL PROTECTED]gt; Cc: WHAT Working Group lt;whatwg@lists.whatwg.orggt;, Maik Merten lt;[EMAIL PROTECTED]gt; Oggetto: Re: [whatwg] media elements: Relative seeking Data: 24/11/08 03:17 gt; Silvia - gt; gt; On Nov 23, 2008, at 1:40 PM, Silvia Pfeiffer wrote: gt; gt;gt; I don't see addition of a duration attribute as much of a problem. We gt;gt; have width and height for images, and sizes for fonts, too, and web gt;gt; developers have learnt how to deal with these in various entities (px, gt;gt; em, pt). I would not have a problem giving web developers the gt;gt; opportunity to report the real duration of a video in an attribute in gt;gt; either bytes or seconds (might be better called: length), which would gt;gt; allow a renderer to display an accurate timeline. It is help for a gt;gt; display mechanism just as width and height are. gt; gt; Those attributes are different because they change the presentation gt; of the element: image width and height are the rendered width and gt; height, font-size controls fond rendering size, etc. In order for a gt; duration attribute to be equivalent we would need for it to limit the gt; amount of the file played (like the now-removed 'end' attribute did). gt; Well, the length attribute could be an indication about such limit and could accept a generic value, such as 'unknown' (or '0', with the same meaning - just to have only numerical values) to indicate an endless stream (i.e. a realtime iptv): in such a case, any seeking operation could be either prohibited or just related to the amount of yet played content which is eventually present in a local cache. gt;gt; In case of contradiction between the attribute and the actual decoded gt;gt; length, a renderer can still override the length attribute at the time gt;gt; the real length is known. In case of contradiction between the gt;gt; attribute and the estimated length of a video, the renderer should gt;gt; make a call based on the probability of the estimate being correct. gt; gt; In the case of a file with video or VBR audio the true duration gt; literally isn't actually known until *every* frame has been examined. gt; gt; When would you have the UA decide to switch from the attribute to gt; the to the real duration? I guess the U.A. could avail of an external codec, which could provide facilities to estimate the real duration: in this case everything would be as easy as just demanding the averaging an estimation to the codec, and getting the real/estimated duration as the result of a callback. gt; What would you have the UA do if the user seeks to time 90 seconds when gt; attribute says a file is 100 seconds long, but the file actually has a gt; duration of 80? gt; gt;eric Nothing special, according to me. Just update any visual time indicator, both for total and current time, and convert the previous seek value to a relative, percentage one, to normalize the requested position in respect to the real duration. That is, let's just switch from absolute to relative seeking as needed, it shouldn't be so difficoult, after all. Regards, Alex -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: CheBanca! La prima banca che ti dà gli interessi in anticipo. Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7916d=20081124
Re: [whatwg] Deprecating small , b
I was thinking mostly about the tag's current usage on the web, which is a crazy mix between the HTML4 and HTML5 definition of the element. HTML4 defines it purely presentational, HTML5 mostly semantical. In that context, I believe small is inappropriate. However, as you write and as HTML5 defines it, there is nothing wrong with small per se, and I agree that as an element indicating smallprint, it works just fine. Since my initial reply might have been a bit too colored by the HTML4 definition of the element and its current usage on the web, I hereby withdraw my comment and conclude that I mostly agree with you. :-) But isn't this just the reason why it should be dis-used? The HTML4 spec defined it as a styling tag, and that is how it is *mostly* used and understood by the majority of the users/authors. Just because HTML5 redefines the element does not mean that the element will suddenly be semantic. Even if people start using it purely semantically from now on (and what is the chance of that?), the existing websites still carry small-tags that are not compliant with the new definition. By redefining it the (existing) web breaks; allbeit purely in the semantic area.
Re: [whatwg] media elements: Relative seeking
nbsp; - Original Message Da: Maik Merten lt;[EMAIL PROTECTED]gt; To: WHATWG Proposals lt;whatwg@lists.whatwg.orggt; Oggetto: Re: [whatwg] media elements: Relative seeking Data: 24/11/08 08:45 gt; Eric Carlson schrieb: gt;gt; QuickTime has used this method this since it started supporting VBR gt;gt; mp3 in 2000, and in practice it works quite well. I am sure that there gt;gt; are degenerate cases where the initial estimate is way off, but gt;gt; generally it is accurate enough that it isn't a problem. An initial gt;gt; estimate is more likely to be wrong for a very long file, but each pixel gt;gt; represents a larger amount of time in the time slider with a long gt;gt; duration so changes less noticeable. gt; gt; Well, I do believe this works fine for audio (which usually hasn't a gt; wildly fluctuating bitrate if you e.g. average over a second or two), gt; I'm mostly concerned about video. An example for an outrageously off gt; estimate would be the trailer for Generic space-pirate movie. gt; gt; The first few seconds would be mostly a static green/red/yellow/whatever gt; screen (This pirate movie has been rated ARR!) - this part would gt; be coded with like 100 kbit/s or less. The next few scenes (this is a gt; trailer, after all) would mostly show exploding ships, genetically gt; engineered mutant parrots attacking space-adventurers and a few cuts gt; into random love scenes - so this part can be multi-megabit/s. After gt; this the bitrate would dramatically decrease again as the last few gt; seconds will just show Summer 2010. gt; gt; Does QuickTime also handle such content gracefully (e.g. display a gt; position slider that doesn't jump around wildly)? Am I overestimating gt; the problem? gt; Maik The slider should just indicate a relative position (i.e. a percentage) between 0 and the (currently known) duration of the content, which may be estimated with a variable average time, perhaps retarded at the beginning, and varied according to the bitrate variation with some euristic, to make the computation more accurate (or maybe a few consecutive evaluation, at fixed and rapid intervals, could be averaged to get a better value, before updating anything), so no crazy horse jumping should happen. Silvia Pfeiffer has proposed a 'length' attribute to indicate the overall duration in the markup, and I think its value could help to improve accuracy, even when wrong. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: CheBanca! La prima banca che ti dà gli interessi in anticipo. Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7919d=20081124
Re: [whatwg] Deprecating small , b
Pentasis wrote: I was thinking mostly about the tag's current usage on the web, which is a crazy mix between the HTML4 and HTML5 definition of the element. HTML4 defines it purely presentational, HTML5 mostly semantical. In that context, I believe small is inappropriate. However, as you write and as HTML5 defines it, there is nothing wrong with small per se, and I agree that as an element indicating smallprint, it works just fine. Since my initial reply might have been a bit too colored by the HTML4 definition of the element and its current usage on the web, I hereby withdraw my comment and conclude that I mostly agree with you. :-) But isn't this just the reason why it should be dis-used? The HTML4 spec defined it as a styling tag, and that is how it is *mostly* used and understood by the majority of the users/authors. Just because HTML5 redefines the element does not mean that the element will suddenly be semantic. Even if people start using it purely semantically from now on (and what is the chance of that?), the existing websites still carry small-tags that are not compliant with the new definition. By redefining it the (existing) web breaks; allbeit purely in the semantic area. Note that the semantic meaning that HTML5 gives it is very weak. All it says is that the text inside the b is different from the text outside it. All the existing uses on the web that I've seen are correct according to this semantic definition. Do you have any counter examples of this, where the b was containing something that was exactly semantically the same as the surrounding content? / Jonas
Re: [whatwg] media elements: Relative seeking
Eric, On Mon, Nov 24, 2008 at 1:17 PM, Eric Carlson [EMAIL PROTECTED] wrote: Silvia - On Nov 23, 2008, at 1:40 PM, Silvia Pfeiffer wrote: I don't see addition of a duration attribute as much of a problem. We have width and height for images, and sizes for fonts, too, and web developers have learnt how to deal with these in various entities (px, em, pt). I would not have a problem giving web developers the opportunity to report the real duration of a video in an attribute in either bytes or seconds (might be better called: length), which would allow a renderer to display an accurate timeline. It is help for a display mechanism just as width and height are. Those attributes are different because they change the presentation of the element: image width and height are the rendered width and height, font-size controls fond rendering size, etc. In order for a duration attribute to be equivalent we would need for it to limit the amount of the file played (like the now-removed 'end' attribute did). I see the length attribute as rendering help for the timeline, not the video. It would not relate to changing the actual video or the video's playback time. In case of contradiction between the attribute and the actual decoded length, a renderer can still override the length attribute at the time the real length is known. In case of contradiction between the attribute and the estimated length of a video, the renderer should make a call based on the probability of the estimate being correct. In the case of a file with video or VBR audio the true duration literally isn't actually known until *every* frame has been examined. So the length attribute is used for the timeline until we reach the end of the file or go past the given length. Not much of a problem, I'd say. When would you have the UA decide to switch from the attribute to the to the real duration? The browser would need to have it's own estimate of reliability of the length attribute. If there is a high probability that the length attribute is wrong, e.g. we have already played beyond the given length, or we have obviously too much data to decode for the given length, it would ignore the length attribute. I would however hope that web developers generally test their pages and the length attribute to make sure the display is correct. If that data is provided through a CMS, then the information should be correct anyway. What would you have the UA do if the user seeks to time 90 seconds when attribute says a file is 100 seconds long, but the file actually has a duration of 80? Realize that we have hit 80, that 100 cannot be right, update our knowledge of the actual length, update the timeline display and place the play pointer at the end, displaying a length of 80. That is the same problem as you get when you make a wrong estimate of length. length is only meant as a well-informed user hint. I think it solves more problems than it creates. But we won't know unless we implement and test it, I guess. :-) Regards, Silvia.
Re: [whatwg] Deprecating small , b
Am Montag, den 24.11.2008, 15:10 -0800 schrieb Jonas Sicking: Note that the semantic meaning that HTML5 gives it is very weak. All it says is that the text inside the b is different from the text outside it. All the existing uses on the web that I've seen are correct according to this semantic definition. Weak in this case means: Not of much semantic, probably only of presentational use. So can't we just mark all presentational elements as obsolete in a clear, consistenst way, instead of trying to redefine them ? Maybe put them into a presentational annex of the spec, that defines rendering of obsolete elements ? The thing I am concerned with is that if they are included like normal (read: semantic) elements, authors will probably use them for new pages. Cheers, Nils
[whatwg] Video metadata attributes clarification
Hi, I'm seeking clarification on when the videoWidth and videoHeight attributes are expected to become valid. Actually it'd probably be useful to have all of the metadata attributes listed explicitly somewhere so that it's clear exactly what is expected to be valid when readyState is HAVE_METADATA. Looking at section 4.8.7, the discussion of videoWidth says: If no video data is available, then the attributes must return 0. And the definition of no video data (mentioned a little later in the same section): When no video data is available (the element's readyState is either HAVE_NOTHING or HAVE_METADATA). Based on this, it seems like videoWidth and videoHeight should become valid at the time readyState reaches HAVE_SOME_DATA. However, the load algorithm in section 4.8.10.5 says, when discussing readyState reaching HAVE_METADATA (in step 11.4) says: the duration of the media resource, its dimensions, and other metadata. And just below that, at step 3: A number of attributes, including duration, buffered, and played, become available. I'm not clear if dimensions here refer to videoWidth and videoHeight, or the dimension attributes discussed in section 4.8.17. It seems that the latter would depend on the former anyway. In the lists of readyStates, for HAVE_METADATA, it says the metadata attributes are initialized (e.g. the length is known). Also, as mentioned, it'd be useful to have an explicit list of the metadata attributes that become available at that time. Cheers, -mjg -- Matthew Gregan |/ /|[EMAIL PROTECTED]
[whatwg] Solving the login/logout problem in HTML
As can be seen in the feedback below, there is interest in improving the experience with logging in and out of Web sites. Currently there are two main mechanisms: HTTP authentication, and cookie-based authentication with a form login. Benefits of form authentication over HTTP authentication: - supports creating an account - supports recovering a lost password - supports showing the login form inline with other content - supports styling the login form - supports an obvious way of logging out from within the page Limitations of form authentication: - no way to indicate that access is being denied because the credentials passed were wrong or because there were no credentials passed - insecure when unencrypted It seems to me that the first limitation of form authentication could be removed by inventing a new WWW-Authenticate challenge that means reply to the form in the page. I have now specified such a value in HTML5 (since it is specific to entity bodies that contain HTML forms): challenge = HTML [ form ] form = form = form-name form-name = quoted-string (There's no credentials value for this scheme, since the login is done as a POST to a login script and then the server sets proprietary login information, like a cookie using Set-Cookie.) So when you get to a page that expects you to be logged in, it return a 401 with: WWW-Authenticate: HTML form=login ...and there must be a form element with name=login, which represents the form that must be submitted to log in. We could also make HTTP login work better, but frankly I'm not convinced there's much point. The form login cowpath is so commonly frequented that not only has someone already gone and paved it but it has also been tree-lined, has garbage collection scheduled for Tuesdays and Thursdays, and will be electing a representative at the next general election. With all this in mind: On Fri, 17 Dec 2004, Matthew Thomas wrote: On 17 Dec, 2004, at 6:08 PM, Ian Hickson wrote: On Fri, 17 Dec 2004, Matthew Thomas wrote: Future browsers could, instead of displaying an alert for HTTP authentication, provide the authentication UI in a panel at the top of the non-authenticated page (fixing annoying modality issues in the process). That wouldn't require any change to HTTP authentication either. A very interesting idea. The problem with that is that if you show the 401 page at the moment, you'll get something like: 401 UNAUTHORIZED YOU DO NOT HAVE THE PROPER PERMISSIONS ___ Username: [_] Password: [___] (Login) [X] Well since I said at the top of the non-authenticated page, and since ~70 percent of sites use Apache, most of the time it would look more like this ... | Committee Members Area ID: [ ]| | foo.example.org Password: [ ] ( Log In ) | || || | AUTHENTICATION REQUIRED| :: which would be quite okay, since authentication required isn't contradicting anything. (Further, a really earnest browser might delay rendering of any unauthorized page to prevent FOUC, and then display the unauthenticated page only if it didn't contain the case-insensitive regexp 401*.unauthorized. That would be weird, but hardly weirder than Internet Explorer's current length-based overriding of server error messages.) I think this is still a good idea, but requires nothing of HTML5. We could get around that by saying that you can include WWW-Authenticate headers with 200 OK responses as well (nothing in HTTP seems to say you can't), and that if you do, then the bar is shown as above (interactive user agents should provide a non-modal authentication interface). Then, if you've already sent your credentials and you get a 401, then you get the 401 page and the bar, instead of the modal dialog. ... Yes, that's a simpler option. :-) (Provided that current browsers still ask for authentication even when given a 200 OK.) I don't think they do now, but it's something we can move towards. I think the above idea (of using WWW-Authenticate with 200 OK) is a good one, but is something we should let the HTTPWG worry about. On Fri, 17 Dec 2004, Greg Kilwein wrote: Related to this, it would be nice to have a standard, simple way for a browser session to log out of its HTTP authentication. Currently with some UAs, a user must to close all of his or her browser windows and/or tabs in order to be able to log in as someone else. Granted, there are ways to trick the browser into popping up the authentication box, but it would be nice to have a standard log out feature. The
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: It seems to me that the first limitation of form authentication could be removed by inventing a new WWW-Authenticate challenge that means reply to the form in the page. I have now specified such a value in HTML5 (since it is specific to entity bodies that contain HTML forms): challenge = HTML [ form ] form = form = form-name form-name = quoted-string (There's no credentials value for this scheme, since the login is done as a POST to a login script and then the server sets proprietary login information, like a cookie using Set-Cookie.) So when you get to a page that expects you to be logged in, it return a 401 with: WWW-Authenticate: HTML form=login ...and there must be a form element with name=login, which represents the form that must be submitted to log in. This idea has promise, but is it compatible with existing browsers? The case where the only challenge included is HTML is probably okay, since browsers will at this point likely determine that they don't support any of the given schemes and just display the entity body. The only concern in this case is browser-provided default error pages for the 401 response, which can hopefully be suppressed in much the same way as sites suppress IE's default 404 error page by padding the response to take it above a certain filesize. More bothersome is this case: HTTP/1.1 401 Unauthorized ... WWW-Authenticate: HTML form=login WWW-Authenticate: Basic realm=... Will existing browsers see Basic there and use that in preference to displaying the error page? I suspect the answer is it depends. I recall that some browsers only use Basic if it appears first, or perhaps only ever use the first in the list, which would be great for the use case of supporting at the same endpoint HTML auth for browsers and some other mechanism for non-browser agents that can't render HTML. (For example, a Microformats parser may be able to parse HTML and extract data but not have a way to present usable forms to the user.) There's also one more case to consider. Many sites react to an unauthed request by *redirecting* to the login page. Maybe: HTTP/1.1 302 Found Location: /login.php WWW-Authenticate: HTML form=login Where in this case the form is assumed to be in the body of the resource at /login.php, not in the response body. UI-wise I'm imagining that browsers would auto-focus, highlight or otherwise make available easily the nominated form once rendered. Is that what you were imagining?
[whatwg] Could we add setCapture to DOM Events?
Web Apps WG, Would it be possible to add setCapture() (as supported in IE; see below) to DOM3 Events? It seems more appropriate to have it there than in HTML5. Note that I don't think we'd need releaseCapture(); we should just say that capture is canceled when the mouse is released if it was captured. This gets around the problem of unbalanced set/release. On Thu, 14 Aug 2008, Greg Houston wrote: On Thu, Aug 14, 2008 at 6:14 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 14 Aug 2008, Greg Houston wrote: 1. You have a fluid layout where the columns are resizable via javascript by dragging the borders. The content of one of the columns is an iframe. You begin dragging the border between it and the column to the left, but as soon as the cursor goes over the iframe, the dragging functionality stops because you have now entered the context of the iframe. Thus it becomes impossible or at the very least very difficult to resize the column containing it. This seems like a bug. It seems like we would want to address this directly rather than requiring authors to disable iframes when doing drags (especially since that wouldn't help with things like plugins or whatever). Wouldn't the better solution be to provide some sort of mechanism to say that while the mouse button is down, all the mouse move events should go to the element that got the mousedown event? That would probably work, though I don't know if limiting it to the specific element itself might cause any issues. For instance, something lacking in the HTML5 drag and drop specification is the ability to define a handle for the element that is being dragged. With the drag and drop in javascript libraries you can define a handle (a different element) that drags the draggable element. If the handle property/attribute is null then the element itself is it's own handle. Perhaps there is a mousemove event in the current context (the parent document let's say) that is checking to see if the user tries to drag an object over it. We don't want to break the ability to create this sort of collision detection. It might be safer to say that while the mouse button is down, all the mouse move events should be processed in the same context the mousedown event occurred in. So if the mousedown occurs in the parent, mouse move events should be processed in the parent until a mouseup occurs. Likewise, if a mousedown occurs in the child iframe, mouse move events should be processed in the child iframe until a mouseup occurs. Yet there should also probably be some way to disable this or a way for one context to release mouse ownership to another context. I did a search for drag and drop between iframes, and there is at least one application out there that can fake this: http://intersoftpt.wordpress.com/2007/03/16/drag-and-drop-across-iframes/ Also, from a forum post on drag and drop between iframes: I have *heard* of people doing this by using the parent window to store and mediate state between the 2 child iframe windows. So when a drag was in progress, and the mouse coord reached the edge of the iframe window, you would notify the other iframe to start listening for mouseover events and create the illusion of a seamless drag. In these cases you would probably want a way to change context during mousedown, though the change should probably be controlled from the context the mousedown occurred in. That context gets to decide if it relinquishes control of the mouse move events before the mouseup or not. By default it should not. On Fri, 15 Aug 2008, Cameron McCormack wrote: The old SVG 1.2 Full draft had a pair of methods (which are implemented in Batik), startMouseCapture()/ stopMouseCapture(), that could be used to do this kind of thing. On Fri, 15 Aug 2008, Ojan Vafai wrote: setCapture/releaseCapture is how IE supports this. Seems to work well with iframes. It even deals with event coordinates in the expected way (e.g. clientX, clientY are relative to the document that the captured element is in instead of the document of the iframe). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] window.onerror -ancient feature needs upgrade
On Tue, 19 Aug 2008, Garrett Smith wrote: On Tue, Aug 19, 2008 at 6:16 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 22 Sep 2007, Garrett Smith wrote: window.onerror There needs to be a way to capture errors on the window. Is window.onerror not enough? window.onerror would be sufficient if it: * accepted an Error parameter. * fired when an EventListener callback had an Error * fired when a callback in setTimeout had an Error But unfortunately, none of the above is true. At least some of it is true in some browsers. HTML5 now requires the second and third of those. It doesn't do the first. Accepting an Error parameter is important because it provides standard information of the Error or Exception. At least one implementation provides a 'stack' property (Firefox). Another implementation provides stack info in the error message (Opera). I agree that it would be nice but I think we should punt this until the next version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media elements: Relative seeking
Dave Singer schrieb: I don't think you mean 'relative' here, which I would take to be go forward 10 seconds, but 'proportional', please go to 60% of the way through. Right, proportional for sure is the correct word for what I had in mind. Thanks. IF we are to do this, I would have thought it would be by adding units to the where to seek to argument: * go to this time in NPT (normal play time, which runs from 0 to media duration) * go to this SMPTE time code * go by this relative distance in NPT times * go to this proportional time * go to this proportional byte distance * go by this relative byte distance Hmmm... I'm in favor of of making implementations more simple (and thus more robust in this case), so I think inflating the number of ways of how one can seek may be going into the wrong direction. Note that proportional distances are not well defined for some streams (e.g. indefinite ones). Okay, this use case basically rules out just seeking by values between zero and one. Even with indefinite streams the user may want to e.g. jump to second 20 of the stream, which won't work with the proportional seeking I asked for. We'd have to define what bytes are counted and what aren't, especially if a URL offers a set of sub-streams only some of which a client would normally choose to have sent to it for playing. Oh my, that's true and it isn't pretty. I'm currently slamming a subset of the HTML5 media API onto a Java applet (to offer a fallback for browsers without audio/video). http://people.xiph.org/~maikmerten/demos/bigbuckbunny-applet-javascript.html Estimating the duration *does* work - poorly in this case, but still. Currently this applet uses the byte-position of the last byte fetched from the server, which isn't the correct *playback* byte-position due to not accounting for the bytes in the buffer (which, in this case, is 4 megabytes big - so this is severe). I assume that once this is corrected a reasonable-enough (for a status bar position slider) estimate may actually be possible, meaning things could just stay the way they are. Maik
