I checked the site/app http://domai.nr/

Turns out html5plea.se is available.

OVH are doing really nice prices for these domains (.SE)

It should be totally bought, and hooked up to Github pages.

Just a thought.

all the markdown files have their descriptions on a long line. Because the way markdown works you can split them into multiple lines and it will still be rendered in one <p> as long as you don't put an empty line between them.

I claim the markdown source is more readable if we split all the markdown items over multiple lines.

Can I be totally OCD and change this on all posts?

also we're interested in reviews from people like this...

• @ slightlyoff
• @ necolas
• @ tabatkins
• @ chriscoyier
• @ rem
• @ desandro
• @ fyrd
• @ malarkey
• @ jdalton
• @ simurai

also either heillman or nyman..

(intentionally not @mention'd in order to not ping them too early)

• exclusions
• pagedMedia

Need to add similar to http://tests.caniuse.com/?ua=

So, we can get links for all of them :)

title pretty much sums it up

"you can use Respond.js, but be aware it has performance overhead that slows down page load."

I wanted to ask why Respond.js got a conditional recommendation? Is there data to support this as a noticeable performance issue? I've skimmed through the sister H5BP issue but no data provided, it's just assumed "Clearly [media query polyfills] have this extra cost for IE baked in".

Thanks!
Dave "Ball-Busterz" Rupert

While named HTML5 Please, this site discusses features beyond the HTML5 specification, coming from CSS, SVG, and the greater Open Web Platform umbrella.

As indicated by @iandevlin and @adactio, CSS3 is not part of HTML. However, HTML5 represents an umbrella term for all new technologies (as is inferred from platform.html5.org). Also, the specification itself is now a living standard known as HTML and not HTML5.

So, I am not quite sure how this collusion of terms would reflect in developer choices in real life.

• Would they stop using CSS3 because it is now part of HTML5?
• Would they make poorer use of CSS?
• Will this cause choice paralysis in terms of which technology to use?

A word acquires its meaning not because of its original definition but by what people bestow on it while it remains in use. I strongly feel the meaning of 'HTML5' has long since left the building and its implication to refer to the specification itself also has been abandoned by the spec editors.

I would love to hear your thoughts here before we go about adding disclaimers to the site.

@ConnorMontgomery yo!

we need to bring over some more data on these features from the modernizr wiki

there is a shell script to create markdown files for each feature

dig?

[divya here] - sorting by priority

• Sectioning Elements
• IndexDB
• Web Workers
• CSS3 Media Queries
• (Web) Audio (Data) API
• Accessibility / ARIA
• Microdata API
• cross-Document/Domain Messaging (postMessage)
• VTT: Video Timed Track (subtitles)
• Browser State Management
• Animated Png (APNG)
• summary
• <output>, <command>, and <keygen> elements
• Base64 ()window.atob and window.bota
• Device access via <device>
• MathML
• DOM
• Dom Range and Selection
• DOM Parsing and Serialization
• ECMAScript 6 (Harmony)
• XBL
• <link rel="prefetch|prerender"...>
• Visibility

When documenting DOM we have a lot of options here.

We can either go for "DOM" as in the living standard as in DOM4 or

we can go for

• DOM0
• DOM1 Core
• DOM1 Events
• DOM1 HTML
• DOM2 Core
• DOM2 Events
• DOM2 HTML
• DOM3 Core
• DOM3 Events
• DOM4

As for specfically DOM4. Given knowledge of the following two shims

• DOM-shim
• ES5-DOM-shim

It should be possible to correctly shim DOM4 upto IE6 but I don't trust either as a production ready solution.

As for everything else (DOM0 - DOM3) this would require significant research, of which quirksmode has done a lot for DOM0 - DOM2.

Note that DOM2 HTML is superceeded by WHATWG HTML (or W3C HTML5).

I can draft up details about DOM4 and recommend "use with caution" as the shims are not battle tested. Unless @term1uc1 wants to garantuee his shim is DOM4 compliant and fully production ready.

You wrote:

When you sunset IE6 support, you can use:
(...)
dt + dd : next sibling selector
(...)
p:first-child

I think you should mention, that these two selectors work only with static elements, shouldn't you?

suggestion from @shadowhand on twitter

should link to the css-tricks post about (styling) it

and mostly focus on its styling issues.

