r54567 MediaWiki - Code Review archive

Actually, WebKit also supports required="" in the very latest builds (since July 17). I've posted a notice on the Mozilla and WebKit Bugzillas:

https://bugzilla.mozilla.org/show_bug.cgi?id=344614 https://bugs.webkit.org/show_bug.cgi?id=19264

. . . wow, bare URL input is pretty broken on CodeReview, huh?

I'm not sure how much benefit there is to using 'autofocus' given lack of support; we need to do such focusing in JavaScript to make it actually work on current browsers. (Of course we could change our implementation from the occasional one-off <script> to a standard wikibits.js component which finds the appropriate element with 'autofocus' attribute...?)

Well, we could also write a JavaScript library to enforce all the other HTML 5 attributes in all browsers. Or we could not, and just let other browsers gracefully degrade. If someone wants to spend the time writing up something in wikibits.js to make autofocus automatically focus, required be required, etc., etc., then great. (I assume there's some easy way to tell from JS whether browsers support these attributes already, like checking for an "autofocus" property.)

This would be more convenient if we were able to drop $wgHtml5 and have it always on, so that we could use autofocus in all cases instead of having to try to figure out how to embed "autofocus me" metadata in XHTML 1.0 while still validating. Then the script could get getElementsByName( "input" ) and check each one for the autofocus attribute, if the browser doesn't already support it. Otherwise we'd have to dump an array of id's in the generated JS variables or something? Messy.

I should point out that it wouldn't be ideal to only focus the autofocus stuff onload. That seems to be what we do now for Special:Search, but on a slow server, maybe in a hypothetical future where most of our scripts were at the bottom of the page, there could be a significant delay between the input becoming usable and focusing. So it occurs to me that one way to do this would be to just have something like this output immediately after the <input>:

<script>
var focusInput = document.getElementsByName( "$name" );
// If there are multiples, the last one is probably what we want, since this is
// executed synchronously and is immediately after the element in the page
// source
focusInput = focusInput[focusInput.length - 1];
// Don't focus() if the browser already supports autofocus
if ( autofocus not in focusInput ) { focusInput.focus(); }
</script>

. . . probably somewhat more compact and with the comments in the PHP source, of course.

(Is it just me, or does GeSHi not really work here for some reason?)

That would be bug 19474.

With respect to <input type=email>, see my post to whatwg about it. I think it's validated a little too strictly at present, so I haven't changed our server-side checks, but it should work fine for ~99.9% of our users, and ~99.999% if the user manually removes extra whitespace and <> and (comments) and such. So I think it's fine to keep the client-side email type even if it's slightly too strict right now in Opera (the only browser that supports it).