Tag: css

Categories
Mozilla Web Development

On Prefixing And Monobrowser Culture

I’ll say right off the bat that Daniel Glazman is right, and I fully support his message. The failure to alter the course of the web now will lead to headaches. Truthfully it’s already a headache, it’s just going to get worse. The IE Days were the dark ages of web development. I don’t want to go back to that.

In an ideal world, CSS prefixing wouldn’t be necessary. Browser vendors would spec things out, agree on a standard and implement it. That however is too rational, so CSS prefixing is an unfortunate reality. It outright won’t happen by the admission of Microsoft and Apple (pointed out by bz):

tantek (Mozilla): I think if you’re working on open standards, you should propose
your features before you implement them and discuss that here.
smfr (Apple): We can’t do that.
sylvaing (Microsoft): We can’t do that either.

Of course you can question if there’s really a legitimate need to work on standards in private. I’m personally skeptical a CSS property will leak the next iPhone.

It’s also worth noting Apple and Microsoft are both OS vendors and (cynically speaking) have interests that are explicitly contrary to the internet being a universal platform. Fragmenting the web and making it a more difficult platform to develop on is potentially in their interest. Not to different from their stance on h.264 of whom they are both licensors and thus haven’t implemented WebM.

I’m starting to second guess the permanence of prefixes. I personally think once there’s a standard the first release of a browser 12 months after standardization drops support for the prefix. Yes, this will break a few websites that never update. However it’s almost always an easy fix. I’d venture 95%+ of the time it could be done safely via a regex. Truth is you’re talking about 18-24 months from initial implementation in practice anyway. Possibly longer. A website that is so stale it can’t manage to deal with this in 1.5-2 years is in pretty poor shape to begin with. LESS and Sass can also be a big help in automating this. W3C CSS Validator already errors on prefixes. The tools to deal with this are in place today.

I should note dropping is unlikely to happen and thus wishful thinking.

A large part of this issue is how many websites are built these days, especially “mobile sites” which are typically separate sites bolted onto an API or even the backend database of a website. Often built by 3rd party vendors getting things passable and out the door is key. As a result every shortcut in the book is taken, including the absolute minimum in testing and compatibility.

For what it’s worth, this blog has only one prefix in use, and it’s coded as:

-moz-border-radius: 3px;
-khtml-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;

Which catches everyone. That takes all of 30 seconds at most to do.

Categories
Web Development

Profiling CSS

Some interesting research regarding CSS and performance that any web developer should read. Nothing really groundbreaking but it’s good to see the reason behind many of the rules we often hear. It’s also good to see multiple browsers releasing tools to test performance of selectors.

Categories
Web Development

Mobile Experience On A Budget

This blog is largely read by people on traditional desktops and laptops. It’s mobile usage is a bit on the low side, though that’s changing. I decided I wanted to start making the mobile experience suck less, but I didn’t want to go as far as serving a whole new experience for mobile. Responsive web design is interesting, but I didn’t want to invest so much time in it just yet.

This is still an ongoing project, and partially an experiment but here is my game plan:

Make The Standard Design Light/Flexible

The site right now is actually pretty simple in design and structure. It’s a grid layout, everything is modular and ID/classed up. I’m a slight performance junkie and graphically impaired, so image use is pretty minimal and I’ve sprited what I could to make the design as light weight as possible. The core site itself is actually just a few requests. Everything that can benefit from being so is minimized/gziped to lessen the payload down the wire. JS is only included on pages where it’s needed. Light payloads and minimal requests are the name of the game.

This benefits all platforms. Even with 45 thumbnails from Project 365 images on one page, I still can load it all about 2.5 seconds on my laptop. That’s not terrible. Some say “think mobile first”. I say “think performance everywhere”. There’s no reason why performance should be limited to mobile.

Rejigger For Mobile

Step two is to adjust the site for mobile. In my case that means hiding some less useful things, and some size and layout related changes to fit on a smaller screen. Like I said, I’m not serving up a separate mobile site. My pages are already rather light and saving 1 KB doesn’t seem worth it to me just yet. I just want my existing site to not feel like a desktop site. This is more about usability. Performance wise I optimized with mobile in the back of my head while working on the desktop experience.

I didn’t want to include a separate mobile stylesheet since my changes are intended to be subtle and minimal. Besides, that’s a separate request for mobile users. Instead I appended to my existing stylesheet with something like this:

@media only screen and (max-device-width: 480px) {
    body  {
        min-width: 0;
        width: auto;
    }
    #page {
        min-width: 0;
        width: 100%;
    }
    /* and so on… */
}
@media screen and (max-device-width: 480px) and (orientation:landscape) {
    /* landscape specific CSS */
}

