Re: [whatwg] Deprecating small , b
Pentasis writes: [Asbjørn Ulsberg writes:] 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. :-) Yay, consensus! Thanks, Asbjørn. 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. That may be true (though authors who want smaller text just because they think the default looks too large could also use font size=2 or CSS), but authors who wanted to diminished the emphasis of certain content to users are likely to pick small because there isn't much else available. Just because an element is currently widely used for a purpose we deem inappropriate doesn't mean that its appropriate uses aren't important. Tables are widely used for layout; br-s are widely misused. Both of those clearly have other valid uses, so are still in HTML. 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. Yes. But the suggested alternative was to deprecate small entirely and invent a new element to convey the semantic of 'small print'. That would of course make _all_ current uses of small non-conforming. Presentational small-s are going to be non-conforming either way; allowing semantic small-s to conform doesn't change that. By redefining it the (existing) web breaks; allbeit purely in the semantic area. That's intentional. If anybody checks legacy content against the new standard they will discover that what they did is no longer recommended. However, browsers will 100% support it and continue to render it as it always has been, so the 'breakage' is no way visible; if the author chooses not to care about it then no harm is done. Smylers PS: Pentasis, please could you send mails that do at least one of attributing who you're quoting or include In-Reply-To: headers so that they continue the existing thread rather than starting a new one. Without either it's rather tedious to have to look up who said the text you quote. Thanks.
Re: [whatwg] window.onerror -ancient feature needs upgrade
[didn't notice this discussion at the time] Garrett Smith wrote on 20 August 2008 04:08 On Tue, Aug 19, 2008 at 6:16 PM, Ian Hickson [EMAIL PROTECTED] wrote: 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. A very nice improvement list! These are exactly the flaws I've been hitting when trying to use window.onerror for something useful in Ajax apps. Instead we have had to resort to decorating all event handlers with try/catch logic. I'm not sure I follow what the problem is here. Is this to aid debugging? Yes. window.onerror seems useful for testing and debugging but leaves some to be desired. The way we would have liked to use it is actually for fallback error handling/presentation in Ajax apps. Ie, if you need custom error handling for some site function then implement it as try/catch in the respective event handler, but if you just want error presentation with standard recovery then let it bubble out to the global error handling in window.onerror. Naturally, for this scenario it is also important with the Error parameter for onerror. Best regards Mike Wilson
[whatwg] Issues relating to the syntax of dates and times
On Sat, 18 Nov 2006, Henri Sivonen wrote: Why does WA 1.0 require the year to be exactly 4 digits long when in WF 2.0 it is four or more digits? Fixed. Why doesn't WA 1.0 make 1 AD the first year thus dodging the year zero issue like WF 2.0? Fixed. Have I understood correctly, that * WF 2.0 date formats never allow surrounding white space for document conformance and must be rejected by UAs if they do Correct. * WA 1.0 Specific moments in time never allow surrounding white space for document conformance but UAs must gracefully ignore surrounding white space and trailing garbage As of the recent edits, the WF2 form of not skipping whitespace has been adopted. * WA 1.0 Vaguer moments in time always allow surrounding white space? I revamped the syntax for these. It is now consistent with the others -- no spaces in attributes, White_Space allowed around in content. Why do WA 1.0 datetime formats for attributes allow space around T or multiple spaces in place of T when WF 2.0 only allows T? Also, why are spaces allowed before the time zone designator in the attribute variants in WA 1.0 when WF 2.0 does not allow spaces before Z? Fixed. Also, the in content variant of the Vaguer moments in time algorithm is not stable over time, because Unicode can add more Zs characters. Correct. On Mon, 20 Nov 2006, Henri Sivonen wrote: Also, for consistency with WF 2.0 and HTML 4.01, I suggest that vaguer moments in time *in attributes* not allow spaces in conforming strings and require T as the date/time separator. Done. On Mon, 20 Nov 2006, Henri Sivonen wrote: Currently, the definition of Vaguer moments in time allows seconds that have only one digit before the decimal point and no digits after the decimal point. This doesn't make sense considering that hours and minutes must have two digits. They use the same as all other times now. The motivation for these formats is consistency with HTML 4.01 and Web Forms 2.0 where departure from the formats required by those specs is not necessary. These formats allow leading zeros in the year. However, I think it would be reasonable to ban leading zeros in years that have 5 or more digits if WF 2.0 also bans those. Not banned in HTML5. On Sun, 27 Apr 2008, Ernest Cline wrote: In section 3.10.10, the second example is: time datetime=2006-09-24 05:00 -7 However, the algorithm given in 3.2.4.2 for parsing date or time strings requires that the timezone hour offset be exactly 2 digits. (This is the same requirement ISO 8601 has.) Hence, the example as given is invalid according to the provided parser algorithm, since it has only 1 digit. Fixed. On Sun, 27 Apr 2008, Ernest Cline wrote: At present the HTML 5 draft version extends the allowed syntax of the datetime value from that used in HTML 4 / XHTML 1 to include strings that are not valid ISO 8601 specifiers. Specifically, it breaks syntax allowed by ISO 8601 by allowing optional whitespace. I can to some degree see the value of allowing whitespace where the textContent of the time element is being parsed instead of the datetime attribute. However, for the attribute itself, unless an existing implementation is accepting extra whitespace when parsing the datetime attribute of ins and del in HTML 4, I can't see the value in accepting whitespace for the attributes. I've changed back to not allowing whitespace. On Wed, 30 Jul 2008, Benjamin Hawkes-Lewis wrote: Regardless of what elements are added to HTML5, I believe HTML5 needs a simple extension point where microformats can insert machine-parsable equivalents and expansions of human friendly data. Data types are by no means limited to those already covered by the HTML5 proposals: http://microformats.org/wiki/machine-data Such an extension point could meet the use-case of making datetimes BC extractable and also any use-case for far-future datetimes without requiring HTML5 to explicit specify calendar APIs for them. The suggestion on that page: We're meeting up on Northumberland Avenue (span class=geo51.507033,-0.126343/span). span class=duration3 minutes and 23 seconds span class=valuePT3M23S/span/span ...seems fine to me. On Wed, 30 Jul 2008, WeBMartians wrote: At the very least, ensure that the range of times (dates, durations, intervals and times-of-day) and the granularity are well and rigorously specified. Ensure, also, that there is a Javascript mechanism to alarm, mechanically, when such element values exceed the specified envelope (I do not see such in the current text). Is the current text satisfactory? If the browser cannot handle a datetime string of -0548-11-22 18:23:46,03276548901+3 (other-epochal, proleptic, locale-dependent and, I'm certain, annoying in several other respects), just make sure Javascript does something predictable and explicit. The spec is pretty explicit now about what
Re: [whatwg] media elements: Relative seeking
On Tue, Nov 25, 2008 at 6:58 PM, Maik Merten [EMAIL PROTECTED] wrote: Dave Singer schrieb: 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. I don't really see a need for anything else than minutes/seconds, bytes, and percentages. Even in temporal URIs, we saw people prefer using minutes/seconds over SMPTE, which would be more accurate. 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. Live streams are somewhat bad to deal with anyway, because a timeline is badly defined on such. All you could really do is show the past and have a continues pointer at the end. Most live streams (e.g. the recent YouTube live concert) simply don't show a timeline and disallow people to jump around in the presentation. 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. No, I think that's a wrong assumption. When referring to bytes in a media resource, one is always referring back to the one on the server. So, number of bytes are well-defined wrt a media resource and they cross any substream boundaries. Byte 500 may be in the video track, while byte 501 may be part of the audio track. What's a much larger problem is that there are file formats where there is no linearly increasing mapping between a byte position and a time offset. Meaning: byte 500 could relate to a video track at 3 seconds, while byte 501 could relate to an audio track at 1 second. For some formats these don't even need to be in different tracks, because the codec jumps around. So, bytes may indeed be a poor indicator of timeline progress. However, percentage should not be a problem I would think. 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. Are you using the byte position to estimate duration or are you using the granulepos in Ogg to do this? The granulepos on the last data page may be more accurate than simply using byte positions in Ogg. However, it may also be more complicated and error-prone. In any case - if you (and also Chris Double) are satisfied with the estimates you're getting for file duration/length - I'll stop arguing for it. It would be nice to hear some experimental evidence about how well it's doing, e.g. for typical movie trailers, so we can lay that argument to bed knowing we've done our homework. Cheers, Silvia.
Re: [whatwg] media elements: Relative seeking
Relative seeking is always possible: currentTime+=10. Proportional seeking is possible as long as the duration is known and finite. I would avoid as far as possible any use of byte positions as this information isn't exactly trivial to get given all the buffering and asynchronous decoding involved in typical media frameworks. Philip On Tue, 2008-11-25 at 08:58 +0100, Maik Merten wrote: 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 -- Philip Jägenstedt Opera Software
Re: [whatwg] input type=email multiple
Le Tue, 25 Nov 2008 14:36:10 +0200, Ian Hickson [EMAIL PROTECTED] a écrit: On Thu, 4 Jan 2007, Mihai Sucan wrote: I know it's rather very late for comments and suggestions to WebForms 2. Yet, I think they are welcome for future versions. Hixie, if you have any notes (or whatever) about WF3, please also include this suggestion (if you haven't done so already). Today I was working on a newsletter web application where the client is given an input labeled To, just like in email clients. The client can wirte multiple comma separated email addresses. I intended to use the input type=email WF2 enhancement, however I've just learned this only works with inputs which accept one single email address. For WF3 I would suggest that this use case should be taken into consideration. Most email web applications have a single To field where the user can write multiple comma separated email addresses, with autocomplete for each address. The new type value could be emails, email-list, or even email-csv. I've added input type=email multiple for this case. [snip other e-mails saying the same thing] Just wanted to say thank you! Best regards, Mihai -- Mihai Sucan http://www.robodesign.ro
[whatwg] input type=email multiple
On Thu, 4 Jan 2007, Mihai Sucan wrote: I know it's rather very late for comments and suggestions to WebForms 2. Yet, I think they are welcome for future versions. Hixie, if you have any notes (or whatever) about WF3, please also include this suggestion (if you haven't done so already). Today I was working on a newsletter web application where the client is given an input labeled To, just like in email clients. The client can wirte multiple comma separated email addresses. I intended to use the input type=email WF2 enhancement, however I've just learned this only works with inputs which accept one single email address. For WF3 I would suggest that this use case should be taken into consideration. Most email web applications have a single To field where the user can write multiple comma separated email addresses, with autocomplete for each address. The new type value could be emails, email-list, or even email-csv. I've added input type=email multiple for this case. [snip other e-mails saying the same thing] -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Kinds of Content
Lachlan Hunt wrote: http://www.whatwg.org/specs/web-apps/current-work/#kinds-of-content In the list of categories near the beginning of that section, it includes Form control content. But this isn't mentioned or described anywhere else in the spec. Is its inclusion in the list intentional or is it a mistake? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Issues relating to the syntax of dates and times
Ian Hickson wrote: While I could see that maybe one day there'd be a use case for time that would need historical dates, I really think that we'd have to tackle other calendars in use today before looking at calendars that aren't in use anymore. So I'd rather punt this for now. While it is true that there are to many factors to take into account regarding which calendar, which era, etc. I can also imagine, (just brainstorming here) if I look at this example in the spec: pWe stopped talking at time datetime=2006-09-24 05:00 -75am the next morning/time./p This means I should also mark up something like this: pIt was time datetime=???5 seconds after the big bang/time./p There are more factors to take into consideration in this example than just calendars. So... Wouldn't it be far more efficient and convinient to have a construction by which we can set a base-date/time? (something like the base-url-thing). That way you can set the date/time to anything at all based on a reference-setting. And this reference setting could be anything (another calendar, a specific point in time (or perhaps even time-space) or a relative reference. I don't think this would have to be dealt with by the UA but can be done by scripting. Bert
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: 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): This bit confused the hell out of me. Like Martin Atkins (no relation... probably) suggested, whenever someone's auth is bad for whatever reason I redirect them to the login page, possibly with an error message explaining what went wrong. I would never have imagined trying to solve this problem at the level you're suggesting, nor do I think it is particularly necessary, since every server side language can do a redirect by themselves. ~TJ
Re: [whatwg] Issues relating to the syntax of dates and times
On Tue, Nov 25, 2008 at 7:36 AM, Pentasis [EMAIL PROTECTED] wrote: Ian Hickson wrote: While I could see that maybe one day there'd be a use case for time that would need historical dates, I really think that we'd have to tackle other calendars in use today before looking at calendars that aren't in use anymore. So I'd rather punt this for now. While it is true that there are to many factors to take into account regarding which calendar, which era, etc. I can also imagine, (just brainstorming here) if I look at this example in the spec: pWe stopped talking at time datetime=2006-09-24 05:00 -75am the next morning/time./p This means I should also mark up something like this: pIt was time datetime=???5 seconds after the big bang/time./p 5 seconds after the big bang is an exceedingly ill-defined time, though. Currently you'd be lucky to peg it within a billion years of the accurate time, ignoring any relativistic issues with timekeeping. This was Ian's point about far-past dates being nearly never exact enough to justify a machine-readable timestamp. There are more factors to take into consideration in this example than just calendars. So... Wouldn't it be far more efficient and convinient to have a construction by which we can set a base-date/time? (something like the base-url-thing). That way you can set the date/time to anything at all based on a reference-setting. And this reference setting could be anything (another calendar, a specific point in time (or perhaps even time-space) or a relative reference. I don't think this would have to be dealt with by the UA but can be done by scripting. How does this solve the issue of the base time being too ill-defined for a timestamp? Assuming you have a basetime of the big bang, you can certainly exactly specify exactly 5 seconds after, but how would you specify the basetime? You're just moving the issue one level back. This doesn't solve the underlying issue that far-past dates aren't exact enough to give them a timestamp. This problem requires an entirely different solution, and trying to shoehorn it into a timestamp-based solution just gives you two bad solutions. ~TJ
Re: [whatwg] media elements: Relative seeking
On Nov 24, 2008, at 2:21 PM, Calogero Alex Baldacchino wrote: 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. It is a mistake to assume that media data is present in the local cache after it has been played. Some devices have very limited storage (eg. small handhelds) and choose to use a very limited non-persistent cache, live streams have essentially unbounded size and can't be cached, even downloaded content can be so large that clients on a desktop class machine may choose to no buffer the entire file. eric
Re: [whatwg] Deprecating small , b ?
Smylers wrote: 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. [...] Of course that's possible, but, as you noticed too, only by redefining the small semantics, and is not a best choice per se. That's both because the original semantics for the small tag was targeted to styling and nothing else (the html 4 document type definitions declared it as a member of the fontstyle entity, while, for instance, strong and em were parts of the phrase entity), and because the term 'small', at first glance, suggests the idea of a typographical function, regardless any other related concept which might be specific for the English (or whatever else) culture, but might not be as well immediate for non-English developers all around the world. As a consequence, since any average developer could just rely on the old semantics, being he intuitively confident with it, the semantics redefinition could find a first counter-indication: let's think on a word written with alternate b and small letters, or just to a paragraph first letter evidenced by a b, obviously the application of the new semantics here would be untrivial (i.e. an assistive software for blind users would be fouled by this and give unpredictable results). Despite the previous use case would be a misuse of the b and small markup, yet it would be possible, meaning not prohibited, and so creating a new element with a proper semantic could be a better choice. But, you're right, we have to deal with backward compatibility, and redefining the small and b semantics can be a good compromise, since a new element would face some heavy concerns, mainly related to rendering and to the state of the art implementations in non-visual user agents (and the alike). However, I think that a solution, at least partial, can be found for the rendering concern (and I'd push for this being done anyway, since there are several new elements defined for HTML 5). Most user agents are capable to interpret a dtd to some extent, so it could be worth the effort to define an html 5 specific dtd in addition to the parsing roules - which aim to overcome all problems arising by previous dtd-only html specifications - so that a non html5-fully-compliant browser can somehow interpret any new elements. HTML 5 Doctype declaration could accept a dtd just for backward compatibility purpose, and any fully compliant user agent would just ignore such dtd. More specifically, such a dtd could define default values for some attributes, such as the style attribute (to have any new element properly rendered - some assistive technologies are capable to interpret style sheets too), and, anyway, there should be a way, in SMGL, to create an alias for an element (i.e., a new element - let's call it incidental - could be aliased to small for better compatibility). Let's come to the non-typographical interpretation a today u.a. may be capable of, as in your example about lynx. This can be a very good reason to deem small a very good choice. But, are we sure that *every* existing user agent can do that? If the answer is yes, we can stop here: small is a perfect choise. Better: small is all we need, so let's stop bothering each other about this matter. But if the answer is no, we have to face a number of user agents needing an update to understand the new semantics for the small tag, and so, if the new semantics can be assumed as *surely* reliable only with new/updated u.a.'s (that is, with those ones fully compatible with html 5 specifications), that's somehow like to be starting from scratch, and consequently there is space for a new, more appropriate element. 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
Re: [whatwg] Issues relating to the syntax of dates and times
- Original Message - From: Tab Atkins Jr. To: Pentasis Cc: [EMAIL PROTECTED] Sent: Tuesday, November 25, 2008 4:44 PM Subject: Re: [whatwg] Issues relating to the syntax of dates and times On Tue, Nov 25, 2008 at 7:36 AM, Pentasis [EMAIL PROTECTED] wrote: Ian Hickson wrote: While I could see that maybe one day there'd be a use case for time that would need historical dates, I really think that we'd have to tackle other calendars in use today before looking at calendars that aren't in use anymore. So I'd rather punt this for now. While it is true that there are to many factors to take into account regarding which calendar, which era, etc. I can also imagine, (just brainstorming here) if I look at this example in the spec: pWe stopped talking at time datetime=2006-09-24 05:00 -75am the next morning/time./p This means I should also mark up something like this: pIt was time datetime=???5 seconds after the big bang/time./p 5 seconds after the big bang is an exceedingly ill-defined time, though. Currently you'd be lucky to peg it within a billion years of the accurate time, ignoring any relativistic issues with timekeeping. This was Ian's point about far-past dates being nearly never exact enough to justify a machine-readable timestamp. There are more factors to take into consideration in this example than just calendars. So... Wouldn't it be far more efficient and convinient to have a construction by which we can set a base-date/time? (something like the base-url-thing). That way you can set the date/time to anything at all based on a reference-setting. And this reference setting could be anything (another calendar, a specific point in time (or perhaps even time-space) or a relative reference. I don't think this would have to be dealt with by the UA but can be done by scripting. How does this solve the issue of the base time being too ill-defined for a timestamp? Assuming you have a basetime of the big bang, you can certainly exactly specify exactly 5 seconds after, but how would you specify the basetime? You're just moving the issue one level back. This doesn't solve the underlying issue that far-past dates aren't exact enough to give them a timestamp. This problem requires an entirely different solution, and trying to shoehorn it into a timestamp-based solution just gives you two bad solutions. ~TJ No, actually you (and Ian) say it yourself. Dates and times far-in-the-past can *never* be exactly defined. So we should instead settle for a relative or approximate base if we cannot provide for an exact one. In the example of the big bang I could set the base-time either to be big-bang or according to theory x. To name but a few. The advantage of this is that the actual exact date/time can then always be re-calculated as we acuire more knowledge about the date in question without having to re-mark-up the whole thing. (but only if we want/need it). The fact remains that dates and times can *never* be exact. Besides why would we need that in mark-up language? What benefit is it to HTML and UAs if dates and times are all based on one base? I would much rather have a construct by which I can at least set a date which makes sense in some way and I can rest easy to know that this will automatically become more and more accurate (according to the than used universal base-time-code) as science and knowledge evolves. I do not have to specify the base-time as you put it, why do I have to? How would you define UTC for that matter? Sure there is a definition for it, but that is also only valid based on other agreements (UTC has no meaning when traveling at the speed of light between Jupiter and Magellen I think). Besides, the UTC timing will also be ill-defined someday in the future, so current date/times are no different (relativelly speaking) from far-past-dates. Another advantage of this is -I just realized- that one could mark up time in a fictional article with fictional dates. But, I will concede to the fact that this may make things more difficult. But in that case I would ask for the definition of the spec to be changed from The time element represents a date and/or a time. into something more restricting and exact which at least represents the limitations of this element that are presented in this discussion. Or better yet, drop the element as it makes no sense (IMO). Bert
Re: [whatwg] Deprecating small , b ?
On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: Smylers wrote: 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. [...] Of course that's possible, but, as you noticed too, only by redefining the small semantics, and is not a best choice per se. That's both because the original semantics for the small tag was targeted to styling and nothing else (the html 4 document type definitions declared it as a member of the fontstyle entity, while, for instance, strong and em were parts of the phrase entity), and because the term 'small', at first glance, suggests the idea of a typographical function, regardless any other related concept which might be specific for the English (or whatever else) culture, but might not be as well immediate for non-English developers all around the world. As a consequence, since any average developer could just rely on the old semantics, being he intuitively confident with it, the semantics redefinition could find a first counter-indication: let's think on a word written with alternate b and small letters, or just to a paragraph first letter evidenced by a b, obviously the application of the new semantics here would be untrivial (i.e. an assistive software for blind users would be fouled by this and give unpredictable results). Despite the previous use case would be a misuse of the b and small markup, yet it would be possible, meaning not prohibited, and so creating a new element with a proper semantic could be a better choice. No matter *what* we do, if there *is* a default style for an element, it will be misused by people. This is a fact of life. Defining a new element which is identical to small in every way except that it hasn't been misused *yet* is thus a mug's game, because it *will* be misused in the same way as small, and then we just have two identical elements for no reason. Yes, bad markup will foul up semantic agents. But people will *always* write bad markup. At least with the semantic redefinition we get to declare lots of usages that *are* appropriate to be conforming without any effort on the author's part. And really, the type of people who would write a word with alternating letters wrapped in b and small tags are hardly the kind to even *care* about semantics. But, you're right, we have to deal with backward compatibility, and redefining the small and b semantics can be a good compromise, since a new element would face some heavy concerns, mainly related to rendering and to the state of the art implementations in non-visual user agents (and the alike). However, I think that a solution, at least partial, can be found for the rendering concern (and I'd push for this being done anyway, since there are several new elements defined for HTML 5). Most user agents are capable to interpret a dtd to some extent, so it could be worth the effort to define an html 5 specific dtd in addition to the parsing roules - which aim to overcome all problems arising by previous dtd-only html specifications - so that a non html5-fully-compliant browser can somehow interpret any new elements. HTML 5 Doctype declaration could accept a dtd just for backward compatibility purpose, and any fully compliant user agent would just ignore such dtd. More specifically, such a dtd could define default values for some attributes, such as the style attribute (to have any new element properly rendered - some assistive technologies are capable to interpret style sheets too), and, anyway, there should be a way, in SMGL, to create an alias for an element (i.e., a new element - let's call it incidental - could be aliased to small for better compatibility). Html5 is no longer an SGML language. Let's come to the non-typographical interpretation a today u.a. may be capable of, as in your example about lynx. This can be a very good reason to deem small a very good choice. But, are we sure that *every* existing user agent can do that? If the answer is yes, we can stop here: small is a perfect choise. Better: small is all we need, so let's stop bothering each other about this matter. But if the answer is no, we have to face a number of user agents needing an update to understand the new semantics for the small tag, and
Re: [whatwg] Issues relating to the syntax of dates and times
I suddenly noticed this line in the spec: The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such. I agree with this, so disregard my previous remarks on this subject. I would however recommend dropping the word primary. Bert
Re: [whatwg] media elements: Relative seeking
Eric Carlson ha scritto: On Nov 24, 2008, at 2:21 PM, Calogero Alex Baldacchino wrote: 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. It is a mistake to assume that media data is present in the local cache after it has been played. Some devices have very limited storage (eg. small handhelds) and choose to use a very limited non-persistent cache, live streams have essentially unbounded size and can't be cached, even downloaded content can be so large that clients on a desktop class machine may choose to no buffer the entire file. eric Ok, I understand that point was too unclear, and I have to write something meaningful, lol! What I meant was: let's assume the user agent has a somewhat buffer big enough to maintain a part of the yet played contet; such a buffer could be a portion of the download buffer, or a somewhat buffer acting like a proper, little cache (or variable in size from u.a. to u.a. - that's it: I called such a client-side non-better-defined buffer a 'local cache', not meaning that should be persistent); if this happens (and the user agents - or any codec avaied of - should know what part of the stream has yet been played and is still in the buffer, if any exists), the user agent could allow a backward seek limitedly to the amount of buffered, yet-played stream, and also buffer a little portion of the following stream, not much, just what would be enough to let a retarded playback of the stream (in such a scenario, after a while the buffered content would/could be discarded, so the 'local' cache would be a little and non persistent one). Of course all of this could (and perhaps should) be implementation dependent, I just aimed (in my crazy mind) to briefly trace such eventuality. However, the above suggests me something else: a somewhat user agent could give the opportunity to record a (portion of a) stream (despite this being a 'fixed-size' audio/video or a livestream - for the sake of this mail I'm disregarding any DRM related concern), so there could be a real persistent cache, which could also work as a 'set-top-box' cache allowing retarded playback of a live stream (such a cache could even be non-local, but provided by a remote server as a web-based service, eventually related with the streamed content provider; in such a case, the user agent would coordinate with the remote cache, i.e. getting informations about the cache start point, the current position and the overall duration). Perhaps the specificacions could sketch out such a possibility too, yet leaving it to the implementation. Or perhaps that's out of the specifications scope, and I'm just wasting my and your time... if so, I apologize. Regards. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Scegli Carta Eureka per tutti i tuoi acquisti! Con zero costi di attivazione avrai un credito fino a 3000 euro. Attivala ora! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8428d=25-11
[whatwg] video audio support?
Hello, Quick question, Is there a list of browsers that support the video and audio tags ? Thanks -- Martin McEvoy http://weborganics.co.uk/
Re: [whatwg] Solving the login/logout problem in HTML
Hi Ian, thanks a lot for this proposal which seems to go into the right direction. I didn't yet have time to look into this in detail, but it currently seems to require the UA to still parse the HTML page. Wouldn't it be better of the *headers* of the response (such as WW-Authenticate, Link, ...) would contain sufficient information to perform the login without having to do that; such as a URI to POST to, plus the parameter names for user name and password? BR, Julian
Re: [whatwg] video audio support?
Am Dienstag, den 25.11.2008, 17:46 + schrieb Martin McEvoy: Hello, Quick question, Is there a list of browsers that support the video and audio tags ? First, i think this is the WRONG mailing list for questions like this. Second, FF Nighlies (Minefield), Opera Demo Build, Safari (and probably more Webkit stuff in the future). Don't know more. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
[whatwg] accesskey attribute with display:none elements
Hi all, currently it isn't specified anywhere (AFAIK) what should happen if the element which has an accesskey attribute is hidden using display:none. HTML4 says the following: Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link... The problem is that focusing and activating isn't the same thing. FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets. FF3 changed the behavior to require visible and focusable element. IE7 doesn't seem to activate, only focus (at least a elements), and because hidden element isn't really focusable, it doesn't seem to do anything with elements with display:none. A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588 I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. (Key event listeners could do something similar, but they'd need to handle all the different browsers and OSes.) So I prefer what FF2, Safari and Opera do, and would like to change FF3.1 to work the same way. Anyway, I hope some behavior could be standardized. Comments? br, -Olli
Re: [whatwg] media elements: Relative seeking
Silvia Pfeiffer schrieb: In any case - if you (and also Chris Double) are satisfied with the estimates you're getting for file duration/length - I'll stop arguing for it. It would be nice to hear some experimental evidence about how well it's doing, e.g. for typical movie trailers, so we can lay that argument to bed knowing we've done our homework. I now also account for the bytes in the buffer to compute the current playback byte-position and added a status bar showing playback progress. http://people.xiph.org/~maikmerten/demos/bigbuckbunny-applet-javascript.html Given that I estimate the duration with outrageous crudeness (no averaging) and also compute the slider position without any means to ensure it doesn't jump around wildly I think it's pretty smooth - so perhaps estimating the duration is in fact a viable fallback if one doesn't want to determine the duration properly. Maik
Re: [whatwg] input placeholder=
On Nov 17, 2008, at 10:05 AM, Ian Hickson wrote: ... On Mon, 21 May 2007, Stijn Peeters wrote: ... It makes sense to clear these values when the field is focused, as the user will probably want to insert a new value rather than edit the value that is currently in it. Currently this is mostly done through javascript, which is not necessarily a bad thing, but seeing that attributes such as autofocus= have also found their way into the spec, I suppose this is also inside the scope of Web Forms 2 or HTML5. As for the attribute name, clearonfocus= with clearonfocus as the only possible value (indicating the input field or textarea should be cleared upon focusing it) would probably be most suitable. ... On Wed, 23 May 2007, Matthew Paul Thomas wrote: I don't understand. What use is a default value if you can't edit it? Why not make the field empty to begin with? On Fri, 25 May 2007, Matthew Paul Thomas wrote: No, we already addressed the label use case. I asked specifically about the default value use case. I don't know what you are asking for here. I was asking, obviously, what use is a default value if you can't edit it. If an enabled text field had a displayed value= but the value was not actually editable, that would be unpleasantly surprising. That problem applies just as much to input placeholder=foo as it would have done to input value=foo clearonfocus: depending on whether the placeholder text is greyed out, it would make the field either look like it has a value when it actually doesn't, or look disabled when it actually isn't. It would also hide the label or hint for the field for *precisely* the period when you need it most. I'm not aware of any possible presentation that avoids both (or even one of!) those problems, and previously HTML5 has shied away from expecting browsers to implement things that have no known reasonable presentation. I appreciate that Web authors currently go to some scripting lengths to position labels for text fields inside the fields, and I think it's quite appropriate that they should have to go to those lengths, because it makes bad design more difficult. I would rather see, as I've previously suggested, markup for associating form controls with hints outside them in a similar way as labels can be associated now. ... On Tue, 30 Sep 2008, Andy Lyttle wrote: ... 3) anybody who is currently using the title attribute doesn't expect it to be displayed as a placeholder, so we would break things for them (especially if their title string is too long to fit inside a small field) We can't really change the behavior of title= now, it'd have all kinds of weird unexpected effects on existing pages ... On Thu, 2 Oct 2008, Tab Atkins Jr. wrote: ... Of course, it's still not in any way semantic. The only difference between (optional) being displayed near the input and being displayed *within* the input is one of aesthetics. The meaning of the document isn't changed one iota. This leans me even more toward a CSS solution. I don't see any harm to having this in the language really. We don't disallow UAs from rendering this after the control. ... But they couldn't really do that, it'd have all kinds of weird unexpected effects on pages designed by people using browsers that present it the way the spec suggests. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Kinds of Content
On Tue, 25 Nov 2008, Lachlan Hunt wrote: Lachlan Hunt wrote: http://www.whatwg.org/specs/web-apps/current-work/#kinds-of-content In the list of categories near the beginning of that section, it includes Form control content. But this isn't mentioned or described anywhere else in the spec. Is its inclusion in the list intentional or is it a mistake? Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues relating to the syntax of dates and times
On Tue, 25 Nov 2008, Pentasis wrote: The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such. I agree with this, so disregard my previous remarks on this subject. I would however recommend dropping the word primary. I wouldn't want to make people think their particular use case was excluded. What if someone wanted to use a date to indicate the time an entry was added, for instance? Hence the word primary. That whole paragraph might be rewritten in due course though to not refer to use cases (I try to keep the spec clear of actually using the term explicitly and instead just show the use cases in examples). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
On Tue, 25 Nov 2008, Tab Atkins Jr. wrote: This bit confused the hell out of me. Like Martin Atkins (no relation... probably) suggested, whenever someone's auth is bad for whatever reason I redirect them to the login page, possibly with an error message explaining what went wrong. You can still do that. You also have the opportunity to use a 401 on the login page itself. I would never have imagined trying to solve this problem at the level you're suggesting, nor do I think it is particularly necessary, since every server side language can do a redirect by themselves. It may be that few enough people want to use the HTTP mechanisms for this that the feature will need to be removed when the spec progresses to the next level. On Tue, 25 Nov 2008, Julian Reschke wrote: thanks a lot for this proposal which seems to go into the right direction. I didn't yet have time to look into this in detail, but it currently seems to require the UA to still parse the HTML page. Wouldn't it be better of the *headers* of the response (such as WW-Authenticate, Link, ...) would contain sufficient information to perform the login without having to do that; such as a URI to POST to, plus the parameter names for user name and password? The problem is that you'd basically have to duplicate the entire form, since login forms can be arbitrarily complex. If the bot has the username and password, why not also give it the username field name, password field name, and login script url? Just consider them part of the credentials. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: ... I didn't yet have time to look into this in detail, but it currently seems to require the UA to still parse the HTML page. Wouldn't it be better of the *headers* of the response (such as WW-Authenticate, Link, ...) would contain sufficient information to perform the login without having to do that; such as a URI to POST to, plus the parameter names for user name and password? The problem is that you'd basically have to duplicate the entire form, since login forms can be arbitrarily complex. If the bot has the username and password, why not also give it the username field name, password field name, and login script url? Just consider them part of the credentials. That works in theory, but doesn't scale. For instance, we've been working on a search engine that scan internet sites that may require authentication. Configuring that login for each site would be a maintenance nightmare. So, on the other hand, if the login form is more complex than username + password, what is a bot supposed to do with it? BR, Julian
Re: [whatwg] Deprecating small , b ?
Tab Atkins Jr. ha scritto:
On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Of course that's possible, but, as you noticed too, only by
redefining the small semantics, and is not a best choice per se.
That's both because the original semantics for the small tag was
targeted to styling and nothing else (the html 4 document type
definitions declared it as a member of the fontstyle entity,
while, for instance, strong and em were parts of the phrase
entity), and because the term 'small', at first glance, suggests
the idea of a typographical function, regardless any other related
concept which might be specific for the English (or whatever else)
culture, but might not be as well immediate for non-English
developers all around the world. As a consequence, since any
average developer could just rely on the old semantics, being he
intuitively confident with it, the semantics redefinition could
find a first counter-indication: let's think on a word written
with alternate b and small letters, or just to a paragraph
first letter evidenced by a b, obviously the application of the
new semantics here would be untrivial (i.e. an assistive software
for blind users would be fouled by this and give unpredictable
results). Despite the previous use case would be a misuse of the
b and small markup, yet it would be possible, meaning not
prohibited, and so creating a new element with a proper semantic
could be a better choice.
No matter *what* we do, if there *is* a default style for an element,
it will be misused by people. This is a fact of life. Defining a new
element which is identical to small in every way except that it
hasn't been misused *yet* is thus a mug's game, because it *will* be
misused in the same way as small, and then we just have two
identical elements for no reason.
I'll start with an example. A few time ago I played around with Opera
Voice. It seemed to be capable to interpret visual style sheets and
specifically font styles, so that bold or italics text (so constraint in
the style sheet, not the markup) were spoken differently from 'normal'
text, but a paragraph first letter differing from the rest of the word
(which is a non-rare typographical choice), as far as I remember, caused
the whole word to be skipped. This suggests me that if we really want a
'cross-presentation' semantics, we have to keep as far as we can from
anything having a *main* typographical semantics (as small and b
have from their birth). Every language is somehow prone to side-effects
caused by misuse (i.e. it is possible to cause a big mess in a software
written in a language allowing to pass a pointer to a function - there
are tons of examples for language design issues - yet such could be a
desireable capability), but appropriate choices for both semantics and
syntax may help to reduce the likelyhood of a misuse.
I think that very likely both b and small will carry on their old
semantics, so being more prone to misuse with respect to their new one,
since very likely a lot of developers are, and will rest, more confident
with their original semantics, which is also suggested by their names
('b' standing for 'bold' and 'small'... for something small on the
screen or on paper). Instead, a new element would require the developer
to take some effort at least to learn about its existence, so he would
read that such element primary use is to indicate a different importance
of a piece of text, so that a non visual user agent can present it in an
appropriate manner, and a visual or print user agent can render it in
different ways. Ah, the default style could be slightly or very
different from the small one, i.e. the text could be surrounded by
parenthesis or hyphens, despite of the font size (and the new elements
could be designed such to accept just non-empty strings consisting of
more than one non-spacing character).
Yes, bad markup will foul up semantic agents. But people will
*always* write bad markup. At least with the semantic redefinition we
get to declare lots of usages that *are* appropriate to be conforming
without any effort on the author's part.
And really, the type of people who would write a word with alternating
letters wrapped in b and small tags are hardly the kind to even
*care* about semantics.
Let me reverse this approach: what should an assistive user agent do
with such a bM/bsmallE/smallbS/bsmallS/small? I think
that dealing with that word as normal text would be a more gracefull
degradation than discarding it, and if we clearly state that b and
small have only typographical semantics, while different elements are
provided to differentiate the grade of emphasys of a phrase, an
assistive user agent could support a better behaviour, while any author
disregarding semantics would not cause any trouble (the
Re: [whatwg] media elements: Relative seeking
On Wed, Nov 26, 2008 at 7:22 AM, Maik Merten [EMAIL PROTECTED] wrote: Silvia Pfeiffer schrieb: In any case - if you (and also Chris Double) are satisfied with the estimates you're getting for file duration/length - I'll stop arguing for it. It would be nice to hear some experimental evidence about how well it's doing, e.g. for typical movie trailers, so we can lay that argument to bed knowing we've done our homework. I now also account for the bytes in the buffer to compute the current playback byte-position and added a status bar showing playback progress. http://people.xiph.org/~maikmerten/demos/bigbuckbunny-applet-javascript.html Given that I estimate the duration with outrageous crudeness (no averaging) and also compute the slider position without any means to ensure it doesn't jump around wildly I think it's pretty smooth - so perhaps estimating the duration is in fact a viable fallback if one doesn't want to determine the duration properly. Nice work! The duration is indeed jumping quite a bit between 8min and 12 min and even at the end still has a gap of actual end time of 9m54s while the estimate is still at 10m44s. Players like YouTube's player display the duration of the file which is very useful for a consumer to estimate if they actually have the time to spend on watching the video. So, even if we don't use the duration/length attribute for calculating the timeline, it may well be useful metadata for display purposes. BTW: are you planning to implement seeking on the timeline, too? It would probably not too bad given the smoothness of the slider position. Cheers, Silvia.
Re: [whatwg] Issues relating to the syntax of dates and times
- Original Message - From: Ian Hickson [EMAIL PROTECTED] To: Pentasis [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Sent: Tuesday, November 25, 2008 10:52 PM Subject: Re: [whatwg] Issues relating to the syntax of dates and times On Tue, 25 Nov 2008, Pentasis wrote: The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such. I agree with this, so disregard my previous remarks on this subject. I would however recommend dropping the word primary. I wouldn't want to make people think their particular use case was excluded. What if someone wanted to use a date to indicate the time an entry was added, for instance? Hence the word primary. That whole paragraph might be rewritten in due course though to not refer to use cases (I try to keep the spec clear of actually using the term explicitly and instead just show the use cases in examples). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' This confuses me again ;-) Sorry. Are you saying that examples and use-cases will be excluded from the spec? If so, than I disagree with it again. Like I stated before, I understand that times/dates are never *exact* (esp. very old ones). So either this element should get a limited use-case (like blog entries, calendar dates for meetings etc.) or should be able to handle all time/date use-cases (even fictional ones). Either way, this should be explicitly defined or excluded in the spec. shouldn't it? Bert
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto: Hi all, currently it isn't specified anywhere (AFAIK) what should happen if the element which has an accesskey attribute is hidden using display:none. HTML4 says the following: Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link... The problem is that focusing and activating isn't the same thing. FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets. FF3 changed the behavior to require visible and focusable element. IE7 doesn't seem to activate, only focus (at least a elements), and because hidden element isn't really focusable, it doesn't seem to do anything with elements with display:none. A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588 I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. (Key event listeners could do something similar, but they'd need to handle all the different browsers and OSes.) So I prefer what FF2, Safari and Opera do, and would like to change FF3.1 to work the same way. Anyway, I hope some behavior could be standardized. Comments? br, -Olli Maybe, the standard behaviour (for both 'display:none' and 'visibility:hidden') could be just focusing (and changing visibility) after pressing the access key (so the user notices what's happening before activating any 'control'), then activating the element after a second press. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Incontri con Meetic : Primo sito d'incontri in Europa - Milioni di single ! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8293d=25-11
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson schrieb: On Tue, 25 Nov 2008, Julian Reschke wrote: The problem is that you'd basically have to duplicate the entire form, since login forms can be arbitrarily complex. If the bot has the username and password, why not also give it the username field name, password field name, and login script url? Just consider them part of the credentials. That works in theory, but doesn't scale. For instance, we've been working on a search engine that scan internet sites that may require authentication. Configuring that login for each site would be a maintenance nightmare. Well for a piece of software of that scale, parsing the document using an off-the-shelf HTML parser and finding the first matching form element and then applying normal HTML semantics to get to the form fields Ugh. Philipp Kempgen
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: For instance, we've been working on a search engine that scan internet sites that may require authentication. Configuring that login for each site would be a maintenance nightmare. Well for a piece of software of that scale, parsing the document using an off-the-shelf HTML parser and finding the first matching form element and then applying normal HTML semantics to get to the form fields seems like a pretty small task in comparison to the rest. Well, that's what we have been doing. I was looking forward where this could be used by somebody who isn't an expert (think Microsoft Webfolder client or Apple WebDAV FS driver), and where running an HTML parser (in the kernel?) would be problematic. So, on the other hand, if the login form is more complex than username + password, what is a bot supposed to do with it? I don't understand why it makes a difference what the form is like. It should apply whatever credentials it has been given -- whatever those might be, username/password, certificate, fake addressa and phone number, whatever, and submit the form. Just like a user. To do that, it would need to *capture* that information somewhere. I was assuming the whole point in the exercise was to avoid having to pop up an HTML based UI... BR, Julian PS: But even if it doesn't help authenticating without an HTML based UI, this could be useful because it allows non-interactive clients to understand that they're looking at a login form, not the real thing.
Re: [whatwg] input placeholder=
On Tue, Nov 25, 2008 at 2:42 PM, Matthew Paul Thomas [EMAIL PROTECTED]wrote: On Nov 17, 2008, at 10:05 AM, Ian Hickson wrote: ... On Mon, 21 May 2007, Stijn Peeters wrote: ... It makes sense to clear these values when the field is focused, as the user will probably want to insert a new value rather than edit the value that is currently in it. Currently this is mostly done through javascript, which is not necessarily a bad thing, but seeing that attributes such as autofocus= have also found their way into the spec, I suppose this is also inside the scope of Web Forms 2 or HTML5. As for the attribute name, clearonfocus= with clearonfocus as the only possible value (indicating the input field or textarea should be cleared upon focusing it) would probably be most suitable. ... On Wed, 23 May 2007, Matthew Paul Thomas wrote: I don't understand. What use is a default value if you can't edit it? Why not make the field empty to begin with? On Fri, 25 May 2007, Matthew Paul Thomas wrote: No, we already addressed the label use case. I asked specifically about the default value use case. I don't know what you are asking for here. I was asking, obviously, what use is a default value if you can't edit it. If an enabled text field had a displayed value= but the value was not actually editable, that would be unpleasantly surprising. I'm still as confused as Ian here. This isn't a default value. You use @value for that. @placeholder can represent a *sample* value, but that is *not* intended to be submitted, and has no need to be editted. It's never expected to be directly useful, but rather just to show the user directly what is expected in the field. That problem applies just as much to input placeholder=foo as it would have done to input value=foo clearonfocus: depending on whether the placeholder text is greyed out, it would make the field either look like it has a value when it actually doesn't, or look disabled when it actually isn't. It would also hide the label or hint for the field for *precisely* the period when you need it most. I'm not aware of any possible presentation that avoids both (or even one of!) those problems, and previously HTML5 has shied away from expecting browsers to implement things that have no known reasonable presentation. Actually, due to the prevalance of this sort of thing, most people are rather used to gray (and possible italicized) text in an input disappearing when they click into it. It doesn't confuse them at all. The fact that it *is* relatively widely used, and isn't confusing to the average person, means that the suggested presentation *is* useful. I appreciate that Web authors currently go to some scripting lengths to position labels for text fields inside the fields, and I think it's quite appropriate that they should have to go to those lengths, because it makes bad design more difficult. I would rather see, as I've previously suggested, markup for associating form controls with hints outside them in a similar way as labels can be associated now. Actually, it's really not any great length at all. For example, http://www.kryogenix.org/code/browser/labelify/ is a dead-simple jQuery plugin that does it automagically for you. There are several other variants on the theme (this is just the first I found in a quick search), and I'm certain other js libraries have similar things built for them. The problem, of course, is that alternative display devices which try to run javascript but display pages or handle user interaction substantially differently may get an extremely messed up result out of any js-based solution. By building it directly into the language the UA can decide precisely how it wants to render and control this sort of thing to be maximally useful to its users. ... On Tue, 30 Sep 2008, Andy Lyttle wrote: ... 3) anybody who is currently using the title attribute doesn't expect it to be displayed as a placeholder, so we would break things for them (especially if their title string is too long to fit inside a small field) We can't really change the behavior of title= now, it'd have all kinds of weird unexpected effects on existing pages ... On Thu, 2 Oct 2008, Tab Atkins Jr. wrote: ... Of course, it's still not in any way semantic. The only difference between (optional) being displayed near the input and being displayed *within* the input is one of aesthetics. The meaning of the document isn't changed one iota. This leans me even more toward a CSS solution. I don't see any harm to having this in the language really. We don't disallow UAs from rendering this after the control. ... But they couldn't really do that, it'd have all kinds of weird unexpected effects on pages designed by people using browsers that present it the way the spec suggests. This is true, at least for the standard desktop browsers. They'll all standardize on the standard gray text that's already
Re: [whatwg] Solving the login/logout problem in HTML
Julian Reschke schrieb: Ian Hickson wrote: For instance, we've been working on a search engine that scan internet sites that may require authentication. Configuring that login for each site would be a maintenance nightmare. Well for a piece of software of that scale, parsing the document using an off-the-shelf HTML parser and finding the first matching form element and then applying normal HTML semantics to get to the form fields seems like a pretty small task in comparison to the rest. Well, that's what we have been doing. I was looking forward where this could be used by somebody who isn't an expert (think Microsoft Webfolder client or Apple WebDAV FS driver), and where running an HTML parser (in the kernel?) would be problematic. So, on the other hand, if the login form is more complex than username + password, what is a bot supposed to do with it? I don't understand why it makes a difference what the form is like. It should apply whatever credentials it has been given -- whatever those might be, username/password, certificate, fake addressa and phone number, whatever, and submit the form. Just like a user. To do that, it would need to *capture* that information somewhere. I was assuming the whole point in the exercise was to avoid having to pop up an HTML based UI... PS: But even if it doesn't help authenticating without an HTML based UI, this could be useful because it allows non-interactive clients to understand that they're looking at a login form, not the real thing. Good points. There are circumstances where the client is not prepared to handle or parse HTML. However if the client is a human user you want a nice login page instead of the ugly basic authentication dialog. Philipp Kempgen -- http://www.das-asterisk-buch.de - http://www.the-asterisk-book.com Amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 --
Re: [whatwg] Solving the login/logout problem in HTML
On Tue, 25 Nov 2008, Julian Reschke wrote: Well for a piece of software of that scale, parsing the document using an off-the-shelf HTML parser and finding the first matching form element and then applying normal HTML semantics to get to the form fields seems like a pretty small task in comparison to the rest. Well, that's what we have been doing. I was looking forward where this could be used by somebody who isn't an expert (think Microsoft Webfolder client or Apple WebDAV FS driver), and where running an HTML parser (in the kernel?) would be problematic. I wouldn't recommend running an HTTP parser in the kernel either. Anywhere where you can safely run an HTTP parser you can run an HTML parser too. So, on the other hand, if the login form is more complex than username + password, what is a bot supposed to do with it? I don't understand why it makes a difference what the form is like. It should apply whatever credentials it has been given -- whatever those might be, username/password, certificate, fake addressa and phone number, whatever, and submit the form. Just like a user. To do that, it would need to *capture* that information somewhere. I was assuming the whole point in the exercise was to avoid having to pop up an HTML based UI... Well if you don't have the credentials, you can't really login anyway. If the request is to be able to take an HTML form and display it to the user as some other UI, then just apply the HTML semantics to the form to get the UI out. That's exactly what HTML is _for_: encoding media- and presentation-independent semantics. PS: But even if it doesn't help authenticating without an HTML based UI, this could be useful because it allows non-interactive clients to understand that they're looking at a login form, not the real thing. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues relating to the syntax of dates and times
Pentasis wrote: Ian Hickson wrote: On Tue, 25 Nov 2008, Pentasis wrote: The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such. I agree with this, so disregard my previous remarks on this subject. I would however recommend dropping the word primary. Note that what you've quoted was from a note about a potential issue with the DOM APIs which appears in the last formally published WD, but which has since been removed from the current editor's draft. I wouldn't want to make people think their particular use case was excluded. What if someone wanted to use a date to indicate the time an entry was added, for instance? Hence the word primary. This confuses me again ;-) Sorry. Are you saying that examples and use-cases will be excluded from the spec? No. It's just that the note didn't list all possible use cases and that there are other similar use cases for marking up contemporary dates which are equally valid. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: I wouldn't recommend running an HTTP parser in the kernel either. Anywhere where you can safely run an HTTP parser you can run an HTML parser too. Maybe, maybe not. I'll leave the answer to those who need to do it. To do that, it would need to *capture* that information somewhere. I was assuming the whole point in the exercise was to avoid having to pop up an HTML based UI... Well if you don't have the credentials, you can't really login anyway. People are trained to configure credentials as value pairs (name, password). Anything more complex than that will be tricky to deploy in generic frameworks. In theory, you should be able to reformat everything that. If the request is to be able to take an HTML form and display it to the user as some other UI, then just apply the HTML semantics to the form to get the UI out. That's exactly what HTML is _for_: encoding media- and presentation-independent semantics. OK, so how do you tell a mount command that your credentials are more complex than username/password? For that matter, how do UAs like FF's password manager handle cases like these? ... BR, Julian
Re: [whatwg] Issues relating to the syntax of dates and times
On Tue, 25 Nov 2008, Pentasis wrote: This confuses me again ;-) Sorry. Are you saying that examples and use-cases will be excluded from the spec? I'm saying that examples of use cases will be included, and that the words use cases will generally be avoided. Like I stated before, I understand that times/dates are never *exact* (esp. very old ones). So either this element should get a limited use-case (like blog entries, calendar dates for meetings etc.) or should be able to handle all time/date use-cases (even fictional ones). Either way, this should be explicitly defined or excluded in the spec. shouldn't it? I've clarified the spec on this topic. Let me know if it is still vague. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] accesskey attribute with display:none elements
On 11/25/2008 11:17 PM, Calogero Alex Baldacchino wrote: Maybe, the standard behaviour (for both 'display:none' and 'visibility:hidden') could be just focusing (and changing visibility) after pressing the access key (so the user notices what's happening before activating any 'control'), then activating the element after a second press. That isn't what any of the browsers do currently, so I'm not in favor of this pretty strange behavior. And how could the browser know how to change the display value? From display:none to display:inline or display:block or display:inline-block or what?
Re: [whatwg] Issues relating to the syntax of dates and times
Lachlan Hunt ha scritto: Pentasis wrote: Ian Hickson wrote: On Tue, 25 Nov 2008, Pentasis wrote: The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such. I agree with this, so disregard my previous remarks on this subject. I would however recommend dropping the word primary. Note that what you've quoted was from a note about a potential issue with the DOM APIs which appears in the last formally published WD, but which has since been removed from the current editor's draft. I wouldn't want to make people think their particular use case was excluded. What if someone wanted to use a date to indicate the time an entry was added, for instance? Hence the word primary. This confuses me again ;-) Sorry. Are you saying that examples and use-cases will be excluded from the spec? No. It's just that the note didn't list all possible use cases and that there are other similar use cases for marking up contemporary dates which are equally valid. In other words, the normative section of the spec will be as generic as possible, while a non-normative section will cover a bounch of use cases and examples, without pretending to be exahustive with regard to all possible use cases. Am I 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=8435d=25-11
[whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
Calogero Alex Baldacchino wrote: I know, and agree with the basic reasons; however I think that deriving an SGML version (i.e. by adding new entities and elements, as needed, to an html 4 dtd) should not be very difficoult, and could be worth the effort (i.e. to graceful degrade the presentation of a menu element thought as a context menu, wich content should not be shown untill a right click happens - if the u.a. cannot handle it, not showing it at all could be a reasonable behaviour). The derived sgml version should be aimed just for older browsers, while newer, html 5-aware ones should just ignore any dtd reference. I'd consider this chance, at least on the fly - I suspect that the complete break out with the earlier sgml specifications might carry in an undesireable side-effect: from one side it solves the problems arised from sgml partial support/bad implementation and from browser-specific quirks, but from the other side no mechanism is provided to make sgml-somehow-based user agents to gain whatever awareness on the newly defined elements. What SGML-somehow-based user agents? While many web browsers switch behavior based on what they detect in the first characters of an HTML document (including the doctype declaration), there are no (or at any rate, no remotely /popular/ web browsers) that read text/html DTDs in the way required for this idea to be workable. Since all you're proposing is to bake implied STYLE values into the DTD, it seems to me your use-case could be served by making an HTML5 foundation stylesheet publicly available. Compare: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ http://developer.yahoo.com/yui/base/ -- Benjamin Hawkes-Lewis
Re: [whatwg] Solving the login/logout problem in HTML
On Tue, 25 Nov 2008, Julian Reschke wrote: To do that, it would need to *capture* that information somewhere. I was assuming the whole point in the exercise was to avoid having to pop up an HTML based UI... Well if you don't have the credentials, you can't really login anyway. People are trained to configure credentials as value pairs (name, password). Anything more complex than that will be tricky to deploy in generic frameworks. Nothing requires servers to do anything but username/password. I don't really understand what you are asking here. Presumably in a system where only username/password credentials are desired, only username/ password credentials will be used. If the request is to be able to take an HTML form and display it to the user as some other UI, then just apply the HTML semantics to the form to get the UI out. That's exactly what HTML is _for_: encoding media- and presentation-independent semantics. OK, so how do you tell a mount command that your credentials are more complex than username/password? How do you tell a mount command that your credentials are a certificate? This isn't an HTML issue. For that matter, how do UAs like FF's password manager handle cases like these? Password managers vary in implementation, but some remember all fields, others just the password field and one other heuristically-chosen field, others bail on such forms. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues relating to the syntax of dates and times
On Tue, 25 Nov 2008, Calogero Alex Baldacchino wrote: In other words, the normative section of the spec will be as generic as possible, while a non-normative section will cover a bounch of use cases and examples, without pretending to be exahustive with regard to all possible use cases. Am I wrong? The examples in the spec are already in the spec in their expected final location, so you can pretty much see what we intend to do by looking at the spec today. http://whatwg.org/html5 There will be more examples in time, but that's the only real planned difference of relevance here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay wrote: I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. Hmm … Couldn't you style such elements visible with :focus and :active? Does popular assistive technology report accesskey on elements that aren't rendered (display: none;) rather than merely hidden off-left (position:absolute; left:-9em;)? (It tends not to report elements that are display: none; at all, note.) And, either way, is there any reason why it should report the accesskey but not the element? -- Benjamin Hawkes-Lewis
Re: [whatwg] Issues relating to the syntax of dates and times
- Original Message - From: Ian Hickson [EMAIL PROTECTED] On Tue, 25 Nov 2008, Pentasis wrote: This confuses me again ;-) Sorry. Are you saying that examples and use-cases will be excluded from the spec? I'm saying that examples of use cases will be included, and that the words use cases will generally be avoided. Like I stated before, I understand that times/dates are never *exact* (esp. very old ones). So either this element should get a limited use-case (like blog entries, calendar dates for meetings etc.) or should be able to handle all time/date use-cases (even fictional ones). Either way, this should be explicitly defined or excluded in the spec. shouldn't it? I've clarified the spec on this topic. Let me know if it is still vague. Well, I hate to be nitpicking here. But the way it is described now still creates a difference in *possible* markup between: The battle of waterloo was fought on time datetime=1815-06-18Sunday 18 June 1815/time and: Julius Ceasar was assassinated on the ides of march in the year 44BC. The spec allows us to use the time-element in the first case but not in the second, while the type of information and semantics of the sentence are the same in both cases and both dates are known dates and agreed upon to be true. I can imagine this to be confusing for authors/users. Bert
Re: [whatwg] Deprecating small , b ?
On Tue, Nov 25, 2008 at 3:08 PM, Calogero Alex Baldacchino
[EMAIL PROTECTED] wrote:
Tab Atkins Jr. ha scritto:
On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Of course that's possible, but, as you noticed too, only by
redefining the small semantics, and is not a best choice per se.
That's both because the original semantics for the small tag was
targeted to styling and nothing else (the html 4 document type
definitions declared it as a member of the fontstyle entity,
while, for instance, strong and em were parts of the phrase
entity), and because the term 'small', at first glance, suggests
the idea of a typographical function, regardless any other related
concept which might be specific for the English (or whatever else)
culture, but might not be as well immediate for non-English
developers all around the world. As a consequence, since any
average developer could just rely on the old semantics, being he
intuitively confident with it, the semantics redefinition could
find a first counter-indication: let's think on a word written
with alternate b and small letters, or just to a paragraph
first letter evidenced by a b, obviously the application of the
new semantics here would be untrivial (i.e. an assistive software
for blind users would be fouled by this and give unpredictable
results). Despite the previous use case would be a misuse of the
b and small markup, yet it would be possible, meaning not
prohibited, and so creating a new element with a proper semantic
could be a better choice.
No matter *what* we do, if there *is* a default style for an element, it
will be misused by people. This is a fact of life. Defining a new element
which is identical to small in every way except that it hasn't been
misused *yet* is thus a mug's game, because it *will* be misused in the same
way as small, and then we just have two identical elements for no reason.
I'll start with an example. A few time ago I played around with Opera
Voice. It seemed to be capable to interpret visual style sheets and
specifically font styles, so that bold or italics text (so constraint in the
style sheet, not the markup) were spoken differently from 'normal' text, but
a paragraph first letter differing from the rest of the word (which is a
non-rare typographical choice), as far as I remember, caused the whole word
to be skipped.
Do you mean that if you had markup like pbW/bhen I was young.../p,
it would be read out as I was young...? If so, that's clearly a bug in
the reader, and has nothing to do with semantics or the lack of it. There
is *no* legitimate interpretation of that markup that would lead one to
discard the first word.
This suggests me that if we really want a 'cross-presentation' semantics,
we have to keep as far as we can from anything having a *main* typographical
semantics (as small and b have from their birth). Every language is
somehow prone to side-effects caused by misuse (i.e. it is possible to cause
a big mess in a software written in a language allowing to pass a pointer to
a function - there are tons of examples for language design issues - yet
such could be a desireable capability), but appropriate choices for both
semantics and syntax may help to reduce the likelyhood of a misuse.
I think that very likely both b and small will carry on their old
semantics, so being more prone to misuse with respect to their new one,
since very likely a lot of developers are, and will rest, more confident
with their original semantics, which is also suggested by their names ('b'
standing for 'bold' and 'small'... for something small on the screen or on
paper). Instead, a new element would require the developer to take some
effort at least to learn about its existence, so he would read that such
element primary use is to indicate a different importance of a piece of
text, so that a non visual user agent can present it in an appropriate
manner, and a visual or print user agent can render it in different ways.
Well, the new semantics are purposely very close to the old 'semantics'.
Bold text *is* text purposely offset from the surrounding prose. Some
legacy uses of b are more correctly done with other existing elements,
like strong or h1, but at least it's *close*.
And again, the type of author who *is* marking up random things with b for
purely stylistic reasons isn't the sort who is going around reading
standards documents, or likely even caring in the slightest. If they *did*
discover a new element that has the correct semantics (like standout or
something), they'll either ignore it (if it's basically identical to b) or
use it nonsemantically as well (if it offers some exciting new default
styling).
Basically, there is a subset of authors who are morons, and they'll screw up
anything we do. Most of us aren't like that, but
Re: [whatwg] Issues relating to the syntax of dates and times
Ian Hickson ha scritto: On Tue, 25 Nov 2008, Calogero Alex Baldacchino wrote: In other words, the normative section of the spec will be as generic as possible, while a non-normative section will cover a bounch of use cases and examples, without pretending to be exahustive with regard to all possible use cases. Am I wrong? The examples in the spec are already in the spec in their expected final location, so you can pretty much see what we intend to do by looking at the spec today. http://whatwg.org/html5 There will be more examples in time, but that's the only real planned difference of relevance here. But an example is just that, an explanation on a specification rule which adds nothing to its generic formulation but a clarification, without covering all possible scenarios, but only the more relevant for clarification sake, and might be labeled as non-normative. This is what I meant (specifically a 'logical' separation, not a 'physical' relocation, as opposit to a whole discarding of use cases). Sorry if I posted a messed up concept. -- 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=25-11
Re: [whatwg] Issues relating to the syntax of dates and times
On Tue, 25 Nov 2008, Pentasis wrote: But the way it is described now still creates a difference in *possible* markup between: The battle of waterloo was fought on time datetime=1815-06-18Sunday 18 June 1815/time and: Julius Ceasar was assassinated on the ides of march in the year 44BC. The spec allows us to use the time-element in the first case but not in the second, while the type of information and semantics of the sentence are the same in both cases and both dates are known dates and agreed upon to be true. I can imagine this to be confusing for authors/users. Could you, for both cases, give the precise number of seconds from the day of the event in question until now? My impression is that we would not be able to give the precise number of seconds since a date on the Roman calendar. For example, were the years after 44BC regular or intercalary? As I said before, I think before we start supporting other calendars (like the Roman calendar, or even the more recent Julian calendar), we should support non-Gregorian calendars that are in active use today. But I don't propose to do this at this time, as that is an inordinately complicated problem and we don't yet know if time is going to be widely used or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media elements: Relative seeking
On Wed, Nov 26, 2008 at 12:28 AM, Silvia Pfeiffer [EMAIL PROTECTED] wrote: In any case - if you (and also Chris Double) are satisfied with the estimates you're getting for file duration/length - I'll stop arguing for it. It would be nice to hear some experimental evidence about how well it's doing, e.g. for typical movie trailers, so we can lay that argument to bed knowing we've done our homework. I won't be estimating the duration - the user experience of a fluctuating duration is terrible. For now for Ogg files, I'm seeking to the end and getting the duration. For the few servers that don't support seeking, duration is not available. I may check for X-Content-Duration which I believe mod_annodex and soon oggz-chop support. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Solving the login/logout problem in HTML
On Tue, 25 Nov 2008, Julian Reschke wrote: I was hoping that the authentication scheme you're defining can be used without parsing the HTML response. A simple way to achieve it would be to restrict it to username/password pairs, and to have the names of these form parameters live in the response headers as well. We would have to, at a minimum, include the name of the username field, the name of the password field, and the URL of the form to POST to. I am very wary of duplicating information that is already available as it tends to become out of date and thus ends up being even more of a pain than if the information isn't there in the first place. OK, so how do you tell a mount command that your credentials are more complex than username/password? How do you tell a mount command that your credentials are a certificate? If your credentials are a cert, why would you use form-base logon? (I admit I'm not an expert on these issue, so please by patient with me). My point was not that a form might use cert authentication, but that whatever mechanism is available today for logging in with authentication schemes other than username/password would be the same ones one would continue to use to login to systems with authentication schemes other than username/password. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] accesskey attribute with display:none elements
On 11/26/2008 12:39 AM, Benjamin Hawkes-Lewis wrote: Olli Pettay wrote: Couldn't you style such elements visible with :focus and :active? What you mean? How do you focus a display:none element? Good point. You can't. Isn't that a problem in practice? i.e. When do you want a control to have an accesskey but _not_ be focusable? For example when you want to execute some JS when accesskey is pressed: a accesskey=x href=javascript:doSomething(); That behavior is used in the web https://bugzilla.mozilla.org/show_bug.cgi?id=419059mark=1#c1 The comment mentions dhtml menus and that is a valid use case for accesskeys in display:none elements. -Olli
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto: On 11/25/2008 11:17 PM, Calogero Alex Baldacchino wrote: Maybe, the standard behaviour (for both 'display:none' and 'visibility:hidden') could be just focusing (and changing visibility) after pressing the access key (so the user notices what's happening before activating any 'control'), then activating the element after a second press. That isn't what any of the browsers do currently, so I'm not in favor of this pretty strange behavior. And how could the browser know how to change the display value? From display:none to display:inline or display:block or display:inline-block or what? Maybe I've replied to quickly, sorry for this. The user agent should have a default style sheet with a default display value for each element, so that value could apply (this may lead to unwanted results if the element had a different display value before the value none was set, and this case should be handled by script). I guess what you wish is something like a shortcut in a desktop application, letting you access any control in a menu without showing and esploring the menu. Despite this could be a desireable behaviour for a web application, I think it could also be used to trick the user, or cause an unwanted operation to be performed as a consequence of a casual key pressing, thus the idea of showing the control before activating it, giving the user a chance to stop the operation. For the possible tricks, I guess that might be a minor concern (since there are far 'better' ways to compromise your navigation); anyway, consider that an element constraint with 'display:none' is not a part of the formatting structure for any media and you cannot access it anyway (i.e. you cannot click on it, you cannot reach it by pressing the tab key). That's not just invisible, that's not presented to you at all, almost if that wasn't in the document tree, so that's not focusable at all, and accessing it through an access key would be quite a tricky way to bypass the above 'restrictions' (as if that was forced into the document layout). A better way to do what you aim would consist of setting a listener for key events on a displayable element and choosing a different operation basing on the pressed key(s); a perhaps tricky alternative would be using controls with an accesskey attribute properly set and 'emulating' the 'display:none' layout property by setting their width, height, margin, etc., to a value of zero, and their display property to the 'inline' value. I guess any browser allowing the behaviour you ask for any element with a 'display:none' value perhaps just works around a somewhat misuse of the display property as a quirk. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Incontri con Meetic : Primo sito d'incontri in Europa - Milioni di single ! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8293d=26-11
Re: [whatwg] Solving the login/logout problem in HTML
On Tue, 25 Nov 2008 05:26:47 -, Ian Hickson [EMAIL PROTECTED] wrote: http://www.w3.org/TR/1999/NOTE-authentform-19990203 [...] I don't really understand what problem the above solves that isn't solved better by SSL. I agree that if real security is desired, SSL is the only way to go. However given that most login forms on the web send passwords in the clear, other problems were more important than security. Form + Digest avoids these SSL problems: * Does not negatively impact performance. In TLS handshake lots of messages are going back and forth, so this can't be fixed by beefing up servers' CPUs. * Does not need access to server's configuration, and generation, installation and renewal of certificates. Redistributable software can support it out of the box, on almost any server, without manual installation steps. Additionally, it's better than new WWW-Authenticate: HTML authentication mechanism: * It's compatible with existing non-HTML HTTP clients. * Although its security is weak compared to SSL, it's a step up from forms + cookies. * It's easier to sell: It will allow bots to log in doesn't sound very desirable. It will protect your users' passwords against passive eavesdropping sounds better. I don't think WWW-Authenticate: HTML is a significant improvement. It doesn't offer anything to existing websites/browsers. It's primarily targetted for non-browser UAs, but it's not compatible with them. If UAs are required to parse HTML, they could as well look for form with a single password field. -- regards, Kornel Lesinski
Re: [whatwg] WF2: Non-validating submit buttons
On Wed, 24 Jan 2007, Martin Atkins wrote: It would be useful to be able to mark certain submit buttons as non-validating. I've added a novalidate= attribute for this case. Thanks for the discussion of use cases and examples of actual sites, which were useful in determining whether this was worth adding, in particular: On Wed, 4 Apr 2007, Martin Atkins wrote: * Allowing the user to submit an unfinished form to the server to be saved for later completion. * A preview button that allows the user to see the results of what has been completed so far without completing the entire form. * Buttons that trigger round-trips to the server to alter the form in some way. On Wed, 4 Apr 2007, Christian Schmidt wrote: There appears to be at least some demand for such a feature, and so far there has been no negative responses. What is the next step? The next step is that I eventually (about 670 days later in this instance) get around to reading the feedback and processing it into the spec. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Geolocation in the browser
I include below a number of e-mails sent on the topic of Geolocation and possible things we should add to HTML5 around this. I haven't added anything, because I the W3C's Geolocation group is already working on providing an API for this. I encourage people who want to work on this topic to join that group: http://www.w3.org/2008/geolocation/ I didn't see anything in the feedback below that hasn't already been more or less said in the context of that group, so this time I haven't forwarded the feedback to the other group as I usually do. On Wed, 21 Feb 2007, Ryan Sarver wrote: Hey guys. I have been watching the list for a bit and thought it was time for me to jump in here and kick off a discussion on geolocation-aware browsing. I tried to search through the archives to see if the discussion had come up before and didn't find anything, so please forgive me if it has. I am the Dir of Product Development at Skyhook Wireless where we have a Wi-Fi Positioning System - think GPS, but software-only and uses Wireless APs instead of satellites. We have been working on developing a plugin for Firefox that gives a website access to the user's location via javascript. User's can control access to this information at the domain level in much the same way they control cookies and popups. We have been successful in exposing it through the Javascript DOM and wanted to start talking with standards bodies about coming up with a standard implementation to make location-aware browsing common functionality at the browser level. I was hoping to kick off a discussion around possible implementations and get the community's thoughts on the topic. Location could be exposed through a standard Javascript object/interface var location = window.getLocation(); - would it make sense to also expose it in the request headers? This way the server receives it on the first request as opposed to through the client after the initial page request User-Geolocation: 43.338018, -71.817930 What are people's thoughts on location in the browser? Is the window object the right object to attach to? Im interested to hear everyone's thoughts... On Wed, 21 Feb 2007, David Latapie wrote: Surely you've heard of ICBM (meta name=ICBM content=46.025507, 14.300186 /) Could elaborate on what you like and dislike on this? On Wed, 21 Feb 2007, Ryan Sarver wrote: The ICBM standard is for geotagging the actual content whereas we are talking about a standard that lets the content know the location of the User or device so that the website can be location-aware. I want to use as much of the existing standards, but have more questions about where it should exist in ecosystem and how servers and webpages would expect to see it and use it. On Wed, 21 Feb 2007, Ryan Sarver wrote: That's a good point. I think you're right that the navigator object might make more sense: // Example var location = navigator.getLocation(); alert(location.latitude+', '+location.longitude); On Wed, 21 Feb 2007, Ryan Sarver wrote: It's also important to remember that this functionality would be an opt-in system - unlike your cell phone :) The prototype that we are working on would allow the browser to point to a COM port where it could find a GPS device or any NMEA-compatible device or software. It would then read the NMEA stream over the COM port and use that to deliver the user's location to the website via the DOM. Our software positions you based on WiFi triangulation and can emulate a GPS device by streaming NMEA over a virtual COM port so that the user wouldn't need to have a dedicated GPS antennae. On Wed, 21 Feb 2007, Ryan Sarver wrote: I hear you ... the idea is really two fold -- the first part is to standardize how web applications access the location information, regardless of how it is determined. The second is to offer a standard way of different location acquiring technologies -- GPS, Wifi positioning, geocoding an user-entered address, etc -- to deliver location to the browser. In this case I am proposing using the NMEA standard as it is well documented and would allow for compatibility with existing GPS devices. I agree, there are very few GPS-enabled laptops - in fact the only one I know if us a UMPC - but there are a lot of Bluetooth capable laptops and Bluetooth antennas to provide the location. There are also solutions like ours at Skyhook that are software-only and would allow people to immediately begin to provide their location to the browser via a simple download. This would all obviously be configurable in the UA... On Fri, 23 Feb 2007, Dave Raggett wrote: Following on from Michael Smith's email on proosed W3C work in this area, I thought it might be helpful to provide a litte context. There is a great deal of interest in location based web applications and the challenge is how to expose this to
Re: [whatwg] Web forms 2, input type suggestions
On Sat, 14 Jul 2007, Martin Atkins wrote: Benjamin Joffe wrote: type=address Indicates that the input should represent an address, the user agent may aid by displaying data from a GPS or use an online map etc. I have a little more trouble with this idea, for a number of reasons: * Address formats vary from region to region. * Sites usually want items like the postal code, state, county or town separated from the street address for various reasons. This is not catered for by your proposal. * To do anything special for this field beyond just displaying a big text box some sort of external data source is required, but it is not at all obvious what that data source would be or what a good UI for this field type might be. Yeah, I don't see why type=text isn't enough here. type=location Same as above but instead of sending an address string it would send latitude/longitude information, this (as opposed to the above) would send a well-formed string. Perhaps coordinates/geocoordinates or something else would be a more suitable name for the latter. I have similar reservations about this one, but at least there is a more obvious UI: mobile devices with built in GPS recievers could concievably provide an option to fill in the current coordinates. However, I'm not sure that submitting geographic coordinates is a common enough case to warrant an input type of its own. Part of me wants to generalize it to be type=2dvector and type=3dvector, which can then represent any 2D or 3D coordinates. I'm not really sure what a UA would do to such a field that would be any more useful than two or three type=text elements, though. We used to have type=location, long ago. It was removed due to the problems involved in providing this information. Now that the W3C is working on a Geolocation API, I think we should defer this for now and only if there is still a clear need for this in a few years should we reconsider it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Kornel Lesinski wrote: On Tue, 25 Nov 2008 05:26:47 -, Ian Hickson [EMAIL PROTECTED] wrote: http://www.w3.org/TR/1999/NOTE-authentform-19990203 [...] I don't really understand what problem the above solves that isn't solved better by SSL. I agree that if real security is desired, SSL is the only way to go. However given that most login forms on the web send passwords in the clear, other problems were more important than security. Form + Digest avoids these SSL problems: * Does not negatively impact performance. In TLS handshake lots of messages are going back and forth, so this can't be fixed by beefing up servers' CPUs. This is also the case with form authentication. * Does not need access to server's configuration, and generation, installation and renewal of certificates. Redistributable software can support it out of the box, on almost any server, without manual installation steps. Form authentication is even easier to support than Digest auth. Additionally, it's better than new WWW-Authenticate: HTML authentication mechanism: * It's compatible with existing non-HTML HTTP clients. Agreed. * Although its security is weak compared to SSL, it's a step up from forms + cookies. Not really. If you can sniff the password from forms + cookies, then you can almost always also MitM a Digest connection, after which point you have basically lost. * It's easier to sell: It will allow bots to log in doesn't sound very desirable. It will protect your users' passwords against passive eavesdropping sounds better. Unfortunately, both of those advantages pale in comparison to you can style your login form, which is the real advantage of WWW-Authenticate: HTML and (in particular) HTML form authentication. I don't think WWW-Authenticate: HTML is a significant improvement. It doesn't offer anything to existing websites/browsers. It's primarily targetted for non-browser UAs, but it's not compatible with them. If UAs are required to parse HTML, they could as well look for form with a single password field. I agree that it's not that great. But it is slightly better than nothing, and the cost to support this is pretty minimal. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Drag-and-drop feedback
(Note: feedback relating to drag-and-drop of files from the filesystem, with possible uploading of content, isn't included in this e-mail. I am waiting to see what happens with the Web Apps File Upload spec.) On Mon, 30 Apr 2007, Jon Barnett wrote: On 4/30/07, Ian McKellar [EMAIL PROTECTED] wrote: On 4/25/07, David Hyatt [EMAIL PROTECTED] wrote: The use case of being able to drop images into a contenteditable region and have them show up as img elements at the appropriate place and then get automatically uploaded somewhere is a really compelling one. Is there already an API for knowing exactly where something is dropped? Possibly - an empty Range object as either the relatedTarget or part of the detail of a drop event. There isn't, but isn't the cursor moved to the drop target position automatically in most systems? And in systems where that doesn't happen, shouldn't the drop happen where the cursor is anyway? On Wed, 18 Jun 2008, Neil Deakin wrote: The initDragEvent/initDragEvent methods take a DataTransfer as an argument. Is it expected that the DataTransfer to use here can be created with 'new DataTransfer'? No. If you really wanted to create your own DragEvent object, you'd have to fake a DataTransfer object using a JS object that happened to implement all the right attributes and methods. IE and Safari allow a no-argument form of clearData as well which clears all formats. Added. The description for the 'types' property implies that this should be a live list. Why? Why not? The clearData, setData and getData methods should clarify what happens if an empty format is supplied. Done. I still don't understand the purpose of the addElement method. Either this should be removed or there should be clarification of the difference between addElement and setDragImage Added a note. Previously, I said that DragEvents should be UIEvents. I think they should instead inherit from MouseEvent. Done. We have a need to be able to support both dragging multiple items, as well as dragging non-string data, for instance dragging a set of files as a set of File objects (see http://www.w3.org/TR/file-upload/) from the file system onto a page. Agreed, but I haven't added anything for files yet because I'm waiting for that spec to stabilise. On Fri, 20 Jun 2008, Robert O'Callahan wrote: On Thu, Jun 19, 2008 at 9:31 AM, Thomas Broyer [EMAIL PROTECTED] wrote: That's how Adobe AIR solved the problem. They added a Bitmap and File list data formats, for which getData returns AIR-specific objets (a BitmapData and an array of File objects respectively) Creating a new data format for each kind of collection seems suboptimal. And it breaks completely if you want heterogeneous collections. It would be useful to have a clearer description of use cases for this kind of thing. When would an app be dragging a mixed bag of stuff like this? (That aren't all files, and that can't all be described together as a single piece of data with a single type.) On Thu, 14 Aug 2008, Greg Houston wrote: [...] 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. Isn't that just dragging the handle? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] input type=color
On Sat, 14 Jul 2007, Martin Atkins wrote: Benjamin Joffe wrote: Have the following possible values for the TYPE attribute been considered for the INPUT element? type=color The user agent would display an appropriate colour picker and would send a hexidecimal string represting that colour to the server. I like this idea. It's simple and it's something I've implemented (and seen implemented) dozens of times. Added. On Sat, 14 Jul 2007, Sander wrote: I like this one too. It should have an pallet attribute that defines the color pallet. I'm not shure how though, cause on one hand I'd like to be able to choose easily from standard pallets, but on the other hand I'd like the option to create custom pallets. Perhaps pallet=custom combined with a datalist could be an option here. I've made list= and datalist apply to type=color, but not given any control over the actual range of colours allowed, so users can pick any opaque sRGB color. On Sat, 14 Jul 2007, Sander Tekelenburg wrote: Same here. A use case I can imagine is an authoring tool that let's users create CSS rules. Simply clicking the wanted colour avoids the risk of (syntactically) incorrect color values. However, to make it complete it would have to work both ways: if the form defines a color (input type=color value=#66f), that colour should be presented s selected by the UA's color picker. Perhaps that's something to leave entirely up to the UA, but I'd like it better if the at least suggests that they may do. I've required the value= to set the initial value. I wonder what the fallback mechanism should be though. What should UAs that do not/can not provide a color picker do? type=text fallback seems to work ok for this. Could be useful if you'd need to allow the user to choose only from a limited list of options, yes. If there already is a standard that describes colour palettes, that might be useful. If not, this might be too complicated. If you really want a specific set of colours, use select. On Sat, 14 Jul 2007, Andrew Fedoniouk wrote: There are many possible implementations for different purposes. Here is one of color selectors we use in HTML: http://www.terrainformatica.com/sciter/screenshots/color-chooser.png I think it is not realistic to define all of them in single specification - too many different use cases. I've made the spec say the control is a color well, leaving the details of the color picker to the UA. I would define some generic extensible mechanism for inputs rather than defining particular input type=foo. See XBL2 for this. On Mon, 16 Jul 2007, Lachlan Hunt wrote: Martin Atkins wrote: Lachlan Hunt wrote: http://www.haymespaint.com.au/haymes/colourcentre/ http://www.ficml.org/jemimap/style/color/wheel.html http://wellstyled.com/tools/colorscheme2/ These are some rather contrived examples. How can you possibly call them contrived, when they are real world examples of colour selection applications? I haven't made type=color suitable for color-specific applications that have rather specific needs (e.g. picking Pantone colors, or colors in a specific color space, or whatnot). On Mon, 16 Jul 2007, Martin Atkins wrote: Applications for exploring colour spaces already have a satisfactory solution, as in your examples. Since their focus is on colour selection they implement a more elaborate UI that fits their purpose exactly. Right. Likewise, applications such as Google Calendar implement their own UI for exploring the calendar rather than relying on the UI provided by input type=date Right. But Google Calendar could use type=color for the color widget instead of rolling their own as they do now. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Interactive Content
The definition of Interactive Content states: Certain elements in HTML have an activation behavior, which means the user agent should allow the user to manually trigger them in some way, for instance using keyboard or voice input (though not mouse clicks, which are handled above). It's not clear which section the last statement in parenthesis is referring to. I couldn't find anywhere above that in the spec that discusses the handling of mouse clicks. Please add a link to the appropriate section. http://www.whatwg.org/specs/web-apps/current-work/#interactive-content-0 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Interactive Content
On Wed, 26 Nov 2008, Lachlan Hunt wrote: The definition of Interactive Content states: Certain elements in HTML have an activation behavior, which means the user agent should allow the user to manually trigger them in some way, for instance using keyboard or voice input (though not mouse clicks, which are handled above). It's not clear which section the last statement in parenthesis is referring to. I couldn't find anywhere above that in the spec that discusses the handling of mouse clicks. Please add a link to the appropriate section. http://www.whatwg.org/specs/web-apps/current-work/#interactive-content-0 Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] usemap= and related issues
On Thu, 26 Jun 2008, Jonas Sicking wrote: On Sat, 18 Aug 2007, Jonas Sicking wrote: Since ID is case sensitive everywhere else, I don't see a reason to make an exception from that rule here. That seems to unnecessarily complicate implementation as well as introduce weird inconsistencies for authors. It already is inconsistent for usemap=. At least for legacy Web content I don't think we can do much about it. At that point, I'd rather just extend that to XHTML than to keep another difference. In mozilla for HTML we only look at the name attribute, and only do so case insensitively. For XHTML we only look at the id attribute, and are always case sensitive. We have had a number of bugs filed on id not working on HTML, (with most of them pointing at the XHTML spec as a reason it should work) but they all use the same casing for the usemap attribute and the id attribute. Do you have any data showing that using case sensitive matching for the id attribute would break compatibility with any pages? I do not. It seems like something where being incompatible with what IE does is unnecessary, though. What I did notice in our code though is how we deal with the case when there are multiple maps with the same name. In this case we generally use the first map. But if the first map is empty, we use the first non-empty map. This was done for compatibility with some sites. See https://bugzilla.mozilla.org/show_bug.cgi?id=264624 I have no idea if this matters today or not. I couldn't reproduce this behavior. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media elements: Relative seeking
Silvia Pfeiffer schrieb: The duration is indeed jumping quite a bit between 8min and 12 min and even at the end still has a gap of actual end time of 9m54s while the estimate is still at 10m44s. Actually that gap means the byte-accounting is still buggy. Hmmm... Players like YouTube's player display the duration of the file which is very useful for a consumer to estimate if they actually have the time to spend on watching the video. So, even if we don't use the duration/length attribute for calculating the timeline, it may well be useful metadata for display purposes. I agree. However, even if the media element itself doesn't evaluate that attribute content providers could still attach it to the media element for their JavaScript-players to fetch that information. Making that standard may make sense, though. BTW: are you planning to implement seeking on the timeline, too? It would probably not too bad given the smoothness of the slider position. Aye, I'm absolutely planning to implement seeking. This applet is supposed to become a fallback option if the browser itself has no media elements, so it should implement enough HTML5-media scripting to be usable for the more common usecases. Maik
