IE6 is a browser that all web developers hate. Or at least that is the case if you tow the line.
IE6 used to be by far the most common browser and once was the most advanced. However, things have moved on since 2001. Web developers hate IE6 for its poor implementation of standards. Web developers hate the vagaries of the IE6 rendering engine and the performance of its JavaScript engine. These problems are well documented elsewhere.
However, the important people, the ones who matter, the ones who web developers do all their hard work for - the users - they don't seem to care nearly as much. This can be evidenced by the proportion of users who still use IE6. Even today, 8 years after its launch, over 15% of users typically visit a website with IE6. If I were Microsoft, I might just be congratulating myself for making a product so beloved of its users. Of course, where I to do that then I would naively be ignoring the massive proportion of users who have no idea what browser they are using, that there are other browers out there or how to switch.
We as web developers must also not ignore this set of users. There have been a lot of campaigns started recently to end IE6 support. Some have gone even further such as this one I just came across. I support the idea of getting our users using a more modern browser, but its up to them not us.
I don't get the big deal here. I stopped treating IE6 as a "fully supported browser" about 2 years ago. I think the problem here is this idea that a website must look identical in all supported browsers. What is wrong with a website looking subtly different in different browsers?
Of all the websites I have built from scratch in the last 2 years, not one has looked identical in different browsers unless it has been demanded from the client. They all worked in an identical way, but they looked subtly different - generally because browsers have different default rendering styles.
These differences have never been an issue. In IE6 you might get simpler button styles, you might get a more linear visual layout or you might find text looking slightly different. When I have shown them to a client and explained why they are different, the client does not care either - in fact they are thankful for the money and time saved!
I have only had problems with IE6 when I have been maintaining a site where the client has it in writing that browser support will include IE6 and that the site will be identical in all browsers.
In the many many demonstrations to clients that I have made in the last 2 years, I have never once been asked to use any browser other than the one I picked for the demo.
So, I just don't get the big deal with IE6 these days. Lets make a big deal about why we need to make websites look identical in different browsers on different platforms. Lets make a big deal about making websites more accessible. Lets make a big deal about building standards compliant websites with the simplest possible code.
If we spend our energies doing this, then we are more likely to have built-in zero cost support for many many browsers including mobile browsers, not just a narrow set often defined well before the release of a website and therefore out of date at its release.
Showing posts with label Browsers. Show all posts
Showing posts with label Browsers. Show all posts
2 April 2009
20 January 2009
Browser detection
I am not a fan of user agent sniffing. I think it is a wholly inappropriate way to find out the capabilities of a user agent accessing your website.
However, it has its uses. Steve Souders built UA Profiler, for gathering browser performance characteristics. This is undoubtedly an important and intriguing project. In order to detect which browser you are using, he has written his own user agent sniffing code as he describes in his latest blog post.
He also offers to make this code available through a web service. This is an intriguing possibility. My first reaction was to think that this was an excellent move. A high quality user agent sniffer, improved upon by the community and its breadth of use that we could all access via a web service meaning we would not have to ask our users to download the code to do the detection.
Having calmed down slightly, I started to think more clearly. Overall, I am not convinced this is the best idea. Generally I feel that detecting a user agent from its user agent string is dangerous. This makes the assumption that no user agent spoofing is taking place, that your detection is granular and perfect enough and that browser features and support will not change. None of these are necessarily true.
I prefer to use feature detection. If I want to know whether the browser I am using is capable of applying a particular method, does that method exist?
The only reliable way I have found to detect a browser is for Internet Explorer only using conditional comments, both in HTML (useful for including CSS and JavaScript files for specific versions of IE) and in the JavaScript itself.
I notice that the latest version of jQuery (1.3) is deprecating its user agent sniffing. This decision is to be applauded.
I also realised that the next version of JSquared will actually add the ability to determine if the browser you are using is IE and if it is version 6 or another version. Whilst I might be adding a limited set of user agent support to my library, I am trying to do it in a fail-safe way.
However, it has its uses. Steve Souders built UA Profiler, for gathering browser performance characteristics. This is undoubtedly an important and intriguing project. In order to detect which browser you are using, he has written his own user agent sniffing code as he describes in his latest blog post.
He also offers to make this code available through a web service. This is an intriguing possibility. My first reaction was to think that this was an excellent move. A high quality user agent sniffer, improved upon by the community and its breadth of use that we could all access via a web service meaning we would not have to ask our users to download the code to do the detection.
Having calmed down slightly, I started to think more clearly. Overall, I am not convinced this is the best idea. Generally I feel that detecting a user agent from its user agent string is dangerous. This makes the assumption that no user agent spoofing is taking place, that your detection is granular and perfect enough and that browser features and support will not change. None of these are necessarily true.
I prefer to use feature detection. If I want to know whether the browser I am using is capable of applying a particular method, does that method exist?
The only reliable way I have found to detect a browser is for Internet Explorer only using conditional comments, both in HTML (useful for including CSS and JavaScript files for specific versions of IE) and in the JavaScript itself.
I notice that the latest version of jQuery (1.3) is deprecating its user agent sniffing. This decision is to be applauded.
I also realised that the next version of JSquared will actually add the ability to determine if the browser you are using is IE and if it is version 6 or another version. Whilst I might be adding a limited set of user agent support to my library, I am trying to do it in a fail-safe way.
3 November 2008
Browser wars
To finish up this little series of posts about browser standards, I wanted to refer to the browser wars and ask this simple question:
Do we need another browser war?
Well? What do you think?
I think we cannot have another browser war in quite the same way. When it was Netscape vs Internet Explorer, every user spoke (or perhaps didn't speak) and chose (or perhaps was simply given) Internet Explorer. What then happened is that all the proprietary features of IE could be safely used whilst knowing there was a very high support rate.
Since IE6 came out and the browser war ended, there was a little stagnation but really what happened was that people got a bit bored and wanted more. So Firefox came along as a viable competitor. That was the time to have a browser war. The moment has passed.
Right now there is too much competition (or maybe none - its hard to tell) between the browser vendors. The market is too segmented. We now need the vendors to follow a standard spec. And so we get into the sordid world of the W3C and standards.
Do we need another browser war?
Well? What do you think?
I think we cannot have another browser war in quite the same way. When it was Netscape vs Internet Explorer, every user spoke (or perhaps didn't speak) and chose (or perhaps was simply given) Internet Explorer. What then happened is that all the proprietary features of IE could be safely used whilst knowing there was a very high support rate.
Since IE6 came out and the browser war ended, there was a little stagnation but really what happened was that people got a bit bored and wanted more. So Firefox came along as a viable competitor. That was the time to have a browser war. The moment has passed.
Right now there is too much competition (or maybe none - its hard to tell) between the browser vendors. The market is too segmented. We now need the vendors to follow a standard spec. And so we get into the sordid world of the W3C and standards.
Standards?
Yesterday, I posted about some of my thoughts on web standards. It raised some questions for me. It was a post I was reluctant to make but only because I could not reasonably say in one post how I feel and what I think about the current state of affairs. I don't want this blog to descend into a series of rants about the W3C and standards etc etc.
I will attempt now to clarify my thoughts on where we should go from here.
Firstly, I think we do need to make progress. We need to move things forwards. We cannot stagnate. We must find ways to innovate. However, I don't think we have even scratched the surface of what is commercially possible and viable given today's technology. The browser has proven itself to be a remarkable platform capable of producing almost any sort of UI.
So here are some thoughts for each proposed standard:
What I am generally advocating is a simplification of the specs to make them manageable for browser vendors. Lets give the browser vendors an easier task to get themselves up to scratch and then lets ask them to add new features. As always these new features should be able to be applied using the principles of progressive enhancement.
The savior for us all could be JavaScript libraries. They transcend the browser differences hiding them conveniently. Of course that creates a level of ignorance about those issues amongst some, but they are undeniably popular and successful.
But the world of JavaScript libraries is amazingly similar to the early world of the browser. They all do basically the same things but in quite different ways. Some libraries do some things well, others do other things well. Funnily enough, libraries need to converge on something of a unified API. Just like the browsers.
So for the foreseeable future, the web developer will continue to bridge the gap with ingenuity, cunning, blood, sweat and tears. Its OK for me, but will it still be OK in 10 years time? Will we still be in the same situation in 10 years time? Sadly, I think yes. Does this dull my passion for my job? Absolutely not! I enjoy dealing with these vagaries and having to think on my feet every day!
Surely though, we can sort this out, one way or another...
I will attempt now to clarify my thoughts on where we should go from here.
Firstly, I think we do need to make progress. We need to move things forwards. We cannot stagnate. We must find ways to innovate. However, I don't think we have even scratched the surface of what is commercially possible and viable given today's technology. The browser has proven itself to be a remarkable platform capable of producing almost any sort of UI.
So here are some thoughts for each proposed standard:
- HTML 5
I am unconvinced by large parts of the spec and I think it is far too large a specification. I want to see greater interoperability between the various browsers and as such I believe simplification would be better. I also strongly believe that the next spec should enforce an XML type syntax. Its easier to maintain and easier to find errors. I would encourage the browser vendors to simplify their parsing engines, not force them into more complicated solutions. - CSS 3
The power of CSS is in its expressive simplicity. This will not be lost within CSS 3, but do we really need much more on top of CSS 2.1? Do we need to have 4 rendering engines in wide use which are trying to implement a load of new CSS properties that will not be widely used? Are we not better off getting the current specs properly implemented with perhaps a few additions (multiple background images comes to mind) which can be progressively applied using the principles of progressive enhancement? - JavaScript 2
I do not think JavaScript should gain classes and I do not think the language should be greatly extended. Interfaces may be a useful addition, but generally I just think a little tidying is needed. Its in the DOM that work is required. Lets get the DOM objects of the various browsers to be more closely aligned with each other.
What I am generally advocating is a simplification of the specs to make them manageable for browser vendors. Lets give the browser vendors an easier task to get themselves up to scratch and then lets ask them to add new features. As always these new features should be able to be applied using the principles of progressive enhancement.
The savior for us all could be JavaScript libraries. They transcend the browser differences hiding them conveniently. Of course that creates a level of ignorance about those issues amongst some, but they are undeniably popular and successful.
But the world of JavaScript libraries is amazingly similar to the early world of the browser. They all do basically the same things but in quite different ways. Some libraries do some things well, others do other things well. Funnily enough, libraries need to converge on something of a unified API. Just like the browsers.
So for the foreseeable future, the web developer will continue to bridge the gap with ingenuity, cunning, blood, sweat and tears. Its OK for me, but will it still be OK in 10 years time? Will we still be in the same situation in 10 years time? Sadly, I think yes. Does this dull my passion for my job? Absolutely not! I enjoy dealing with these vagaries and having to think on my feet every day!
Surely though, we can sort this out, one way or another...
31 October 2008
Standard nonsense
My thoughts on web standards change on an almost weekly basis. I now consider myself a sceptical evangelist! I believe in web standards as an end but I do not agree with the means by which we seem to be getting there. I think we should be using web standards, but I live and work in the real world where web standards remain nothing more than a laudable goal and an occasional convenient excuse.
Currently, we have HTML 5 and CSS 3 and JavaScript 2 as the shining examples of where we are heading with web standards. I am aware that JavaScript 2 is no more (the end of a great folly in my opinion), however, these three serve to demonstrate my point.
The vast majority of users on the web, and surely its the users who are most important - not us developers, are using Internet Explorer as their primary web browser. IE is a fine product for browsing the web today and I suspect it fulfills the needs of those users in the vast majority of cases.
A good proportion of users are using Firefox with many using Firefox 3. This too is a fine browser. As is Safari which dominates the remaining small proportion of users.
At this point, others may launch into a diatribe about how users should switch browsers. Some may wish to analyse the statistics on a deeper level. But I wish to just re-iterate that for users, their current browser works fine! Why are we - the developers - getting so upset about users not changing their browser?
HTML 5, CSS 3 and JavaScript 2 are (or were) all meant to be innovations and additions to the interface developers toolkit, allowing us to do exciting new and innovative things. Creating new types of web pages, allowing the user to interact in new and exciting ways. Hmm. Writing that makes me think of AJAX. AJAX was meant to be an innovation and an addition to the interface developers toolkit allowing us to do exciting new and innovative things. AJAX was meant to allow us to create new types of web pages, allowing the user to interact in new and exciting ways.
Why did it work with AJAX? Its because support was already in the users browser. When AJAX started to become popular, there were some older browsers in use almost as much as Firefox 2 is in use today. Well, those older browsers disappeared as users could not access the websites that used advanced AJAX techniques. The other very helpful factor for AJAX was that computers became very cheap and very powerful and so users were upgrading more easily and more frequently. Most users only change browser when they change computer.
I believe there are the following 3 main reasons that HTML 5 and CSS 3 are not in common use today and will not be for at least 5 years from now:
Ultimately, there is no business case for building a website implementing new standards. Indeed, the opposite is true - it is better for businesses to ensure their websites work on the widest cross-section of browsers out there which means implementing old standards.
So is this all a cause for depression? Absolutely not. Do we need new standards? Not really! Wow, that was a controversial statement. I would like new and more appropriate standards, I would like those standards to be adhered to so I don't have to deal with cross browser issues. But, I am still doing really exciting and innovative work, I still find new bugs and issues with the browsers and I am yet to see a design or specification for a website which I could not build with today's existing technologies.
Currently, we have HTML 5 and CSS 3 and JavaScript 2 as the shining examples of where we are heading with web standards. I am aware that JavaScript 2 is no more (the end of a great folly in my opinion), however, these three serve to demonstrate my point.
The vast majority of users on the web, and surely its the users who are most important - not us developers, are using Internet Explorer as their primary web browser. IE is a fine product for browsing the web today and I suspect it fulfills the needs of those users in the vast majority of cases.
A good proportion of users are using Firefox with many using Firefox 3. This too is a fine browser. As is Safari which dominates the remaining small proportion of users.
At this point, others may launch into a diatribe about how users should switch browsers. Some may wish to analyse the statistics on a deeper level. But I wish to just re-iterate that for users, their current browser works fine! Why are we - the developers - getting so upset about users not changing their browser?
HTML 5, CSS 3 and JavaScript 2 are (or were) all meant to be innovations and additions to the interface developers toolkit, allowing us to do exciting new and innovative things. Creating new types of web pages, allowing the user to interact in new and exciting ways. Hmm. Writing that makes me think of AJAX. AJAX was meant to be an innovation and an addition to the interface developers toolkit allowing us to do exciting new and innovative things. AJAX was meant to allow us to create new types of web pages, allowing the user to interact in new and exciting ways.
Why did it work with AJAX? Its because support was already in the users browser. When AJAX started to become popular, there were some older browsers in use almost as much as Firefox 2 is in use today. Well, those older browsers disappeared as users could not access the websites that used advanced AJAX techniques. The other very helpful factor for AJAX was that computers became very cheap and very powerful and so users were upgrading more easily and more frequently. Most users only change browser when they change computer.
I believe there are the following 3 main reasons that HTML 5 and CSS 3 are not in common use today and will not be for at least 5 years from now:
- The W3C
A large slow moving organisation that seemingly cannot decide in which direction to lumber. There has been some progress over the last year, but they have absolutely set the pace. The gap between HTML 4 and HTML 5 being proper standards will be mirrored by the gap between users using browsers which implement those standards. - The browser vendors
More slow moving organisations. The era of co-operation never began and never will be. There seems to be more effort being made to improve the performance of existing browser features rather than in implementing anything new. This in itself is a positive, but it does not really move the game forwards. This is the vendors playing catch-up so the websites we already build can run in a more reasonable fashion.
There appears to be so little real competition in this market that vendor specific features are becoming acceptable again within the web development community. As developers we just want something shiny and new to play with! - The Users
The only group that should really matter. Users have not been given any real incentive to change browsers or to support those vendors attempting to implement and push forwards new standards. Users will only shift their position on this in response to catastrophic security issues or a family member who knows better and has a convincing voice.
Users still use older browsers such as IE 6 and Firefox 2 because there is nothing that the newer browsers offer which is compelling enough to make the change. Users are not technically savvy and nor should they have to be. Users only demand reliability, usable performance and security - even IE 6 can provide that.
Ultimately, there is no business case for building a website implementing new standards. Indeed, the opposite is true - it is better for businesses to ensure their websites work on the widest cross-section of browsers out there which means implementing old standards.
So is this all a cause for depression? Absolutely not. Do we need new standards? Not really! Wow, that was a controversial statement. I would like new and more appropriate standards, I would like those standards to be adhered to so I don't have to deal with cross browser issues. But, I am still doing really exciting and innovative work, I still find new bugs and issues with the browsers and I am yet to see a design or specification for a website which I could not build with today's existing technologies.
30 October 2008
The Quiet
Its been pretty quiet on this blog for the last 6 weeks or so. I have been very busy working on an interesting, fairly complex and fairly large JavaScript application during the day and then recovering from it at night! I also had the pleasure of a lovely week away in this period of quiet.
I have also recently got my hands on a rather sexy new phone - an HTC Touch Diamond - and have spent a lot of time playing with that. Its a Windows Mobile PocketPC and its been an interesting experience, particularly Opera 9.5 Mobile which is the default browser.
Browsing on a handheld device has been a new experience for me. My phone comes with Pocket IE installed as well, but that is rather archaic. I have done all I can to avoid using it.
Opera Mobile however is a fantastic browser. Its fairly fast, pretty standards compliant and renders most pages rather well. It has also given me a useful insight into a different type of user agent for browsing the web. Its quite a different experience and its easy to see which sites are well designed and which are not.
I have taken away a couple of important lessons from my experience. Firstly, clear interface design is very important on this type of device. The browser can zoom into pages but when a page loads, it is zoomed out and most text cannot be read clearly at all. However, a site with good design is very usable as I can zoom in on just the right area. Clearly defined navigation really helps with browsing on a mobile device.
The second lesson I have learnt is that the easiest sites to use employ a liquid or semi-liquid layout. My phone has a resolution of 480x640 and if a site can flow its content to fit into either of those widths, that helps greatly. If I were designing a website today, I would definitely ensure it works in a browser width of 640 pixels!
The final lesson I have taken with me thus far is that the size of elements on screen really matters. I use my finger to navigate a website and having links tightly packed together with a small font size makes life very difficult. Having small form fields or form fields with a small font size and another link right next to or just underneath the form field can make it difficult to select the element I want to interact with. Finally, having heavily styled buttons, especially image buttons makes submitting a form harder than it needs to be, particularly if pressing enter on the keyboard does not work.
For me, the most noteworthy new aspect of interface development that I will carry with me is the importance of keyboard interaction with a form - never ever stop a form being submitted with the enter key!
There is much more to say about this phone and browsing the web using Opera, but at least for now, the quiet is no more!
I have also recently got my hands on a rather sexy new phone - an HTC Touch Diamond - and have spent a lot of time playing with that. Its a Windows Mobile PocketPC and its been an interesting experience, particularly Opera 9.5 Mobile which is the default browser.
Browsing on a handheld device has been a new experience for me. My phone comes with Pocket IE installed as well, but that is rather archaic. I have done all I can to avoid using it.
Opera Mobile however is a fantastic browser. Its fairly fast, pretty standards compliant and renders most pages rather well. It has also given me a useful insight into a different type of user agent for browsing the web. Its quite a different experience and its easy to see which sites are well designed and which are not.
I have taken away a couple of important lessons from my experience. Firstly, clear interface design is very important on this type of device. The browser can zoom into pages but when a page loads, it is zoomed out and most text cannot be read clearly at all. However, a site with good design is very usable as I can zoom in on just the right area. Clearly defined navigation really helps with browsing on a mobile device.
The second lesson I have learnt is that the easiest sites to use employ a liquid or semi-liquid layout. My phone has a resolution of 480x640 and if a site can flow its content to fit into either of those widths, that helps greatly. If I were designing a website today, I would definitely ensure it works in a browser width of 640 pixels!
The final lesson I have taken with me thus far is that the size of elements on screen really matters. I use my finger to navigate a website and having links tightly packed together with a small font size makes life very difficult. Having small form fields or form fields with a small font size and another link right next to or just underneath the form field can make it difficult to select the element I want to interact with. Finally, having heavily styled buttons, especially image buttons makes submitting a form harder than it needs to be, particularly if pressing enter on the keyboard does not work.
For me, the most noteworthy new aspect of interface development that I will carry with me is the importance of keyboard interaction with a form - never ever stop a form being submitted with the enter key!
There is much more to say about this phone and browsing the web using Opera, but at least for now, the quiet is no more!
2 September 2008
Google Chrome
So, its finally happened. Google's next step towards world domination is here, and its a web browser! Its also pretty clever. Indeed, I am writing this post in the new browser.
Its called Google Chrome. The Google Chrome chrome is extremely minimal and I like it. The tabs have certainly taken center stage and got a nice feel to it. It is extremely fast to use and the JavaScript engine appears to be fast and well, I am impressed!
Its well worth a download and a play, and dont forget the developer tools - yes, they are included in the browser.
I wont go into any technical details as Google have done a good (if somewhat unusual) job of explaining things. Check out the website for more information.
My favourite feature so far is the way the browser remembers searches you perform on other sites and makes it so easy for new searches to be performed.
If this is how Google are approaching their application development - and lets face it, no-one expected anything different - then I have high hopes for Android. On that subject, I have recently become the proud owner of an HTC Touch Diamond which is a Windows Mobile phone and I am keeping my fingers crossed that Chrome Mobile is coming soon!
As an aside, being a Webkit based browser, I was hoping that JSquared would "just work". However, I will be doing some testing and you can expect another report soon, especially given the new JavaScript engine.
Its called Google Chrome. The Google Chrome chrome is extremely minimal and I like it. The tabs have certainly taken center stage and got a nice feel to it. It is extremely fast to use and the JavaScript engine appears to be fast and well, I am impressed!
Its well worth a download and a play, and dont forget the developer tools - yes, they are included in the browser.
I wont go into any technical details as Google have done a good (if somewhat unusual) job of explaining things. Check out the website for more information.
My favourite feature so far is the way the browser remembers searches you perform on other sites and makes it so easy for new searches to be performed.
If this is how Google are approaching their application development - and lets face it, no-one expected anything different - then I have high hopes for Android. On that subject, I have recently become the proud owner of an HTC Touch Diamond which is a Windows Mobile phone and I am keeping my fingers crossed that Chrome Mobile is coming soon!
As an aside, being a Webkit based browser, I was hoping that JSquared would "just work". However, I will be doing some testing and you can expect another report soon, especially given the new JavaScript engine.
21 August 2008
The future of JavaScript
For those who have not heard, ECMAScript 4 is no more. That also means that JavaScript 2 is currently at best paused. Some will mourn this as a great loss. I am not one of those.
JavaScript 2 had some very interesting ideas in it, but I am far from convinced that it was the future. I firmly believe that JavaScript 1.x has a long long way to run yet.
It is not often that I will link to an article on Slashdot, but this one piqued my interest.
The future of JavaScript is very much tied up in the present and future of browsers. Much of what I have to say here is also true about future versions of CSS.
The problems we as web professionals face today is not due to a shortcoming of JavaScript or CSS or HTML. They are due to shortcomings of the browsers. Until browsers support the standards, there may as well not be standards.
So we have options. We can introduce new ideas and new technologies which will only be supported by a sub-set of users for a fairly long period and will then fall into a category of technologies we are reticent to use due to the need to support older browsers.
Or, we can wait for the browsers to catch up with the standards so that we can exploit them to the full, with guaranteed compatibility.
Well, I dont fancy waiting something like 4 or 5 or even 6 years for browsers to catch up with the standards, I want to do cool, new and interesting things now. So, we are left with the former of the 2 options I present above.
Of course, the thing which allows us to push forward and use the new technologies of CSS and JavaScript which are being introduced and still provide a good level of cross browser support is JavaScript! Look at how the innovative use of JavaScript, largely by library authors, has driven the W3C and browser vendors to introduce new native features to the browsers. This is only of benefit to us.
I firmly believe that changing the core nature of JavaScript now would undermine a lot of the good work of the last few years and it would also be to deny the true power of JavaScript as it stands today. Yes, there is a barrier to people wanting to learn JavaScript - it can be complex, it is difficult to master - but this also is a good thing. Ultimately the standard of JavaScript development will improve and we don't need a new version of the language to make this happen.
JavaScript is an amazingly flexible language and finding new ways of bending it to our will is going to define the next set of standards, the next set of tools that we want to see, and it is the next set of standards that are far more likely to be adhered to than the current generation.
We must not stifle innovation, we must encourage it. Keeping a massive level of embedded knowledge whilst JavaScript is still at its infancy of true professionalism is the right way forward. Maintaining the core of the language as it stands moving forward must be a good thing. Yes, lets play with other languages in the browser, lets even use and support them, but where JavaScript is concerned, my message is clear - don't go changing!
JavaScript 2 had some very interesting ideas in it, but I am far from convinced that it was the future. I firmly believe that JavaScript 1.x has a long long way to run yet.
It is not often that I will link to an article on Slashdot, but this one piqued my interest.
The future of JavaScript is very much tied up in the present and future of browsers. Much of what I have to say here is also true about future versions of CSS.
The problems we as web professionals face today is not due to a shortcoming of JavaScript or CSS or HTML. They are due to shortcomings of the browsers. Until browsers support the standards, there may as well not be standards.
So we have options. We can introduce new ideas and new technologies which will only be supported by a sub-set of users for a fairly long period and will then fall into a category of technologies we are reticent to use due to the need to support older browsers.
Or, we can wait for the browsers to catch up with the standards so that we can exploit them to the full, with guaranteed compatibility.
Well, I dont fancy waiting something like 4 or 5 or even 6 years for browsers to catch up with the standards, I want to do cool, new and interesting things now. So, we are left with the former of the 2 options I present above.
Of course, the thing which allows us to push forward and use the new technologies of CSS and JavaScript which are being introduced and still provide a good level of cross browser support is JavaScript! Look at how the innovative use of JavaScript, largely by library authors, has driven the W3C and browser vendors to introduce new native features to the browsers. This is only of benefit to us.
I firmly believe that changing the core nature of JavaScript now would undermine a lot of the good work of the last few years and it would also be to deny the true power of JavaScript as it stands today. Yes, there is a barrier to people wanting to learn JavaScript - it can be complex, it is difficult to master - but this also is a good thing. Ultimately the standard of JavaScript development will improve and we don't need a new version of the language to make this happen.
JavaScript is an amazingly flexible language and finding new ways of bending it to our will is going to define the next set of standards, the next set of tools that we want to see, and it is the next set of standards that are far more likely to be adhered to than the current generation.
We must not stifle innovation, we must encourage it. Keeping a massive level of embedded knowledge whilst JavaScript is still at its infancy of true professionalism is the right way forward. Maintaining the core of the language as it stands moving forward must be a good thing. Yes, lets play with other languages in the browser, lets even use and support them, but where JavaScript is concerned, my message is clear - don't go changing!
30 June 2008
Not lovely...
Well, its not often that I have had a bad word to say about Mozilla Firefox. However, for the second time in a week, I now do.
I have been aware of issues with the Mozilla implementation of eval for some time, but the latest exposure was news to me and seemingly many others.
Full details can be found here. There is no reliable way round that I can find as yet so I will continue along the assumption that in the JavaScript world, nothing is safe.
I will still use a module pattern (as I have discussed before in a previous post) and I will still call "private" members private. I will also continue to discourage the use of evil eval.
Douglas Crockford has a few things to say about Firefox in general and had his own comments about this latest issue.
I am deeply disappointed frankly. Firefox 3 ruined my week last week (well, truthfully, Firebug was as much to blame) and now this. I suppose its nice to see that other browser vendors make mistakes!
I have been aware of issues with the Mozilla implementation of eval for some time, but the latest exposure was news to me and seemingly many others.
Full details can be found here. There is no reliable way round that I can find as yet so I will continue along the assumption that in the JavaScript world, nothing is safe.
I will still use a module pattern (as I have discussed before in a previous post) and I will still call "private" members private. I will also continue to discourage the use of evil eval.
Douglas Crockford has a few things to say about Firefox in general and had his own comments about this latest issue.
I am deeply disappointed frankly. Firefox 3 ruined my week last week (well, truthfully, Firebug was as much to blame) and now this. I suppose its nice to see that other browser vendors make mistakes!
24 June 2008
Firefox 3
Well, it has been a good few days now that I have been running the release version of Firefox 3 and I thought I would share some of my experiences - both positive and negative.
First off, I like the interface updates, the "awesome bar" and the speed improvements. I have been very impressed with its stability as well.
However, I have found difficulty using a number of plugins and in particular Firebug. This is simply unacceptable. I have tried using a number of different versions of Firebug but to no avail - all were slow and often crashed Firefox.
Whilst this has proven to be just about acceptable for working at home on things such as JSquared, at work it has proven utterly useless and I have downgraded to Firefox 2 and Firebug 1.05. The improvement in performance of Firebug was immense.
How are you finding Firefox 3 and Firebug? Have you found a combination that works for you?
First off, I like the interface updates, the "awesome bar" and the speed improvements. I have been very impressed with its stability as well.
However, I have found difficulty using a number of plugins and in particular Firebug. This is simply unacceptable. I have tried using a number of different versions of Firebug but to no avail - all were slow and often crashed Firefox.
Whilst this has proven to be just about acceptable for working at home on things such as JSquared, at work it has proven utterly useless and I have downgraded to Firefox 2 and Firebug 1.05. The improvement in performance of Firebug was immense.
How are you finding Firefox 3 and Firebug? Have you found a combination that works for you?
3 April 2008
Future proofing
With updates to some of the most popular and widely used browsers soon to appear - namely IE 8 and Firefox 3 - the question has to be posed about how and when to support them.
It is a fairly simple matter to test your websites in the new versions of these browsers as there are beta versions of both available, however, it can be very time-consuming to fix issues and clients can find it a bitter pill to swallow.
The biggest problem here is a lack of overall transparency about how and when these browsers will be released. This issue is much much greater where IE is concerned.
We know that Firefox is slated for a June release and it is likely that the automatic update system will offer users the new version. It is therefore reasonable to suppose that there will be a fairly rapid surge in the number of users for Firefox 3.
As far as IE is concerned, we cannot be sure of a release date or the mechanism by which the update will be delivered. It is possible that there will be a split between IE 7 and IE 8 users for some time until IE 8 is pushed through automatic updates as a high priority update. This in a way is what has happened with the IE 6 to IE 7 transition.
I think it is reasonable for an interface developer to support 2 versions of a popular web browser (perhaps at different levels of support), but I do not like the idea of having to support 3 versions at any level, particularly when one of those is IE 6!
So, the question is, what to do? I am unsure at the moment, though I am considering testing my websites in Firefox 3 as of now and attempting a good level of support. As far as IE 8 goes, if its IE 7 mode works well, then that is a very good reason to not support IE 8 until it is actually released.
If Microsoft released a road map with release dates for IE 8 and the version afterwards, then I could plan my browser support strategy much more easily. So come on Microsoft, talk to me....
It is a fairly simple matter to test your websites in the new versions of these browsers as there are beta versions of both available, however, it can be very time-consuming to fix issues and clients can find it a bitter pill to swallow.
The biggest problem here is a lack of overall transparency about how and when these browsers will be released. This issue is much much greater where IE is concerned.
We know that Firefox is slated for a June release and it is likely that the automatic update system will offer users the new version. It is therefore reasonable to suppose that there will be a fairly rapid surge in the number of users for Firefox 3.
As far as IE is concerned, we cannot be sure of a release date or the mechanism by which the update will be delivered. It is possible that there will be a split between IE 7 and IE 8 users for some time until IE 8 is pushed through automatic updates as a high priority update. This in a way is what has happened with the IE 6 to IE 7 transition.
I think it is reasonable for an interface developer to support 2 versions of a popular web browser (perhaps at different levels of support), but I do not like the idea of having to support 3 versions at any level, particularly when one of those is IE 6!
So, the question is, what to do? I am unsure at the moment, though I am considering testing my websites in Firefox 3 as of now and attempting a good level of support. As far as IE 8 goes, if its IE 7 mode works well, then that is a very good reason to not support IE 8 until it is actually released.
If Microsoft released a road map with release dates for IE 8 and the version afterwards, then I could plan my browser support strategy much more easily. So come on Microsoft, talk to me....
18 December 2007
Browser support
This is an issue which crops up in one form or another on almost every project I have ever worked on. Its normally the project manager who will approach me and say in a sometimes off-handed way something like "I assume we will support this list of browsers (which someone gave me back in 2001)."
My usual answer is "No. We will support this standard support matrix."
I then proceed to hand the project manager something which at the time of writing includes the following:
I also consider this matrix to be a testing guide for the testers of the website. Most testers are not completely familiar with ID concepts, and they need some help. I have seen testers using up to 20 different browsers and raising bugs if they are not all perfect. This is obviously very costly on the project - testing takes a long time and fixing the bugs is extremely tedious and often not really possible.
To get around this issues (and to help with dealing with the client who still happens to be using Ie5 on Windows 98) I normally talk in terms of graded support. At the time of writing, I use 2 level of support:
Level 1
All features of the website are fully functional. All content is available. The web pages will match the designs provided completely. The web pages will look the same across all browsers at this level.
Level 2
All features of the website are functional if only in a fall back manner. All content is available. The web pages will largely match provided designs. The web pages may look slightly different between browsers at this level and those at other levels.
This provides a sensible testing structure as well as fulfilling all other requirements. If an awkward browser (such as IE 5.5) absolutely must be supported, we have the option of only offering level 2 support - the key here is that all content will be available.
In reality, browser support only matters for the visual and enhanced behavior of the website. If the website is built using the principles of progressive enhancement, then all user agents, all browsers should be able to access the website in some form or another. It is the content of the website which is most important, and using well structured, semantic HTML should ensure that this content is available to all.
The message here is that agreeing a sensible browser support matrix is very important in both a business sense and for testing. It is also imperative to adhere to the agreed support levels, but the principles of progressive enhancement, particularly starting with well formed, semantic HTML will ensure the widest possible support even if that is with a degraded experience.
My usual answer is "No. We will support this standard support matrix."
I then proceed to hand the project manager something which at the time of writing includes the following:
- Internet Explorer 6+
- Firefox 1.5+ (all platforms)
- Safari 2+ (all platforms)
- Opera 9+ (all platforms)
I also consider this matrix to be a testing guide for the testers of the website. Most testers are not completely familiar with ID concepts, and they need some help. I have seen testers using up to 20 different browsers and raising bugs if they are not all perfect. This is obviously very costly on the project - testing takes a long time and fixing the bugs is extremely tedious and often not really possible.
To get around this issues (and to help with dealing with the client who still happens to be using Ie5 on Windows 98) I normally talk in terms of graded support. At the time of writing, I use 2 level of support:
Level 1
All features of the website are fully functional. All content is available. The web pages will match the designs provided completely. The web pages will look the same across all browsers at this level.
Level 2
All features of the website are functional if only in a fall back manner. All content is available. The web pages will largely match provided designs. The web pages may look slightly different between browsers at this level and those at other levels.
This provides a sensible testing structure as well as fulfilling all other requirements. If an awkward browser (such as IE 5.5) absolutely must be supported, we have the option of only offering level 2 support - the key here is that all content will be available.
In reality, browser support only matters for the visual and enhanced behavior of the website. If the website is built using the principles of progressive enhancement, then all user agents, all browsers should be able to access the website in some form or another. It is the content of the website which is most important, and using well structured, semantic HTML should ensure that this content is available to all.
The message here is that agreeing a sensible browser support matrix is very important in both a business sense and for testing. It is also imperative to adhere to the agreed support levels, but the principles of progressive enhancement, particularly starting with well formed, semantic HTML will ensure the widest possible support even if that is with a degraded experience.
Subscribe to:
Comments (Atom)
Posts
