A couple of months ago I saw a Google+ post by Robert Nyman referring to the shortcut keys menu that appears when you hit the ? key on the keyboard.
Try it: Go to Twitter.com, GitHub.com, or Gmail, and you’ll see each of those apps will trigger a modal window of shortcut key definitions when you hit the question mark key.
In addition to the unique property/value pairs that CSS offers, there are also a small handful of language-wide features that can come in handy, including a few that are brand new in the spec.
These often go unnoticed, especially by beginners, because when CSS properties and their possible values are discussed (in tutorials, books, or even in the spec), these features are usually omitted for brevity.
Here’s something interesting that you may not have realized about CSS3 transitions. Normally, you’ll see a transition declared by utilizing three different properties, either in longhand or shorthand.
In both cases, we’re explicitly declaring three of the four transition-related properties (leaving out transition-delay). Can a transition occur with less code than that? Well, yes.
Ever since HTML5 Boilerplate put the ::selection pseudo-element on the map, so to speak, most CSS developers nowadays have been including this selector as part of their universal styles.
To get cross-browser support, the ::selection pseudo-element (which is used to change styles on highlighted, or selected, text) is declared like this:
Off and on over the past few months, I’ve been planning and working on a new project that is now ready to launch: Web Tools Weekly, a (you guessed it) weekly email newsletter targeted at front-end developers, with a special focus on tools.
This is not, by any stretch of the imagination, a unique idea. As many of us know, there are lots of options in the recent web dev newsletter boom.
As most of us probably are aware, a significant part of the HTML5 spec is the expansion of the History API.
This post will not be a super extensive discussion of this subject, especially since it’s something that I’m only now just getting into understanding better. But I thought I would put down the main components of the API, for my own quick reference, and I hope it will prove useful to my readers and those searching via Google.
It should be a coder’s goal to make sure that every character in every line of code serves some purpose.
The quality of code is not dependent on good form, prettiness, or theoretical benefits. Code should solve problems.
HTML5 lets you omit closing paragraph tags and closing tags for list items. Some cringe at the thought of this, but it’s perfectly valid code. So if omitting extra tags helps your code become leaner and faster, then you’re solving a problem and that makes it good code.
For those who have studied web site accessibility, this is probably old hat. Admittedly, I haven’t spent enough time thinking about accessibility, so this is one of those things I didn’t even realize until recently. So shame on me. :)
Let’s say you have the following page, with various elements, starting with maybe a form field:
I’m reading an old article on A List Apart by Andy Rutledge called Contrast and Meaning, which, before getting into the meat of the content of the article, lays the foundation by defining communication fundamentals.
Let’s say you’re viewing different pages in your browser, and in the midst of your browsing you decide to visit a Google’s home page.
The cursor is blinking in the search field. This means the cursor has been automatically focused into the search field, either via JavaScript or using HTML5’s autofocus attribute.