Like I said, I intended for my changes to be pretty subtle. This works pretty well. The one thing it can’t really handle is images. I tend to be pretty light on image use, so it’s not a deal killer for me. However I may eventually look at better solutions in the responsive image world. For now I’ll just make the editorial decision to keep image use tame.

In general my philosophy has been:

  • Does this have value in a mobile context? (no: hide it, yes: continue)
  • Can I adjust the layout/design to make this not suck on mobile? (no: hide it, yes: continue)
  • Is this more work than it’s worth? (no: do it, yes: hide it)

Final Thoughts

I’ve still got some more polish to do, I know <pre/> blocks don’t look/feel right and the comments area is still not quite there. The image gallery experience is not even started. But overall it’s still better than the desktop experience I was serving just hours ago.

Perhaps one day the paradigm will shift on this blog, but I don’t see that happening just yet. Most of what benefits mobile also benefits the desktop experience. This approach gives me an improved mobile experience with minimal hassle. I also benefit from not needing two do work twice as I would if I had a separate mobile experience. That means more time to be productive.

Categories
Mozilla

Things You’ll Love About Firefox 4.0

It’s that time again. Here’s my list of awesome things you’ll love about Firefox 4:

For Users

New Look For Tabs

New Tabs For Firefox 4
One of the first things that you’ll notice is tabs on top. This paradigm really makes more sense since the tab defines not just the content but the environment it’s viewed (prev/next button, URL bar). It’s also just much sleeker looking. After a few minutes you’ll likely agree this is a better approach than tabs under.

Another nice touch is if you enter a URL that’s already open in another tab, you’ll be given the option to switch to that tab. Perfect for those of us who end up with 50 tabs by lunch time.

It also just feels tighter and less intrusive on the web browsing experience.

Continue reading “Things You’ll Love About Firefox 4.0”
Categories
Around The Web Funny Web Development

Enterprise CSS/JS/HTML

Here’s a fantastic trilogy of websites: Enterprise HTML / JS / CSS.

What makes them so brilliant is that they are actually 100% true. I spent a summer cleaning up just this type of stuff. It’s true, it’s out there, it’s painful.

Categories
Mozilla Web Development

Optimizing @font-face For Performance

You want to use @font-face, then you realize it’s got some downsides. First of all, it’s another HTTP request, and we know that the golden rule of web performance is to keep HTTP requests to a minimum. Secondly fonts aren’t even small files, they can be 50k+ in size. Lastly the lag of fonts loading last means you page seems to morph into it’s final form.

Here’s a cool little optimization. By using a data: URL you can use the font inline by encoding in base64. For example:

@font-face {
    font-family: "My Font";
    src: URL("data:font/opentype;base64,[base-encoded font here]");
}
 
body {
    font-family: "My Font", serif
}

You can see this in action here. This seems to work fine in Firefox 3.5, and Safari 4 (presumably any modern WebKit based browser). Other browsers will simply act as if they don’t support @font-face.

In practice I’d recommend putting it in a separate stylesheet rather than inline CSS so that your pages are smaller and CSS can be cached for subsequent page views.

Data URL’s are part of Acid2, which most modern browsers either pass or plan to pass. If you use an Open Type font you’d get pretty decent compatibility (IE only supports Open Type). Using True Type you’d still get pretty good compatibility sans IE. Check the @font-face page on MDC for more details. Unlike images, browsers that support @font-face are likely to support data: URL’s as well, making this a pretty good solution.

Special thanks to Open Font Library for having some nice free fonts with awesome licensing. This post was partially in response to a comment left the other day on my @font-face hacks blog post.

Categories
Mozilla Web Development

@font-face Hacks

I’m going to make a bold prediction on the night before a certain web browser is scheduled gets an upgrade. @font-face (MDC) will change web design, but not just for typography. As I suggested a few days ago, to use a font on the web it needs to sit on a webserver so the browser can download it, hence the website is “distributing” the font. Licensing for many fonts doesn’t currently permit this, making @font-face for fonts somewhat problematic and hard to use… at least today.

Cool Trick!

Rule #1 of Steve Souders popular book “High Performance Web Sites” is simply:

Make Fewer HTTP Requests

That said, @font-face can be essentially as an image sprite by creating your own font with the glyphs you want. Unlike image sprites they aren’t hacky in nature requiring tricky coordinates, nor are they obnoxiously memory intensive (and a drag on mobile devices). Firefox also loads fonts last, so you can be assured it won’t slow down the rest of your page. They also degrade nicely for devices that don’t support them.

