Need a reason for semantic HTML?

Try this on for size: an automatic bullshit detector. The Nieman Journalism Lab writes:

You’re reading a wrap-up of the Sept. 22 Republican presidential debate when you land on this claim from Rep. Michele Bachmann: “President Obama has the lowest public approval ratings of any president in modern times.”

Really? You start googling for evidence. Maybe you scour the blogs or the fact-checking sites. It takes work, all that critical thinking.

That’s why Dan Schultz, a graduate student at the MIT Media Lab (and newly named Knight-Mozilla fellow for 2012), is devoting his thesis to automatic bullshit detection. Schultz is building what he calls truth goggles — not actual magical eyewear, alas, but software that flags suspicious claims in news articles and helps readers determine their truthiness. It’s possible because of a novel arrangement: Schultz struck a deal with fact-checker PolitiFact for access to its private APIs.

Bull beware: Truth goggles sniff out suspicious sentences in news 

Yes, yes, I know it’s not using semantic HTML for its fact-finding, but it’s easy to imagine a world where an intelligent webcrawler can use the semantic meaning embedded in every (well crafted) piece of writing on the internet to find and analyze related content.

Let’s invent an example. Say you’re writing a blogpost or an essay in a wordprocessor. You write a loaded sentence like: ”evolution is just a theory”. Behind the scenes, the bullshit detector you’ve installed runs a search for the keywords in this sentence. It gets lots of results, written by everyone from respected scientists to religious crackpots. It then runs a background check on the most relevant results and ranks them by trust-worthiness (the algorithm could take following items into consideration: citations, health-status of links, popularity, the presence of attributions and footnotes, etc… maybe even using a crowd-sourced repository of facts, curated by top-scientists and respected writers) and uses human language analysis to compare your statement (“evolution is just a theory”) with the facts-backed consensus (“evolution is a scientific fact”) and then points out your (potential) lies.

The technology could work for readers too. Say you’re reading an article or opinion-piece on a news-site or politician’s blog, and it underlines all potential lies or falsehoods.

Right now, most false information on the internet (and beyond, as traditional media aren’t much better) isn’t born out of malice or ill-intent, but rather out of sheer intellectual laziness. In the future, the use of semantic HTML combined with Siri-like human language processing could lead to technology that makes doing the right thing, intellectually, as easy as running a spell-check.

The technology to do this is here, albeit in a primitive form (at the moment something like Apple’s Siri requires a massive server-farm). The content is there too, but it still needs a lot of work in terms of marking up the semantic connections between articles and their sources.

And that’s something I think webdevelopers like myself and countless others can – and should – do our part for. And it could start as easy as just using <blockquote> and <cite> correctly.

Lynx would not be impressed ∞

Principal Developer Evangelist of the Mozilla Developer Network Christian Heilmann weighs in on the semantics issue:

A lot of the debate about semantic value and using the correct HTML is kept alive by people who have been around for a long time and seen browsers fail in more ways we care to remember. Valid markup and sensible structure was our only chance to reach maintainability and make sense of the things around us. This was especially important in the long long ago. I remember using Lynx to surf the web.

What follows is a brief history of webdesign and he wraps up with some advice for the pragmatic use of HTML

• If you write a document by hand, use all the semantics you can add in. This is your handwriting, your code is your poetry and people learn from looking at what you did.
• If you need to write a hard-core application and every byte is a prisoner try to play nice with the semantics but follow your end goal of delivering speed. Make sure to tell people though that your code is the end result of conversions and optimisations and not for humans to look at.
• Regardless of what you build – when you can use new technology (maybe in connection with old, like <div class="section"><section></section></div>) use it.
• Remember that the web is not your browser and computer – add fallbacks for other browsers when using bleeding edge technology. When the others catch up you won’t have to alter your code!
• The main focus of markup and web code that is not optimised for edge case apps is to make it easy for people to maintain it. If people can see in the HTML what is going on – win. If what only works with JS is generated by JS- even better.
• More markup is not a crime when it is markup that adds value. Arguments that STRONG is worse than B because it means more code and slower loading pages are irrelevant in times of gzipping on the server
• We can only escape the chicken and egg problem of new HTML when we use it. Right now, if you ask for support in browsers for new elements the answer from most vendors is that nobody uses them so why bother. And when you ask people why they don’t use them they tell you because browsers don’t support them. One of us has to start changing that.

