Snippets

Web forms are complex beasts. There are a lot of field types to remember, each with dozens of attributes. It’s hard to know which is the right way to go, especially when presented with a choice between two seemingly similar options for disallowing a field to be edited: disabled and readonly.

TL;DR: If you really need it, which you probably don’t, readonly is what you want.

[…]

The Key Difference

So why do we have two attributes that do the same thing? Unfortunately this is where developers often get confused: the user experience is the same, but the mechanics are quite different.

Fields marked as readonly are collected along with all of the normal field values in a form submission (“successful controls” in the spec). The only difference between a readonly field and a regular field is the user experience.

Fields marked as disabled are ignored when collecting values from the form. In a traditional form submission, the action page would never receive values for a disabled field, regardless of whether it has a name attribute.

In Resilient Web Design Jeremy Keith discusses the idea of material honesty. He says that “one material should not be used as a substitute for another, otherwise the end result is deceptive”.

Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.

In Buttons In Design Systems Nathan Curtis says that we should distinguish links from buttons because “button behaviours bring a whole host of distinct considerations from your simple anchor tag”.

For example, we can open a link in a new tab, copy the address or bookmark it for later. All of which we can’t do with buttons.

A quick overview of new JavaScript features in ES2015, ES2016, ES2017 and beyond.

Firebug has been a phenomenal success. Over its 12-year lifespan, the open source tool developed a near cult following among web developers. When it came out in 2005, Firebug was the first tool to let programmers inspect, edit, and debug code right in the Firefox browser. It also let you monitor CSS, HTML, and JavaScript live in any web page, which was a huge step forward.

Firebug caught people’s attention — and more than a million loyal fans still use it today.

So it’s sad that Firebug is now reaching end-of-life in the Firefox browser, with the release of Firefox Quantum (version 57) next month. The good news is that all the capabilities of Firebug are now present in current Firefox Developer Tools.

The story of Firefox and Firebug is synonymous with the rise of the web. We fought the good fight and changed how developers inspect HTML and debug JS in the browser. Firebug ushered in the Web 2.0 era. Today, the work pioneered by the Firebug community over the last 12 years lives on in Firefox Developer Tools.

If you are using Grid in a very simple way, and positioning items rather than using auto-placement then the fact that grid exists in Internet Explorer from version 10 could turn out very useful. You could certainly use this in order to create a simpler layout for IE10 and up, once Grid is shipped in other browsers.

However be aware that this is going to require some additional testing and work, you are unlikely to be able to simply rely on Autoprefixer to run and do the work for you. For example, if you have used auto placement for any item and then don’t set a position using the -ms properties, that item is going to stack up with any other unpositioned items in the first grid cell.

The good news is that the IE implementation is pretty much frozen in time between IE10, 11 and current versions of Edge (presumably until Edge updates to the new specification). So work you do to implement grid in IE should work in those versions without needing to do different things for different IEs.