Of course this changes webdesign to use simpler icons and pick 1 color per glyph… but there are some pretty interesting enhancements for example the ability to scale. Fonts are designed to resize much better than an image.

The other caveat is that this can make your markup slightly ugly. However it’s not so bad when your building something in JavaScript. Consider for example implementing Pac-Man. Rather than a dozen images, or some complex sprite you can simply move <em>p</em> around. You can have quite a few glyphs in 1 font file.

Of course you can also use <canvas/> or a data: URL to embed images, but IE doesn’t support <canvas/> and only recently started supporting data:. IE has supported OpenType (not TrueType) fonts since IE 4.

I’d be curious if anyone actually implements this and how well it works in practice. It’s not a true replacement for image sprites, but for a few cases, such as simple icons, it could actually do the trick.

Um What?

This trick can also be engineered to work against the way the web traditionally works. For example, I could create a ROT13‘d font or any other encoding I imagined. This essentially lets you remap the way characters are on the page, and the way they appear. For example on the page may appear:

<span class="rot13font">rknzcyr@qbznva.gyq</span>
<small><strong>Note:</strong> Do not copy/paste my email address</small>

That looks like a totally invalid address, but with a ROT13 font, you’d know what it is… though if you copy/paste it you’re going to get the encoded version. (I could in theory course engineer some JS to ROT13 the string). This also could deter some spam bots, which lore says have found ways around JS munging.

Conclusion

Moral of the story: @font-face can be fun for more than just typography. Cult of Helvetica be damned… all you typography geeks.

Categories
Internet Web Development

Printable Stylesheets To Save The Environment

Printing is a really wasteful process. The obvious waste is paper, ink, and of course money. The less obvious waste is the carbon footprint of printers and making paper/ink.

The internet is a notorious waste of paper. One could argue there’s no need for printing online content since you could easily save it either as text, the entire page, or print to a PDF file (my personal preference). The main source of waste is due to the design of the page resulting in sometimes several useless pages and 1 page of useful content. The rest of them simply go in the recycling bin, or worse the trash. Some clever users preview first and only print the pages they want. Most just print.

There are a few software products out there that try and reduce the amount of wasted printing such as GreenPrint, though it requires installation, companies hate buying site licenses for this type of stuff, etc. Personally I think they are a pain and prefer to do it myself.

If every site were to include a printable stylesheet, the number of wasted pages would drop dramatically.

Without a printable stylesheet a short post on this blog would take 3 pages to print out, 2 of which were worthless navigational elements. The pages are also awkward to read. With a printable stylesheet the output not only looks nicer but is reduced to 1. That saves ink, paper and sanity.

Separate printable pages suck. They are so 1999. Nobody goes there anymore and they often drop content such as images which you may want to have.

When you look at some of GreenPrint’s statistics you can’t help but wonder how much would be saved if more sites had printable stylesheets that tried to reduce the amount of unnecessary printing is done. I’d guesstimate just getting rid of some useless design elements in printable output could likely reduce the amount of ink consumed by 30-50%.

For developers looking to get started A List Apart has a great tutorial on them. Most developers know how to do it, but printable stylesheets become an afterthought in the development process.

Categories
Around The Web Google Mozilla

Secrets In Websites II

This post is a follow up to the first Secrets In Websites. For those who don’t remember the first time, I point out odd, interesting, funny things in other websites’ code. Yes it takes some time to put a post like this together, that’s why it’s just about a year since the last time. Enough with the intro, read on for the code.

Continue reading “Secrets In Websites II”
Categories
Mozilla Open Source Programming

Benchmarking And Testing Browsers

When people talk about open source they often talk about the products, not the process. That’s not really a bad thing (it is after all about the product), but it overlooks some really interesting things sometimes. For example open source tools used in open development.

A few months ago Jesse Ruderman introduced jsfunfuzz, which is a tool for fuzz testing the js engine in Firefox. It turned up 280 bugs (many already fixed). Because the tool itself is not horded behind a firewall it’s also helped identify several Safari and Opera bugs. It’s a pretty cool way to find some bugs.

The WebKit team has now released SunSpider a javascript benchmarking tool. Something tells me this will lead to some performance improvements in everyone’s engine. How much will be done for Firefox 3.0 is a little questionable considering beta 2 is nearing release, though you never know. There’s been some nice work on removing allocations recently. So just because it’s beta, you can’t always assume fixes will be minor in scope.

Another test that many are familiar with is Acid 2 which essentially is checking CSS support among browsers. Ironically this one too was released when Gecko is somewhat late in the development cycle.

Efforts like this really help web development by allowing browser developers to have a baseline to compare their strengths and weaknesses. Having a little healthy competition as motivation can be pretty helpful too 😉 .