could point out the [speech] attribute just for fun.

Showing a feature in light of its current exposure in Userland would be pretty valuable. Different kinds of apps can have wildly different userbases, but continental data can also be illuminating.

I began to update the build script by dragging in and parsing out platform usage data from StatCounter's CSVs. Then it dawned on me that StatCounter might actually take exception to someone accessing their data programmatically and redistributing it.

Ideas, opinions?

Currently it says "up to 5MB is safe to use", that is not correct. Thanks to Chrome (and a few other browsers), only 2.5MB can be relied on.

See http://dev-test.nemikor.com/web-storage/support-test/ and related Chromium issue: http://code.google.com/p/chromium/issues/detail?id=58985#c15

An alternative wrapper library is Amplify.js Store: http://amplifyjs.com/api/store/ - that falls back to globalStorage and userData, instead of cookies (ugh). Recommending to use cookies as a fallback sounds like a really bad idea.
That sessionStorage project seems to also be rather odd. Using window.name along with "secure" cookies? Really?

I think WebGL should be classified as "caution" because it's not a safe technology by now:

• As per caniuse.com, WebGL is not fully supported by any available browsers.
• The support of WebGL is platform dependent and some WebGL browsers display some awkward warning if the can't run WebGL content.
• The support of WebGL is stuck with graphic drivers and all browsers does not support the same set of drivers. That means that if a WebGL browser work on a platform, an another WebGL browser may not.
• All browsers mark their WebGL support as "experimental" (see http://doesmybrowsersupportwebgl.com/ or http://get.webgl.org/ with any WebGL enabled browser)
• Some browsers (such as Chrome or Firefox) just crash when they try to pass the Kronos WebGL conformance test suite : https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html

Because of all those hazards, WebGL should be used with caution until things get a bit more stable and consistent across platforms.

I mentioned this to Paul in an IM. He was unsure why the 'laggy' scrolling, or 'choppy' behavior was happening when the visitor scrolled up and down, in a quick fashion.

(Firefox 9.01) Win7, 4GB RAM, ATI Radeon GFX Card.

I suggest the background be 'fixed'. (The denim png file). I always found fixed backgrounds are very perform-ant.

Maybe I'm wrong, but years of coding websites, you learn a thing or two. Call it intuition if you will.

I'm not an authority on this, but I remember a talk by Paul explaining the browser's paint / reflow mechanism.

I always got the sense, un-fixed backgrounds caused the reflow/paint to go crazy...

Also, what's the buzz with them circles in the BG? For a site claiming to use new browser features wisely, you over-embellish and confuse your users with over-engineered bulky choppy graphics?

Just a thought

-Dave

EDIT:

see this:

http://piratepad.net/morefeatures

reported by john foliot.

if anyone can diagnose the FF Android issue that'd be awesome.

Geez yeah we need this one pronto.

It's a bit strange to suggest to use Canvg with IE. Because IE8- does not support nor Canvas nor SVG, it could lead some unexperienced web developer to perform some dangerous performance thing such as using both Canvg AND FlashCanvas to render some SVG content which is a terrible performance issue to say the least.

The use of Canvg is very useful on the Android platform but quite dangerous with IE.

I suggest to change the text on the SVG technology to make thing a bit clearer.

from desandro:

What do you think about putting elements in brackets? <meter>, <menu>, <canvas> ? I immediately communicates that these are HTML elements and that the others are not.

i just did this to <meter> .. you gotta use a < in the feature name in the YAML.
95d78fb...f251a91

@ConnorMontgomery can you jump on this?

omg

"use the new and shiny responsibly" ?

paul: a little jocular with "new and shiny" but i think everyone feels a little amateur when they do it. "responsibly" adds some credibility to the information on the site

divya: responsibly is very grandfatherly

paul i'm thinking very much of the vibe of "we've got your back." "we've done this before." "learn from our experience"

"deliver the shiny with professionalism" ?

"use the shiny, safely" ?

Awesome site.
Given it's iffiness within IE6 and 7, I think having a section on inline-block would be really useful!

basically Paul and Divya need to go through these one by one and say their status.

Please read the following blogpost by Jonathan Snook to understand the problem

http://snook.ca/archives/html_and_css/hiding-content-for-accessibility

we have gtie6/7/8 tags on a bunch of items. the idea here is if you dont support ie7 anymore than all the stuff that's tagged gtie7 is available to you without a polyfill.
woo!

lets have a nice UI for people to discover whats available when they sunset each of the oldIEs

i imagine this is mostly just some UI that sets the value of the search input.

design, anyone?

Hey everyone!

So right now we have 42 features on html5please. Awesome, except 11 5 of those features (see the list below) aren't on caniuse. I'm making a few commits that fixes 6 of them right after I make this issue.

Features that aren't going to the right caniuse.com location:

• exclusion
• flex-box
• font-feature-settings
• geo-location (fixed with my commit)
• match-media
• media-queries (fixed with my commit)
• multiple-backgrounds (fixed with my commit)
• multiple-columns (fixed with my commit)
• offline-events (fixed with my commit)
• pagedmedia
• web-fonts (fixed with my commit)

Also - I wasn't sure if I was supposed to change the markdown file in the /posts directory or make the changes inline on index.html. I went ahead and changed it inline on the index page, but we may want an attribute on the YAML that is the caniuseparameter, since it differs sometimes (or sometimes doesn't even have the feature).

