I have a wide monitor and I like my windows to be maximised (I’m on Windows 7). I also like when Chrome is maximised, because I usually have about 7,623 tabs open at any given time, so the bigger the window, the better.
Thus, when I visit a page on Wikipedia, it’s unreadable — because Wikipedia’s layout is fluid and it fills the whole monitor. It normally looks like this:
With all the excitement over the flashy new stuff in CSS3 (like transitions, transforms, and keyframe animations), some other properties may get pushed into the … well… background.
The CSS3 spec has introduced some new properties related to backgrounds. Here’s a quick and dirty description, along with a few examples, of one of those properties: background-clip.
Baseball season is in full swing in North America and I’ve noticed some nice changes to the design of the MLB.com website. In addition to changing their Flash content slider to JavaScript, they’ve also started to supercharge their design with some CSS3 enhancements.
On the game wrap-up pages, there’s some subtle use of rounded corners, opacity, and text-shadow, the latter of which I’ll be focusing on here.
The experience on the site is pretty similar on older versions of IE as it is on modern browsers. Here’s a screenshot of a game wrap-up page in IE6:
This is not going to be an extensive post, but just something to serve as a quick reference, along with some interesting points from the spec.
In another post, I’ll break down CSS3 radial gradients, but for now I’ll just focus on linear, to keep things simple.
After years of developing CSS layouts and reading web design blogs and CSS books, I still can’t believe I come across things that I don’t know about super-common CSS properties.
Maybe it’s just me; maybe I’m just a creature of habit and fail to look closely at things I’m really used to seeing, and I forget that there’s more to CSS than what I’ve personally discovered and learned so far.
Well, while reading Christian Heilmann’s chapter in the Smashing Book 2, I noticed he used the following code snippet when showing some CSS (edited for brevity):
This is not going to be a long article, but just a quick note about something that all front-end developers should be paying attention to.
If you don’t already know, the W3C has formulated a fairly brief, yet valuable document called HTML Design Principles that outlines exactly what principles have guided and continue to guide the creation and evolution of HTML5 and its related APIs and other technologies.
It would seem that with the introduction of HTML5’s semantic elements, styling those new elements should be an easier task. But as I’ve started to use HTML5 more, I’ve realized that it takes quite a bit of forethought to create maintainable CSS that targets the new semantic elements in a future-proof way.
In some cases, it could be fairly straightforward, but in others it’s a little disheartening because targeting the new elements actually creates more verbose markup.
Let’s consider a few examples. If you had a page that used the <header> element to hold the logo, nav, etc, and the <footer> element to hold the website’s footer, then your CSS would look something like this:
I’ll be the first to admit that I haven’t given this too much thought, so I admit there could be some drawbacks I haven’t considered, but I thought I’d throw the idea out there and see what my readers think.
Suppose we have an element that, for design and flexibility purposes, has no set width, and no set height. But obviously it has content, so in most browsers it expands to hold its content. We want that element to have a linear gradient background using CSS3, and we add a Microsoft proprietary filter to cover all versions of IE.
Here’s the element, demoed live on the page, with the aforementioned characteristics:
The topic of scoped CSS styles in HTML5 came up twice in the comments of a recent post by Chris Coyier.
The post itself was discussing the contenteditable attribute, but a few users brought up HTML5’s new scoped attribute, used on the <style> element.
Let’s take a brief look at this future HTML5 feature and see how it might be useful in the ever-changing web development landscape.
Alright, that title might be a bit exaggerated. Flame wars are bad for the community, and I don’t condone them. I think differences of opinion can be expressed in respectful ways that don’t involve unrelated personal attacks. I guess what I really mean to say here is that you can benefit from “heated discussions” that sometimes escalate into flame wars.
But nearly every super-heated discussion (whether in the web design community or elsewhere) has a common denominator: Two opposing sides with valid points of view. It’s unfortunate that sometimes these discussions turn a bit ugly and the actual pros and cons being discussed can go somewhat unnoticed and often forgotten.
