Thursday, March 20, 2008
New Video of BigDog Quadruped Robot Is So Stunning It's Spooky
Boston Dynamics keeps working on their BigDog quadruped robot, which will probably grow to be the future AT-AT of the Pentagon. Its evolution since the last time we saw it is nothing sort of mindblowing, and a bit spooky.
It looks like an actual biological quadruped. Seeing it climb through rubble, snow, jumping over obstacles like a wild goat, and saving a near-fall on iced ground at the last second (fast forward to the middle of the video) defies belief. It feels so "animal" that I almost feel bad when they hit it to demonstrate how it regains balance on its own.
The new version of the robot can now carry 340 pounds, which is almost triple the previous weight. It looks to me that that $10 million funding they got from Darpa has been put to good use. [IEEE]
Tuesday, March 18, 2008
Saturday, March 15, 2008
Searchme project
Introduction to Searchme
Searchme Demo
Searchme is a new search engine that uses visual search and category refinement. We think it will help you find what you're looking for, faster, with a lot less spam. It's a new way to search that takes advantage of the size and bandwidth of today's Internet and the increasingly visual way that we all interact online.
The idea for Searchme came when Mark Kvamme, Searchme's chairman, got tired of looking through a bunch of unrelated results for articles on motocross. He suggested to founders Randy Adams and John Holland that they create a search engine that sorted results into categories. The Searchme visual interface came about when Randy, a father of seven, helped his four-year-old son search for children's web sites that he'd seen on TV. It struck Adams that if a search engine could show big pictures of the pages it found before users clicked through to a site, it'd be much easier to quickly find what they were looking for.
After more than three years of engineering, imaging billions of web pages, and fine-tuning our approach many times over, Searchme was born. We've built it from the ground up to optimize it for speed, but we still have a long way to go. We're just getting started on our first steps toward creating a smart new way to search today's Web.
How It Works
Searchme sorts your search results into relevant topics, then lets you scroll through and preview the web pages associated with your query, before you click through. As you start typing, category icons appear that relate to your search. For example, if you type "bonds", it suggests "savings" or "stocks" or "baseball". Choose a category, and you'll see pictures of the web pages that match your search. You can quickly review these pages to find the best one, then go right to that site.
Simply put, Searchme lets you see what you're searching for, before you click through.
Why It's Unique
Searchme's visual interface and category suggest features make us different from most other search engines. The visual interface delivers results as a browsable stack of "pages" - pictures of actual web pages that users can check out before visiting them. Category suggest, a seemingly simple feature, is based on a complicated analysis and categorization process that uses unique technology to divide results into predetermined, carefully-honed topics.
We're growing every day, and the quality of our results will vary as we make Searchme better and better. We'd love your help - if you have any suggestions, let us know!
Who Should Use It
Anyone can use Searchme - casual Internet users, professionals, college students. It especially appeals to visual people. Structured like a video game, Searchme's visual style and categories make it easy and fun to use, on a laptop or big screen.
Who's Involved
Searchme was founded in 2005 by Randy Adams, CEO, and John Holland, CMO, and received initial funding from Sequoia Capital. If you'd like to help us build Searchme, check out our jobs section.
Searchme Demo
Searchme is a new search engine that uses visual search and category refinement. We think it will help you find what you're looking for, faster, with a lot less spam. It's a new way to search that takes advantage of the size and bandwidth of today's Internet and the increasingly visual way that we all interact online.
The idea for Searchme came when Mark Kvamme, Searchme's chairman, got tired of looking through a bunch of unrelated results for articles on motocross. He suggested to founders Randy Adams and John Holland that they create a search engine that sorted results into categories. The Searchme visual interface came about when Randy, a father of seven, helped his four-year-old son search for children's web sites that he'd seen on TV. It struck Adams that if a search engine could show big pictures of the pages it found before users clicked through to a site, it'd be much easier to quickly find what they were looking for.
After more than three years of engineering, imaging billions of web pages, and fine-tuning our approach many times over, Searchme was born. We've built it from the ground up to optimize it for speed, but we still have a long way to go. We're just getting started on our first steps toward creating a smart new way to search today's Web.
How It Works
Searchme sorts your search results into relevant topics, then lets you scroll through and preview the web pages associated with your query, before you click through. As you start typing, category icons appear that relate to your search. For example, if you type "bonds", it suggests "savings" or "stocks" or "baseball". Choose a category, and you'll see pictures of the web pages that match your search. You can quickly review these pages to find the best one, then go right to that site.
Simply put, Searchme lets you see what you're searching for, before you click through.
Why It's Unique
Searchme's visual interface and category suggest features make us different from most other search engines. The visual interface delivers results as a browsable stack of "pages" - pictures of actual web pages that users can check out before visiting them. Category suggest, a seemingly simple feature, is based on a complicated analysis and categorization process that uses unique technology to divide results into predetermined, carefully-honed topics.
We're growing every day, and the quality of our results will vary as we make Searchme better and better. We'd love your help - if you have any suggestions, let us know!
Who Should Use It
Anyone can use Searchme - casual Internet users, professionals, college students. It especially appeals to visual people. Structured like a video game, Searchme's visual style and categories make it easy and fun to use, on a laptop or big screen.
Who's Involved
Searchme was founded in 2005 by Randy Adams, CEO, and John Holland, CMO, and received initial funding from Sequoia Capital. If you'd like to help us build Searchme, check out our jobs section.
Thursday, March 13, 2008
10 Future Web Trends
We’re well into the current era of the Web, commonly referred to as Web 2.0. Features of this phase of the Web include search, social networks, online media (music, video, etc), content aggregation and syndication (RSS), mashups (APIs), and much more. Currently the Web is still mostly accessed via a PC, but we’re starting to see more Web excitement from mobile devices (e.g. iPhone) and television sets (e.g. XBox Live 360).
What then can we expect from the next 10 or so years on the Web? As NatC commented in this week’s poll, the biggest impact of the Web in 10 years time won’t necessarily be via a computer screen - “your online activity will be mixed with your presence, travels, objects you buy or act with.” Also a lot of crossover will occur among the 10 trends below (and more) and there will be Web technologies that become enormously popular that we can’t predict now.
Bearing all that in mind, here are 10 Web trends to look out for over the next 10 years…
1. Semantic Web
Sir Tim Berners-Lee’s vision for a Semantic Web has been The Next Big Thing for a long time now. Indeed it’s become almost mythical, like Moby Dick. In a nutshell, the Semantic Web is about machines talking to machines. It’s about making the Web more ‘intelligent’, or as Berners-Lee himself described it: computers “analyzing all the data on the Web - the content, links, and transactions between people and computers.” At other times, Berners-Lee has described it as “the application of weblike design to data” - for example designing for re-use of information.
As Alex Iskold wrote in The Road to the Semantic Web, the core idea of the Semantic Web is to create the meta data describing data, which will enable computers to process the meaning of things. Once computers are equipped with semantics, they will be capable of solving complex semantical optimization problems.
So when will the Semantic Web arrive? The building blocks are here already: RDF, OWL, microformats are a few of them. But as Alex noted in his post, it will take some time to annotate the world’s information and then to capture personal information in the right way. Some companies, such as Hakia and Powerset and Alex’s own AdaptiveBlue, are actively trying to implement the Semantic Web. So we are getting close, but we are probably a few years off still before the big promise of the Semantic Web is fulfilled.
Semantic Web pic by dullhunk
2. Artificial Intelligence
Possibly the ultimate Next Big Thing in the history of computing, AI has been the dream of computer scientists since 1950 - when Alan Turing introduced the Turing test to test a machine’s capability to participate in human-like conversation. In the context of the Web, AI means making intelligent machines. In that sense, it has some things in common with the Semantic Web vision.
We’ve only begun to scratch the surface of AI on the Web. Amazon.com has attempted to introduce aspects of AI with Mechanical Turk, their task management service. It enables computer programs to co-ordinate the use of human intelligence to perform tasks which computers are unable to do. Since its launch on 2 November 2005, Mechanical Turk has gradually built up a following - there is a forum for “Turkers” called Turker Nation, which appears to have light-to-medium level patronage. However we reported in January that Mturk isn’t being used as much as the initial hype period in Nov-Dec 05.
Nevertheless, AI has a lot of promise on the Web. AI techniques are being used in “search 2.0″ companies like Hakia and Powerset. Numenta is an exciting new company by tech legend Jeff Hawkins, which is attempting to build a new, brain-like computing paradigm - with neural networks and cellular automata. In english this means that Numenta is trying to enable computers to tackle problems that come easy to us humans, like recognizing faces or seeing patterns in music. But since computers are much faster than humans when it comes to computation, we hope that new frontiers will be broken - enabling us to solve the problems that were unreachable before.
3. Virtual Worlds
Second Life gets a lot of mainstream media attention as a future Web system. But at a recent Supernova panel that Sean Ammirati attended, the discussion touched on many other virtual world opportunities. The following graphic summarizes it well:
Looking at Korea as an example, as the ‘young generation’ grows up and infrastructure is built out, virtual worlds will become a vibrant market all over the world over the next 10 years.
It’s not just about digital life, but also making our real life more digital. As Alex Iskold explained, on one hand we have the rapid rise of Second Life and other virtual worlds. On the other we are beginning to annotate our planet with digital information, via technologies like Google Earth.
4. Mobile
Mobile Web is another Next Big Thing on slow boil. It’s already big in parts of Asia and Europe, and it received a kick in the US market this year with the release of Apple’s iPhone. This is just the beginning. In 10 years time there will be many more location-aware services available via mobile devices; such as getting personalized shopping offers as you walk through your local mall, or getting map directions while driving your car, or hooking up with your friends on a Friday night. Look for the big Internet companies like Yahoo and Google to become key mobile portals, alongside the mobile operators.
Companies like Nokia, Sony-Ericsson, Palm, Blackberry and Microsoft have been active in the Mobile Web for years now, but one of the main issues with Mobile Web has always been usability. The iPhone has a revolutionary UI that makes it easier for users to browse the Web, using zooming, pinching and other methods. Also, as Alex Iskold noted, the iPhone is a strategy that may expand Apple’s sphere of influence, from web browsing to social networking and even possibly search.
So even despite the iPhone hype, in the US at least (and probably other countries when it arrives) the iPhone will probably be seen in 10 years time as the breakthrough Mobile Web device.
5. Attention Economy
The Attention Economy is a marketplace where consumers agree to receive services in exchange for their attention. Examples include personalized news, personalized search, alerts and recommendations to buy. The Attention Economy is about the consumer having choice - they get to choose where their attention is ’spent’. Another key ingredient in the attention game is relevancy. As long as the consumer sees relevant content, he/she is going to stick around - and that creates more opportunities to sell.
Expect to see this concept become more important to the Web’s economy over the next decade. We’re already seeing it with the likes of Amazon and Netflix, but there is a lot more opportunity yet to explore from startups.
Image from The Attention Economy: An Overview, by Alex Iskold
6. Web Sites as Web Services
Alex Iskold wrote in March that as more and more of the Web is becoming remixable, the entire system is turning into both a platform and the database. Major web sites are going to be transformed into web services - and will effectively expose their information to the world. Such transformations are never smooth - e.g. scalability is a big issue and legal aspects are never simple. But, said Alex, it is not a question of if web sites become web services, but when and how.
The transformation will happen in one of two ways. Some web sites will follow the example of Amazon, del.icio.us and Flickr and will offer their information via a REST API. Others will try to keep their information proprietary, but it will be opened via mashups created using services like Dapper, Teqlo and Yahoo! Pipes. The net effect will be that unstructured information will give way to structured information - paving the road to more intelligent computing.
Note that we can also see this trend play out currently with widgets and especially Facebook in 2007. Perhaps in 10 years time the web services landscape will be much more open, because the ‘walled garden’ problem is still with us in 2007.
Image from Web 3.0: When Web Sites Become Web Services, by Alex Iskold
7. Online Video / Internet TV
This is a trend that has already exploded on the Web - but you still get the sense there’s a lot more to come yet. In October 2006 Google acquired the hottest online video property on the planet, YouTube. Later on that same month, news came out that the founders of Kazaa and Skype were building an Internet TV service, nicknamed The Venice Project (later named Joost). In 2007, YouTube continues to dominate. Meanwhile Internet TV services are slowly getting off the ground.
Our network blog last100 has an excellent overview of the current Internet TV landscape, with reviews of 8 Internet TV apps. Read/WriteWeb’s Josh Catone also reviewed 3 of them - Joost, Babelgum, Zattoo.
It’s fair to say that in 10 years time, Internet TV will be totally different to what it is today. Higher quality pictures, more powerful streaming, personalization, sharing, and much more - it’s all coming over the next decade. Perhaps the big question is: how will the current mainstream TV networks (NBC, CNN, etc) adapt?
Zattoo, from Internet Killed The Television Star: Reviews of Joost, Babelgum, Zattoo, and More, by Josh Catone
8. Rich Internet Apps
As the current trend of hybrid web/desktop apps continues, expect to see RIA (rich internet apps) continue to increase in use and functionality. Adobe’s AIR platform (Adobe Integrated Runtime) is one of the leaders, along with Microsoft with its Windows Presentation Foundation. Also in the mix is Laszlo with its open source OpenLaszlo platform and there are several other startups offering RIA platforms. Let’s not forget also that Ajax is generally considered to be an RIA - it remains to be seen though how long Ajax lasts, or whether there will be a ‘2.0′.
As Ryan Stewart wrote for Read/WriteWeb back in April 2006 (well before he joined Adobe), “Rich Internet Apps allow sophisticated effects and transitions that are important in keeping the user engaged. This means developers will be able to take the amazing changes in the Web for granted and start focusing on a flawless experience for the users. It is going to be an exciting time for anyone involved in building the new Web, because the interfaces are finally catching up with the content.”
The past year has proven Ryan right, with Adobe and Microsoft duking it out with RIA technologies. And there’s a lot more innovation to happen yet, so in 10 years time I can’t wait to see what the lay of the RIA land is!
9. International Web
As of 2007, the US is still the major market in the Web. But in 10 years time, things might be very different. China is often touted as a growth market, but other countries with big populations will also grow - India and African nations for example.
For most web 2.0 apps and websites (R/WW included), the US market makes up over 50% of their users. Indeed, comScore reported in November 2006 that 3/4 of traffic to top websites is international. comScore said that 14 of the top 25 US Web properties now attract more visitors from outside the US than from within. That includes the top 5 US properties - Yahoo! Sites, Time Warner Network, Microsoft, Google Sites, and eBay.
However, it is still early days and the revenues are not big in international markets at this point. In 10 years time, revenue will probably be flowing from the International Web.
10. Personalization
Personalization has been a strong theme in 2007, particularly with Google. Indeed Read/WriteWeb did a feature week on Personalizing Google. But you can see this trend play out among a lot of web 2.0 startups and companies - from last.fm to MyStrands to Yahoo homepage and more.
What can we expect over the next decade? Recently we asked Sep Kamvar, Lead Software Engineer for Personalization at Google, whether there will be a ‘Personal PageRank’ system in the future. He replied:
“We have various levels of personalization. For those who are signed up for Web History, we have the deepest personalization, but even for those who are not signed up for Web History, we personalize your results based on what country you are searching from. As we move forward, personalization will continue to be a gradient; the more you share with Google, the more tailored your results will be.”
If nothing else, it’ll be fascinating to track how Google uses personalization over the coming years - and how it deals with the privacy issues.
What then can we expect from the next 10 or so years on the Web? As NatC commented in this week’s poll, the biggest impact of the Web in 10 years time won’t necessarily be via a computer screen - “your online activity will be mixed with your presence, travels, objects you buy or act with.” Also a lot of crossover will occur among the 10 trends below (and more) and there will be Web technologies that become enormously popular that we can’t predict now.
Bearing all that in mind, here are 10 Web trends to look out for over the next 10 years…
1. Semantic Web
Sir Tim Berners-Lee’s vision for a Semantic Web has been The Next Big Thing for a long time now. Indeed it’s become almost mythical, like Moby Dick. In a nutshell, the Semantic Web is about machines talking to machines. It’s about making the Web more ‘intelligent’, or as Berners-Lee himself described it: computers “analyzing all the data on the Web - the content, links, and transactions between people and computers.” At other times, Berners-Lee has described it as “the application of weblike design to data” - for example designing for re-use of information.
As Alex Iskold wrote in The Road to the Semantic Web, the core idea of the Semantic Web is to create the meta data describing data, which will enable computers to process the meaning of things. Once computers are equipped with semantics, they will be capable of solving complex semantical optimization problems.
So when will the Semantic Web arrive? The building blocks are here already: RDF, OWL, microformats are a few of them. But as Alex noted in his post, it will take some time to annotate the world’s information and then to capture personal information in the right way. Some companies, such as Hakia and Powerset and Alex’s own AdaptiveBlue, are actively trying to implement the Semantic Web. So we are getting close, but we are probably a few years off still before the big promise of the Semantic Web is fulfilled.
Semantic Web pic by dullhunk
2. Artificial Intelligence
Possibly the ultimate Next Big Thing in the history of computing, AI has been the dream of computer scientists since 1950 - when Alan Turing introduced the Turing test to test a machine’s capability to participate in human-like conversation. In the context of the Web, AI means making intelligent machines. In that sense, it has some things in common with the Semantic Web vision.
We’ve only begun to scratch the surface of AI on the Web. Amazon.com has attempted to introduce aspects of AI with Mechanical Turk, their task management service. It enables computer programs to co-ordinate the use of human intelligence to perform tasks which computers are unable to do. Since its launch on 2 November 2005, Mechanical Turk has gradually built up a following - there is a forum for “Turkers” called Turker Nation, which appears to have light-to-medium level patronage. However we reported in January that Mturk isn’t being used as much as the initial hype period in Nov-Dec 05.
Nevertheless, AI has a lot of promise on the Web. AI techniques are being used in “search 2.0″ companies like Hakia and Powerset. Numenta is an exciting new company by tech legend Jeff Hawkins, which is attempting to build a new, brain-like computing paradigm - with neural networks and cellular automata. In english this means that Numenta is trying to enable computers to tackle problems that come easy to us humans, like recognizing faces or seeing patterns in music. But since computers are much faster than humans when it comes to computation, we hope that new frontiers will be broken - enabling us to solve the problems that were unreachable before.
3. Virtual Worlds
Second Life gets a lot of mainstream media attention as a future Web system. But at a recent Supernova panel that Sean Ammirati attended, the discussion touched on many other virtual world opportunities. The following graphic summarizes it well:
Looking at Korea as an example, as the ‘young generation’ grows up and infrastructure is built out, virtual worlds will become a vibrant market all over the world over the next 10 years.
It’s not just about digital life, but also making our real life more digital. As Alex Iskold explained, on one hand we have the rapid rise of Second Life and other virtual worlds. On the other we are beginning to annotate our planet with digital information, via technologies like Google Earth.
4. Mobile
Mobile Web is another Next Big Thing on slow boil. It’s already big in parts of Asia and Europe, and it received a kick in the US market this year with the release of Apple’s iPhone. This is just the beginning. In 10 years time there will be many more location-aware services available via mobile devices; such as getting personalized shopping offers as you walk through your local mall, or getting map directions while driving your car, or hooking up with your friends on a Friday night. Look for the big Internet companies like Yahoo and Google to become key mobile portals, alongside the mobile operators.
Companies like Nokia, Sony-Ericsson, Palm, Blackberry and Microsoft have been active in the Mobile Web for years now, but one of the main issues with Mobile Web has always been usability. The iPhone has a revolutionary UI that makes it easier for users to browse the Web, using zooming, pinching and other methods. Also, as Alex Iskold noted, the iPhone is a strategy that may expand Apple’s sphere of influence, from web browsing to social networking and even possibly search.
So even despite the iPhone hype, in the US at least (and probably other countries when it arrives) the iPhone will probably be seen in 10 years time as the breakthrough Mobile Web device.
5. Attention Economy
The Attention Economy is a marketplace where consumers agree to receive services in exchange for their attention. Examples include personalized news, personalized search, alerts and recommendations to buy. The Attention Economy is about the consumer having choice - they get to choose where their attention is ’spent’. Another key ingredient in the attention game is relevancy. As long as the consumer sees relevant content, he/she is going to stick around - and that creates more opportunities to sell.
Expect to see this concept become more important to the Web’s economy over the next decade. We’re already seeing it with the likes of Amazon and Netflix, but there is a lot more opportunity yet to explore from startups.
Image from The Attention Economy: An Overview, by Alex Iskold
6. Web Sites as Web Services
Alex Iskold wrote in March that as more and more of the Web is becoming remixable, the entire system is turning into both a platform and the database. Major web sites are going to be transformed into web services - and will effectively expose their information to the world. Such transformations are never smooth - e.g. scalability is a big issue and legal aspects are never simple. But, said Alex, it is not a question of if web sites become web services, but when and how.
The transformation will happen in one of two ways. Some web sites will follow the example of Amazon, del.icio.us and Flickr and will offer their information via a REST API. Others will try to keep their information proprietary, but it will be opened via mashups created using services like Dapper, Teqlo and Yahoo! Pipes. The net effect will be that unstructured information will give way to structured information - paving the road to more intelligent computing.
Note that we can also see this trend play out currently with widgets and especially Facebook in 2007. Perhaps in 10 years time the web services landscape will be much more open, because the ‘walled garden’ problem is still with us in 2007.
Image from Web 3.0: When Web Sites Become Web Services, by Alex Iskold
7. Online Video / Internet TV
This is a trend that has already exploded on the Web - but you still get the sense there’s a lot more to come yet. In October 2006 Google acquired the hottest online video property on the planet, YouTube. Later on that same month, news came out that the founders of Kazaa and Skype were building an Internet TV service, nicknamed The Venice Project (later named Joost). In 2007, YouTube continues to dominate. Meanwhile Internet TV services are slowly getting off the ground.
Our network blog last100 has an excellent overview of the current Internet TV landscape, with reviews of 8 Internet TV apps. Read/WriteWeb’s Josh Catone also reviewed 3 of them - Joost, Babelgum, Zattoo.
It’s fair to say that in 10 years time, Internet TV will be totally different to what it is today. Higher quality pictures, more powerful streaming, personalization, sharing, and much more - it’s all coming over the next decade. Perhaps the big question is: how will the current mainstream TV networks (NBC, CNN, etc) adapt?
Zattoo, from Internet Killed The Television Star: Reviews of Joost, Babelgum, Zattoo, and More, by Josh Catone
8. Rich Internet Apps
As the current trend of hybrid web/desktop apps continues, expect to see RIA (rich internet apps) continue to increase in use and functionality. Adobe’s AIR platform (Adobe Integrated Runtime) is one of the leaders, along with Microsoft with its Windows Presentation Foundation. Also in the mix is Laszlo with its open source OpenLaszlo platform and there are several other startups offering RIA platforms. Let’s not forget also that Ajax is generally considered to be an RIA - it remains to be seen though how long Ajax lasts, or whether there will be a ‘2.0′.
As Ryan Stewart wrote for Read/WriteWeb back in April 2006 (well before he joined Adobe), “Rich Internet Apps allow sophisticated effects and transitions that are important in keeping the user engaged. This means developers will be able to take the amazing changes in the Web for granted and start focusing on a flawless experience for the users. It is going to be an exciting time for anyone involved in building the new Web, because the interfaces are finally catching up with the content.”
The past year has proven Ryan right, with Adobe and Microsoft duking it out with RIA technologies. And there’s a lot more innovation to happen yet, so in 10 years time I can’t wait to see what the lay of the RIA land is!
9. International Web
As of 2007, the US is still the major market in the Web. But in 10 years time, things might be very different. China is often touted as a growth market, but other countries with big populations will also grow - India and African nations for example.
For most web 2.0 apps and websites (R/WW included), the US market makes up over 50% of their users. Indeed, comScore reported in November 2006 that 3/4 of traffic to top websites is international. comScore said that 14 of the top 25 US Web properties now attract more visitors from outside the US than from within. That includes the top 5 US properties - Yahoo! Sites, Time Warner Network, Microsoft, Google Sites, and eBay.
However, it is still early days and the revenues are not big in international markets at this point. In 10 years time, revenue will probably be flowing from the International Web.
10. Personalization
Personalization has been a strong theme in 2007, particularly with Google. Indeed Read/WriteWeb did a feature week on Personalizing Google. But you can see this trend play out among a lot of web 2.0 startups and companies - from last.fm to MyStrands to Yahoo homepage and more.
What can we expect over the next decade? Recently we asked Sep Kamvar, Lead Software Engineer for Personalization at Google, whether there will be a ‘Personal PageRank’ system in the future. He replied:
“We have various levels of personalization. For those who are signed up for Web History, we have the deepest personalization, but even for those who are not signed up for Web History, we personalize your results based on what country you are searching from. As we move forward, personalization will continue to be a gradient; the more you share with Google, the more tailored your results will be.”
If nothing else, it’ll be fascinating to track how Google uses personalization over the coming years - and how it deals with the privacy issues.
Why Validate CSS?
This document attempts to answer the questions many people have regarding why they should bother with Validating their web sites and tries to dispel a few common myths.
The original version was written by Nick Kew of WebÞing Ltd. for their Site Valet service and he has generously donated it for our use. This version has been slightly modified, but is essentially the same.
What is Validation?
Validation is a process of checking your documents against a formal Standard, such as those published by the World Wide Web Consortium (W3C) for HTML and XML-derived Web document types, or by the WapForum for WML, etc. It serves a similar purpose to spell checking and proofreading for grammar and syntax, but is much more precise and reliable than any of those processes because it is dealing with precisely-specified machine languages, not with nebulously-defined human natural language.
It is important to note that validation has a very precise meaning. Unfortunately the issue is confused by the fact that some products falsely claim to "validate", whilst in fact applying an arbitrary selection of tests that are not derived from any standard. Such tools may be genuinely useful, but should be used alongside true validation, not in place of it.
Why Validate?
Well, firstly there is the very practical issue that non-valid pages are (by definition) relying on error-correction by a browser. This error correction can and does vary radically across different browsers and versions, so that many authors who unwittingly relied on the quirks of Netscape 1.1 suddenly found their pages appeared totally blank in Netscape 2.0. Whilst Internet Explorer initially set out to be bug-compatible with Netscape, it too has moved towards standards compliance in later releases. Other browsers differ further.
The three questions below deal with three different points of view on the issue of Validation.
The novice (or non-technical website owner) question:
"My site looks right and works fine - isn't that enough?"
The answer to this one is that markup languages are no more than data formats. So a website doesn't look like anything at all! It only takes on a visual appearance when it is presented by your browser.
In practice, different browsers can and do display the same page very differently. This is deliberate, and doesn't imply any kind of browser bug. A term sometimes used for this is WYSINWOG - What You See Is Not What Others Get (unless by coincidence). It is indeed one of the principal strengths of the web, that (for example) a visually impaired user can select very large print or text-to-speech without a publisher having to go to the trouble and expense of preparing a separate edition.
It is perhaps unfortunate that the best-known browsers - Netscape Navigator and MS Internet Explorer on Windows - are visually very similar indeed in their presentation of many documents, differing only in trivial details like margins and spacings. The "same" browser on a Mac or Unix/Linux display will often look far more different.
The perceptive observation
"Lots of websites out there don't validate - including household-name companies."
Do remember: household-name companies expect people to visit because of the name and in spite of dreadful websites. Can you afford that luxury?
Even if you can, do you want to risk being on the wrong side of a lawsuit if your site proves inaccessible to - for instance - a disabled person who cannot use a 'conventional' browser? Accessibility is the law in many countries. Whilst validation doesn't guarantee accessibility (there is no substitute for common sense), it should be an important component of exercising "due diligence". It is now just over a year since a court first awarded damages to a blind user against the owners of a website he found inaccessible (Maguire vs SOCOG, August 2000).
The strawman argument
"Validation means boring websites, and stifles creativity"
This is simply head-in-the-sand ignorance (indeed, it lies at the heart of the most spectacular hype-filled dot-com failures). Validation is fully compatible with a wide range of dynamic pages, multimedia presentations, scripting and active content, etc. It is part of the difference between doing it right and doing it wrong in a dynamic multimedia presentation, just as much as in a purely textual site.
It is perfectly in order for authors to express their creativity on the Web, though it is of course generally more appropriate to some sites (e.g. recreational ones) than to others (e.g. informational or functional sites like this one). But authors with creative ambitions should bear in mind that in any artistic field, you must start with a thorough understanding of the rules before breaking them. Otherwise you just look foolish.
http://validator.w3.org
The original version was written by Nick Kew of WebÞing Ltd. for their Site Valet service and he has generously donated it for our use. This version has been slightly modified, but is essentially the same.
What is Validation?
Validation is a process of checking your documents against a formal Standard, such as those published by the World Wide Web Consortium (W3C) for HTML and XML-derived Web document types, or by the WapForum for WML, etc. It serves a similar purpose to spell checking and proofreading for grammar and syntax, but is much more precise and reliable than any of those processes because it is dealing with precisely-specified machine languages, not with nebulously-defined human natural language.
It is important to note that validation has a very precise meaning. Unfortunately the issue is confused by the fact that some products falsely claim to "validate", whilst in fact applying an arbitrary selection of tests that are not derived from any standard. Such tools may be genuinely useful, but should be used alongside true validation, not in place of it.
Why Validate?
Well, firstly there is the very practical issue that non-valid pages are (by definition) relying on error-correction by a browser. This error correction can and does vary radically across different browsers and versions, so that many authors who unwittingly relied on the quirks of Netscape 1.1 suddenly found their pages appeared totally blank in Netscape 2.0. Whilst Internet Explorer initially set out to be bug-compatible with Netscape, it too has moved towards standards compliance in later releases. Other browsers differ further.
The three questions below deal with three different points of view on the issue of Validation.
The novice (or non-technical website owner) question:
"My site looks right and works fine - isn't that enough?"
The answer to this one is that markup languages are no more than data formats. So a website doesn't look like anything at all! It only takes on a visual appearance when it is presented by your browser.
In practice, different browsers can and do display the same page very differently. This is deliberate, and doesn't imply any kind of browser bug. A term sometimes used for this is WYSINWOG - What You See Is Not What Others Get (unless by coincidence). It is indeed one of the principal strengths of the web, that (for example) a visually impaired user can select very large print or text-to-speech without a publisher having to go to the trouble and expense of preparing a separate edition.
It is perhaps unfortunate that the best-known browsers - Netscape Navigator and MS Internet Explorer on Windows - are visually very similar indeed in their presentation of many documents, differing only in trivial details like margins and spacings. The "same" browser on a Mac or Unix/Linux display will often look far more different.
The perceptive observation
"Lots of websites out there don't validate - including household-name companies."
Do remember: household-name companies expect people to visit because of the name and in spite of dreadful websites. Can you afford that luxury?
Even if you can, do you want to risk being on the wrong side of a lawsuit if your site proves inaccessible to - for instance - a disabled person who cannot use a 'conventional' browser? Accessibility is the law in many countries. Whilst validation doesn't guarantee accessibility (there is no substitute for common sense), it should be an important component of exercising "due diligence". It is now just over a year since a court first awarded damages to a blind user against the owners of a website he found inaccessible (Maguire vs SOCOG, August 2000).
The strawman argument
"Validation means boring websites, and stifles creativity"
This is simply head-in-the-sand ignorance (indeed, it lies at the heart of the most spectacular hype-filled dot-com failures). Validation is fully compatible with a wide range of dynamic pages, multimedia presentations, scripting and active content, etc. It is part of the difference between doing it right and doing it wrong in a dynamic multimedia presentation, just as much as in a purely textual site.
It is perfectly in order for authors to express their creativity on the Web, though it is of course generally more appropriate to some sites (e.g. recreational ones) than to others (e.g. informational or functional sites like this one). But authors with creative ambitions should bear in mind that in any artistic field, you must start with a thorough understanding of the rules before breaking them. Otherwise you just look foolish.
http://validator.w3.org
Table Based Web Layout vs. CSS Positioning
I reviewed an excellent book on this topic recently that should be of interest to anyone who finds this blog post by searching regarding table based design or CSS. The book is the Zen of CSS Design.
When I learned HTML 3 a few years back, I enjoyed the power to publish content to the web where people from all over the world could access it easily. But as the web projects I developed became larger, I wished for a way to control design elements in a more centralized way.
In this pre-CSS world, if text links throughout the site were not visible enough to attract users’ attention, each link or at least the body element on each page would need to be edited to change the behavior and display of the text links throughout the site. In addition, the most frustrating aspect of design with HTML alone was being forced to use tables, designed to organize tabular data, to control the visual presentation of documents. Spacing needed to be done with images, and the code did not make sense in a text browser.
When I was introduced to Cascading Style Sheets (CSS) in its first incarnation, CSS was limited largely to the control of text and link behaviors. Even in its nascent form, it showed a great deal of potential to save repetitive work for the web designer. The many benefits of design with CSS include a lower page weight and faster load time, greater accessibility to text browsers and handheld devices, greater control over type display, cleaner (X)HTML code that often results in better search engine results.
Now that I am free of table based design, I have no desire to return. Of course, I still think tables should be used for tabular data like calendars and well, tables. The chief arguments against CSS design for visual control are that it is difficult to learn (true, but it is well worth the effort) and that it requires hacks in order to render equally well in current and older browsers. These are valid reasons to think twice before learning CSS, but not valid reasons to avoid using it if you already have mastered its intricacies. In fact, as skill level with CSS increases, it becomes almost imperative to use it rather than tables.
When I started using CSS 2.1 for document layout, I made the mistake of mostly substituting page divisions (DIV tags) for table cells. Though this increased the accessibility of the pages I designed and enabled more ease in maintenance and making site wide changes, it merely replaced one sort of cluttered code with another less cluttered code. As my comfort level increases, I have found ways to style natural page elements (semantic code) rather than introducing page divisions. So as knowledge increases, code can become increasingly simple, semantic, and accessible. As this takes place CSS begins to tower over tables as a visual design tool in its flexibility and power.
The next frontier that I must take my small design firm through is the mastery of accessibility to audio interpreters, such as screen readers, handheld devices, and full Section 508 compliance as mandated by law. Imagine a screen reader parsing a table based web design, “table data, image, table data, welcome to this web site, table row, table data, image, table”. You get the point. Within a mature understanding of CSS and semantic code, these standards can be gracefully implemented without a loss of visual appeal and without an increased page load. This is the future of web design, a virtual world with as few barriers as possible.
http://blog.designdelineations.com
When I learned HTML 3 a few years back, I enjoyed the power to publish content to the web where people from all over the world could access it easily. But as the web projects I developed became larger, I wished for a way to control design elements in a more centralized way.
In this pre-CSS world, if text links throughout the site were not visible enough to attract users’ attention, each link or at least the body element on each page would need to be edited to change the behavior and display of the text links throughout the site. In addition, the most frustrating aspect of design with HTML alone was being forced to use tables, designed to organize tabular data, to control the visual presentation of documents. Spacing needed to be done with images, and the code did not make sense in a text browser.
When I was introduced to Cascading Style Sheets (CSS) in its first incarnation, CSS was limited largely to the control of text and link behaviors. Even in its nascent form, it showed a great deal of potential to save repetitive work for the web designer. The many benefits of design with CSS include a lower page weight and faster load time, greater accessibility to text browsers and handheld devices, greater control over type display, cleaner (X)HTML code that often results in better search engine results.
Now that I am free of table based design, I have no desire to return. Of course, I still think tables should be used for tabular data like calendars and well, tables. The chief arguments against CSS design for visual control are that it is difficult to learn (true, but it is well worth the effort) and that it requires hacks in order to render equally well in current and older browsers. These are valid reasons to think twice before learning CSS, but not valid reasons to avoid using it if you already have mastered its intricacies. In fact, as skill level with CSS increases, it becomes almost imperative to use it rather than tables.
When I started using CSS 2.1 for document layout, I made the mistake of mostly substituting page divisions (DIV tags) for table cells. Though this increased the accessibility of the pages I designed and enabled more ease in maintenance and making site wide changes, it merely replaced one sort of cluttered code with another less cluttered code. As my comfort level increases, I have found ways to style natural page elements (semantic code) rather than introducing page divisions. So as knowledge increases, code can become increasingly simple, semantic, and accessible. As this takes place CSS begins to tower over tables as a visual design tool in its flexibility and power.
The next frontier that I must take my small design firm through is the mastery of accessibility to audio interpreters, such as screen readers, handheld devices, and full Section 508 compliance as mandated by law. Imagine a screen reader parsing a table based web design, “table data, image, table data, welcome to this web site, table row, table data, image, table”. You get the point. Within a mature understanding of CSS and semantic code, these standards can be gracefully implemented without a loss of visual appeal and without an increased page load. This is the future of web design, a virtual world with as few barriers as possible.
http://blog.designdelineations.com
Tables or CSS: Choosing a layout
Dave Winer walked into a long-simmering debate when he recently asked what's so important about tableless layout. The kinds of passionate responses he received have been regularly heard throughout the web design community—including places like evolt.org's own lists.
Not ready for prime time?
One of the common arguments against CSS-based design is that reality hasn't caught up with the technology's benefits.
Although no popular web browsers fully support CSS2 yet, many of the latest versions (Netscape, IE5+, Opera, and OmniWeb among others) have excellent support for CSS1 and strong support for CSS2. Even better, the public seems to be adopting these new browsers relatively quickly.
A year ago, more than one-quarter of the surfing population used browsers with poor CSS support (including IE 4). Now less than 12 percent do—putting support of CSS-based design at the same level as JavaScript and Java.
Three reasons why
Advocates of tableless design have their own pet reasons as to why style sheets are better (“it's faster”, “there's better design control”, “it's the right thing to do”), but three common reasons are presented again and again:
1. Semantics: The HTML table was conceived as a means to display tabular data. Using tables for layout was mentioned in HTML 3.2, but only to acknowledge existing use—the concept didn't appear in the original RFC. In future recommendations, the W3C said style sheets, not tables, should be used for layout. Using tables for layouts is like wearing dress shoes jogging—both work, but they're the wrong tools for the job.
2. Accessibility: Screen readers and text browsers struggle to read table-based layouts. In fact, the W3C, in its Web Content Accessibility Guidelines, explicitly says “[d]o not use tables for layout...” A tableless-layout designed using CSS can present the most appropriate, and usable design for each user agent—be it a cell phone, a screen reader, a TV-based browser, or a browser running on a desktop computer.
3. Efficiency: For both the site developer and the reader, a CSS-based design offers a degree of flexibility nearly impossible in restrictive table-based layouts. Not only can developers quickly and easily redesign an entire site by modifying one file, they can also present alternate designs for the reader. Separating content from the detailed structure table-based layouts provide, has the added benefit of future compatibility and portability.
Think about the future
Given the direction of current browser development and of the W3C itself, CSS-based design looks to become the de facto method of web design. Before switching to a tableless design, though, designers should consider the site's audience and goals (as they do whenever using anything other than pure HTML):
* Do most of the audience's browsers have good CSS support? If 30 percent of the audience uses Netscape 4.x, for example, switching may not be the best idea right now.
* Can CSS be implemented efficiently through all or part of the site? If all of the site cannot be changed immediately, small sections could benefit from CSS.
* Can there be two or more versions of the site? Some sites offer the previous tabled layout to older browsers, and the CSS version to the newer ones.
* Will the redesign by unveiled now, in six-months, or a year? The longer the planned roll-out, the more likely the audience will better support a CSS-based design.
* Is/will the site be available in multiple formats and media? If so, the benefits of CSS far outweigh the negatives.
Even if a tableless design may not be suitable for one site today, it will be for a growing number of others now and in the future.
http://www.evolt.org
Not ready for prime time?
One of the common arguments against CSS-based design is that reality hasn't caught up with the technology's benefits.
Although no popular web browsers fully support CSS2 yet, many of the latest versions (Netscape, IE5+, Opera, and OmniWeb among others) have excellent support for CSS1 and strong support for CSS2. Even better, the public seems to be adopting these new browsers relatively quickly.
A year ago, more than one-quarter of the surfing population used browsers with poor CSS support (including IE 4). Now less than 12 percent do—putting support of CSS-based design at the same level as JavaScript and Java.
Three reasons why
Advocates of tableless design have their own pet reasons as to why style sheets are better (“it's faster”, “there's better design control”, “it's the right thing to do”), but three common reasons are presented again and again:
1. Semantics: The HTML table was conceived as a means to display tabular data. Using tables for layout was mentioned in HTML 3.2, but only to acknowledge existing use—the concept didn't appear in the original RFC. In future recommendations, the W3C said style sheets, not tables, should be used for layout. Using tables for layouts is like wearing dress shoes jogging—both work, but they're the wrong tools for the job.
2. Accessibility: Screen readers and text browsers struggle to read table-based layouts. In fact, the W3C, in its Web Content Accessibility Guidelines, explicitly says “[d]o not use tables for layout...” A tableless-layout designed using CSS can present the most appropriate, and usable design for each user agent—be it a cell phone, a screen reader, a TV-based browser, or a browser running on a desktop computer.
3. Efficiency: For both the site developer and the reader, a CSS-based design offers a degree of flexibility nearly impossible in restrictive table-based layouts. Not only can developers quickly and easily redesign an entire site by modifying one file, they can also present alternate designs for the reader. Separating content from the detailed structure table-based layouts provide, has the added benefit of future compatibility and portability.
Think about the future
Given the direction of current browser development and of the W3C itself, CSS-based design looks to become the de facto method of web design. Before switching to a tableless design, though, designers should consider the site's audience and goals (as they do whenever using anything other than pure HTML):
* Do most of the audience's browsers have good CSS support? If 30 percent of the audience uses Netscape 4.x, for example, switching may not be the best idea right now.
* Can CSS be implemented efficiently through all or part of the site? If all of the site cannot be changed immediately, small sections could benefit from CSS.
* Can there be two or more versions of the site? Some sites offer the previous tabled layout to older browsers, and the CSS version to the newer ones.
* Will the redesign by unveiled now, in six-months, or a year? The longer the planned roll-out, the more likely the audience will better support a CSS-based design.
* Is/will the site be available in multiple formats and media? If so, the benefits of CSS far outweigh the negatives.
Even if a tableless design may not be suitable for one site today, it will be for a growing number of others now and in the future.
http://www.evolt.org
CSS vs Tables
When I started exploring the design possibilities of the internet back in 1996, NetObjects Fusion was (at that point) a revolutionary WYSIWYG editor that allowed you to place pretty much any components anywhere you wanted on the page. Unfortunately for Website Pros, Inc. Macromedia had also seen the potential in WYSIWYG editors and developed what is arguably the most popular web design tool ever – Dreamweaver.
Dreamweaver has managed to keep up with the requirements of the modern day web developer by constantly updating and improving aspects of its design, layout and functionality. With the latest release of Dreamweaver, Macromedia have again improved on various features but have also come to realise the potential and the need to support (in more detail) the new designer’s technique – cascade style sheets (CSS).
Having always designed using table based layouts, I recently (less than 3 months ago in fact) decided it was time to look in more detail at CSS, to learn what it could do to improve the quality of my work, specifically in terms of positioning and layout of website elements. At that point I already had a basic understand of CSS and how to use CSS to influence text styling, link styles, table colours and borders etc. The challenge was (more clearly) to see if designing layouts using CSS instead of tables was (to me) easier and more beneficial – could I be persuaded to change despite my dedication to tables?
My choice of two books (which I’m still reading incidentally), are both written and published by Sitepoint. The first (The CSS Anthology – 101 Essential Tips, Tricks & Hacks) is an excellent practical guide, not only for beginners but also for people (like me) wanting to learn a bit more (or in fact a lot more) about the potential of CSS. Whether you want to know how to justify text, create a pure CSS drop down menu or implement a liquid, two-column layout, this book is an excellent start or continuation for anyone interested in CSS.
The second and probably more relevant book that I chose (again by Sitepoint) is the 2nd Edition HTML Utopia: Designing Without Tables using CSS. This book again goes over the basics of CSS, but in a more concise and brief manor. The main bulk of the book concentrates on more examples of positioning and layout. In short these are two books that I know I’m eventually going to read from cover to cover – two books that will always be to hand and provide the answer to my question when something goes wrong or I don’t fully understand exactly what I’m doing (something that happens on a regular basis).
So what have I learnt in the last few months from reading these books, reading relational website articles and listening to peoples points of view on webmaster forums? Quite simply I was quite stubborn in the beginning. I had tried about a year ago to use CSS for layouts but hadn’t got very far (although at that stage I had no books to use for reference). This time around I had the knowledge (or more accurately the books of knowledge) but was already expecting my own personal failure (based on my previous experiences). Luckily though I stuck with it and now know a lot more (although obviously not everything, by a long shot) about the potential of CSS.
Obviously (just by looking at my site) you can see that I have indeed changed from table based layouts to CSS layouts – but what truly changed my mind and would I ever go back to tables? Is this site simply a one off?
Tables were in fact not originally intended to be used as layout tools – expert designers (especially in the beginning) discovered that they could use tables, within tables, within tables to create and position quite precisely most (if not all) web page elements. The major problem and issue with this method (which has been emphasised even more so in recent years) is using this method to produce standard compliant web pages.
Tables, nested again and again and again result in load times that are longer than necessary, encourage the use of inefficient ‘placeholder graphics’ that further slow performance, cause major issues for web page maintenance (even when simple, minor changes are required) and can often cause the page(s) to become inaccessible to those who are not using a graphical web browser. CSS in short overcomes all these issues by separating content from code.
The intended purpose of tables is in fact to display tables of data – something that CSS gurus are constantly quoting in web forums and web logs. This is highly understandable when you accurately understand how tables work and load within a browser. Web browsers are deliberately designed to ensure that each table downloads as a single entity. None of the material that is contained in a table will be displayed until all the contents of that table are downloaded to the client machine and available for display. In complex designed sites where lots of nested tables are used it is quite easy to see how this problem can effect the load time of web pages – in addition to the apparent delay in load time there is also the issue of the sheer quantity of HTML code that’s required to create each individual web page. Table-based layouts almost certainly account for more user concern over long page-load times than any other single factor.
Another major issue that I am all too familiar with is how ridged tables can be when trying to create a visually appealing site design. I am a designer who likes everything positioned in a pixel perfect manor. It has often been the case where additional room has been need above or below a certain table element to allow the design and content to ‘breath’. On conceivable method around this problem (as any table layout designer will know) is the use of a transparent gif image, a tiny GIF image that has no visible content. By creating table cells that contained these transparent images, additional space (either vertical or horizontal) can be added to achieve the required appearance that the designer requires. This solution in itself can and does cause major problems. Given a table with dozens (or even hundreds) of these transparent type images, the performance impacts of transparent GIFs on a web page can be significant. More importantly though, this technique often restricts the page to a fixed pixel size and clutters the page with images that are irrelevant to the meaning of the page content.
Combine all of the above with the additional complex and problematic ability to maintain a complex array of deeply nested tables and you’ll find even with tools such as Dreamweaver or Adobe GoLive that you’ll soon be tearing your hair out or getting the undying need to throw your computer out the window!
Finally tables are bad due to their inability to be correctly viewed by none graphical web browsers – such as the screen readers used by many visually impaired users. When a text only device reads he content of a site, it starts at the top and works down the page line by line. When it comes to a table, it starts at the top left and works left to right, row by row. For obvious reasons when nested tables are used to display chunks of text in the desired layout, that content can become nonsensical when read in this manor.
So would I or will I go back to table based layouts? In a word no! Not only does cascade style sheet layouts allow faster load times and better accessibility to people with disabilities, but it also allows me to create and design accurate cross browser enabled websites. I can position elements and components exactly where I want and can easily separate content from code!
The principle of CSS is thus:
The World Wide Web Consortium, better known as the W3C, saw that separating the content of a site from its presentation (or appearance) would be the most logical solution of future web design and development. This technique would enable content experts – writers, artists, photographers and programmers to provide the ‘stuff’ that people come to a site to see, read or experience. It would also free the design experts – artists, graphic designers and typographers to determine a site’s aesthetics independently of its content.
The result was CSS.
Dreamweaver has managed to keep up with the requirements of the modern day web developer by constantly updating and improving aspects of its design, layout and functionality. With the latest release of Dreamweaver, Macromedia have again improved on various features but have also come to realise the potential and the need to support (in more detail) the new designer’s technique – cascade style sheets (CSS).
Having always designed using table based layouts, I recently (less than 3 months ago in fact) decided it was time to look in more detail at CSS, to learn what it could do to improve the quality of my work, specifically in terms of positioning and layout of website elements. At that point I already had a basic understand of CSS and how to use CSS to influence text styling, link styles, table colours and borders etc. The challenge was (more clearly) to see if designing layouts using CSS instead of tables was (to me) easier and more beneficial – could I be persuaded to change despite my dedication to tables?
My choice of two books (which I’m still reading incidentally), are both written and published by Sitepoint. The first (The CSS Anthology – 101 Essential Tips, Tricks & Hacks) is an excellent practical guide, not only for beginners but also for people (like me) wanting to learn a bit more (or in fact a lot more) about the potential of CSS. Whether you want to know how to justify text, create a pure CSS drop down menu or implement a liquid, two-column layout, this book is an excellent start or continuation for anyone interested in CSS.
The second and probably more relevant book that I chose (again by Sitepoint) is the 2nd Edition HTML Utopia: Designing Without Tables using CSS. This book again goes over the basics of CSS, but in a more concise and brief manor. The main bulk of the book concentrates on more examples of positioning and layout. In short these are two books that I know I’m eventually going to read from cover to cover – two books that will always be to hand and provide the answer to my question when something goes wrong or I don’t fully understand exactly what I’m doing (something that happens on a regular basis).
So what have I learnt in the last few months from reading these books, reading relational website articles and listening to peoples points of view on webmaster forums? Quite simply I was quite stubborn in the beginning. I had tried about a year ago to use CSS for layouts but hadn’t got very far (although at that stage I had no books to use for reference). This time around I had the knowledge (or more accurately the books of knowledge) but was already expecting my own personal failure (based on my previous experiences). Luckily though I stuck with it and now know a lot more (although obviously not everything, by a long shot) about the potential of CSS.
Obviously (just by looking at my site) you can see that I have indeed changed from table based layouts to CSS layouts – but what truly changed my mind and would I ever go back to tables? Is this site simply a one off?
Tables were in fact not originally intended to be used as layout tools – expert designers (especially in the beginning) discovered that they could use tables, within tables, within tables to create and position quite precisely most (if not all) web page elements. The major problem and issue with this method (which has been emphasised even more so in recent years) is using this method to produce standard compliant web pages.
Tables, nested again and again and again result in load times that are longer than necessary, encourage the use of inefficient ‘placeholder graphics’ that further slow performance, cause major issues for web page maintenance (even when simple, minor changes are required) and can often cause the page(s) to become inaccessible to those who are not using a graphical web browser. CSS in short overcomes all these issues by separating content from code.
The intended purpose of tables is in fact to display tables of data – something that CSS gurus are constantly quoting in web forums and web logs. This is highly understandable when you accurately understand how tables work and load within a browser. Web browsers are deliberately designed to ensure that each table downloads as a single entity. None of the material that is contained in a table will be displayed until all the contents of that table are downloaded to the client machine and available for display. In complex designed sites where lots of nested tables are used it is quite easy to see how this problem can effect the load time of web pages – in addition to the apparent delay in load time there is also the issue of the sheer quantity of HTML code that’s required to create each individual web page. Table-based layouts almost certainly account for more user concern over long page-load times than any other single factor.
Another major issue that I am all too familiar with is how ridged tables can be when trying to create a visually appealing site design. I am a designer who likes everything positioned in a pixel perfect manor. It has often been the case where additional room has been need above or below a certain table element to allow the design and content to ‘breath’. On conceivable method around this problem (as any table layout designer will know) is the use of a transparent gif image, a tiny GIF image that has no visible content. By creating table cells that contained these transparent images, additional space (either vertical or horizontal) can be added to achieve the required appearance that the designer requires. This solution in itself can and does cause major problems. Given a table with dozens (or even hundreds) of these transparent type images, the performance impacts of transparent GIFs on a web page can be significant. More importantly though, this technique often restricts the page to a fixed pixel size and clutters the page with images that are irrelevant to the meaning of the page content.
Combine all of the above with the additional complex and problematic ability to maintain a complex array of deeply nested tables and you’ll find even with tools such as Dreamweaver or Adobe GoLive that you’ll soon be tearing your hair out or getting the undying need to throw your computer out the window!
Finally tables are bad due to their inability to be correctly viewed by none graphical web browsers – such as the screen readers used by many visually impaired users. When a text only device reads he content of a site, it starts at the top and works down the page line by line. When it comes to a table, it starts at the top left and works left to right, row by row. For obvious reasons when nested tables are used to display chunks of text in the desired layout, that content can become nonsensical when read in this manor.
So would I or will I go back to table based layouts? In a word no! Not only does cascade style sheet layouts allow faster load times and better accessibility to people with disabilities, but it also allows me to create and design accurate cross browser enabled websites. I can position elements and components exactly where I want and can easily separate content from code!
The principle of CSS is thus:
The World Wide Web Consortium, better known as the W3C, saw that separating the content of a site from its presentation (or appearance) would be the most logical solution of future web design and development. This technique would enable content experts – writers, artists, photographers and programmers to provide the ‘stuff’ that people come to a site to see, read or experience. It would also free the design experts – artists, graphic designers and typographers to determine a site’s aesthetics independently of its content.
The result was CSS.
Wednesday, March 12, 2008
Written by Richard MacManus
Sometimes when you talk to a professional web developer you'll hear the phrases 'CSS layout' and 'Tables Layout'. Without knowing something of the history of web development these phrases would be meaningless to you which is why I'm going to talk about them today as they happen to be quite important.
Back in the mists of time there was HTML. HTML was the basic programming language used to create websites and since there was only one major web browser on the scene all web pages were built in HTML to look good with this browser. Because HTML was young and basic the best way to achieve complex layouts was to use something called the table tag. The table tag was very flexible and allowed the programmer to create tables where each table cell contained text or graphics or both. With a bit of ingenuity, patience and imagination, increadibly complex designes could be built using this method.
But as time went on other web browsers became popular and each had subtly different ways of 'rendering' the HTML and tables. Because the browsers were in competition with each other they each added different features and extentions which were not part of the official standards and the rendering differences between the browsers grew greater and greater. Problems also became apparent with maintaining sites with complex table layouts and browsers for blind people (commonly called screen readers) had major problems disiphering and distilling these sites in a meaningful way. Eventually, the 'Browser Wars' as they were known back then were won by Microsoft and its Internet Explorer browser. This had the effect of killing innovation dead and for a while we were left with horrible table layouts and bad standards support.
To present day
When it seemed all was lost a number of crucial things happened. With its dying breath Netscape (the other major player in the browser wars) won an Antitrust case again Microsoft. This had the effect of creating enough breathing space in the browser market for competitors to re-appear and three new browsers began to gain a foothold, Mozilla's Firefox, Apple's Safari and Opera's Opera browser.
At the same time the standards organisation W3C (World Wide Web Consortium) began to re-assert its authority in the face of calls for better support for screen readers and disabled internet users. This new round of standards were called Cascading Styles Sheets (CSS) and xHTML and were aimed at providing a more descriptive way of building complex web layouts without sacrificing accessiblity, effectively allowing developers to totally separate content from appearance.
This provided a common cause for Microsoft's competitors to champion and before long the only browser not doing CSS and xHTML properly was Microsoft's Internet Explorer. Microsoft finally stared to fix this deficiency with IE7 in 2007 and they promise to be fully compliant by the end of 2008 with IE8 but its taken a 15% drop in market share for this to happen.
Thanks for the history lesson but what does this mean?
So thats the history but what does it mean to you? Well, as you might have guessed its common opinion that CSS/xHTML is good and that Tables and HTML4 is bad. This is for several reasons:
- CSS/xHTML when done right will be more more accessible to people with disabilities
- Because CSS/xHTML is a rigidly defined standard, your page should always look the same across standards compliant browsers (providing its built correctly)
- Theoretically it should be easier to completely change the appearance ofa CSS/xHTML website without modifying content or the actual webpages thus making CSS/xHTML site much more maintainable.
So why do developers still do table layouts if CSS is so great? Well its a complex issue, many developers have learned their Tables skills through years of hard work coaxing the different browsers to do the right thing. CSS is a fundimentally different way of building websites and as such Tables based skills are next to useless. Busy web developers are understandably reluctant to throw away their hard earned skills and start again, this costs them time, money and possibly reputation as they re-learn their trade.
Fine you say, if its so difficult to change then why cant we just have both? The problem here is that because the two approaches are so different from each other, if a site is built in Tables in this day and age it is already effectively obsolete and will NOT be maintainable in a couple of years time. Right now all new sites should be being built to the standards, this will help Microsoft and other vendors make their products more standards compliant which in turn will make life easier not only for web developers but for users with disabilities and ultimately for all of us.
What should I do with this information?
When deciding who you want to help you build your new website make sure you ask them if they build in CSS or Tables and if they answer that they use CSS then ask them to show you a site they have built that validates. A validator is a tool which examines a website and checks for errors against the standards, ideally a website should validate but if it fails on minor errors its not the end of the world. In general, the closer a site sticks to the standards the better it will look across browsers and the more users you'll have access to. Your site will also be able to be much more clever incorporating things like animation and better interactivety with the user.
As always if you have any questions, comments or disagreements with what I've said here then drop me a line!
http://www.jamesburrows.info
CSS layouts vs Tables: What's the Pragmatic Choice?
There's a debate going on in the Web world about Lockergnome's backwards conversion from a modern CSS design to a 1997-era HTML tables design. The web design community is outraged by the decision, because it's basically a slap in the face to the Web Standards movement. Photo Matt compares table-based designs to McDonald's food and XHTML/CSS designs to healthy, fresh food. Paul Scrivens and Dave Shea both ask: what's the point in going backwards? Those that agree with Lockergnome's decision argue that tables-based designs are still the easiest and most pragmatic solution. Scoble sings the Content is King rap and Rogers Cadenhead says that "...aside from accessibility issues, no one should care how pure your markup is."
I have to agree with Photo Matt and the other designers on this - Web Standards are important and Lockergnome's decision is short-sighted. What's more I'll argue below that CSS designs are the pragmatic choice - if not in the short-term, then very definitely in the medium and long term.
The fact is HTML is a structural-based mark-up language and HTML tables are NOT designed for presentational purposes. Using tables for webpage layout is a hack, pure and simple. CSS on the other hand is specifically designed for presentation purposes. All modern browsers support CSS now, unlike browsers circa 1997, so there's little excuse not to separate structure (HTML/XHTML) and presentation (CSS).
(aside: stay tuned for my upcoming Digital Web article, which I recently submitted for review. It has a section on this very point).
But actually it's no use me moralising, I need to provide some pragmatic reasons why people should want to use XHTML/CSS...
I wrote an article back in October 2003 explaining why I'd decided to move my Radio Userland weblog from the default tables-based design to an XHTML-compliant, CSS layout. Let me briefly re-iterate some of my reasons:
- While in the short-term CSS is harder to implement than tables, in the medium-term CSS is easier to maintain. Having to fuss around with a bunch of table cells in order to re-jig a design layout, is more hassle than simply modifying a couple of lines in a CSS file.
- XHTML/CSS designs convey semantic information about the structure of your site. While you may not see many benefits of this today, think of these future benefits: Your site will be more easily rendered on mobile devices, it can be easily re-purposed to another format, it can be probed and analysed using XPath and other such technologies, it can be re-mixed and transformed with other XML content, and so on.
There are also more practical web design reasons too - e.g. CSS designs use up less bandwidth than table-based designs. All of these reasons make XHTML and CSS the pragmatic choice when viewed from a medium and long-term perspective.
RSS is actually a very good example of the value of semantically-structured web publishing (and publishing is what we do with websites too). RSS is an XML data format and the content is wrapped up in semantically-meaningful tags. I don't want to get into a debate about how semantic RSS 2.0 is compared to RSS 1.0 or Atom (that'd be like jumping out of the frypan and into the fire!). My point is that web publishing is no longer just about slapping together some HTML tags, placing it on the Web, and 'Bob's yer Uncle' that's the end of the process. When we publish to the Web using semantically rich structures and Web Standards, we make it a whole lot easier to share and re-use content. The process doesn't end when we publish - it's only just begun. That's sort of what I was getting at the other day with my There is no End User post. But I'm still working on that theory...
Written by Richard MacManus
CSS Layouts Vs. Table Layouts
CSS Layouts Vs. Table Layouts - Alternate Browsers and Accessibility Issues
When developing a web site one can choose between creating a CSS-based or TABLE-based web site. Both types of layouts have advantages and disadvantages and perform quite differently. They also raise (or address) accessibility issues.
This article will try to focus alternatively on each layout and point out the course of action for web developers employing either of them so as to improve the accessibility of their website.
TABLE-based layouts
Tables have been used in designing web sites for a very long time. Yet, even today, with the multitude of browsers available, many compatibility and accessibility issues rise to the surface. All these issues must be addressed in order to ensure a web site is completely functional to all users including those using alternate browsers.
Facts about web sites using tables
- They're easy to use and implement (compared to css-layouts).
- WYSIWYG (What You See Is What You Get) editors like Frontpage and Dreamweaver make it very easy for developers to include them.
- Tables "break" on various browsers (newer and older versions) thus producing layout dysfunctions.
- Increase almost unnecessarily the HTML/text ratio. This means that other options could be used to create layouts that produce smaller page files by employing less HTML tags.
We see tables being used on over 95% of the websites on the net today. We see them being used on web sites with heavy content like news sites as well as on simpler sites like corporate sites or educational sites.
Among the many issues related to tables, the most disturbing one (for users as well as web developers) is browser compatibility. Among the most common browsers today, we see Internet Explorer, Netscape, Opera and Mozilla. However, there are several versions of each on the market. This means that web sites should be tested on as many versions as possible in order to obtain an accurate compatibility analysis.
During the compatibility analysis we see that on other browsers than Internet Explorer the table layout "breaks". We see gaps that should not be there, or weird positioning of cells or even thicker rows or columns than intended. Such issues require a lot of extra effort and time on the developers' part to fix. Strangely enough, a table layout can even look broken on Netscape 6.x due to the DOCTYPE declaration at the beginning of the source file.
Admittedly, the developer can not always be accountable for layout dysfunctions. There are numerous bugs all browsers have that can cause that.
When using WYSIWYG for designing a web site the risk of "bloating" the source code with unnecessary tags (or invalid tags for that matter) rises significantly. The less experienced web designers are faced with having to fix what a software broke.
Text browsers, screen readers and speech output browsers read the source code line by line and then render it to the user. If cells aren't linearized, meaning that when reading Cell1, Cell2, Cell3 and Cell4 the content does not read in a logical flow, then the information becomes difficult to retrieve for disabled users. The above mentioned situation can occur when you have navigation in Cell1 and Cell3 and content in Cell2 and Cell4.
Alternative browsers will also have difficulties rendering content properly if the layout uses tables within tables or table cells. This would break up the logical structure of the page.
---------------------
CSS-based layouts
CSS or Cascading Style Sheets have been used until now for text formatting but recently, developers have started using it for positioning and layouts. CSS layouts are still difficult and time-consuming to implement but their advantages are certainly worth the trouble.
Facts about CSS layouts
- Widely supported by modern browsers but not by older browsers
- Allows extreme flexibility in positioning
- Increases usability by encouraging liquid design
- Keeps the HTMl/text ratio at a low level thus decreasing load time
- Allows the display of main content first while the graphics load afterwards
Although almost all modern browsers have good CSS support, older browsers are at a disadvantage. However, on older browsers a CSS-based layout still proves to be usable by displaying navigation and content at the beginning of the page.
By making use of its flexibility, developers can easily create layouts that expand as much as the screen allows it. Another advantage is that by changing a single .css file one can completely change the aspect of the site, making it perfectly suitable for screen or printing.
Because of increased positioning options, the main content can be placed at the top of the source code. This causes the information to display first and leave the bandwidth consuming elements to load at the end. This proves to be much more usable for users because they do not have to wait for an entire table with content and graphics to load as it happened with TABLE-based layouts. Users have now to wait much less before the relevant information is displayed..
Increasing accessibility through CSS
Graphic intense sites or those that employ elements that prove inaccessible to disabled users can put CSS to good work by placing all these elements at the bottom of the source code. This way, normal browsers will render the layout properly for normal users, letting them enjoy the visuals while alternate browsers will easily render the simplified, informational content to disabled users.
Using CSS can also avoid accessibility issues raised by table cells. When creating CSS-based web sites the content flows logically without disruption.
By Craig from TX.
http://www.ex-designz.net/articleread.asp?aid=323
Subscribe to:
Posts (Atom)