Archive for September, 2012

Establishing An Open Device Lab // Mobile Testing


  

Managing a personal device lab can be quite hard with an ever expanding number of devices. It’s not only expensive, but also bad for our environment. Think of a situation where every Web developer would purchase a large pile of gadgets and keep adding new ones as they are launched — this wouldn’t make much sense. Thankfully, there are better ways to handle the problem.

During the spring of 2012, Jeremy Keith wrote on his website that anybody is welcome to visit their device lab at Clearleft’s office in Brighton, UK and use their devices. What they didn’t expect, though, was that in response many local developers offered to add their own devices to the collection as well. Two weeks later Jeremy Keith and Remy Sharp also presented this idea at the Mobilism conference in Amsterdam and the people attending loved it. A few months after Mobilism, similar labs started popping up in places like Amsterdam, Berlin, London and Malmö.

Following this example, we decided to bring our own devices to the Kisko Labs office and do the same thing in Helsinki. We now have an open device lab where anyone can come, start using the devices and contribute by lending their old devices. Three weeks after establishing this we already have three new devices from the local community: a Nokia N900 running Maemo, a Nokia Lumia 800 running Windows Mobile and an HTC Desire HD running Android. I have also been in contact with the device manufacturers and so far at least Nokia, Palm and Sony have promised to help us out with the lab.

Helsinki Open Device Lab
Helsinki Open Device Lab, opendevicelab.com.

I encourage everyone to do the same thing in the city they live in as well. This article will cover most of the things needed to be considered when doing that. It will also work as a guide and give practical tips — things like location, how to get devices, what devices to get and what software to use. At the end of the article is also a list of all the current open device labs around the world.

Location

This is probably the hardest part as it should be relatively open, easily accessible, but also a safe location to prevent burglars. I wouldn’t be too worried though as that’s a risk you need to take with any office space that’s filled with desktop computers and other gadgets. Just make sure that the space has proper locks and an alarm system in place.

Mozilla’s workspace in London
Mozilla’s workspace in London. Image by @mozillaeu.

Finding a location was never a problem for us as we had a space at the office which wasn’t used that often, but I understand that it might be hard to find one unless you already work in a location like that. However, I imagine that the best places to start asking are local Web community meet-ups, conferences and Twitter. Find out about local co-working spaces too, as those could be the best candidates to host these kind of projects. I also asked Shaun Dunne (who established the London Device Lab) if he had any advice on how to find a space, and this is what he answered:

“I was in the Reasons to be Appy conference during April when Christian Heilmann mentioned Mozilla’s new London office and how it had a co-op space with free WiFi for anyone to use. I spoke to him after his talk and mentioned what I was trying to do and he said that he thought Mozilla would be more than happy to host it. He said I should speak to @cyberdees who runs things in the office. We exchanged a few emails and I went there a couple of times and it was born from there.”

Devices

You don’t need a huge collection of devices to establish a lab — it can initially be small and grow once other developers start contributing their devices. Some device manufacturers are also willing to help the community by providing test devices for initiatives like this, so you should definitely contact them too.

There are basically four main areas that need to be covered in the lab. These are: feature phones, smartphones with low level support, smartphones and tablets. Later on you might also want to consider adding a Smart TV and other more exotic devices like game consoles. Additionally, the lab should also efficiently cover various screen sizes between 240 x 320 and 1280 x 800 pixels, as well as some high-DPI variants.

PhoneGap’s Device Wall
PhoneGap’s Device Wall. Photo © 2012 Adobe Systems Inc.

David Blooman from BBC recently shared the process that they use while testing on mobile devices, and the minimum set of devices to get the job done. This list is a slightly modified version of their minimum test device stack. For now it is a good starting point for anyone who is thinking about setting up an open device lab:

  • iOS 5 — iPhone 4
  • iOS 6 — iPad 3 Retina
  • Android 2.2 — HTC desire
  • Android 2.3 — Huawei U8650
  • Android 2.3 — Kindle Fire (Silk browser)
  • Android 3.X — Motorola Xoom
  • Android 4.X — Samsung Galaxy Tab 2
  • Blackberry OS 5 — Curve 8900
  • Blackberry OS 6 — Bold 9700
  • Windows Phone 7.5 — Lumia 800
  • Symbian S40 — Nokia 2700
  • Symbian S60 — Nokia N95
  • Symbian Belle — Nokia 500

