Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!



Smartphone-Style Touch Sensing On an 82-Inch Screen

JimDabell Already in use (31 comments)

Just this Monday we were filming for a TV programme and we used these guys to demo an iPad app on a giant touchscreen. It's still early days for the technology, but it works well for that use case already.

more than 3 years ago

Do You Care if Your Website is W3C Compliant?

JimDabell Reasons to validate (624 comments)

Reposted from something I wrote a while ago

You cannot prove anything about the future... but you can identify trends.

Before Netscape 1.2 came out, it was a common, non-standard hack to use multiple title and body elements to get crude animation. Netscape 1.2 came out, and screwed these pages up. Following standards ensured forwards compatibility with Netscape 1.2.

Before Netscape 2.0 came out, missing quotes on the end of an attribute were detected as errors by Netscape 1.x and compensated for. Netscape 2.0 came out; it did not. Large sections of pages disappeared. Following standards ensured forwards compatibility with Netscape 2.0.

Before Netscape 3.0 came out, people were careless with their ampersands, failing to correctly encode them in URLs, for example. These were detected as errors by the current browsers, and compensated for. Netscape 3.0 came out; it did not. Lots of broken links everywhere. Following standards ensured forwards compatibility with Netscape 3.0.

Before Netscape 4.0 came out, people were still careless with character entities, omitting the trailing semicolon (I believe this was a property of many graphical editors, such as Frontpage). This was detected by the current browsers, and compensated for. Netscape 4.0 came out; it did not. Following standards ensured forwards compatibility with Netscape 4.0.

Before Netscape 6.0 came out, people used a variety of non-standard Javascript techniques and layer elements, detecting Internet Explorer, and serving them alternative code. Netscape 6.0 came out, it didn't support the proprietary Netscape-isms of previous releases. Following standards ensured forwards compatibility with Netscape 6.0.

More recent problems include stylesheets served with an incorrect content-type header, and table-layout images being broken up with lots of little gaps.

This list only includes Netscape behaviour, as that is the only list I have to hand. (Thanks to this article). I'm sure similar things apply to other browsers.

There is plenty of evidence that sticking with standard code results in forwards compatibility.

There are really only two important properties of future browsers:

  • They are likely to support at least as much of the specifications as the current version
  • Nobody can test in them

Thus, my overwhelming desire is to simply treat future browsers as I would any other browser I couldn't test in: code to standards, and when I get a chance to test, fix up what is necessary.

There are very few good reasons these days to write invalid code. Mostly it's just ignorance and apathy that causes people to write invalid code.

more than 8 years ago


JimDabell hasn't submitted any stories.


JimDabell has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>