A useful list. I was surprised to find that I'd only heard of one of these.
The pattern attribute for regular expressions looks like a great addition. Obligatory comment that "no more...server side code to check if the user's input is a valid email" is clearly a terrible advice. Always validate on the server.
I should point out it's generally not a good idea to try to use regex on an email address. It's surprisingly complex and very easy to miss something. I'd rely on type="email" and send a verification link server-side.
Specifically, they've redefined the format of email addresses in a way that's much simpler and is actually amenable to regular expressions. "This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here."
The spec even includes a Perl-compatible regex as an example. :)
You know, I really think at this point that the random historical crap that's technically legal in an email address should be treated the same as if you walked into a restaurant and tried to order in Latin. It's time to retire a lot of it and tell people to move on.
That doesn't change the fact that a lot of validators disallow common, everyday things like + tags or even . characters. The only good way to be sure is to make sure the address contains an @ SOMEWHERE other than the last character (.+@.+, maybe), and then send a validation e-mail.
The good thing is that the regex will be the same. It's also pretty trivial to write a polyfill to work on old browsers. I've found it's really nice to define that in one place then to use it everywhere. Newer users get the HTML5 validation, older ones the Javascript fallback, and everyone gets a second round of checking before it hits the database.
Pattern is super useful, but not for type=email, which guarantees syntax check already. Use it with type=text for special fields like serial numbers, SKUs, credit card numbers (for which type=number is not appropriate).
dns-prefetch and prerender are not "HTML5". They're experimental/proposals from couple of browser vendors.
For that matter, I'm not sure how much this feature actually helps... I know there is a cost to a lot of dns lookups.. but having the dns-prefetch in the header along with the actual link to the css likely won't help much... it might help a bit with script includes at the bottom of the page though...
Also, a lot of the other bits aren't supported on IE 8/9 which is optimistically 1/3-1/2 the users on a lot of websites... it's worth doing, but doesn't mean you can/should forgo server-side checks/code. I find a lot of the client/server frameworks that are client-centric people are coming up with that do no input validation server-side to be more dangerous than a lot of older frameworks. It's like SQL injection issues all over again.
Is the dns-prefetch only useful for things that are not already linked/included on the page? (such as redirect chains... t.co links might DNS prefetch the domain of the end of the chain)
Or is the benefit that you can start the DNS resolution whilst receiving the <head>, for the JavaScript resources only included near the </body>? (being a very slight performance benefit)
Edit: And I suddenly thought... for SSL pages would dns-prefetching leak some information to an observer about the composition pf content or the linked resources on a page by grouping such DNS requests into a short burst at the same time as the SSL request?
Correct on both counts.. Pre-fetching DNS names for origins not on the page is, indeed, a nice use case - redirects are a good example. Similarly, embedding a <link rel=dns-prefetch> in the head will trigger an early DNS lookup, which can, in fact, deliver big latency savings -- you would be surprised how slow DNS lookups are in practice.
Last but not least, AFAIK, I'm not aware of any logic to group DNS-prefetch hints or similar strategies when running over TLS.
I tried implementing it for my blog’s pagination, but I definitely don’t see the zero-second latency Google report in the video, and it doesn’t seem any faster at all.
Can you tell me if it’s actually working from using the pagination at the bottom of the front page, or the pagination inside the permapages: http://pygm.us/1e9KHCYt. (Link fixed.)
More than the "force download" aspect, it's mostly useful to specify a filename when linking to a download where the filename can be strange or non-existent, like a data: url, or some remote resource you don't completely control.
I'm pleasantly surprised to find out it now works correctly on Firefox. It was Chrome only last time I checked.
Surte, but one cannot underline enough the importance of relevant and correct examples. May I suggest something like "<a href='verybiglogoftheday/' download='log-2013-12-11.txt'>"
Yes, look at my example (http://jsbin.com/utugex/1/edit), the href is pointing to an .html file, so in the normal case the browser will display the content of the page but with the download attribute the browser will be forced to download it as "myfile.pdf".
The regular expression pattern checking is pretty awesome. I'll disagree though where they say you don't need any more server side validations. You can easily remove / change the pattern value in the DOM. Which begs the question, what's the integrity of client-side testing if it cam be bypassed so easily?
anything client-side is never about security or consistency since no matter what you do, anybody can always send you any data they want.
client side validity checking is about the user experience, I mean if the user is doing something wrong you can guide them to the right direction without the need of server interaction and server interaction is always slower that one line of client side code.
The prefetch demo is obnoxiously misleading. If it is definitely the link you'll be loading, I doubt you will wait upwards of 7 seconds before clicking the link. In which case, it will not be 0 seconds loading. Then there is the equally likely, you were confident it was what I wanted, but you were wrong case. In which case I just downloaded a ton of garbage I didn't want. (Can't wait for ad servers to preload their assets for you...)
And this is also somewhat amusing, since if I recall firefox has boasted 0 second reloads when you hit "back" fora long time now. Does chrome support that, yet?
The prefetch is an option which you can opt-out from, and i think you are mixing prefetch and prerender, just to let you know Firefox has actually supported prefetching since...wait for it... 2003.
AWESOME POINTS! I spend alot of time on Html5Rocks.com and I studied Html5, but I never even heard of some of these feautres....Made a new wrinkle in my brain ;)
This should make pagination really, really interesting. I just need to add some checks to ensure I don't force users to prefetch a huge chunk of data, of course.
Must the prefetch/render tags be present at first load, or might they be added dynamically with JavaScript? Pagination is a good example, since a news site might want to load the second page of an article only after the user get so far in. Single-page sites are another good use case.
It would be neat if caniuse had a widget that you could embed which would show % usage at time of reading the post, so I could know right away instead of looking each feature up.
You'd also have the advantage of the article always being relevant.
The RegEx input checker on the client-side is not a replacement for server-side validation. It doesn't prevent someone from sending requests to the server with bad data, so don't forget to make sure that all requests have valid data.
What it does is help the interface to be more responsive so the user doesn't have to wait for a round-trip before finding out that they forgot to put in an email address / other valid input.
Yep. Prefetch != prendering. Prefetch only fetches the single resource, and is meant as a "post load" hint. Whereas prerendering fetches the entire page, and all of its assets.
But isn't it really a matter of time before the `prefetch` and `prerender` options get ignored? Some rogue sites are just going to mark all their links with `prerender`. This is almost akin to the `meta keywords` that were abused for a long time, and then all search engines started ignoring it.
There's probably a reason most browsers have been so slow to adopt it - especially Opera. Perhaps the reason Chrome is the only browser supporting it is that Google can leverage the web crawlers to scan for malicious use of the attributes.
I'm disappointed that DNS prefetching does not specify the record type (A, MX, TLSA etc), thus limiting utility solely to protocols that use nothing but A records.
Oversights like these subsequently constrain other developments, such as the case for basing HTTP 2 on SRV records, using DANE to authenticate certificates and so forth.
this was immediately distracting to me and annoyed me very fast. Maybe it's because I'm reading on a mobile device and "x mins remaining" took up ~1/4 of my screen every time I scrolled. What value exactly does it add? It's likely to be wrong, and just got in my way.
While it is nice to have, datalists are currently lacking in common functionality and are no real substitute for fully featured autocompletes. For example, datalist only matches the beginning of the values. Typing "soft" into a datalist will not match "Microsoft".
Hugh's point is incredibly important. You don't really want one hundred thousand <option> elements in your DOM as your "auto-complete" solution.
To be honest, datalists are pretty worthless for every situation where I've needed to implement auto-complete functionality in projects, simply because the universe of possible entries has been always been huge.
The pattern attribute for regular expressions looks like a great addition. Obligatory comment that "no more...server side code to check if the user's input is a valid email" is clearly a terrible advice. Always validate on the server.