Remember: You will want to end up with a collection that represents the audience and overall market share in your own location, which might be different from what I have listed here. Stephanie Rieger, who is a co-owner of Yiibu, has written an excellent article explaining Strategies for choosing test devices (so be sure to read that to find out more about the subject). Dave Olsen has also written an article about how to build a device lab, where he explains how and why they decided to get certain devices.

“If I had to start from nothing, I would start with the phone in my pocket. After that, I would take the usual suspects — Android 2.3, iOS5, etc., and make sure to have the more popular phones in place, but not go overboard. One of each to begin with, and then more varieties as time goes on. In a good way, everyone’s device lab should be different, as every market is going to have variations. There is no golden list of devices.”

— David Blooman

How To Contact Device Manufacturers

  • You will need to have a space and a website (a single-page website is fine) for the lab before asking for any devices. Otherwise, it may be hard to look convincing.
  • Twitter and email seem to be the best way. Look for developer relations accounts like this from Twitter and send emails to their developer related addresses. You can find the addresses from the developer websites, which usually reside in an URL formed like this: developer.manufacturer.com.
  • Ask people on Twitter if they know someone who works at one of the companies you are trying to contact. It may be an easier way to begin communicating with the right people.
  • When sending emails, explain carefully what the project is about, what you need and why you need it. It’s good to keep it short and get straight to the point.
  • Remember that you are sending emails to other human beings, not to some random corporations.
  • If you don’t get any answer from them within two weeks try to contact another person from that manufacturer.
  • Last but not least: Don’t be afraid to ask for help. I contacted several people about their test devices and where they got them from. Shaun Dunne (from the London Device Lab) was also kind enough to provide his perspective on how to contact the manufacturers:

“I started hitting the developer relations people up on Twitter. BB and Palm got back to me via Twitter and an email conversation went on from there. Nokia had their developer relations person at Mobilism, so I found out his email and sent him an email directly. It’s about being persistent, really, email is hard because it could end up in their spam or they can ignore it.”

“In a public forum like Twitter it’s harder for them not to engage. Don’t just go after the hardware manufacturers either, it’s worth speaking to the Android + WP7/8 people to see what they can do for you. If they want people to develop applications and websites that work on their devices, then it’s in their best interests to get those devices in developers’ hands. The best and easiest way to get the devices in their hands is through a community lab.”

Setting Up The Lab

You don’t need much in the beginning: a table, a few chargers and a Wi-Fi connection is all you need to get things up and running. If you have more than five devices, it may be a good idea to get a USB hub which can provide power to avoid cable clutter and stands where you can put the devices on. A few of the labs have also built their own stands and you can get some ideas from the resources listed below. Jeremy Keith also told me that they have all the devices running through a wall socket that’s on a timer which switches the power off in the evening and nighttime and back on again in the morning. That might be useful for saving some energy and also to keep the batteries healthy.

64 Digital’s device testing station
64 Digital’s device testing station. Photo © 2012 64Digital.

Later on, when there are many more devices in the lab, you may want to start considering getting a better wireless router which can handle all the devices. Andre Jay Meissner told me that Apple’s Airport Extreme can handle up to around 30 devices, but not much more (it claims to support 50!). SIM cards with data plans are also something which you might need once you start adding older devices that exclude Wi-Fi.

Software Tools To Get You Started

Adobe Shadow: Probably one of the best tools for testing at the moment. It allows device pairing, synchronous browsing and remote inspection using Chrome extension on either Mac or Windows. To be able to use Adobe Shadow you will need to download and install the mobile client to all test devices. In addition, you will also need the Google Chrome extension to run Shadow on your laptop.

Adobe Shadow running on multiple devices
Adobe Shadow running on multiple devices. Photo © 2012 Adobe Systems Inc.

JS Bin: JS Bin is a Web app specifically designed to help JavaScript and CSS folks test snippets of code, within some context, and debug the code collaboratively. You can use JS Bin together with the Adobe Shadow mentioned earlier.

Web Inspector Remote: Weinre is a remote inspector tool for WebKit browsers. It has been included in the Adobe Shadow application, but you can also set up your own installation to be able to use it on platforms like WebOS and Blackberry (in addition to the iOS and Android platforms).

xip.io: xip.io is a domain name that provides wildcard DNS for any IP address. You can use these domains to access virtual hosts on your development Web server from devices on your local network (like iPads, iPhones, and other computers).