That way, we will only link to the items that are on caniuse, and not have any mistaken links that aren't going anywhere...

Just my two cents! Commits coming in a sec.

<3

Here is my Microdata shim for all browsers including IE6,7 (with this ES5/DOM shim https://github.com/termi1uc1/ES5-DOM-SHIM)
https://github.com/termi1uc1/Microdata-JS

Features:
Pure JS, no extra libs use (only shims).
It's successfully pass (not all, but many) this tests case http://w3c-test.org/html/tests/submission/Opera/microdata/001.html

Great job on the design.

But how about making the status colors (use, caution, avoid) a bit stronger. So the green a bit greener and the red a bit reder?

Would it be worth it to document another option beside polyfills? I'm talking about shims. I've noticed some recommendations aren't true polyfills, but something different.

My understanding is a Polyfill adds a feature missing in a browser by making the called API act as it would in another browser. A polyfill is dropped in via <script> and forgotten about by the developer. Browsers that support the feature will not touch the polyfill code.

A Shim is a wrapper, offering a developer a new API, that provides equal feature functionality to all browsers. A Shim will use native functionality if it exists and its solution if it doesn't. Developers have to be aware of the shim and use it accordingly.

Both aim for the same goal: providing a feature across all browsers, but how they're used and implemented are different.

ECMAScript 6 (Harmony)

• es6 collections
• es6 shim

Problem with ES6 is that the of the current features in Firefox/Chrome

• WeakMap, Map, Set (can be shimmed)
• Proxies (no idea, doubt it, might be do-able with really expensive polling assuming your happy with race conditions)
• modules (depending on the API, the API might be shimmable, the declarative will not)
• let / const (not shimmable)
• typeof null === "null" (not shimmable)

Note that because ES6 has so many new syntax solutions the ideal solution to this problem is a coffeescript style transpiler. A few projects are attempting this Reference SO question

• traceur
• Caja
• ES transpiler

This is a use with caution at the very best since the un-shimmable subset of ES6 is signficantly large then the un-shimmable subset of ES5.

I have not added an item for ES6 as I would like feedback on whether we want use with caution or avoid.

Once a stable transpiler exists I would recommend use with fallback where the fallback is the transpiler (you can sniff the http request on the server for things like "text/javascript;version=6" and send either ES6 or transpiled ES3 to browsers).

http://listjs.com/

the data in the site is getting a little unweidly. it'd be good to maintain in a better format.. YAML perhaps?

from there lets chuck it into the site. using a node build script might be nice.. pipe it through some nice templating library.

alternatively could pull it in clientside and apply it with MDV http://mdv.googlecode.com/svn/trunk/docs/design_intro.html .. but we lose SEO i suppose.. hard to tell

anyway.. we need a better data format and really easy step to bring that into the document. FWIW i think the haml is optional.. it was mostly to avoid the messy markup around this data.

I think the Visibility API is worth a mention.

Currently there is native support for Chrome > 13, IE 10 and Firefox 10 although only with prefixes.

Pollyfills:

• https://github.com/addyosmani/visibly.js
• https://github.com/evilmartians/visibility.js

In my opinion the status should be "Use with pollyfills" .

What do you think?

sorry jason.

but clientside css polyfills are too costly for the benefit they provide.

To make each article more semantic the h2 should be moved to the top in the header-element. This will help e.g people that uses screen readers to understand what each article is about.

Looking at the generated source of: http://h5bp.github.com/html5please/ it would appear that we haven't configured any account information for the GA script.

var _gaq=[['_setAccount','UA-XXXXX-X'],['_trackPageview'],['_trackPageLoadTime']];

Am I just being silly or have we forgotten this? :)

