Snook.ca

Changing Display Resets Scroll Offset

jonathan@snook.ca (Jonathan Snook) — Thu, 10 Jun 2010 14:49:49 PDT

In Chrome 5, Safari 4, Opera 10.53 and sometimes Firefox (although I was unable to reproduce it in this test case), changing the visibility of the element by toggling display:none will cause the scroll offset to reset to zero. Toggling visibility:hidden does not seem to trigger the same problem.

Scroll the container and then toggle the classes applied.

Class applied:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

I haven't tested this in Internet Explorer, yet. Feel free to report in the comments.

Handling Active State for jQuery Animated Backgrounds

jonathan@snook.ca (Jonathan Snook) — Thu, 27 May 2010 00:24:44 PDT

Awhile back, I wrote an article on how to animate background images with jQuery to create some nifty effects. One of the most common questions I receive on that article is, "How do I handle active states?" It is time to answer that question.

There are two ways in which you can handle the active state:

Create a different animation for active elements; or
Change the background image to be animated.

The HTML

The HTML for this is exactly the same as before except an active class would be applied to the LI. You can add the active class to the link, if you wish. You just need to update the code below accordingly.

<ul>
  <li><a href="…"></a></li>
  <li class="active"><a href="…"></a></li>
  <li><a href="…"></a></li>
</ul>

Different Animation for Active Elements

This should hopefully be very straightforward: just create two sets of animation. One will animate on any element that is not with an active class and another will animate on any element that does have an active class.

$('#nav li:not(.active) a')…
$('#nav li.active a')…

The rest of the code will be tailored to handle the animation however you wish.

Change the Background Image

This is by far the more optimized of the two solutions as the amount of additional JavaScript required is absolutely zero but is based on the assumption that the animation will be exactly the same.

All that needs to be done is to have the background image set to something else for the active state.

#a a { background:url(bg.jpg) repeat -20px 35px; }
#a .active a { background-image:url(bg-active.jpg); }

And that's it!

Filling in the Gaps

jonathan@snook.ca (Jonathan Snook) — Mon, 17 May 2010 00:38:22 PDT

HTML started as a very simple language. By many accounts, it's still very simple. You create some text and you wrap some tags around it. The tags provide a small measure of meaning and allow user agents—aka browsers—to present the content in a meaningful way.

In the early days of the web, browser developers quickly added features that helped web developers build more exciting sites and applications. Tables, font tags, and images gave us a decent amount of flexibility to create the sites we wanted. We even had this fancy thing called "JavaScript" that allowed us to interact with the page in basic ways.

One Plugin to Rule Them All

One notable addition was the embed tag (and the applet and object tag after that). It's notable because it recognized that browsers could not do everything. From this sprung forth slow and cumbersome Java applets, Shockwave 3D, Real Audio streaming and more panaroma plugins than you could shake an animated trailing cursor at. Adobe Flash, née Macromedia Flash, was born in this era.

At this point, one of the largest problems for web developers was ensuring that site visitors had the necessary plugin installed. Otherwise, it required users to download it, install it, and restart their browser. Requiring this complicated process just to view your web site meant that fewer people would take the time to complete the task.

Impressively, the Flash player began to be bundled with browsers. Flash, above all else, became nearlyubiquitous with statistics showing the Flash Player being available on 99% of all Internet-enabled desktops. As a web developer, you now had technology that you could rely on almost as much as HTML but with a lot more power. At the turn of the millenium, even CSS was still gaining traction.

It's important to note that Macromedia (and Adobe) did not rest on its laurels. They continued to fill the gaps of what the browser could provide us. Between then and now they've managed to offer useful features such as cross-domain requests, local storage, binary sockets, multi-file uploads, and shared objects. On the animation front, there are 3D effects, inverse kinetics, and pixel bending. On the streaming side, there is support for multiple codecs, full-screen playback, and dynamic streaming. Flash also allows for screen, audio, and webcam capturing, as well as peer-to-peer connections.

Yet, Flash has turned into an annoyance for many consumers. Garish advertising is strewn everywhere; large, slow and confusing animated site intros are unnecessary glitz; deep-linking to content is often impossible; and normal browser features like keyboard navigation aren't available.

Flash's downfall, however, has more to do with those wielding its power—the web developers and designers who misuse it—and less to do with the technology itself.

Shifting to the Browser: is HTML5 the saviour?

First, a small apology: I'm lumping a bunch of technologies under the umbrella of HTML5 for succinctness. I hope this isn't too confusing.

These days, browser developers are moving quickly to add new features; many—but certainly not all—of which compete with Flash. There is canvas, SVG, CSS-based animations, web sockets, local storage, multi-file uploads, and native video and audio.

These new features do negate some of the need to use Flash; however, I'm reluctant to think that these few features will be the death of Flash. There are simply too many use cases out there for which HTML5 does not serve. Hulu's reluctance to embrace HTML5 is very much case in point. Chat Roulette would be another. Or tinychat. Or Adobe Connect.

HTML5 just doesn't have the same breadth of features as Flash. That's not to say browsers won't get there someday. It's just not there, yet.

What of the mobile web?

