Re: [whatwg] Expanding the cite element
Hi all, I really like this idea, how would this be handled from a presentational point of view? I guess it will be a CSS style issue but, will browsers implement some standard way of displaying these cite elements if it has the uri attribute? Schalk Neethling From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Simpson, Grant Leyton Sent: Thursday, May 06, 2010 4:44 AM To: whatwg@lists.whatwg.org Subject: [whatwg] Expanding the cite element Dear WHATWG list participants, Forgive me if this conversation has been had before; I've just recently joined the list. Is there any value in adding an href or uri or similar attribute to the cite element to indicate a location for a work (or information about the work) or, in the case of a URI, an indicator that can be used as a reference programmatically? q has a cite attribute, so it seems to me that if we have a place to link to further information in q it makes sense to do so in cite. After all, whether an author quotes from a reference (q) or merely discusses it without quoting (cite), both of these would end up in a works cited in a traditional paper. Therefore, I think both should link (or refer) to somewhere. If it were a URI (and therefore not necessarily retrievable), it would help in cases where the same work gets referenced in slightly different ways: pAs Ashley Crandall Amos says in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/cite ... Amos also mentions in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means/cite/p ✍ Best, Grant Simpson ¶ Senior Analyst/Programmer, Office of the Registrar ¶ Doctoral Student, Department of English ¶ Representative, IU Bloomington Professional Council Indiana University Bloomington
Re: [whatwg] RFC: input type=username
The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). The input type='email' isn't only about semantic. The browser has to check if the email is valid according to HTML5 specifications. Please, have a look at: http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address If the entered email address is invalid, the element will suffer from a type mismatch. Here are some possible solutions to allow the use of something like input type=login/username along with an email 1) change type=login to role=login (and thus allow a text/selec/email/whatever). Based on the feedback so far this is now my preferred solution. 2) add a role to form element and have the browsers continue to rely on id/name/class
Re: [whatwg] RFC: input type=username
Your suggestion sounds really interesting Thomas, I will have a read over it. I agree that if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address. If that was a problem, it would have been detected during registration. Schalk Neethling -Original Message- From: Thomas Broyer [mailto:t.bro...@gmail.com] Sent: Thursday, May 06, 2010 12:09 PM To: Markus Ernst Cc: Schalk Neethling; WHATWG List; Steve Dennis Subject: Re: [whatwg] RFC: input type=username On Thu, May 6, 2010 at 11:51 AM, Markus Ernst derer...@gmx.ch wrote: Am 05.05.2010 23:06 schrieb Schalk Neethling: The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). But actually, I'm not convinced type=username is required (or even useful). We're told that Cookies are bad for security and shouldn't be used for authentication (or other sensible data), so spec'ing this in HTML, which is expected to live for tens of years, would really be a Bad Thing (tm). It has been proposed earlier (a year and a half ago, at least) to reconcile Cookie-based auth with HTTP-auth, and that could be a way to tell the browser which form and/or which fields in the page are related to login. I posted a first draft of such a thing more than a year ago: http://tools.ietf.org/html/draft-broyer-http-cookie-auth I worked a bit on it since then to answer the feedback but I'm far from an -01 draft (I'd like to rewrite it from scratch actually...) http://github.com/tbroyer/http-cookie-auth -- Thomas Broyer /tɔ.ma.bʁwa.je/
[whatwg] meta=encrypt tag is needed
meta=encrypt pubkey=ABABAEFEF2626EFEFEF pubtool=EC256-AES|RSA2048-AES passsalt=no|domainname auth=verisign Please try to fully decrypt the above meta-encrypt tag and *see* how the browser-server communication could utilize it. (HINT: browser submits a (session specific) 256bit elliptic curve public key to the server inside every URI-request AND if the target page has meta-encrypt tag, the server uses the browser's elliptic curve key and encrypts the page content with that.) It is very simple, doable and STATELESS. And in html5 it would eliminate some of the biggest real life security threats at the internet. If you *could* learn and instinctly use the above meta-encrypt tag then it should be enough simple for actual usage. yes, this suggestion maybe a bit radical, so lets try to find the positive things first. Meaning if you don't understand or like the structure immediately shut up and let those who see the light to express themselves first. Ok, let me start with the passsalt: passsalt = salts the password-field value into = SHA-256($password) format I think the passsalt=(no|domainname) attribute should also be added as a form parameter (with a default value lowercase domain name). Passsalt attribute would prevent the site getting a plain text password as the browser would 'salt' it by default with a domain name string. Thus when internet users anyway use the same passwords on multiple sites, the passsalt will eliminate hacking into various online accounts user has. Real life examples reasons for adding passsalt to html5 1) A finnish site alypaa.com got hacked a month ago. The hacker stole some 100,000 (unencrypted) user passwords from their database. But what media noticed first were that many leading politicians had got their blogs, home pages and Facebook pages defaced. 2) Couple of weeks ago a Russian hacker was selling his user names passwords for 1.5 million Facebook accounts. 3) a week ago a new data protection law for Massachusetts was suggested, basically it says personally identifiable information (that is usable for identity theft crimes) about Massachusetts residents may not be stolen or _you_ will get a fine of $5,000 per breach or lost record. http://www.mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf It can be expected that the laws around the world will be going to that direction as the identity theft problem keeps getting worse. That passsalt attribute alone would eliminate LOTS of identity thefts and it is easily doable. Ok, try to hack the rest of that *beautiful* meta=encrypt tag, and please don't say you instead you can use https / JS or some other thing that JUST DOESN'T WORK in real life. Juuso Hukkanen www.colordev.com
Re: [whatwg] RFC: input type=username
On Thu, May 6, 2010 at 12:12 PM, Mounir Lamouri wrote: On 05/06/2010 12:09 PM, Thomas Broyer wrote: On Thu, May 6, 2010 at 11:51 AM, Markus Ernst derer...@gmx.ch wrote: Am 05.05.2010 23:06 schrieb Schalk Neethling: The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). The input type='email' isn't only about semantic. The browser has to check if the email is valid according to HTML5 specifications. Please, have a look at: http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address If the entered email address is invalid, the element will suffer from a type mismatch. Of course, just like type=url requires the URL to be a valid absolute URL, while hinting browsers to autocomplete based on your bookmarks and/or search history (note: not your account manager). Would you use a type=number (that some browsers would present as a spinner box) if the usernames were only digits? (BTW, the syntax for an e-mail address to be considered valid is quite lax, and can be easily reproduced using a pattern= constraint, as I already said) -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: [whatwg] RFC: input type=username
On Thu, 2010-05-06 at 14:54 +0200, Thomas Broyer wrote: On Thu, May 6, 2010 at 12:12 PM, Mounir Lamouri wrote: On 05/06/2010 12:09 PM, Thomas Broyer wrote: On Thu, May 6, 2010 at 11:51 AM, Markus Ernst derer...@gmx.ch wrote: Am 05.05.2010 23:06 schrieb Schalk Neethling: The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). The input type='email' isn't only about semantic. The browser has to check if the email is valid according to HTML5 specifications. Please, have a look at: http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address If the entered email address is invalid, the element will suffer from a type mismatch. Of course, just like type=url requires the URL to be a valid absolute URL, while hinting browsers to autocomplete based on your bookmarks and/or search history (note: not your account manager). Would you use a type=number (that some browsers would present as a spinner box) if the usernames were only digits? (BTW, the syntax for an e-mail address to be considered valid is quite lax, and can be easily reproduced using a pattern= constraint, as I already said) I wouldn't say the syntax is lax, just that it allows a lot of variation. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] RFC: input type=username
Schalk Neethling writes: if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Surely a major reason for having standard validation types is so web developers don't need to come up with patterns for these common things? It also avoids lots of different authors coming up with something different, and not getting it right. The validation needed to accurately match a valid e-mail address is surprisingly convoluted -- see for example the regular expression on this page: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address. If that was a problem, it would have been detected during registration. Sure, you aren't concerned that a user's correct username might not be a valid e-mail address. But if a user tries to submit something that isn't a syntactically correct e-mail address, then he must have mis-typed his username. Using type=email allows the browser to alert him to this, so he can fix it. Without that, he has to wait for server-side validation. Smylers
Re: [whatwg] onshow event
On May 6, 2010, at 3:19 AM, Anne van Kesteren wrote: On Wed, 05 May 2010 13:47:13 +0900, Ian Hickson i...@hixie.ch wrote: On Tue, 4 May 2010, Perry Smith wrote: It would be wonderful if an element had an event that would fire when that particular element is shown on the page. This might be due to the display attribute changing or it might be due to it scrolling into view. That's more of a presentation issue; I recommend raising this in the context of CSSOM. Anne, is there a bug database or issues list for CSSOM where things like this can be logged? No. I suppose new ideas could be added here (under CSSOM): http://wiki.whatwg.org/wiki/Companion_specifications Issues with the current specification I mostly track through email. I sent an email on the www-style list. Thanks, Perry
Re: [whatwg] RFC: input type=username
Smylers, I understand what you mean but, then I have to agree with Thomas that you can then use an input of type username and use the pattern to validate the email address. Schalk -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Smylers Sent: Thursday, May 06, 2010 3:18 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] RFC: input type=username Schalk Neethling writes: if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Surely a major reason for having standard validation types is so web developers don't need to come up with patterns for these common things? It also avoids lots of different authors coming up with something different, and not getting it right. The validation needed to accurately match a valid e-mail address is surprisingly convoluted -- see for example the regular expression on this page: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address. If that was a problem, it would have been detected during registration. Sure, you aren't concerned that a user's correct username might not be a valid e-mail address. But if a user tries to submit something that isn't a syntactically correct e-mail address, then he must have mis-typed his username. Using type=email allows the browser to alert him to this, so he can fix it. Without that, he has to wait for server-side validation. Smylers
Re: [whatwg] Expanding the cite element
Is there any value in adding an href or uri or similar attribute to the cite element to indicate a location for a work (or information about the work) or, in the case of a URI, an indicator that can be used as a reference programmatically? cite uri has a much worse fallback story than simply embedding a link in cite. pAs Ashley Crandall Amos says in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/cite ... Amos also mentions in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means/cite/p Consider how the above would work in legacy browsers, and then consider how this would work in them: pAs Ashley Crandall Amos says in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/a/cite ... Amos also mentions in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means/a/cite/p Ted
Re: [whatwg] WebSocket: garbage collection
On Tue, 20 Apr 2010 16:00:36 +0200, Simon Pieters sim...@opera.com wrote: [[ WebSocket object with an open connection must not be garbage collected if there are any event listeners registered for message events. ]] Shouldn't it also not be garbage collected if there are listeners for open, error and close? What about when the connection is not yet established? I think the policy should be: if readyState is CONNECTING: has 'open' event listener: don't collect has 'message' event listener: don't collect has 'error' event listener: don't collect has 'close' event listener: don't collect if readyState is OPEN: has 'open' event listener: OK to collect has 'message' event listener: don't collect has 'error' event listener: don't collect has 'close' event listener: don't collect if readyState is CLOSING: has 'open' event listener: OK to collect has 'message' event listener: OK to collect has 'error' event listener: OK to collect has 'close' event listener: don't collect if readyState is CLOSED: has 'open' event listener: OK to collect has 'message' event listener: OK to collect has 'error' event listener: OK to collect has 'close' event listener: OK to collect -- Simon Pieters Opera Software
Re: [whatwg] Keywords for the pattern attribute [was: RFC: input type=username]
input type=text pattern=email input type=username pattern=email What if for some strange reason I wanted to only allow the text e-m-a-i-l ? There would have to be some way to differentiate between a keyword and a normal pattern.
Re: [whatwg] meta=encrypt tag is needed
On Thu, May 6, 2010 at 5:44 AM, juuso_ht...@tele3d.net wrote: meta=encrypt pubkey=ABABAEFEF2626EFEFEF pubtool=EC256-AES|RSA2048-AES passsalt=no|domainname auth=verisign Please try to fully decrypt the above meta-encrypt tag and *see* how the browser-server communication could utilize it. (HINT: browser submits a (session specific) 256bit elliptic curve public key to the server inside every URI-request AND if the target page has meta-encrypt tag, the server uses the browser's elliptic curve key and encrypts the page content with that.) It is very simple, doable and STATELESS. And in html5 it would eliminate some of the biggest real life security threats at the internet. If you *could* learn and instinctly use the above meta-encrypt tag then it should be enough simple for actual usage. Rather than ask us to figure it out ourselves, and possibly get it wrong and have to be corrected, why don't you just tell us: 1) What the exact problem is you're trying to solve 2) What your suggestion is 3) How your suggestion solves the problem 4) How it is better than existing solutions to that problem It's generally a much better use of my time to read something that's well-thought out and explained than to try and decipher a clever idea that someone had but doesn't want to fully explain. ~TJ
Re: [whatwg] meta=encrypt tag is needed
Might be a wrong assumption but, if you place those values into an HTML element, it is visible by simply doing a view source. I am jumping in the middle of the conversation here but, this strikes me as opening another problem. Schalk -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of And Clover Sent: Thursday, May 06, 2010 9:52 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] meta=encrypt tag is needed On 05/06/2010 02:44 PM, juuso_ht...@tele3d.net wrote: browser submits a (session specific) 256bit elliptic curve public key to the server inside every URI-request AND if the target page has meta-encrypt tag, the server uses the browser's elliptic curve key The server has to read and correctly parse each HTML page to decide whether to encrypt it? (And how does the browser know that the page is encrypted, vs. a legacy server that doesn't encrypt?) This proposal is tackling the problem of encryption at entirely the wrong level: it's nothing to do with HTML, it's to do with the connection between the browser and the server. It is very likely that sites would want to encrypt transfers of other files than HTML pages. This is something that should be tackled at the HTTP level, not in HTML5. And lo, there is already a quite suitable mechanism for deploying encryption between the server and browser: HTTPS. Whilst it is true that HTTPS has more organisational overhead in the form of CAs, and more server overhead in the form of making virtual hosting difficult, there are technical approaches to improve this situation (DNSSEC-based certs, SNI), and, notably, this overhead is *necessary*. Otherwise HTTPS would be vulnerable to active man-in-the-middle attacks, just like your proposed protocol is. Without attestation that the site receiving the `pubkey` token is who it says it is, the encryption between the two is worthless. It would only protect against passive MitM attacks, but in reality if you are in a position to MitM passively you are very likely to be able to throw in an active attack just as easily. please don't say you instead you can use https / JS or some other thing that JUST DOESN'T WORK in real life. HTTPS works fine. JS client-side-password-hashing approaches suffer from the same problem as your proposal: they can only ever protect against passive attacks. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/
Re: [whatwg] meta=encrypt tag is needed
On Thu, May 6, 2010 at 8:44 AM, juuso_ht...@tele3d.net wrote: meta=encrypt pubkey=ABABAEFEF2626EFEFEF pubtool=EC256-AES|RSA2048-AES passsalt=no|domainname auth=verisign Please try to fully decrypt the above meta-encrypt tag and *see* how the browser-server communication could utilize it. (HINT: browser submits a (session specific) 256bit elliptic curve public key to the server inside every URI-request AND if the target page has meta-encrypt tag, the server uses the browser's elliptic curve key and encrypts the page content with that.) It is very simple, doable and STATELESS. And in html5 it would eliminate some of the biggest real life security threats at the internet. If you *could* learn and instinctly use the above meta-encrypt tag then it should be enough simple for actual usage. To expand on the threat scenario And referred to: suppose I'm in a position to tamper with your traffic. For instance, I might have set up a malicious free Wi-Fi hotspot that you're using (maybe even you don't know you're using it). So you submit your public key . . . then I record the public key, alter your message to contain my own public key, and send that. The server returns the message encrypted with my public key. I decrypt it with my private key, re-encrypt it with your public key, and send it back to you. I'm reading all your messages and you have no way to detect or prevent that. Authentication is a necessary component of any usable public-key encryption scheme for this reason. If I can eavesdrop, I can very likely tamper with the traffic too. Ok, let me start with the passsalt: passsalt = salts the password-field value into = SHA-256($password) format I think the passsalt=(no|domainname) attribute should also be added as a form parameter (with a default value lowercase domain name). Passsalt attribute would prevent the site getting a plain text password as the browser would 'salt' it by default with a domain name string. Thus when internet users anyway use the same passwords on multiple sites, the passsalt will eliminate hacking into various online accounts user has. A decently-written site should be doing this already on the server side. If the site isn't decently written, it probably won't use this meta tag either, so what's the point? Again, this doesn't hide anything from a man-in-the-middle, because the attacker could just remove the meta tag before passing the page on to you. Real life examples reasons for adding passsalt to html5 1) A finnish site alypaa.com got hacked a month ago. The hacker stole some 100,000 (unencrypted) user passwords from their database. But what media noticed first were that many leading politicians had got their blogs, home pages and Facebook pages defaced. If the site didn't hash its passwords in the database, why would it use your meta tag? The authors of the web app are obviously clueless about security, after all. This has to be done unconditionally on the browser side to be useful, in which case HTML is irrelevant. Indeed, there are plenty of password managers that will autogenerate random passwords for you for each site, solving this problem. 2) Couple of weeks ago a Russian hacker was selling his user names passwords for 1.5 million Facebook accounts. Doesn't tell us anything unless we know how he got them. If they're legitimate, he probably just got them via keyloggers, not network-based attacks. That passsalt attribute alone would eliminate LOTS of identity thefts and it is easily doable. No, it wouldn't. The web page authors who would know enough to use it are already protected against that kind of attack, by storing only salted password hashes in the database. and please don't say you instead you can use https / JS or some other thing that JUST DOESN'T WORK in real life. Well, HTTPS is too cumbersome to be deployed on most websites, yes. Unlike your proposal, though, it has the advantage of actually providing meaningful security. :) Your proposal really doesn't improve anything. If HTTPS had better (free) key certification and played nicely with virtual hosts, it would be pretty much ideal except for the performance hit, which is inevitable to some extent. But if SPDY gets deployed and only works over SSL, even that might be negated for most users. What particular parts of HTTPS do you object to? On Thu, May 6, 2010 at 4:50 PM, Schalk Neethling sch...@ossreleasefeed.com wrote: Might be a wrong assumption but, if you place those values into an HTML element, it is visible by simply doing a view source. I am jumping in the middle of the conversation here but, this strikes me as opening another problem. That's not a problem. Public keys are expected to be available to everyone in the world.
Re: [whatwg] Type Date
Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent talk I gave on HTML 5 the question arose that well, what if the user wants to have both options on the same field? My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option? Thanks, Schalk -Original Message- From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Sent: Thursday, May 06, 2010 11:40 PM To: Schalk Neethling Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Type Date On Thu, May 6, 2010 at 2:19 PM, Schalk Neethling sch...@ossreleasefeed.com wrote: Greetings, Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript? The purpose of input type=date is to allow the browser to supply the user with a datepicker. Opera, for example, already does this. If you would like to show a datepicker to users of all browsers, use feature detection (such as through the Modernizr script) to detect whether or not the browser support date inputs, and if not, supply the js version. ~TJ
Re: [whatwg] Type Date
On Thu, May 6, 2010 at 3:30 PM, Schalk Neethling sch...@ossreleasefeed.com wrote: Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent talk I gave on HTML 5 the question arose that well, what if the user wants to have both options on the same field? My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option? That's a browser UI issue, then. File a bug on Opera suggesting that. ~TJ
Re: [whatwg] Type Date
On Fri, May 7, 2010 at 06:41, Garrett Smith dhtmlkitc...@gmail.com wrote: Opera has native support that mostly works but failed with dates prior to 1582, last I checked. This seems reasonable. Gregorian calendar started in 1582. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Type Date
On Fri, 07 May 2010 10:52:15 +0900, Garrett Smith dhtmlkitc...@gmail.com wrote: On Thu, May 6, 2010 at 6:50 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: Disregard that: Proleptic Gregorian is not required, but optional for ISO 8601. Regardless:- That specification in this case is HTML 5 draft. Opera's implementation of input type=date, should not, without good reason, deviate from what is specified in the draft. Still stands. HTML5 makes no UI requirements. I agree we could (and definitely should in due course) improve our UI, but there is nothing in specification land that forces us too as far as I can tell. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Type Date
On Thu, May 6, 2010 at 7:30 PM, Anne van Kesteren ann...@opera.com wrote: On Fri, 07 May 2010 10:52:15 +0900, Garrett Smith dhtmlkitc...@gmail.com wrote: On Thu, May 6, 2010 at 6:50 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: Disregard that: Proleptic Gregorian is not required, but optional for ISO 8601. Regardless:- That specification in this case is HTML 5 draft. Opera's implementation of input type=date, should not, without good reason, deviate from what is specified in the draft. Still stands. HTML5 makes no UI requirements. I agree we could (and definitely should in due course) improve our UI, but there is nothing in specification land that forces us too as far as I can tell. I'm not sure how suitable this is for on-list, but I some may find it of value... U/X and usability issues aside, The date format and range is specified in HTML5 and cited from rfc3339. HTML 5[1] specifies: | # a date-fullyear is defined as four or more digits | representing a number greater than 0 I read that as to . Is there a different interpretation of that? HTML 5 cites RFC3339[2], which mentions proleptic greg dates, e.g. | All dates and times are assumed to be in the current era, | somewhere between AD and AD. Nice to see native support of that control taking hold. I like to be able to use websites when I need to but most calendars (and websites, for that matter) fall somewhere in quality between awful and totally broken. Take a look at any travel site. Those among the most popular of travel sites are aware of four browsers (if your're lucky), fail with js disabled, throw script errors when enabled, use (m)m/(d)d/ (or worse: yy). This sort of garbage will not stop, not so long as these stupid and harmful trends in web development continue. [1]http://dev.w3.org/html5/markup/datatypes.html#data-date-fullyear [2] http://tools.ietf.org/html/rfc3339
Re: [whatwg] RFC: input type=username
On 5/4/10 12:08 AM, Eitan Adler wrote: 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Furthermore some websites offer a find other members feature where you could type in a username. I've often seen these fields filled in automatically with my name. Firefox's existing password manager doesn't do this. Roughly, it assumes the username field is the first input type=text before the first input type=password in a form. My previous thinking about this problem was to allow tagging the form element with the names of the inputs to be used for the login. For example: form loginfields=abc,def input type=text name=abc input type=password name=def /form But I agree with what Jonas noted earlier in this thread; improving the login experience needs a broader solution than just tweaking HTML attributes. Additionally, I suspect that the sites with currently-broken login forms are the ones least likely to change... It's not hard to make existing sites work with existing password managers, so I don't think it's a problem more markup will solve. Justin