Happy to strip it out if there are no intentions of using, but seemed like something to get rid of if we're not taking advantage of it.

it'd be nice to explain somewhere what is polyfill vs. fallback

yup. looks like we need this. talking about it in #53

I am not totally convinced about opening caniuse in the same window (when you go back you lose status)

good call. need some target=_blank for sho

any way to avoid spam in the edits?

goes through github so i'm not worried at all.

isn't the old flexbox support going to be maintained in browsers that already support it and add the new flexbox as a separate one (instead of one replacing the old one)?

there are existing bugs that havent been fixed for 1yr so no i dont expect legacy impl to get much maintenance.
they can coexist though, to answer the main question.

http://analogysoft.com/learning/ui-hulk-out/#beyondie6

It's got less <70% overall adoption with IE8 (and under) not supporting it. I'm not sure if ignoring 30%+ of web users is really an option for most devs. It really depends on what the bar html5please uses to determine "use" vs. "avoid". Is there such a numeric boundary or precedence?

Would it make sense to change it to "caution"? Maybe add a link to some of the more common hacks recreating "background-image options" in older browsers? I don't think there's a polyfill for that could replicate with reasonable fidelity "background-image options" in IE8, which is why I'm suggesting "caution" vs. "use with polyfill".

As someone with a bit of experience using FlashCanvas spending a number of hours tracing through Actionscript, I'm on the fence as to whether or not canvas should be classified as "use" or "caution". It isn't a drop-in polyfill that's going to transparently produce the kind of results we typically expect from most polyfills. FlashCanvas, in my experience, handles basic shapes and simple animations just fine. But as soon as you take it outside of it's narrow comfort zone, it falls apart.

Also, I should note, the author of the project states that FlashCanvas' does fairly well when put up against this test suite, which it does. However, where FlashCanvas often fails is when you actually throw it into a real-world situation where we're performing a several operations on the canvas at once (like a globalCompositionOperation after a drawImage).

For example, see the limitations with the drawImage method here: https://groups.google.com/group/flashcanvas/browse_thread/thread/a16eea741872b085/d0e66cc44b1441c6

Awhile back, I created a demo to test performance in IE: http://bentruyman.com/lab/canvas/dyo/

I apologize I don't have a more complex example to prove my point. :(

tl;dr Without a better alternative than FlashCanvas, I'd say this one should be classified as "caution".

Hi fellows.
Here is my ES5/DOM shim with IE6 and IE7 support
https://github.com/termi1uc1/ES5-DOM-SHIM

Features:
classList
addEventListener
removeEventListener
dispatchEvent
attributes (IE fixed)
children (IE fixed)
firstElementChild
lastElementChild
nextElementSibling
previousElementSibling
childElementCount
querySelectorAll
querySelector
insertAfter (non standard)
getElementsByClassName
compareDocumentPosition
DOCUMENT_POSITION_DISCONNECTED
DOCUMENT_POSITION_PRECEDING
DOCUMENT_POSITION_FOLLOWING
DOCUMENT_POSITION_CONTAINS
DOCUMENT_POSITION_CONTAINED_BY

DOM API ie IE6,7.

Russian article about my shim http://habrahabr.ru/blogs/javascript/133328/

And here is my details tag with no extra libs use only any ES5 and DOM shim (IE < 8 support with my shim [work not finished])
https://github.com/termi1uc1/Element.details

Some of feature reviewed I am not familiar with. A link to trusted documentation for each feature would be useful!

for example datalist:
http://www.w3.org/wiki/HTML/Elements/datalist
https://developer.mozilla.org/en/HTML/Element/datalist
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element

(it probably goes without saying but please no w3sch**ls.com links.)

This is a short review of the current recommended datalist polyfill's. I think, those issues has to be fixed, before these scripts should be recommended.

ping @chriscoyier and @miketaylr

Additionally, I have created 3 fiddles (those two polyfills + webshims implementation) , to simply test those implementations (http://jsfiddle.net/trixta/3Yu9X/).

feature detection:

rd's implementation:

The main code of rd's implementation has no feature detection. Instead the demos are using the following feature detection:

if (!Modernizr.input.list || (parseInt($.browser.version) > 400))

While there is no problem using browser sniffing against past versions, it's not possible to sniff against future versions. This code breaks as soon as webkit has implemented the datalist element!!!

Use the following featuredetection:

if (!Modernizr.input.list || !('HTMLDataListElement' in window))

To foolproof the script. The script itself has to use feature detection, so that a developer does not has to wrap his code invocation...

Note: This detection will be fixed with next Modernizr update.

options removed (X-browser???)

In HTML4 options are removed, if they are not a child of select or optgroup.

rd's demo

The demo does not use a select element and does not shiv the datalist-element. All options are removed, so that the demo doesn't even work with IE9. Please fix!!!!

mt's demo

This implementation adds a select element using conditional comments for IE. Due to the fact, that all older "HTML4-browser" remove option elements and not only IEs, it is recommended, that the demo should always wrap the options in a select element!!!

option parsing:

There are 4 ways to declare value/label of an option element:

<option value="option 1" />
<option>option 2</option>
<option value="option value 3">option label 3</option>
<option value="option value 4" label="option label 4" />

At least 1 and 4 has to be supported.

rd's implementation

rd's implementation supports only 1 and 2.

mt's implementation

Is dependent from browser. Only 4. option syntax can be used with similiar results in all browsers. Use $.fn.val to also support first option syntax in IE7.

datalist[-overlay] placement

rd's implementation

rd's implementation appends the list to the body and uses $.fn.position to calculate the position of the input element. This is wrong and fails in a lot of cases. This fails as soon as the input element has an offsetParent (position: relative!!!), which is not html / body.

To make this right, $.fn.offset has to be used.

mt's implementation

This implementation is extremley obtrusiv and also fails in many cases. mt's implementation wraps the input element and the generated list inside of a div with relative position to place the datalist. This fails, in many ways, because

• it heavily modifys the structure of the document (selector do not match anymore or selectors which should not match start to match...)
• it's not possible to use overflow: hidden, auto, scroll on an ancestor of input[list] anymore

Use same technique as rd's implementation, but use offset instead of position.

user interaction

mt's implementation

no keyboard interaction, no list filter, no support for long datalists

rd's implementation

• keyboard interaction: select from list with enter submits form
• select is on click, but should be on left mousedown
• list disappears, if user wants to scroll with mouse in a long list

performance

mt's and rd's implementation [too much DOM operations]

Both implementations are creating one (rd) or three (mt) new elements per option. While rd's implementation should be fast enough in webkit, it's a really bad technique for creating a list of elements in IE7 and IE8. mt's implementation should be too slow in all browsers.

Instead of creating new elements per option. The implementations should create a string and let jQuery create the DOM at once using the fast DocumentFragment technique.

rd's implementation [event delegation]

use event delegation

mt's and rd's implementation [be lazy]

you don't see a list initially, only if a user interacts with the input, so be more lazy!

rd's implementation [resize event]

rd's implementation is realigning all datalists on the resize event even if the datalist isn't visible. The eventhandler doesn't use debouncing or throttling.

Those two webkit CSS properties, like you mention, will never be part of any spec. Therefore should this even bring attention to their existence?

I'd be in favour of removing them.

from @aaronpeters

Looks great, but at first, when typing in text field, I thought nothing happened. And then, " oooooh, I need to scroll to see result(s)". Hmm

heard this from @jetienne yesterday too... http://imgur.com/w5wx2

hmmm...

What would be the status for requestAnimationFrame? Use with polyfill?
Is @paulirish's polyfill good enough to be recommended?

Do these deserve a place on the list? With box-sizing?

One of the things I'm excited about with CSS3 is the improved box styles for vertical alignment.

1. It needs to add a class to selected elements ('expanded') when they are selected, so they show expanded rather than collapsed.
2. There should be a way to permalink a search, and when you load a permalink it returns with the set of search results.
3. It needs to be searchable over the title, tags, and kind only. e.g. gteie8, gteie9, box-shadow etc.

@brianblakely do you think you have some time to look at this?

"with fallback" should be removed