The biggest question these days is, "what about the mobile web?" Or more specifically, "what about the iPhone or the iPad?" (Or Android, but it looks like they're going to have Flash soon enough.)

For the most part, I have not missed Flash. Sites have provided non-Flash alternatives or I have been able to rely on native applications to fill the void—such as with games or other applications more likely to be found in a native desktop application than on the web.

Apple certainly isn't hurting right now by pushing developers onto their native development platform. When you look at the current use cases for the mobile web, many of the features in Flash just aren't as necessary.

Yet, these devices are designed to render the web as if it was a desktop browser. Many sites are unfortunately created for the desktop with Flash as an expectation—they expect Flash to be ubiquitous for they were made in a world that predates the iPhone or the iPad. My dentist's web site is all Flash and unviewable on the iPad or iPhone. My massage therapist's web site is all Flash and unviewable on the iPad or iPhone.

Apple runs the risk that the Flash platform—combined with the right mobile device and proper access to the underlying hardware—could provide incentive for developers (and consumers) to shift their focus, time, and money to platforms other than the iPhone or iPad. Build once, run everywhere (or at least, as many places as possible) while also supporting what already exists on the web.

Our duty

As web developers, we should choose the best tools and technology for the job. To do otherwise—out of ignorance or some duty to "web standards"—is a disservice to the clients and customers we serve.

Right now, HTML5 is slowly becoming a viable alternative to Flash for a greater variety of situations. However, Flash will continue to fill in the gaps for years to come because it continues to solve problems that web developers have and that can't be solved with any other client-side technology.

Vendors using Competing Prefixes

jonathan@snook.ca (Jonathan Snook) — Tue, 11 May 2010 07:39:00 PDT

IE Mobile for Windows Phone 7 has decided to implement support for -webkit-text-size-adjust. They'll also be adding their own duplicate vendor-specific prefix, -ms-text-size-adjust. That's right, Microsoft will be adding support for another vendor's non-standard implementation.

Is this good or bad? The general consensus on Twitter would indicate that this is a bad thing but while there is a scenario where this could go terribly wrong, I haven't found a real world example to back it up.

So why is this a bad thing?

Vendor-prefixed implementations may change

The point of a vendor prefix is to avoid a situation where an implementation changes before becoming a standard, thereby breaking all sites that come before it. This is a good thing. A vendor can continue to revise the syntax under a prefixed property without breaking things when they finally do become standard and implementations drop the vendor prefix.

If a competing vendor implements a vendor prefix, they run the risk that changes to the competing browser will then break their implementation. For example, if Webkit changes how -webkit-text-size-adjust works then Microsoft will be in a tough situation because their implementation will break. The problem is, any developer who implemented -webkit-text-side-adjust before the change will also find their implementations broken in newer versions of the browser.

Has there been a situation where a browser has changed the syntax on a vendor-prefixed property that has broken previous implementations? I can't think of any but feel free to chime in on the comments.

Of note, browsers have implemented syntax changes on non-prefixed properties like background that have broken previous implementations. Multiple backgrounds, for example, break on browsers that don't support it, requiring the background property to be specified twice. (The situation is exacerbated by the fact that vendor-prefixed properties in multiple backgrounds will be ignored in other browsers, requiring backgrounds to be specified three or four separate times to support all current browsers.)

Mimicking another vendor's prefix is like using no prefix at all

This argument is a misdirection and not the case at all. If every browser implemented a single vendor's prefixed property then the property would become standard and the prefix would be dropped. For example, imagine -moz-opacity was implemented by all browsers before becoming standard. The property becomes opacity and we all move on. I'd prefer this over -webkit-opacity, -moz-opacity, -o-opacity and opacity all having to be set.

It's perfectly possible for all browsers to agree on an implementation using a prefixed property before re-implementing it with a non-prefixed standards-based property. The simpler the syntax, the easier it is to expect that the implementation won't change. The -webkit-text-size-adjust property is a perfect example of this. It's very simple and extremely unlikely that the implementation will change.

Implementations may change but syntax won't

Sometimes browsers don't get the implementation correct. Border radius is a prime example of this. Firefox 2, for example, had a problem with their implementation that caused the rounding to be unbalanced. (I recall Happy Cog having an issue with this when working on the WordPress admin a couple years back; I can't find the article, though.) Had another browser implemented it like Firefox, the implementations would no longer match.

This situation is a little different because of expectations. In this case, the implementation had a bug. This wasn't a style preference or syntax issue. It was a bug in how a particular edge case was rendered.

Border-radius implementations across all browsers still don't match the specification in a lot of edge cases (something that IE9 is looking to address; my apologies if Opera has already done this in 10.5).

This is a grey area and I can see good points and bad points against this. The question is whether a feature is implemented by a web developer based on the expectation set forth by these edge cases. For example, if I expected all browsers to overlap border corners to compound transparency values then I'd be terribly disappointed when this started to get fixed in subsequent implementations.

In this last case, how does one browser mimicking the implementation of another change this situation? I'm not sure it does.

It's like -beta prefixes and that's bad

A -beta prefix had been bandied about on the W3C style list where browser developers and the public at large discuss CSS implementations. The problem with the -beta prefix is that it prevents versioning of a particular feature. Right now, vendor prefixes essentially act as a versioning process. One browser implements it using Syntax A. That's version 1. Other browsers ponder it and implement it using Syntax B. That's version 2. The vendor prefixes for each browser acts as the versioning system.

In the case of something like CSS gradients, browsers have implemented different vendor prefixes: -webkit-gradient versus -moz-linear-gradient and -moz-radial-gradient. The syntax may be different but so is the property name which essentially means that they are two separate implementations. Microsoft could theoretically implement both syntaxes and still not break anything.

Theoretically and hypothetically speaking

We often argue based on extremes to prove a point but the practicality of the matter is that this particular implementation of the -webkit-text-size-adjust property in IE Mobile isn't really a big deal and is unlikely to affect developers to any extent.