Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. As to comment 2, I agree that the various traps put in place are exceptionally annoying. An alternative would be a forced closing via the browser rather than some modification of the behavior of Javascript. That would side step the question of Have you covered all of the annoying cases (onbeforeunload, on unload, on hide...)?. On 2011-02-28 19:42, Ian Hickson wrote: On Thu, 25 Nov 2010, Biju wrote: 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. What's the use case? On Thu, 25 Nov 2010, Biju wrote: In a software application there is no need to have prompt to the user if the application is not planning to do any branching after user response. When we have alert(), it dont give user any choice other than pressing OK Hence it not possible to code any branching statement after result of user action. (with exception Press OK after you insert DVD to the drive ) So only use for alert() I see is not make a delay, that use case can be improved if web programmer can provide a default time out. As you point out in your original e-mail, it seems like this kind of use case is better handled by Web 2.0 JavaScript libraries. In the medium term I expect we will introduce a feature to create modal and non-modal in-page dialogs using markup, so this will likely become moot. On Thu, 25 Nov 2010, Markus Ernst wrote: Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. This would be a side-effect of the aforementioned markup-based dialogs. On Thu, 25 Nov 2010, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. On Thu, 25 Nov 2010, Nikita Popov wrote: That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Other browsers will follow. On Thu, 25 Nov 2010, Markus Ernst wrote: Opera even provided a Stop executing scripts checkbox in the alert() dialog for years already, which made it my preferred browser for debugging my scripts (handy if you have forgotten an i++ in a loop, and placed an alert() inside). Indeed. On Thu, 25 Nov 2010, Benjamin Poulain wrote: The specification deprecates some elements that use to be widely used (the elements font, big, center, etc). Actually it obsoletes them. Deprecating is only a recommendation for authors to not use the feature. It's hard to effectively do that with script since there's no good way to do scripting validation.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Aryeh! You have made an ad-hominem attack: shame on you! I mention the Microsoft use cases only to save space. There are similar cases in the Linux and Macintosh realms. Judge an idea by its merits, not by its source (even if that source is as disreputable as I certainly am). You are correct that short duration time outs are, often, a terrible idea ... but the standard should not hobble the developer. Terrible ideas are a matter of opinion; my ideas are always grand and glorious, never terrible ... just ask me ... for I never lie and am always right. ...and consider this: just how would you handle the case in which the WWWeb page says: There is an approaching storm! Do you wish to close the dykes? No (let everybody drown) Yes (if you don't answer in an hour, this will be the default) To say that the WWWeb should not be used for this is in itself a terrible idea for you know that it will be used in this manner and neither of us can prevent such stupidities. By-the-Way - I advocate no change to alerts and such ... the above can be implemented with setTimeout without any changes to existing browsers. Best (and please understand my admonitions to be accompanied by affection and great respect)! BdG/WeBMartians === On 2011-03-01 19:46, Aryeh Gregor wrote: On Mon, Feb 28, 2011 at 7:42 PM, Ian Hicksoni...@hixie.ch wrote: Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? We could define script APIs, or features of them, as deprecated if browsers were willing to log some kind of notice to their error consoles when the feature is used. They all have error consoles with different reporting levels already, so it shouldn't be a pain for them to implement. They can have the deprecation warnings off by default so they don't clutter the output. At least Firefox already does this for some things, like document.getSelection() (although that message will probably go away in a future release). Of course, this would only be useful if we had a good alternative to recommend. Don't use alert(), use some giant JavaScript library instead is unlikely to be a very helpful message. But it would be nice for some of the crazier or more horrible APIs, if they have saner replacements. On Tue, Mar 1, 2011 at 9:12 AM, WeBMartianswebmarti...@verizon.net wrote: For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. Timeouts on dialogs are typically a terrible idea, and we shouldn't encourage them. They mean that if the user wasn't paying attention -- which could just mean they were looking at another tab, in browsers with tab-modal dialogs -- they never see the dialog. This is only useful in the case where the dialog is so useless you don't actually care if the user doesn't see it, in which case, why show it? In practice, authors often add timeouts to things that they expect the user to see, leaving the user confused if they don't wind up seeing it. IIRC, one of the nice little improvements I made to MediaWiki a few years ago was removing the last of the timed redirects from it. OS APIs are much more enthusiastic about permitting programmers to shoot themselves in the foot than web APIs. Microsoft specifically also cares much more about developers and less about users, because they depend on developers to write Windows-only apps and maintain Microsoft's lock-in, while users are forced to buy Windows anyway. Browsers, on the other hand, care very strongly about users, because users can easily switch to another browser at any time, while developers (authors) don't help or hurt them much as long as they write cross-browser code. So for multiple reasons, the fact that Windows supports something doesn't mean we should. You need to give actual specific use-cases, not just cite the fact that the feature exists in Windows.
Re: [whatwg] US-ASCII vs. ASCII in Web Socket Protocol
Hmmm... Maybe it would be better to say ISO-646US rather than ASCII. There is a lot of impreciseness about the very low value characters (less than 0x20 space) in the ASCII specifications. The same can be said about the higher end. === Ian Hickson wrote: On Fri, 6 Nov 2009, Yuzo Fujishima wrote: I see both US-ASCII and ASCII are used in: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54 If they mean the same thing, one should be used consistently. In the document, US-ASCII seems to mean encoding while ASCII mean charset. Is this common? (I guess US-ASCII is commonly considered as an alias for ASCII. http://en.wikipedia.org/wiki/ASCII#Aliases ) I've changed the spec to use ASCII consistently. Cheers,
Re: [whatwg] Dates and coordinates in HTML5
It's back! It won't die! :-) Although it can be argued that a standard should not consider the work required for implementation, many of the trade-offs in reference to times and dates do indeed take the present state of code into consideration. One reason for not supporting BCE is a disagreement between historians and, say, astronomers, on how to represent the year immediately preceding year one. Is it year -1 (1 BCE) or year zero? Currently, the text states that all dates and times since the beginning of the common era (0001-01-01 00:00:00Z) must be supported. Yes, the Javascript values can specify dates and times before this epoch. However, there is no way to interrogate the environment as to whether or not such values can be used with time. That would require much more work. Thus, the limitation of common era. I'd love to see support for BCE and even for prolepsis and non-Gregorian calendars. ...but I do see the no BCE compromise as a workable one. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Andy Mabbett Sent: Tuesday, 2009 February 24 13:42 To: WHATWG List Subject: Re: [whatwg] Dates and coordinates in HTML5 In message 49a3e9b9.4090...@lachy.id.au, Lachlan Hunt lachlan.h...@lachy.id.au writes Andy Mabbett wrote: It seems to me that there are several outstanding, and overlapping, issues for time in HTML5, which include use-cases, imprecise dates, Gregorian vs. non-Gregorian dates and BCE (aka “BC“) dates. The time element was primarily designed to address use cases involving contemporary dates. It doesn't address non-Gregorian calendars or BCE dates by design, as it is not really meant for historical dates. Yes; and it is that narrow approach with which I take issue. Probably the most historical dates that it would really be suitably optimised for are people's birthdates, Why? Why are those dates more worthy of being semantically marked-up than, say, the date of the sailing of the Mayflower, of the birthdate of Caesar? [...] These issues have all been discussed before, either here in the whatwg or on public-html, and so I won't go into great detail. I did make a point of saying: I've read up on what prior discussion I can find on the list; but may have missed some. I'll be happy to have anything I've overlooked pointed out to me. First, though, I should like to make the observation that, while hCalendar microformats are most commonly used to allow event details to be added to calendar apps, and that that use case drove their development, they should not be seen simply as a tool to that end. I see them, and hope that others do, as a way of adding semantic meaning to mark-up; and that's how I view the “time element, too. Once we indicate that the semantic meaning of a string of text is date, it's up to other people to decide what they use that for — let a thousand flowers bloom, as the adage goes. I think this is a philosophical difference in approach from that which we used in developing the time element, and other features in HTML5. Semantics for the sake of semantics are not, and should not be, a design goal. I am not proposing semantics for the sake of semantics; I am showing that the semantics are already deployed, and that once deployed, the potential use cases are more varied than the current examples. [...] While it may seem like a logical step to go from supporting those real use cases, to supporting theoretical cases involving BCE dates, Julian calendars, leap seconds and whatever else, this actually only ends up introducing unnecessary complexity. The use-cases I gave are not theoretical. Is the complexity really unnecessary, or are we just putting off a difficult piece of work? Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching... Yes, but the question is, are any of the use cases involving historical dates really worth addressing with the time element? If so, what are those use cases and why are they significant enough? The uses cases are in the paragraph you only quote partially, above. I think they are all worth addressing (indeed, I think it would be foolhardy not to), and I'm not alone in thinking so. How do you propose to measure their worth objectively? hCalendar microformats are already used to mark up imprecise dates (June 1977; 2009). ISO8601 already supports them. Why not HTML5? Though care needs to be taken, it's even possible to mark up words like “today with a precise date, if that's generated real-time, server-side. What are the use cases for marking up such imprecise dates? Are people using hCalendar for such purposes? Yes, as I say in the text you quote; and on the sites I gave in my introduction (and unambiguously supported by the hCalendar specification and ISO8601). Use cases as above. The
Re: [whatwg] Dates and coordinates in HTML5
I think the problem with ISO-8601(:2004?) is that while it is precise, total support requires a large code footprint and effort (durations, intervals, compressed formats and so on). I seem to remember that there is some kind of conflict with something in Javascript regarding years that are represented by strings of more than four characters: years preceding 999 BCE (or 1000 BCE?) or subsequent to CE. -Original Message- From: David Singer [mailto:sin...@apple.com] Sent: Tuesday, 2009 February 24 15:12 To: WeBMartians; 'Andy Mabbett'; 'WHATWG List' Subject: Re: [whatwg] Dates and coordinates in HTML5 At 13:59 -0500 24/02/09, WeBMartians wrote: It's back! It won't die! :-) Although it can be argued that a standard should not consider the work required for implementation, many of the trade-offs in reference to times and dates do indeed take the present state of code into consideration. One reason for not supporting BCE is a disagreement between historians and, say, astronomers, on how to represent the year immediately preceding year one. Is it year -1 (1 BCE) or year zero? Currently, the text states that all dates and times since the beginning of the common era (0001-01-01 00:00:00Z) must be supported. Yes, the Javascript values can specify dates and times before this epoch. However, there is no way to interrogate the environment as to whether or not such values can be used with time. That would require much more work. Thus, the limitation of common era. I'd love to see support for BCE and even for prolepsis and non-Gregorian calendars. ...but I do see the no BCE compromise as a workable one. ISO 8601 is quite precise on this issue. Since these are both machine and human-readable, why is this precision a problem? Why would we not use ISO 6709 (Annex H, text string) as the format for location? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Issues relating to the syntax of dates and times
Asbjørn, while I can't give you a message-list, please believe me when I say that the HTML5 specifications on this are the result of quite a bit of discussion and IMHO represent a reasonable compromise between driving the developers crazy and supporting dates and times back to the Cenozoic era. That said, I'm staying out of this one! ...been here too many times already... -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Asbjørn Ulsberg Sent: Friday, 2009 January 02 16:53 To: Ian Hickson Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Issues relating to the syntax of dates and times On Wed, 26 Nov 2008 11:09:24 +0100, Ian Hickson i...@hixie.ch wrote: The spec draws the line already -- it says that the date has to be in the proleptic Gregorian calendar, and that the year has to be greater than zero. Reading the spec, I have to wonder: Does HTML5 need to specify as much as it does inline? Can't more of it be referenced to ISO 8601 or even better; RFC 3339? I really fancy how Atom (RFC 4287) has defined date constructs: http://www.atompub.org/rfc4287.html#date.constructs Does not RFC 3339 defined date and time in a satisfactory manner to use directly in HTML5? If there's prior discussion regarding this, I'd really appreciate a pointer. Thanks! -- Asbjørn Ulsberg -=|=- asbj...@ulsberg.no «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] Web Forms: change event
My sincere thanks for taking up this issue! Having to build applications for both mobile as well as stationary clients, I claim that the onchange behavior, as implemented (differently) across the browser spectrum, is most frustrating. Generally, I've just punted and implemented something based on onblur instead. Improvements to the clarity of the specification are eminently desirable. Imagine having to change reservations while being in (hopefully, not driving) a vehicle bouncing along a bumpy road. If you fail, you get to spend the night in some bedbug infested hotel. Your mobile browser handles onchange in an annoying manner, and the WWWeb site was not designed to compensate. Do this but once, and you will abandon all other efforts in order to fix the problem. Best! BdG From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tab Atkins Jr. Sent: Thursday, 2008 October 30 08:19 To: Garrett Smith Cc: [EMAIL PROTECTED]; Ian Hickson Subject: Re: [whatwg] Web Forms: change event On Wed, Oct 29, 2008 at 11:32 PM, Garrett Smith [EMAIL PROTECTED] wrote: Ian Hickson wrote: On Wed, 6 Jun 2007, Sander wrote: The specs say that for select ...the change event shall be fired when the selection is completed Does this mean that, when using a keyboard for navigation, the change event is fired when the user hits 'enter' or when she navigates from one option to another? I assume it's the former, but I just to be sure as selectboxes with change event handlers are often (ab)used for navigation purposes. So, can anyone confirm my assumption? Thanks. The HTML 4 specification[1] says: | The onchange event occurs when a control loses the input focus and its | value has been modified since gaining focus. A test case[2] I found does expects that onchange fires when the select has been changed and while it still has focus. | Procedure | 1. Using the keyboard or an assistive technology that emulates the | keyboard, move focus to the select control. | 2. Using the keyboard or an assistive technology that emulates the | keyboard, select a value from the menu to trigger the onChange event. [example] | Expected results | | 1. A star colored according to the select option value appears when | the onchange event is triggered. Firing onchange before the select loses focus does not follow the HTML specification but is more useful and is what browsers mostly do. Often, a select is used to trigger another action, such as showing more fields in a form. The user chooses an option and, based on the selection, a section of the form is shown. If the change event does not fire when the item is chosen, the callback will not be called and the user will not see the event until he changes focus by tabbing or clicking away. Instead, the chagne event should (ideally) fire when a different option has been selected. Goodness no. selects firing their onChange when different options are selected are horrifying for keyboard navigation. You ever been to a site that uses a select and an onChange handler to do some quick navigation? It becomes impossible to use the keyboard as intended, because the very first option that comes up when you use your arrow keys or type part of the name triggers the navigation. Waiting until they lose focus is very slightly clumsy in some uses for users with a mouse, but it's a necessity for alternate input devices like a keyboard. ~TJ
Re: [whatwg] fixing the authentication problem
Vanguard Investments has an interesting approach: 1- User enters an identification but not a password This page is an HTTPS one, by the way. 2- On a subsequent page (also HTTPS), the user enters the password Additionally, there is an identifying image that is associated with the user: Your security image... You'll see your image whenever you log on. Sometimes, based on a variety of factors, there is an intermediate page that challenges with a security question. Please don't consider this to be, in any way, a criticism of the proposal. The above is just an example of what appears to be a very good security regimen within the current constraints. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduard Pascual Sent: Tuesday, 2008 October 21 10:37 To: Aaron Swartz; whatwg@lists.whatwg.org Subject: Re: [whatwg] fixing the authentication problem On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz [EMAIL PROTECTED] wrote: Some major web services redirect the user to an SSL server for the login transaction, but SSL is too expensive for the vast majority of services. The issue is not SSL being expensive: the only expensive part is having a third party (the Certification Authority) to endorse your SSL keys, but for basic authentication self-signed certificates *should* be enough: when a user logs into a forum, for example, s/he shouldn't care about example.com being actually owned by Example Inc.; but just about the fact that the username and password will only be readable by example.com, regardless of who is behind example.com. The actual issue is that current UAs are over-paranoid about self-signed certificates: of course, a CA-endorsed certificate is safer than a self-signed one (specially for transactions involving money); but a self-signed certificate is still safer than no certificate enough (and definitely safe enough for login purposes): browsers, however, treat a self-signed certificate as almost a guarantee of fraud, while sending login data through unencrypted connections doesn't even raise an eyebrow: this behavior is definitely wrong, and this wrong behavior is the actual issue that should be dealt with (I don't really know if it should fall within HTML5's scope to deal with this, probably it doesn't). In essence, if UAs *lie* to the user about security (treating cheap self-signed certificates for login as fraud attempts; but unsecure communications as a non-issue), then what's the point at all about security? My proposal: add something to HTML5 so that the transaction looks like this: Client: GET /login Server: htmlform method=post pubkey=/pubkey.key... Client: POST /login dXNlcj1qb2VzbWl0aDAxJnBhc3N3b3JkPXNlY3JldA== Server: 200 OK Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d where the base64 string is the form data encrypted with the key downloaded from /pubkey.key. This should be fairly easy to implement (for clients and servers), falls back to exactly the current behavior on browsers that don't support it, and solves a rather important problem on the Web. What's the actual difference between this and https? Both mechanisms are using public-key encryption to protect the communications; the only difference being that with https the encryption is handled at the protocol level; while your suggestion would (currently) require to reinvent the wheel, encrypting the data on the client (maybe using JavaScript?) and then decripting it on the server (probably via server-side scripting). Maybe there is a good point on that suggestion, and I'm simply failing to see it. If that's the case, I invite you to enlighten me on it.
Re: [whatwg] fixing the authentication problem
Somewhere, is there a definition of trust in this context? I say that in all seriousness; it's not a facetious remark. I feel that it might be useful. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduard Pascual Sent: Tuesday, 2008 October 21 19:40 To: Kristof Zelechovski; Andy Lyttle; whatwg@lists.whatwg.org Subject: Re: [whatwg] fixing the authentication problem On Tue, Oct 21, 2008 at 4:35 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Sending any data, including, log-in data, through an unencrypted connection is greeted by a warning dialogue box in Internet Explorer. Only the first time. IIRC, the don't display this again checkbox is checked by default. A similar precaution is taken when the server certificate is not trusted. Not similar at all: for unencrypted connections, you have the don't bother me again option, in the form of an obvious checkbox; while with self-signed certificates you are warned continuously; with the only option to install the certificate on your system to trust it (which is a non-trivial task; out of the reach for most average users; still annoying even for web professionals; and, to top it up, you need to do it on a site-by-site basis). It doesn't make any sense for UAs to treat unencrypted connections as safer than (some) encrypted ones: that's simply wrong. The risk of using an invalid certificate is bigger than not using any because your level of trust is bigger while you are equally unprotected. That's, simply put, not true. The level of trust doesn't actually depend (for average users) on the certificate at all, but on what the browser says about it. The level of protection, instead, is independent from the user, and it's not the same for each case: On an unencrypted connection, everyone could read the data being sent. This is no protection at all. On a connection encrypted with a self-signed certificate, the user can rest assured that the data is only readable by the server, regardless of who is actually behind that server. There is some protection here, even if it's not the most possible. On an encrypted connection with a CA-signed cert, the user has the protection from encryption (only the server will be able to read the data), plus the guarantee that the CA has taken care to verify that the entity in charge of that server is who it claims to be. It is not enough to make sure that your credentials do not unintentionally leave example.com. Consider the following scenario: 1. You want to update your blog at blog.com 2. Evil.org poses as blog.com by phishing or DNS poisoning. 3. You log in to evil.org using your credentials of blog.com. 4. The bad guys at evil.org use your credentials to post an entry at blog.com that you are going to deploy a dirty bomb in NYC. 5. You travel to the USA and you end up in Guantanamo. Nice, eh? Although I'm not sure what do you mean by Evil.org poses as blog.com, I see no point in Aaron's original suggestion that would deal with such a case. In summary, besides UAs' paranoia, I can't see any case where the suggested feature would provide anything self-signed certificates don't already provide. And since it involves using public-key encryption, I don't see any reason why UAs would treat the encryption keys differently from current SSL certificates. On Tue, Oct 21, 2008 at 6:08 PM, Andy Lyttle [EMAIL PROTECTED] wrote: 4. The need for a dedicated IP address, instead of using name-based virtual hosts. That and #1 are the reasons I don't use it more. #4 is, again, a cost, but not an expensive one: most of the hosts I know of offer dedicated IP for a fee that's just a fraction of the actual hosting price. And, about #1, I just read my points about self-signed certificates in this and my previous mail.
Re: [whatwg] video tag : loop for ever
...not sure if the following has been noted; if so, apologies... Currently, animated GIF and MNG images are used, sometimes, in loop forever form. Assuming that video might be used in an analogous fashion, loop-forever should be supported. I shudder to think about looping audio, however. Animated GIFs are often called dancing baloney ... and looping audio would be...? A-GIF and MNG do not support sub-clips ... and that's for a good reason: even as primitive as they are, GIF and MNG do offer a level of compression and jumping to some arbitrary or near-arbitrary spot in the clip is very difficult. As a counterpoint, jumps are supported by the various embed and video engines ... and can be completely screwed up if the content does not follow best practices, such as frequent full-frame resets. Using Javascript to estimate duration and thereby control the playback of WAV, MP3 or Ogg files has been done, but may not be feasible due to difficulties in determining load completion (onload), inaccuracy in the handling of timer events, and difficulties in skipping over unwanted content. Currently, the best practice is to have discrete content in order to avoid jumps.
Re: [whatwg] Video : Slow motion, fast forward effects
The big VoDS (Broadbus/Motorola, SeaChange, Arroyo...) do not offer audio when the play rate is anything other than +1.0. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Fraser Sent: Thursday, 2008 August 07 18:52 To: Charles Iliya Krempeaux Cc: Biju [EMAIL PROTECTED]; Dave Singer; whatwg@lists.whatwg.org; Chris Double; Ian Hickson; Jonas Sicking Subject: Re: [whatwg] Video : Slow motion, fast forward effects On Aug 7, 2008, at 12:23 PM, Charles Iliya Krempeaux wrote: Hello, On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Dave Singer wrote: At 20:10 +1200 7/08/08, Chris Double wrote: On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL PROTECTED] wrote: playbackRate is the right way to do it, but maybe Firefox doesn't yet support it. So can I assume HTML5 spec also allow playbackRate to be negative value. ie to support go backward at various speed Yes. Would you expect the audio to be played backwards too? I think that's extra credit and optional. As you say, even with audio coded in independent frames you have to flip the samples, which is a pain. For audio with forward dependencies, correct decoding means decoding forwards and then flipping whole chunks of timeline (though AAC doesn't suffer too badly if you don't do this, by the way). Honestly, this seems useless enough that the spec should just say that when playback is less than 0 sound should be turned off. I'd hate to see engineers working on this just because the spec says it should work that way. I don't think turning sound off is a good idea. This feature would be used to implement scrubing. Like what you see in Non-Linear Editors... for making movies, etc. (I.e., grabbing the position handle of the player, and moving it forwards and backwards through the video, and varying speeds, to find what you are looking for.) In those types of applications, the audio is on. And it is important for usability, for the video editor to hear the sound. But those applications are not naïvely playing the sound at the current playback rate; they are grabbing little snippets of audio samples from the current playhead position, and playing them at normal rate. I don't think the spec should go into this much detail about what happens to audio when rate != 1. Simon
Re: [whatwg] Expanding datetime
Believe it or not, Yes! Consider the couple to be congratulated on their gazillionth anniversary. Is that diamond, gold, platinum? Whatever it is, if your date time system is limited to epoch 1970, you're out of luck. That's why I claim that restrictions (rigorously documented) are OK as long as they are not ludicrous - ludicrous being a gray area, rather than a sharp line - 1970 definitely is, 1900 is probably OK, 1582 is interesting and far less ludicrous, while - is very safe but maybe ludicrous in other ways (prolepsis, locales...). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henri Sivonen Sent: Thursday, 2008 July 31 04:26 To: Benjamin Hawkes-Lewis Cc: 'WHATWG List'; Ian Hickson Subject: Re: [whatwg] Expanding datetime On Jul 30, 2008, at 23:29, Benjamin Hawkes-Lewis wrote: Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney What use case is served by marking up Walt Disney's birthday as bday? Surely people aren't supposed to export Walt Disney's contact information to their address book app and have it remind them to congratulate Walt on his birthday. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Expanding datetime
[Warning: begin tirade, diatribe, fulmination, harangue, jeremiad, and/or philippic] 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). 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. I can see arguments on both sides of the question: + Microformats and extra-UNIXian-epochs are needed and there are business cases Hawkes-Lewis alludes to such with the Disney link (http://en.wikipedia.org/wiki/Walt_Disney) Read: Copyright Issues - It's so painful as to require a document comparable to the entire HTML5 specification Previous postings have commented on datetime strings and ISO-8601 and look at that awful mess I used, above, as an example Strangely, there exists an argument for a crippling of capabilities. It goes like this: If a browser's Javascript is limited, JS files can support microformats, proleptic dates, Before-Common-Era dates, unique epochs and so on. However, the creation of such utilities will be hindered if the needs-case is nebulous. Failing to explicitly specify the HTML5 envelope will only increase that ambiguity (Well, it works most of the time, so why bother?). The question then becomes, Is the specification properly limited or ludicrous? I would claim that an epoch of 1970 (the traditional, UNIX epoch) is ludicrous just because so many luminaries started their existence before that moment (for example, me - ahem). On the other hand, I could understand a requirement that an epoch of no later than 1900, while limited, is at least proper (even in light of some locales' not adopting the Gregorian calendar until the 1930s). Just don't hinder the needs-case for somebody building the JS files (I repeat myself, but I did warn that this would be tediously hortatory). [end tirade - Thank you for your patience] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Hawkes-Lewis Sent: Wednesday, 2008 July 30 16:29 To: Ian Hickson Cc: 'WHATWG List' Subject: Re: [whatwg] Expanding datetime Ian Hickson wrote: On Thu, 24 Apr 2008, Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? Insertion and deletion dates are contemporary. Date form widgets are meant for airline and hotel reservations and, hence, need to pick dates from the near future. The time element is meant for microformats, which means that it will be used for encoding current or near-future events dates. Right. Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney If HTML5 does not provide a way to specify datetimes BC, then the microformats community would be left in the boat they're already in of trying to fudge markup to encode datetimes BC. Little gained, really. 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 XHTML2 provides such an extension point with the (confusingly named) CONTENT attribute: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content 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. DATA-* is not yet such an extension point, since it is only to be used for private scripts not public metadata: http://www.w3.org/html/wg/html5/#custom Obviously, it would be /ideal/ if DATETIME could actually handle a range of dates useful for educational and research purposes as well as social networking and business and if schoolkids and academics didn't have to fall back on extension points and homebrew code, but I accept that it would inevitably be more work to spec and probably for user agent developers to ultimately implement. -- Benjamin Hawkes-Lewis
Re: [whatwg] Expanding datetime
We're in a situation, here, where the HTML specification is about to say You can specify a value, but, maybe, just maybe, you cannot show that value ... Oh, yes, AND we're not even going to tell you when that 'maybe' is in effect! If you can spec a value, you should be able to present it. Imagine setting a Javascript integer to -123456789 but not being able to toString() it. Imagine setting a background-color: Red; but not having it show (or show as a different color). Imagine the howling and complaining about that! The generation of the proper datetime string is easy, technically. Yes, Apple, Microsoft, Mozilla and Opera will have to ensure that the values can be generated, if such test cases do not exist already. The datetime string to value conversion is going to cause some more effort. Can the standard state that datetime strings support ISO 8601:2004 and leave it at that? (just a thought) At the very least, have a MINDate MAXDate (a la the C limits.h) constant. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Cline Sent: Friday, 2008 April 25 13:09 To: Henri Sivonen; Charles McCathieNevile Cc: WHATWG List Subject: Re: [whatwg] Expanding datetime -Original Message- From: Henri Sivonen [EMAIL PROTECTED] The historic astronomy case seems awfully narrow to justify making native date widgets deal with BCE dates. Native date widgets already need to deal with BCE dates at the DOM level as they are well within the range of a DOMTimeStamp. In ECMAScript the range of years for which any time in the year can be represented is from 283,459 BCE to 287,398 AD. What is being proposed is allowing a document to specify such times in the document without having to resort to scripting by expanding the range of values the datetime attribute can represent. The draft is already proposing making changes to the existing HTML 4 specification of datetime by allowing only the date or the time to be given instead of the full date and time, so datetime is already being proposed to be changed, so the question therefore is not should we change datetime, but rather what other changes would be worth incorporating so as to avoid having to change datetime a second time. (For instance, since DOMTimeStamp uses a millisecond granularity, allowing datetime to specify milliseconds may be of use as well.)
Re: [whatwg] Expanding datetime
There's an historical precedent that argues in favor of expanding the datetime string. Many calendar utilities limit the date domain to the UNIX one. Thus, entering an anniversary for a wedding that occurred prior to 1970 is the kiss-of-death: there is no way to determine just which anniversary is involved (silver anniversary, paper, ceramic...). A small item? Not to the gift card and gift industries. So an apparently trivial, supposedly non-business limitation had a big effect. Whether or not providing a means to specify dates before the Gregorian Reform or before the beginning of the first millennium will have a business effect is difficult to determine. One thing that can be said is that the applications which would be enabled certainly won't exist if the facilities are not present. Currently, the extreme datetime values (as opposed to the strings) can be specified in Javascript. Producing the corresponding datetime strings from such values should be mandatory. That argues in favor of proper round trip handling: the conversion of extreme datetime strings should be available too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Cline Sent: Thursday, 2008 April 24 13:58 To: Lachlan Hunt Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Expanding datetime -Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Adding one or two additional digits would also enable a closer match with the range of time values allowed in the DOM representation, and would need to be added at the same time as the ± is added.
[whatwg] Question Regarding table width
Is width=0 a pathological (error) state for table? ...and, for that matter, tr, td and the other tabular tags... I may have just missed this, but I don't see any explicit restriction on zero (or negative) widths. I wonder if such values could be used to allow browsers to render floating tables: side-by-side tables for large displays and vertically sequenced tables for small ones, such as in mobile devices. Thank you. Bruce de Graaf
Re: [whatwg] Question Regarding table width
Arrgh! My mistake; it's late here. Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Tuesday, 2008 January 29 21:27 To: WeBMartians Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Question Regarding table width On Tue, 29 Jan 2008, WeBMartians wrote: Is width=0 a pathological (error) state for table? ...and, for that matter, tr, td and the other tabular tags... I may have just missed this, but I don't see any explicit restriction on zero (or negative) widths. HTML5 doesn't allow the 'width' attribute on table at all. I wonder if such values could be used to allow browsers to render floating tables: side-by-side tables for large displays and vertically sequenced tables for small ones, such as in mobile devices. That seems like a presentational issue, which would be best handled by the CSS working group. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] BC AD BCE CE trivia
There is a disagreement between astronomers and historians about how to count the years preceding year one; astronomers count the BC years astronomically. Thus, the year before the year 1 is the year 0, and the year preceding the latter is the year -1 (2 BC, 1 BC, and one are, astronomically, -1, 0, and 1, respectively). The year which the historians call 585 BC is actually the year -584. The astronomical counting of the negative years is the only one suitable for arithmetical purpose. For example, in the historical practice of counting, the rule of divisibility by 4 revealing the Julian leap-years is no longer valid; these years are, 1 BC, 5 BC, 9 BC, 13 BC... In the astronomical sequence, however, these leap-years are called 0, -4, -8, -12..., and the rule of divisibility by four subsists. In this system we can speak, for instance, of the solar eclipse of -1203-08-28 (twenty-eighth day of August in the year 1204 BC), although at that remote time the Roman Empire was not yet founded and the month of August was still to be conceived! Also, the (politically?) correct way to specify BC is Before Common Era, while AD (Anno Domini) is now CE (Common Era). A good reference is Astronomical Algorithms by J. Meeus and published by Willmann-Bell, Incorporated Post Office Box 35025, Richmond, VA 23235. Heck, according to the Mayan calendar, everything's kaput in five years anyway! (at least, I THINK we have five years) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Krištof Želechovski Sent: Tuesday, 2007 August 28 10:48 To: 'Rikkert Koppes'; whatwg@lists.whatwg.org Subject: Re: [whatwg] (no subject) I think arithmetic notation for dates B.C. is unintuitive and hard to understand (also because in terms of dates -1+1=1). It would be better to present a B.C. check box, or just say it aloud if dates A.D. are not expected. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rikkert Koppes Sent: Tuesday, August 28, 2007 10:39 AM To: whatwg@lists.whatwg.org Subject: [whatwg] (no subject) - are negative years allowed (B.C.)? the datetime description tells me four or more digits (0 to 9) representing the year which implies no. use case: hystory questionary Regards, Rikkert Koppes
Re: [whatwg] img element comments
Clarification- never explicitly defined should probably be never explicitly 'limited' The W3C documents seem to require support for, at least, GIF, JPEG, MNG and PNG. Apologies if this is just nit-picking. [I'll regret saying this, but I wonder if the list can be pruned with the expiration of the GIF patents.] BdG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Thursday, 2007 August 16 00:06 To: Ian Hickson Cc: WHATWG Subject: Re: [whatwg] img element comments Ian Hickson wrote: On Sat, 4 Nov 2006, Lachlan Hunt wrote: And, as I mentioned in IRC, I think it should be defined that the value should resolve to a valid URI for an image, so that img src= alt= isn't conforming, except in this rare case: p xml:base=foo.pngimg src= alt=//p Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and Opera respectively support those.) I think you're putting too much emphasis on the words for an image in what I wrote. I think my intention was to avoid cases where it's pointing to itself. In practical terms, it just needs to point to file in a format that browsers support for img, but HTML has never explicitly defined which image formats browsers should or should not support, and I don't think it should. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Why Canvas?
I copy. So, it's essentially a question of expediency. Is that proper for a
standard? Don't read me wrong - faced with getting the bloody document out, I'd
opt for what is running today, too.
Formally stated, my position is leave it as is, but out of curiosity, do you
see any obvious holes (especially security ones) with extending the graphics
primitives to handle any rectangular entities, not just canvas?
The code snippet to detect canvas functionality
var cvs = document.getElementById(elementIdentity);
if (cvs.getContext){
var ctx = cvs.getContext('2d');
// drawing code here
}
I suppose would work to detect canvas functionality on non-canvas entities as
well.
BtW - Even against canvas entities, I like this script approach (with or
without the use of fallback content) because it can yield a more predictable
presentation over a wide range of browsers, which may or may not support the
closing /canvas tag.
The draft specification seems to imply (but does not state - I'll reread to
make sure) that the script sees the backing store for the canvas rather than
the rendered image itself. As long as the browser's script engine does not
support image manipulation (input) or does not resize images, this is no big
deal. As soon as either or both are implemented, the distinction becomes
critical and must be the backing store. ...or so I claim... Correct?
-Original Message-
From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 2007 August 01 03:51
To: WeBMartians; [EMAIL PROTECTED]
Subject: Re: [whatwg] Why Canvas?
On Wed, 01 Aug 2007 01:34:01 +0200, WeBMartians [EMAIL PROTECTED]
wrote:
Why not allow the graphics primitives to operate on any element (not
just canvas) that has a height and width that may be expressed in
picture elements... ...even window.screen with its .availHeight,
.availWidth, .height, and .width (yeah, I know, the Screen object is
actually a JavaScript object, not an HTML DOM object)?
Because that would lead to many small nasty bugs on different elements.
Having it on a dedicated element makes it easier to implement which is a big
plus given the interoperability issues we have with canvas today (although,
like CSS, it's still usable).
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
===
-Original Message-
From: Křištof Želechovski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 2007 August 01 01:01
To: 'WeBMartians'; [EMAIL PROTECTED]
Subject: RE: [whatwg] Why Canvas?
I think it can already be done using DHTML overlays. Thus no instant amazing
breakthrough is to be expected.
Chris
Re: [whatwg] Why Canvas?
Sorry, Andrew. I missed seeing your email and did not include it in my latest - I haven't had my orange juice yet, and while I may be standing with my eyes open, my brain hasn't yet caught up. I completely missed the CSS aspect and the foreground/background image slant as well. Good call. The introduction of foreground images as well as background images makes things a lot more complicated: - Which one is selected by var cvs = document.getElementById(elementIdentity);? - If you have one foreground image, why not have many in layers? - If you have layers, what about transparency (or alpha) and what about Z-order changes? Wow! World of Warcraft superimposed over the nightly news video! ...given 3D ... Halo superimposed over WWft over nightly news... Shudder... I think this will require more than orange juice. It may be best to let this monster snooze until HTML 6. -Original Message- From: Andrew Fedoniouk [mailto:[EMAIL PROTECTED] Sent: Tuesday, 2007 July 31 20:44 To: WeBMartians; [EMAIL PROTECTED] Subject: Re: [whatwg] Why Canvas? - Original Message - From: WeBMartians [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 4:34 PM Subject: [whatwg] Why Canvas? With canvas a relatively stable (and implemented, actually) tag, this may be a doubtful question. However, I can't think of any answer, so here goes... Why canvas? Why not allow the graphics primitives to operate on any element (not just canvas) that has a height and width that may be expressed in picture elements... ...even window.screen with its .availHeight, .availWidth, .height, and .width (yeah, I know, the Screen object is actually a JavaScript object, not an HTML DOM object)? I think this discussion http://lists.w3.org/Archives/Public/public-html/2007Apr/0355.html is related to the subject. Image (object) has pixel buffer so it is pretty logical to add Graphics interface to it. The only feature left is style.setBackgroundImage() method: var el = document.getElement; el.style.setBackgroundImage( el ); In this case it would be possible to render graphics on any element. And if we will add 'foreground-image' CSS attribute friends (similar to backround-*** attributes) then you would have an option to choose where to draw it - on background or on foreground layer (on top of the content) Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] [Whatwg] Wish
Wasn't this what, originally in LiveScript, the server (versus script) tag was for? There have been off-shoots of the server tag for purposes of ensuring security. For example, server tags can run if and only if the source of the HTML or JS is the browser's machine- thereby implementing a kind of host facility on the client side. To apply such code to the machine, a user must download the HTML/JS explicitly. After that, it may run unhindered, even updating itself. Adding the requirement that the browser must have a white-list with the URL for the original download (and maybe, even, any updates) would help alleviate some of the security concerns. Nonetheless, this could evolve into an enormous hole especially with naive users. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bert Altenburg Sent: Tuesday, 2007 July 31 12:01 To: whatwg@lists.whatwg.org Subject: [Whatwg] Wish I'm the owner of a SME company that has a big web application in use, which is under continuing development. It has been designed for us, but we hope to set it free in the future. The web app allows my company to be paperless and virtual (i.e., my employees don't have to come to an office). I have the following wishes for browsers/HTML 5. I'd like to see browsers to be able to run in two modes, a first one for regular web-sites and a special second one for web- applications. In the second mode an extended set of (JS) commands and HTML tags is available compared to the first mode. For the second mode there are commands that allow certain actions outside the sand box (like writing documents to disk), that currently limit web apps to behave more like conventional apps. For reasons of security, the browser will run in second mode only for URLs selected by the user in the preference window. So, you may have multiple web-pages on your screen, some in first mode (web-sites) and others in second mode (permitted web-apps). The windows could have a visual clue for the user to know about the mode. For the convenience of developers, all JS commands and HTML tags that belong to the extended set could have a standard prefix like EX- or RU- (extended/restricted use). Bert
[whatwg] Why Canvas?
With canvas a relatively stable (and implemented, actually) tag, this may be a doubtful question. However, I can't think of any answer, so here goes... Why canvas? Why not allow the graphics primitives to operate on any element (not just canvas) that has a height and width that may be expressed in picture elements... ...even window.screen with its .availHeight, .availWidth, .height, and .width (yeah, I know, the Screen object is actually a JavaScript object, not an HTML DOM object)? The utility is amazing: a tutorial option could then lead a user through a page or series of pages, circling/outlining an input item (Fill in this, first!), then circling a set of, say, radio buttons (Now, select one of these!), and, finally, circling the Submit button (Congratulations! You did it!). You can see how this would give an instant advantage in Total-Ownership-Cost to Web Applications. === B. de Graaf - [EMAIL PROTECTED]