Showoff.io, Localtunnel, Proxylocal: For sharing your localhost over the web.

Mobile browsers: Remember to install various browsers like Opera Mobile, Opera Mini, Chrome and Firefox to all of your supported test devices.

“Be sure to track the OS versions found on your test devices, and think carefully each time you upgrade. Owning four BlackBerry devices with four different versions of the OS is infinitely more valuable than owning four with the same version.”

— “Strategies for choosing test devices” by Stephanie Rieger.

Maintenance

There are some running expenses — rent, Wi-Fi, personal time used — and you may initially need to spend a few hundred bucks to provide chargers, wires and stands for the devices. So it’s worth considering if a small monthly payment would be acceptable. As it also might not be possible to find a space which is completely open like the one in London, it’s possible to have everything available by appointment too. This seems to be quite common practice and it allows you to use the same space for your own workshops as well, if needed.

In the beginning, when you are setting up the lab, I wouldn’t worry about all of this though. It’s possible that the lab will get popular and have lots of visitors and that someone might be using the devices when someone else comes in, but only time will tell. Shaun Dunne also said that they were discussing this very same problem in the beginning and decided finally that the lab should just be open. Jeremy Keith seems to think in a similar manner:

“When I started the device lab in Brighton, I didn’t worry about the paperwork. Instead of worrying about insurance, theft, liability and all those other worst-case scenarios, I decided to just do it and deal with the bad stuff if and when it arises. So far, so good.”

Closing Words

I believe in testing on real devices. Software emulators and simulators can be useful, but in the end they can only do that; simulate the experience (as Paul Robert Lloyd points out). To make testing on real devices possible for everybody, we need open device labs. If your city doesn’t yet have such a lab, I would say go for it, establish one. Don’t worry about the amount of devices you start off with, you’ll be surprised about how much the community is willing to help.

Last but not least: just a few days ago, while writing this, Andre Jay Meissner contacted me about the possibility to set up LabUp!, which would help people around the world in establishing nonprofit Open Device Labs. I think it’s a splendid idea and everyone who can help should join the movement.

Open Device Labs Around The World

This list is by no means complete, but it should include all the labs which were established before this post was published. For the future you should bookmark the up-to-date list of all open device labs which Jay is collecting.

(jvb) (il)


© Viljami Salminen for Smashing Magazine, 2012.


The Shelf Wallpaper for iPhone 5

After updating my grid wallpaper for the new display of the iPhone 5, I'm glad to announce that an updated version of the Shelf wallpaper is now also available. However it's not just a larger version of the same old wallpaper… I also included three new flavors: washed out, dark and light. Hope you enjoy.

Grid Wallpaper for iPhone 5

Hey guys. I just updated my popular grid wallpaper for your brand new iPhone 5. Make sure you grab it while it's hot :)

It’s Not All Doom And Gloom On The Web // Opinion Column


  

In this article I’d like to discuss the changes happening on the Web and argue that its future is not as problematic and endangered as a lot of people make it out to be. The article is based on the talk I’ve presented at the Smashing Conference a couple of days ago, and you can also see the slides and watch the screencast (see below).

I have been developing websites professionally for the greater part of the last 15 years, and written quite a few books and a lot of articles. Yet when I look around right now, I do feel incredibly… stupid and wonder if I should hang up my coat and do something else. Almost daily we see new tools, new best practices and systems to use, and a lot of them are very far removed from the original Web development technologies that are defined by the standards bodies.

I am also very confused about the message of doom and gloom we have right now about the Web. Many spokespeople look at the sales numbers of smartphones and call us out for not doing enough to keep developers interested and to get newcomers to start on the Web rather than somewhere else.

To me, not everything is doom and gloom, and the Web isn’t losing. I am actually very excited about what we are doing on the Web, and I see a lot of great things happening right now. I look back at what I had to work with in the past and see how professional and rich our development environments are now, and I am very happy indeed.

So, what happened? How come I am excited about the Web and its immediate future, while others feel an urge to protect it from certain doom?

Ubiquity And Speed Of Innovation

Two of the problems we see right now are ubiquity of technology and connectivity. The Web is not the cool new thing any longer. Instead, everybody seems to be on it and using it all the time — not like we did in the past with a desktop computer and browser, but through apps and short updates in social media.