Recommended reading for those of us walking the tightrope between semantic purity and just getting the job done.

Sensible mediaqueries

Or “A perfect blend of best practices and developer comfort, using LESS CSS”

Mediaqueries are the new black. They really are, I checked. Ever since A List Apart’s article on Responsive Web Design it seems like every man and his dog are jumping on the CSS3 mediaqueries bandwagon. But as with all bandwagon jumping, enthusiasm can quickly get in the way of efficiency and common sense.

Mediaqueries are awesome, but come with a lot of gotcha’s.

Using mediaqueries doesn’t guarantee your site is optimized for mobile.

Optimization is more than just changing the layout. Mobile users have a high probability of having a slower than broadband connection, and so it isn’t a good idea to have them download images made to be viewed at resolutions far higher than their current device.

… but if you look at most sites displaying responsive layouts today, that’s exactly what they’re doing. The first layout they finalize is the standard desktop version, optimized for 1024×768, and they then use mediaqueries to twist and distort their desktop version into a mobile frame. Not only does this result in a coding nightmare where you’re constantly having to reset your own CSS rules, but it also misses the point of having a mobile site by having their users first download all the desktop-resolution art assets, and then download the smaller images on top of that.

So the best practice for making mobile sites is to build for the smallest screen size first, and then using mediaqueries to create ever bigger layouts as the screen-size goes up (Andy Clarke’s 320andUp boilerplate modification emphasizes and encourages this practice). Working like this means that the mobile browser won’t download any of the bigger images that you define in the higher-res mediaqueries. So the mobile version of a site won’t download the 1600×1200 background image you use in the desktop version, for example.

However, this technique, while being the best practice, is impractical for those of us living in the real world where not everyone (who’s not on a mobile device) uses Google Chrome on a Macbook Air in a trendy coffeeshop. I’m talking of course about the dreaded Internet Explorer.

Mediaqueries break in older browsers.

And by “older browsers” I mean of course IE6, IE7 and IE8. No other browser-manufacturer has upgrade schemes that are as broken as IE’s which means that we have to continue to support browsers that are literally *years* out of date. (Note: when’s the last time someone asked you to fix a browser issue with Firefox 2? Exactly my point.)

So anyway, IE right up until version 8 has absolutely no support whatsoever for mediaqueries. The above mentioned 320andUp uses the excellent respond.js script to force IE to recognize and respond to mediaqueries as a workaround to this issue, but I have several reservations against using this.

The first is that it doesn’t really improve IE users’ experience with the site. Instead of getting a responsive website, they’re constantly treated to a page that first looks broken, than flashes a bit and then looks okay. Not exactly the shining example of responsive webdesign we’re looking to serve these people.

Then there’s the fact that if Javascript is disabled, they’ll still be stuck with only the lowest-level mobile layout of the site. For IE6 I have no qualms whatsoever about this happening, as it’s really not that different from just serving them a universal IE6 stylesheet. IE7 and IE8 on the other hand are still shafted though, by having their already suboptimal experience becoming even more crippled.

And then the final reason for using respond.js being a bad idea is that, as a front-end developer on a strict deadline, having not just one, but 2, 3 or even 4 different layouts to debug in Internet Explorer isn’t exactly a fun thing to look forward to.

And it’d be mostly wasted effort as well, since most people using IE won’t expect (or need) to view your site in many different resolutions.

So why give yourself the extra stress? Click on to read my solution.

(more…)

Jason Santa Maria: A real webdesign application

Jason Santa Maria - A Real Web Design Application

Prominent webdesigner Jason Santa Maria wrote an interesting article the other day about the pro’s & cons of current webdesign tools (such as Photoshop, Fireworks, etc…) and what a true webdesign application (if it were created today) would need. It’s an interesting read, so check it out at:

http://jasonsantamaria.com/articles/a-real-web-design-application/

The author raises a lot of valid points, notably the huge disconnect between designing static pixels in Photoshop & co. and the crafting of HTML markup, CSS styles and how to resolve cross-browser inconsistencies. Jeffrey Zeldman wrote a similar article a while back and makes the point that hand-coding HTML/CSS isn’t going anywhere anytime soon. I’m of a similar opinion.

(more…)