Creating a website with HTML5 and CSS3 without having to worry about using techniques like progressive enrichment and polyfills is the ultimate dream for modern-day front-end developers.
But unfortunately, mainly because of the widespread use of IE6-8, that is still just a distant dream. But it is getting closer.
Ever since HTML5 has started to gain wider use, many developers have wondered what syntax style should be most prevalent. When coding HTML in XML format, it was easy–because the validator forced you to code in a consistent manner.
Well, since code validation in HTML5 is a bird of another feather, a consistent coding style is going to be extremely unlikely across the web. While an exact coding style across all sites is not really necessary, I think some level of consistency is in order. People’s concerns in this area are valid.
So here are my own personal point-by-point recommendations for clean and consistent markup, and some reasons behind the decisions.
Here’s something interesting I came across while reading Introducing HTML5 by Bruce Lawson and Remy Sharp, which I recently purchased.
In one of the early chapters, Bruce mentions that when tags are not nested properly, the resulting generated DOM will be seen differently in different browsers. Of course, when you “view source”, the code will be the same in all browsers. It’s when you inspect the page (or view the “generated source”) using developer tools that the results can differ.
After some testing, this is indeed the case. Here’s the code that I tested:
Here’s a nice lesson for web app designers and developers, to help streamline the user’s progress when interacting with your application.
In many cases, it’s enough to log users in and then redirect them to the main screen of the app, where they can then choose what they want to do. It’s also good practice to send them back to whatever screen they were on before they logged in, instead of just sending them to the main screen.
But here’s a way to handle a user log-in when the user has not yet interacted with your pages, as shown below from PayPal:
As anyone who codes CSS knows, the color property in CSS defines the color of the text in a specified element. I’ve often wondered why this property was not named text-color or something similar.
A comment that was posted today on one of my older articles by someone named Stu Goymer actually instigated my research into this, but he raised an interesting point: Why doesn’t the font shorthand property allow the color to be defined?
Well, according to the spec, here’s what the color property is supposed to do:
What?? $3.99 for an iPhone app? Are you crazy? The nerve of some people. Lunatics.
How can you expect me to pay $3.99 for this? Every single iPhone app I’ve ever downloaded is either free or costs 99 cents. Now, you expect me to pay $3.99, and all I’m able to judge it by is a couple of screenshots, a brief description and a few shill-sounding reviews.
I wanted to tweet this, but it was too long for Twitter so I thought I’d just post it as a short piece for the weekend.
For those who haven’t seen the news announcing changes to the HTML5 spec on the WHATWG blog, be sure to read that and some of the comments.
But the funniest and most brutally honest comment belongs to someone posting under the name “Hamranhansenhansen”.
Aesthetics, organization, structure, compatibility, mobile-friendliness, best practices, minimalism, typography, color choice, drop shadows, rounded corners, responsiveness, usability, user experience, CSS3, HTML5, jQuery — none of those things is integral to what ultimately falls into the category of “good design”.
What matters the most — that is, what truly puts anything in the category of “good design” — is whether or not the thing you’ve designed achieves the end result you desire.
This is not a knock against my current area of work. I love what I do, and I don’t intend to change. But I think most of us think about what we might do (or what we might have done) if web design wasn’t in the equation.
In this case, though, I’m taking it a little further. Instead of just saying “here’s what I’d do if I couldn’t do web design”, this is actually a list of legitimate jobs that I would rather have if I could jump into them immediately and not do anything related to the field of web design. These are not necessarily in preferred order.
When using or researching CSS pseudo-elements, you may have come across different syntax for the :before and :after pseudo-elements, specifically in the form of a preceding double colon, instead of the traditional single colon. This seems a little confusing at first, but there’s actually a pretty simple explanation.
I had assumed that there would be some difference in the way each functioned, but that’s not the case, as the short and long answers below make clear.