Another issue is the speed of innovation. Almost monthly, something exciting comes out that makes the last big new thing seem boring and unwieldy.

One thing is that we perceive constant new demands from our end users and people who spend money on marketing in our environment. A lot of this is just people repeating things they’ve heard — suspension of disbelief. A video is going around of people being handed an iPhone 4S and being told it is the new iPhone 5. What did they think of it? Nearly all of them found something extraordinarily cool about it and said it is better than the last one — even people who owned the same version!

Of course, in getting excited about these cool new things, a lot of us say that everyone these days has these cool devices and new technologies and that we need to keep up. As Thomas Fuchs puts it:

“Let’s put this in context: mobile Internet usage has doubled last year, and right now about 20% of all Web traffic in the US is from mobile devices. This means Retina screens will soon become the norm.”

It is a very myopic way of thinking, though. The Web is worldwide, and first of all, only a few of us can afford these devices. Secondly, a big chunk of us cannot get these devices where we live. Thirdly, people forget that when the initial investment hurts, people don’t want to replace their hardware a few months after. Not to mention that high-speed connectivity is not as ubiquitous as we consider it to be, especially for mobile devices.

Don’t Always Trust The Web

We seem to be not quite at ease with what we are doing at the moment, despite the fact that our job market being ridiculously good and that we get paid very well for a relatively easy job. Instead of considering this, we constantly measure ourselves against success stories that have been inflated by tech blogs that exist to inflate such stories. Or, as Steve Furtick puts it:

“The reason we struggle with insecurity is because we compare our behind-the-scenes with everyone else’s highlight reel.”

At TechCrunch Disrupt, Mark Zuckerberg was interviewed, and in the immediate coverage by the tech press, he was quoted as saying that HTML5 was a big mistake. The quote that was repeated all over went like this:

“I think that the biggest mistake that we made as a company was betting too much on HTML5 as opposed to native, because it just wasn’t there.”

The interesting bits, though, were ignored in the coverage:

“It’s not that HTML5 is bad. I’m actually long-term really excited about it. And one of the things that’s interesting is we have actually more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So, mobile Web is a big thing for us.”

It seems that the main failure was Facebook’s approach to and internal system for creating HTML5 apps — not the technology itself:

“But there’s no doubt that we went for this approach, we built this internal framework that we called Faceweb, which was basically this idea that we can take the infrastructure that we built out for pushing code everyday, not having to submit to an app store, building Web code on the Web stack that we have, and that we can translate that into mobile development. We just were never able to get the quality of it we wanted…”

It seems to me that the path to keeping your sanity in this world of ours is not to care about the shouting news outlets that need clicks to make money.

It’s All About Hardware

A few things are going wrong right now, and most of them are related to the fact that we emulate native apps and the practices of thick client development, rather than embracing the fact that the Web is a different challenge. Yes, it is software. No, it is not a defined platform with established processes.

There is a secret behind all of the failures of HTML5 in the mobile market, and it is actually very annoying: it is all about the hardware.

We can innovate HTML5 until we are blue in the face, and we can optimize browser performance to reach rocket ship-level speed, but if the hardware and operating system providers don’t allow us to be on their hardware or give early access, then there is no way browsers can perform as well as native code.

When you think about it, most of the money on mobile devices comes from app sales. And the Web gets in the way of app sales as they exist now. So, there is not really much incentive to make Web apps perform well or access all of the good parts in the hardware because then developers wouldn’t have to become part of a vendor’s program or pay to get access to their sales platform.

The lack of drivers that would enable apps written in Web technologies to access the whole hardware is the biggest issue. This even affects laptops and desktop machines — a lot of WebGL cannot even be used in brand new computers.

Firefox OS
Firefox OS will be the first truly open operating system for mobile devices. Image credit.

Mozilla is going full force right now to change this dilemma. Firefox OS will be the first truly open operating system for mobile devices. Underneath the hood of Firefox OS are the Web APIs: open-source drivers with JavaScript interfaces to access all of the hardware of the phone.

The Beautiful Side Of The Web

But that is by the by. Let’s go back and see why the Web actually is a great idea for us to work with. Mozilla Webmaker (which I’m involved in) is an ongoing project to turn pure consumers of the Web into makers. We teach basic Web editing skills, how to publish and mix video with online content, and basic ways to keep safe and have a good time on the Web. Attending one of these events is not only humbling but incredible. It is amazing to see how things that we consider boring and “common knowledge� make people go crazy for creating and doing things they haven’t done before.

