Over on CSS-Tricks, Chris breaks down what some in the industry have said on the possibility that there will one day be a CSS4. The latest article that Chris references is one by a well-respected member of the community, Peter-Paul Koch (“PPK”).
In brief, PPK believes in initiating some sort of marketing gimmick wherein we basically try to repeat the success of the buzz surrounding “CSS3” by pushing the name “CSS4”.
In CSS, every property has what’s referred to as an initial value. Sometimes this is called the default value, but the spec uses the term initial, which I think is a slightly better term.
Technically speaking, the initial value of any given property needs to be declared only if that value is overriding a previously-defined value that’s not the initial value. But initial values are often present even when they’re not necessary.
For example, suppose I have a block-level element that I want to take up the full width of its parent. I want it to sit on its own “line”, so to speak, in the layout, so I add the following CSS:
This just in: Web developers are easily swayed by tentacled sea creatures. But wait, I’m getting ahead of myself. I’ll get back to that in a moment.
Caching and cache-busting front-end resources have been common for a number of years now. When dealing with front-end resources, you want to be able to accomplish two things:
One thing that’s common in development blog posts and documentation is the use of HTML’s <code> tags to mark up code snippets inline and in large blocks (the latter of which is usually done along with <pre> tags).
One of the problems that occurs with styling of <code> tags, however, is when they’re used inline inside of links (or <a> elements).
For the record, I don’t hate w3schools. Apparently, a lot of people find their website useful. And from a human perspective, I’m happy for their success. After all, it’s run by one or more people, just like you and me, who have to feed their families.
But with everything we know about SEO and web development best practices, their ability to remain at the top of search results and also be in the top 200 most-visited websites in the world even after Google has made so many updates to their ranking algorithms, baffles us all.
In this post I’ll attempt to analyze a number of things about the w3schools.com website, both good and bad (mostly bad) and see if we can’t learn a few things and draw some conclusions.
I recently did a complete overhaul of my CSS Values info-app. The design is basically the same, with some minor adjustments. But the website is now using a MySQL database to store all the info (as opposed to throwing everything into plain HTML) and it now includes browser support charts for every CSS property.
Much of the info is probably in need of improvement, but there’s something significant I noticed when transferring the data from the HTML to the database. It turns out, a certain bias exists with the types of properties that the W3C has approved, and I think we can use this information to speed up the standards process in the future.
I think this is a pretty basic point, but I often see people throwing terms around in inappropriate ways (which I’ve also been guilty of), so I thought I would clear this up.
As fallible humans we tend to lean towards making excuses, blaming others, or trying to justify our mistakes or shortcomings. This is why you’ll often read comments from people discussing CSS and web standards, and they’ll say “I don’t use Internet Explorer; I use a standards-compliant browser”. Well, no you don’t. Nobody does.
In the comments of a recent article discussing conditional comments someone mentioned that they prefer to use PHP to detect which browser (user agent) and/or operating system is in use, then they display a custom class for the <body> tag and target the browser accordingly in their CSS.
I’ve known for some time now that this is wrong. I was told that a user agent can be faked, so the people I’ve worked with discouraged this method, and I’ve never used it.
In no way am I an expert in this particular area, so I’m not claiming here to be able to fully explain exactly why we shouldn’t do this, but a little bit of quick research on this topic shows that server-side browser detection is not a good idea.
I’m not going to drag each of these points on (mostly because I don’t have the technical expertise in this area), but instead I’m just going to provide brief quotes and links that discourage the use of this method and provide further insight into the matter.
Use of conditional comments to target certain versions of Internet Explorer is pretty commonplace nowadays, and is generally seen as the best-practice method for including separate styles for IE.
Of course, I’ve argued in a previous article that if your IE-only styles are minimal, then you should just include them in your main stylesheet, a notion that others have echoed.
But conditional comments have some unique possibilities and quirks that maybe you haven’t considered before, or have simply forgotten. Here is an overview of some things you may not know about conditional comments.
Dealing with Internet Explorer is a fact of web design, and it isn’t going to go away anytime soon.
If not for some of the differences in the way IE6 and IE7 handle certain areas of CSS (whether it be margins bugs, float bugs, or other problems), CSS development would be so much easier.
Of course, as I’ve said in past articles on this website and others, I believe IE-only styles can be kept to a bare minimum, and in some cases you may not need any, but it’s unlikely that developers will end up so fortunate. So how do you divide your IE-only CSS styles? The options we have are as follows:
