Re: [whatwg] input type=date
Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
Re: [whatwg] input type=date
yep, that answers my question but, is there any work done to perhaps add an attribute where the author can specify the date format they require/want? Thanks, Scott - Original Message - From: Scott González scott.gonza...@gmail.com To: Schalk Neethling sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Sent: Thursday, January 12, 2012 8:39:21 PM Subject: Re: [whatwg] input type=date I think the following note answers your question: Note: The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates according to the conventions of the user's preferred locale. - http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date) On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling sneethl...@mozilla.com wrote: Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
Re: [whatwg] input type=date
Hey Scott, There will need to be a js, or server side function if js is not available, function that converts whatever you get to the format you require/expact. I was just curious what the default behavior would be for the input element and, whether there would be a way to indicate which format you wish returned. Schalk - Original Message - From: Scott González scott.gonza...@gmail.com To: Schalk Neethling sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Sent: Thursday, January 12, 2012 8:53:13 PM Subject: Re: [whatwg] input type=date I don't believe so. I also don't think there's any way to do the equivalent in JavaScript, e.g., asking for a Date object to generate a string representation in some other locale (aside from UTC). From personal experience, I've found that when users need to enter times for timezones other than their own, the chance of error is high. 2012/1/12 Schalk Neethling sneethl...@mozilla.com yep, that answers my question but, is there any work done to perhaps add an attribute where the author can specify the date format they require/want? Thanks, Scott - Original Message - From: Scott González scott.gonza...@gmail.com To: Schalk Neethling sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Sent: Thursday, January 12, 2012 8:39:21 PM Subject: Re: [whatwg] input type=date I think the following note answers your question: Note: The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates according to the conventions of the user's preferred locale. - http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date) On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling sneethl...@mozilla.com wrote: Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
[whatwg] Question: rel=help
Hi there everyone, Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Does not match the usage as described by the WHAT-WG (http://developers.whatwg.org/links.html#link-type-help) exactly, but close enough? -- Kind Regards, Schalk Neethling Mozilla Corporation
Re: [whatwg] Question: rel=help
Hi Anna, I heard some mention of using the data-* attributes so, something like: a href= data-tooltip=Some help text/a or input type=text data-tooltip=Some help text / Would you agree that this is the better option? On 29/09/2011 16:50, Anne van Kesteren wrote: On Thu, 29 Sep 2011 16:35:33 +0200, Schalk Neethling sneethl...@mozilla.com wrote: Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Does not match the usage as described by the WHAT-WG (http://developers.whatwg.org/links.html#link-type-help) exactly, but close enough? If there is no actual hyperlink, using a link relation does not make sense. -- Kind Regards, Schalk Neethling Mozilla Corporation
[whatwg] Websockets
Hi all, I guess a lot of people are asking the question but, what is the state on the following: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ Apparently this is the case in Opera as well. --- Kind Regards, Schalk Neethling Passionate Web Developer
[whatwg] Scrollable Tables and HTML5
Hi all, I have been working on getting scrollable tables working across all browsers. While there exists jQuery plugins that does the job for the most part, I have to find one that works 100% and works at all in Chrome. The reason I am putting this to the HTML5 list is because I am wondering whether there is something in the HTML5 spec that is going to aid in this regard. In the current HTML 4 spec (http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.2.3) it is stated that: Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD http://www.w3.org/TR/REC-html40/struct/tables.html#edef-THEAD , TFOOT http://www.w3.org/TR/REC-html40/struct/tables.html#edef-TFOOT and TBODY http://www.w3.org/TR/REC-html40/struct/tables.html#edef-TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. The only browser, including the IE9 previews, that has implemented this behavior is Firefox. For the rest it is quite a terrible hack with JavaScript to get similar behavior. Is there any work being done get UA's to implement this as a standard? Is there work being done by other working groups, maybe ARIA, in this regard? Looking forward to your feedback. Kind Regards, Schalk
Re: [whatwg] Article: Growing pains afflict HTML5 standardization
Oops, I believe there was a misunderstanding here. I did not write the article ;-) I just read and thought I would like to know everyone else’s view on the list as I do not agree with the author. Kind Regards, Schalk Neethling From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] Sent: Saturday, July 10, 2010 10:15 PM To: Diogo Resende Cc: 'Schalk Neethling'; wha...@whatwg.org Subject: Re: [whatwg] Article: Growing pains afflict HTML5 standardization On Sat, 2010-07-10 at 20:31 +0100, Diogo Resende wrote: I hate it. From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Schalk Neethling Sent: sábado, 10 de Julho de 2010 18:54 To: wha...@whatwg.org Subject: [whatwg] Article: Growing pains afflict HTML5 standardization Hi all, Would love to hear everyone’s comments on the following article: http://goo.gl/VNg0 While I'm not saying your point is right or wrong, maybe something a little more constructive would help?... Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] Article: Growing pains afflict HTML5 standardization
Hi all, Would love to hear everyone's comments on the following article: http://goo.gl/VNg0
[whatwg] Firefox 4 Beta 1
Hi there everyone, Downloaded and installed the first beta of Firefox 4. To the folks at Mozilla that is on here, what an awesome job. Love the new look and it IS very fast. The reason I mention Firefox 4 is because, on the welcome screen you get after installing the browser, you have the option to view a video introduction to Firefox 4, nothing strange here but, first the video format is WebM, which is awesome, the other thing, and this is the main reason for this mail, if you right click on the video there is a context menu option for full screen. Upon clicking that, the video goes into full screen mode and it does this, I must say, very nicely. I also noted that in full screen right clicking is disabled. With the discussions around full screen HTML5 video as well as content protection, it seems Mozilla has made some progress. Am I correct in saying that they keep running HTML5 video 'mode' when going to full screen or do they somehow switch to Flash? Would be pretty amazing if they do switch to Flash as the video continues playing from the same frame and does not start from the beginning. Looking forward to your feedback, Schalk Neethling
Re: [whatwg] More YouTube response
Could not agree more Anne -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van Kesteren Sent: Friday, July 02, 2010 1:38 PM To: Henri Sivonen; Shane Fagan Cc: Andy Berkheimer; John Harding; wha...@whatwg.org Subject: Re: [whatwg] More YouTube response On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Firefox 4 Beta 1
Ah, ok. I see but then I wonder what the problem is with regards to Youtube and full screen as their full screen mode is fully user driven. -Original Message- From: Adam Barth [mailto:w...@adambarth.com] Sent: Wednesday, July 07, 2010 1:22 PM To: Schalk Neethling Cc: whatwg Subject: Re: [whatwg] Firefox 4 Beta 1 I'm sure they keep using HTML5 video in full screen. The issues around full screen relate to letting the page trigger full screen. It's fine for the user to trigger it directly. Adam On Wed, Jul 7, 2010 at 3:38 AM, Schalk Neethling sch...@ossreleasefeed.com wrote: Hi there everyone, Downloaded and installed the first beta of Firefox 4. To the folks at Mozilla that is on here, what an awesome job. Love the new look and it IS very fast. The reason I mention Firefox 4 is because, on the welcome screen you get after installing the browser, you have the option to view a video introduction to Firefox 4, nothing strange here but, first the video format is WebM, which is awesome, the other thing, and this is the main reason for this mail, if you right click on the video there is a context menu option for full screen. Upon clicking that, the video goes into full screen mode and it does this, I must say, very nicely. I also noted that in full screen right clicking is disabled. With the discussions around full screen HTML5 video as well as content protection, it seems Mozilla has made some progress. Am I correct in saying that they keep running HTML5 video 'mode' when going to full screen or do they somehow switch to Flash? Would be pretty amazing if they do switch to Flash as the video continues playing from the same frame and does not start from the beginning. Looking forward to your feedback, Schalk Neethling
Re: [whatwg] More YouTube response
Hi John, Many good responses and I agree with most but, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content, I am not so sure. Is one of the reasons for tags such as video not to move away from third party plugin's and have this baked into the UA instead? The general idea is good, I just believe implementing this via 3rd party plugin's is not the best way forward. Schalk Neethling From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of John Harding Sent: Friday, July 02, 2010 1:00 AM To: wha...@whatwg.org Cc: Andy Berkheimer Subject: [whatwg] More YouTube response Glad to see my post spurred some good discussion - I'll try to address topic by topic below, but one of the great points made is that some of the functionality YouTube needs from browsers probably doesn't belong in the HTML5 spec (e.g. streaming, content protection). I'm happy to take those discussions elsewhere if this forum is inappropriate, but it seems like it would likely be the same group of people, just on a different mailing list. 1. Standard Video Format Yes, this has been debated a lot, and I generally agree that leaving it out of the spec was the best way forward for the spec. Shane Fagan pointed out that Flash supports multiple different codecs, which is true, but every version since Flash 7 has supported Sorenson Spark video and MP3 audio. I don't think anyone is suggesting that browsers shouldn't support multiple codecs, but having a consistent baseline is important. On the current path, a content provider knows that by offering H.264 and WebM, they can reach all HTML5-capable browsers. This honestly is a reasonable state for YouTube right now - we use H.264 in cases outside the video tag as well, but it would be nice to converge on a single baseline format at some point in the future. 2. Robust Video Streaming Andy Berkheimer on our team has been putting some thought into this, so I'll defer to him for more specific proposals. For an app like YouTube, it is extremely useful to have fine-grained control over how the browser fetches media from the server. Whether the details belong in the HTML5 spec or not depends on the preferred design - something similar to Flash 10.1's appendBytes() mechanism would affect the video tag interface, for example, while a transport protocol could be completely separate. 3. Content Protection Some of the discussion here seems to have conflated application-controlled video delivery with content protection, but in an ideal world, the two are independent. The basic requirements around content protection that we get from content owners basically consist of encrypting the content and limiting the decryption to a verified and authorized client - the realm of traditional DRM. Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. 4. Encapsulation and Embedding As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. 5. Fullscreen Maciej actually covered YouTube's requirements pretty well. I'd add that it's not just controls that are important for us to maintain: we have a lot of additional content that needs to display with and sometimes on top of the video - our interactive annotations, captions, and ads most notably. Maciej's proposal also looks fairly reasonable, though some thoughts on it: When limiting keyboard input, I'd suggest devices w/ onscreen keyboards simply disable the keyboard. Applications that work well with touch interfaces generally provide gesture alternatives for the limited set of keys that would be available. Alternately, devices could limit the keyboard to the set of allowed keys. Keyboard restrictions are better than not having fullscreen support, though they do limit functionality - it would prevent us from supporting search in fullscreen mode, for example. 6. Camera and Micrphone access As pointed out, this is not strictly an issue for video tag, though certainly related especially for local preview. I have not been closely following the work on the device element, though that seems to be where this is headed. -John
[whatwg] Proposal for a widget tag
Hi there, I have watched one video after the other, and read articles just the same. I know we are all unsure when to use section and when to use article. But marking up something as simple as a blogroll as an article? This really makes no semantic sense to me. Therefore I suggest the addition of the widget tag. Below is the most obvious use case and makes much more sense to me. Thoughts? section widget id=blogroll /widget widget id=search /widget /section Kind Regards, Schalk Neethling
Re: [whatwg] Form validation against invisible controls
I would also go with not using the visual state of an element as an indication of whether it needs to be validated or not but rather an additional attribute link the @hidden attribute proposed earlier. I do see though that one might ask the question, how will I indicate an error on a specific field if that field is visually hidden? Good question but, that should be left up to the developer to handle and not the UA. Currently I reckon this is a problem as the UA decides where to place its validation, hoping there will be a way to override this behavior, if desired, in future. Schalk -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab Atkins Jr. Sent: Thursday, June 03, 2010 5:55 PM To: João Eiras Cc: TAMURA, Kent; whatwg; Ian Hickson Subject: Re: [whatwg] Form validation against invisible controls On Thu, Jun 3, 2010 at 8:42 AM, João Eiras jo...@opera.com wrote: On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen. It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate. ~TJ
Re: [whatwg] Canvas and Image problems
Hi Marius,
That is actually a pretty good idea. You can still have your other code run
at document ready, but then do the drawing to canvas once the image is
ready. Best of both ;)
Thanks,
Schalk
From: Marius Gundersen [mailto:gunder...@gmail.com]
Sent: Monday, May 24, 2010 4:49 AM
To: Schalk Neethling
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Canvas and Image problems
You could also add a listener to the image to check that it actually loads:
$(document).ready(function() {
var image = $(#cat).get(0);
image.onload = function(e){
var cv = $(#img_container).get(0);
var ctx = cv.getContext('2d');
ctx.drawImage(image, 0, 0);
};
});
On Sun, May 23, 2010 at 10:30 PM, Schalk Neethling
sch...@ossreleasefeed.com wrote:
Jip, using $(window).load() works perfect.
[whatwg] Canvas and Image problems
Hi everyone,
Having a really weird problem that I would like some input on. I am trying
to draw an image, as well as video, onto canvas. I use the simple code
below:
$(document).ready(function() {
var image = $(#cat).get(0);
var cv = $(#img_container).get(0);
var ctx = cv.getContext('2d');
ctx.drawImage(image, 0, 0);
});
When I load up the HTML page in Chrome absolutely nothing happens and I see
no errors in the JavaScript console. When running it in Firefox 3.6.3 I get
the following error:
uncaught exception: [Exception... Component returned failure code:
0x80040111 (NS_ERROR_NOT_AVAILABLE)
[nsIDOMCanvasRenderingContext2D.drawImage] nsresult: 0x80040111
(NS_ERROR_NOT_AVAILABLE) location: JS frame ::
file:///C:/thelab/HTML5Canvas/scripts/canvas_img.js
file:///C:\thelab\HTML5Canvas\scripts\canvas_img.js :: anonymous :: line
9 data: no]
For The life of me I cannot see what I am doing wrong with the above. I have
done console logs to ensure that the code get's the image as well as the
canvas on the relevant lines and it definitely does. Anything I am
overlooking?
Thank you all in advance,
Schalk
Re: [whatwg] Canvas and Image problems
Hi there Eduard,
Makes total sense, now why did I not think of that ;p
Thanks,
Schalk
-Original Message-
From: Eduard Pascual [mailto:herenva...@gmail.com]
Sent: Sunday, May 23, 2010 12:33 PM
To: Schalk Neethling
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Canvas and Image problems
On Sun, May 23, 2010 at 12:16 PM, Schalk Neethling
sch...@ossreleasefeed.com wrote:
Hi everyone,
Having a really weird problem that I would like some input on. I am
trying to draw an image, as well as video, onto canvas. I use the
simple code
below:
$(document).ready(function() {
var image = $(#cat).get(0);
var cv = $(#img_container).get(0);
var ctx = cv.getContext('2d');
ctx.drawImage(image, 0, 0);
});
When I load up the HTML page in Chrome absolutely nothing happens and
I see no errors in the JavaScript console. When running it in Firefox
3.6.3 I get the following error:
uncaught exception: [Exception... Component returned failure code:
0x80040111 (NS_ERROR_NOT_AVAILABLE)
[nsIDOMCanvasRenderingContext2D.drawImage] nsresult: 0x80040111
(NS_ERROR_NOT_AVAILABLE) location: JS frame ::
file:///C:/thelab/HTML5Canvas/scripts/canvas_img.js :: anonymous :: line
9
data: no]
For The life of me I cannot see what I am doing wrong with the above.
I have done console logs to ensure that the code gets the image as
well as the canvas on the relevant lines and it definitely does.
Anything I am overlooking?
IIRC correctly, jQuery's document ready event is fired as soon as the HTML
itself is loaded and the DOM is built, unlike html's onload which waits
also for all external stuff (CSS, JS, images, etc) to be available. This is
a good thing to speed up things that don't depend on external content but,
in your case, it seems you are trying to use the src resource of an img
element before it's available. I'm no jQuery expert, so I can't tell for
sure; but you may check it out by running your code from html's onload
event instead of the document ready event.
Regards,
Eduard Pascual
Re: [whatwg] Canvas and Image problems
Jip, using $(window).load() works perfect.
-Original Message-
From: Eduard Pascual [mailto:herenva...@gmail.com]
Sent: Sunday, May 23, 2010 12:33 PM
To: Schalk Neethling
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Canvas and Image problems
On Sun, May 23, 2010 at 12:16 PM, Schalk Neethling
sch...@ossreleasefeed.com wrote:
Hi everyone,
Having a really weird problem that I would like some input on. I am
trying to draw an image, as well as video, onto canvas. I use the
simple code
below:
$(document).ready(function() {
var image = $(#cat).get(0);
var cv = $(#img_container).get(0);
var ctx = cv.getContext('2d');
ctx.drawImage(image, 0, 0);
});
When I load up the HTML page in Chrome absolutely nothing happens and
I see no errors in the JavaScript console. When running it in Firefox
3.6.3 I get the following error:
uncaught exception: [Exception... Component returned failure code:
0x80040111 (NS_ERROR_NOT_AVAILABLE)
[nsIDOMCanvasRenderingContext2D.drawImage] nsresult: 0x80040111
(NS_ERROR_NOT_AVAILABLE) location: JS frame ::
file:///C:/thelab/HTML5Canvas/scripts/canvas_img.js :: anonymous :: line
9
data: no]
For The life of me I cannot see what I am doing wrong with the above.
I have done console logs to ensure that the code gets the image as
well as the canvas on the relevant lines and it definitely does.
Anything I am overlooking?
IIRC correctly, jQuery's document ready event is fired as soon as the HTML
itself is loaded and the DOM is built, unlike html's onload which waits
also for all external stuff (CSS, JS, images, etc) to be available. This is
a good thing to speed up things that don't depend on external content but,
in your case, it seems you are trying to use the src resource of an img
element before it's available. I'm no jQuery expert, so I can't tell for
sure; but you may check it out by running your code from html's onload
event instead of the document ready event.
Regards,
Eduard Pascual
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. Hey TJ, I understand what type=date is supposed to offer the user and agree that using Modernizr to detect whether the element is supported and provide a fallback but my more direct question is, would HTML 5 offer the ability to allow a user to use either the date picker or enter the date manually if the type=date attribute is specified. Something like for example input type=date editable=true / Thanks, Schalk
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
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/
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] 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] 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] RFC: input type=username
I personally like the idea of having a type of username for an input field, makes sense based on the use case. Kind Regards, Schalk Neethling -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dirk Pranke Sent: Wednesday, May 05, 2010 8:20 AM To: Boris Zbarsky Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] RFC: input type=username On Tue, May 4, 2010 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/4/10 10:56 PM, Dirk Pranke wrote: What I would like to offer is a way to control some amount of the sign-in/sign-out experience while improving the security, by at least giving an in-page way to trigger sign-in / sign-out (the actual mechanism of collecting the credentials and performing the sign-in would be done by the browser without page intervention, where possible, for security reasons). So this would be something pages opt into? Yes. I also imagine people submitting user scripts that could rewrite existing login forms into forms using the new tags. If not, how would the following sign-in workflows (taken from two banking sites I've dealt with recently) work: Workflow 1: 1) Site prompts user for only a username. 2) After user enters a username, site responds with a Hello, __firstname__ (with either the first name corresponding to the username filled in or a random one generated if there's no such account) and two security questions. 3) After the user correctly answers the two security questions, he is presented with a previously-agreed-on image and phrase (to convince the user that the bank is in fact the bank) and 9 clickable buttons numbered 0-9. 4a) If the user has a mouse, the user clicks the buttons in the right order to enter their PIN (I believe a 7-digit or more number). Else go to 4b. 4b) If the user cannot use the mouse for some reason, the user can follow a link which associates each of the 10 buttons with one of a randomly chosen (each time you hit this screen, as far as I can see) set of 10 letters. The user can then type the letters that correspond to the desired numbers. Workflow 2: 1) Site prompts user for only a username. 2) After user enters a username, site responds with a page that has a password field and a bunch of buttons in the general shape of a qwerty keyboard. 3) The user enters a password in the password field. 4) The user also enters a different password (the site enforces that they're different during account setup) by clicking the correct buttons on the virtual keyboard. Various other banking sites I've dealt with have the previously-agree-on image and phrase thing going on, but these two are the ones that are creative with password input. In particular, the goal seems to be to defeat keyloggers by making replay of logged keystrokes be insufficient to log into the site. There is no question that people have dreamt up a large variety of mechanisms for logging into web sites. It would be difficult to support all of them out of the box, and certainly we would need to eventually extend the specs that Mozilla has defined to talk about how to support two-factor auth and other schemes like the ones you describe, if we can't figure out how to move them to more secure mechanisms. In particular, allowing a safe login from a compromised machine is, to say the least, somewhat challenging :( Both the Mozilla Account Manager and the scheme I'm talking about -- which again, builds on top of the account manager -- at least have the advantages that (a) they take the actual typing in of the password out of page and (b) they make the job of password managers far more reliable. Those alone should deliver enough benefit to make these ideas interesting, in my opinion. -- Dirk
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. Kind Regards, Schalk -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Steve Dennis Sent: Wednesday, May 05, 2010 10:40 PM To: Christoph Päper Cc: WHATWG List Subject: Re: [whatwg] RFC: input type=username On 5/05/2010, at 9:09 PM, Christoph Päper wrote: Eitan Adler: A type=username is added to the input element. type=username would MUST only be used for the name that is used to log in to the site. It MUST NOT be used for registration forms or anything else that requires a username. A form MAY have up to one (but not more) type=username input field. I agree with whomever mentioned that form role=login seems more appropriate. Anyhow, I wondered whether it makes sense to apply microformats to such forms, perhaps reusing hcard: form class=vcard role=login method=post action=./ input type=text name=username class=nickname input type=password name=password input type=submit /form Nick and user name are probably not the same all that often and differ by site, so this probably doesnt make sense at all. Still, form field semantics (name/id and class or role) may improve through some kind of standardization, although names shouldnt be as clumsy as in RFC 3106 (ECML: Field Specifications for E-Commerce) when applied to HTML forms. form action=http://ecom.example.com; method=post class=Ecom fieldset class=Payment-Card legendPlease enter card information/legend label class=NameYour name on the card input type=text name=Ecom_Payment_Card_Name size=40 /label label class=NumberThe card number input type=text name=Ecom_Payment_Card_Number size=19 /label label class=ExpDateExpiration date (MM YY) input type=month class=Month name=Ecom_Payment_Card_ExpDate_Month size=2 input type=year class=Year name=Ecom_Payment_Card_ExpDate_Year size=4 /label input type=hidden class=Protocol name=Ecom_Payment_Card_Protocol /fieldset input type=hidden class=SchemaVersion name=Ecom_SchemaVersion value=http://www.ecml.org/version/1.1; input type=submit input type=reset /form I don't know if it's relevant, but if we're thinking backwards compatibility, keep in mind earlier versions of ASP.NET only allow one form per page, so wrapping a login in a form tag isn't really an option. Someone tell me if I'm wrong on that though, I'm just a designer :) -- Steve Dennis www.subcide.com=