A lot of the frustration we see stems from people — us included — having forgotten the main principles that the Web is based on. I am right now reading New Model Army by Adam Roberts, a science-fiction book about a war in England between the traditional army and the New Model Army, a group of mercenaries organized via the Web and wikis.

Mozilla Webmaker
Mozilla Webmaker is an ongoing project to turn pure consumers of the Web into makers.

The main difference of the NMA is that there is no hierarchy — everything is voted upon and decided on the spot. They are almost impossible to defeat because they move much faster as a result of not having to wait for orders from above. They are also professional soldiers, there to fight other soldiers without any ideological or national interference. All they defend is the right to be truly democratic in their decision-making.

The Starfish and the Spider is another book that talks about a principle that makes the Web what it is. It explains that organizations without a single point of failure are much more likely to succeed than those that have a massive hierarchy and are likely to be crushed by their own size. App markets are those things.

One of the main issues, though, is that the Web exists, driven by the open and free technologies that we advocate. It works, and it has outlived many of the other closed technologies that were always heralded as its end. But this is not at all a time to sit on our laurels. There is no doubt that the Web has lost a lot of its appeal to new people.

Partly this is because we’ve become mainstream. The Web is not the edgy cool new technology that we can play with any way we want. We have to consider that mainstream media is powering a lot of it with advertising and cross-promotion of real-world events and products. Thus, we should be in the productive phase of the hype cycle, but somehow we’ve missed this point and are still struggling to find a way to turn over a lot of products without reinventing.

One big challenge is to rethink the tools we have. As Lea Verou put it:

“I often think that command-line editors like Vi and Emacs were made by sadists who enjoy making people feel stupid, frustrated and helpless.”

Whenever we talk about the Web, sooner or later the talk is about text editors and writing a lot of code by hand. We should be better than that by now, and we should make it easier for anyone to create on the Web.

The success of other platforms with new developers is that they are simple to learn. You are in a fixed environment, you get a few Lego bricks to play with, and you can build your first thing.

Old Tales Of The Web

Instead of concentrating on being as fast on our feet, we keep boring people with the same old tales of how the Web came around and how HTML got better and we can add semantic value with microformats, and many other tales of yesterday. In a world where all browsers run the same incredibly forgiving parser, talk about the purity of HTML and semantics falls on the deaf ears of those just starting out, and it is actually a deterrent. We’ve failed to make semantics matter — microformats are a great idea, but when no browser does anything visible or useful with them and they don’t bring any benefit with search engines, then they are superfluous to people who just want to publish their work.

When HTML5 got defined, we should have been quicker to get our needs and demands in. If you think about it, the JavaScript part of HTML5 is incredibly powerful, but the semantics are not that amazing. We knew we wanted to move the Web from text to apps, but we failed to define the necessary widgets. Instead we got elements that were defined as a result of analyzing which classes people used in their HTML in the past. Most app-style widgets were created with JavaScript and had no classes at all because not many libraries enhanced progressively. Even now, we don’t help browser makers or demand better support for rich forms.

We’ve even failed to think about a packaged format for an HTML5 app. Portability means that we have installers and de-installers, instead of running an app in a browser. Right now we have no one-size-fits-all approach to that. The W3C widgets were not the right format, so Chrome, Mozilla and PhoneGap all came up with their own formats instead.

Outside the world of those who want to crack the app issue, we flee into a world of abstractions. We build preprocessors for CSS, and we build JavaScript libraries that make it easier but that also completely replace the syntax of JavaScript with their own, and we applaud all of these efforts and call them solutions without knowing whether they’ll be supported in future. A lot of them have come and gone without leaving much of a footprint. Maybe it is time to recognize that moving up levels in a building doesn’t mean that the water damage on the ground floor won’t be an issue sooner or later.

We’re always so proud of the portability of our Web technologies and that they are so easy to learn and use and that they adapt to whatever you throw at them. But when you look at it from an outsider’s point of view, a lot of what we do is not portable or reusable. Every single HTML slide system is a great example of that. Or try sending an HTML file to someone who doesn’t know HTML — they’ll open it in Word and everything will break.

And we don’t help the cause much. We repeat the mistake we’ve make in the past of building solutions for one browser or demanding that the end user turn on things and change their setup. Many open solutions demand that the user takes five steps where one installer would be the right thing, and we expect people to like setting up a lot of tools using the command line. This doesn’t help us win against closed technology.

Getting Out Of The Comfort Zone

How do we win back the hearts and minds of developers? I think we need to create new products and take different approaches than we have in the past. We should focus on making things easier for people, not striving for purity and delivering like we have in the past. We need to leave our comfort zone, because that is when the magic happens.

Bret Victor’s “Inventing on Principle� talk is a great start for this. Bret’s big principle is to enable creation by making the step from creating to seeing the results as short as possible. He shows off a few tools that not only are WYSIWYG but that work in both directions. You write a game by playing and adjusting the position of the player along a timeline. Thus, your testing happens while you develop.


Bret Victor on “Inventing on Principle“.

In-browser developer tools are a step towards a world like that. We create and change in the browser, rather than having to reload every time we change our code. Live reloading with editors works the same way. Having this immediacy where it happens makes a lot of sense, and we should be more vocal that every browser these days is also a creation tool.

Other big things I am very excited about are Web Components (which define the missing app widgets we need), X-Tag (which makes those available cross-browser) and the Mortar and WebGame stub systems. The last two enable any developer to start an app or game from building blocks and with a deployment script that uses GitHub as the host. You even create it offline, and the app will manifest for you. Watch out for this.

Another way to get people to think about the Web is not to make them think about it, but instead to use what they do already. Bananabread is a game demo written in C++ that uses Emscripten to run in JavaScript and WebGL. This is recycling as opposed to creating something new that might not be used.

In general, I think we need tools much, much more. A very interesting move was made by Adobe — yes, the Adobe behind the evil Flash — which released Brackets, an editor that also ties into live rendering in the browser. It is pretty alpha, but the very important point here is that the company that makes all of its money from tools and that rules the graphics-creation market supreme is playing with open source. It wants developers to work with it and make Brackets better and see how it works for them. This is a good chance to work with a company that knows how to build good tools and get it to open up more.

“Today is the tomorrow you expected yesterday.”

The Lost Thing by Shaun Tan.

All in all, there is no doom and gloom here. But we should have a sense of urgency. We have an incredible amount of good things to share and talk about, but if we fail to do so, we’ll look like an outdated group of experts. Today is the day you can help the Web be sexy again.

Step One: Write And Share

The first step is simple. Write and share your wisdom. Do not do it in random places. Instead, join one of the open systems that already contain great content and make it better:

Step Two: Complain In Right Channels

The second step is to reconsider our ways of complaining. Yes, venting on Twitter or on our blogs when things are broken feels good, but that doesn’t give you the feedback you need. And you’re not reaching the people who can fix your problems. You’re merely advertising that the Web is not ready and that people are not even fixing the problems. And that is not true; when you file bugs and complain on channels where browser developers and standards makers are available, things do change for the better.

One thing that has come about in recent years is a massive amount of collaborative development tools that enable you to host a development issue and get it fixed by others with you directly there. Use them, because having an issue fixed with an immediate result works much faster than long-winded explanations about what can be done:

Step Three: Support Open Training Tools

Last but not least, support the open training and education tools that are mushrooming all over the Web right now. A lot of them are funded and need content. The earlier we get people to play with the Web, the harder it will be for them to get messed up again by traditional education. I’d wager that all of us came to the Web because of our interest and from tinkering with things, rather than by graduating from a course. Let’s make that the way in for new makers of the Web, too:

The Future Is Bright!

When you try to get people excited about the Web, remember to point out the good things about it. We are far too good at complaining openly about things that are broken, while failing to share our excitement. Let’s do that more.

Finding Nemo was never advertised like this:

“A movie in which a wife and all but one child in a family are brutally murdered. The last child gets kidnapped, and the father undertakes a desperate search to find it, his only ally being a mentally challenged woman.”

(al) (vf)


© Christian Heilmann for Smashing Magazine, 2012.


Tell CSS that JavaScript is available ASAP

When you’re styling parts of a web page that will look and work differently depending on whether JavaScript is available or not, it can be very useful to use JavaScript to change or add a class name to the html element.

By doing this you can create CSS rules that will only be applied when JS is available and vice versa. The trick is to make sure the class names are switched as early as possible during page load.

Read full post

Posted in , .

Copyright © Roger Johansson


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress