tag:blogger.com,1999:blog-178096005657356112024-03-13T04:07:50.412+01:00Itpastorn's Webdev + Thinkpad update & maintenance blogThis is a way for me to share my experiences using Thinkpad laptops using Linux, for web development.Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-17809600565735611.post-38738224351726223792012-02-11T18:23:00.003+01:002012-02-11T18:36:38.461+01:00On CSS vendor prefixes and applying pressure where it is making most sense<p>If you are a web developer chances are pretty good that you have read quite o lot of tweets and blog posts
on vendor prefixes lately. It all started <a href="http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW">when Daniel Glazman issued an urgent call for action</a>. Various people have chipped in including <a href="http://www.brucelawson.co.uk/2012/vendor-prefixes-mobile-monoculture/">Bruce Lawson</a> and <a href="http://www.webstandards.org/2012/02/09/call-for-action-on-vendor-prefixes/">the Web Standards Project</a>.</p>
<p>This is an expanded version from a comment I wrote on <a href="http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/Some-clarifications">Daniel Glazman's blog</a>.</p>
<h3>My background</h3>
<p>Please bear with me as I explain my background. It is important for the thoughts I have at the end.</p>
<p>I am an educator. I teach web development for a living and has done so for more than a decade. As a consultant for Skolverket, Sweden's national agency of education I have in fact succeeded in making standards, accessibility and best practices <a href="http://translate.google.com/translate?sl=en&tl=sv&js=n&prev=_t&hl=sv&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.skolverket.se%2Fforskola-och-skola%2Fgymnasieutbildning%2F2.2576%2Fsok-program-och-amnesplaner%2Fsubject.htm%3FsubjectCode%3DWEB">mandatory requirements for all teaching in the country</a> at the secondary level (approx. senior high school in the USA/A-levels in UK).</p>
<p>I am participating in <a href="http://www.webstandards.org/action/edutf/">the Web Standards Project Education Task Force</a>, am co-author of <a href="http://interactwithwebstandards.com/">InterACT with Web Standards</a> and have written material for the <a href="http://interact.webstandards.org/">InterACT curriculum project</a>. I also participated in <a href="http://www.w3.org/2009/02/owea-xg-charter.html">OWEA</a> and now <a href="http://www.w3.org/community/webed/">the Web Education Community Group</a> at the W3C. (Of course nothing on this blog is the official position of any such entity.)</p>
<p>I thoroughly <strong>believe in education!</strong></p>
<p>Nevertheless I do not see how education alone can solve the problem at hand. Too much misinformation, too much marketing, too much Apple- and Google-centric journalism. Education can only <strong>alleviate</strong> the problem, never solve it.</p>
<h3>There is a solution available that will make the problem disappear</h3>
<p>There is in fact a solution available. One that would do more good than anything else.</p>
<p><strong>Webkit must drop support of prefixed properties when there has been a standards compliant solution implemented</strong>, after a <em>reasonable grace period</em>. Say 6 months.</p>
<p>This is after all what all other browser vendors are doing right now.</p>
<p>This is how prefixes are <em>supposed to work</em>. This is the right thing! Anything else is a violation of the principle.</p>
<p>And yes, this will <strong>break sites</strong>, which is <strong>the exact point</strong> of this solution!!!</p>
<p>This is the only way to create the necessary urgency that will reach into web development sweat shops in India and China, as well as into the corporate management level in the larger companies.</p>
<p>There are educated web developers that simply do not have the time or the mandate to fix problems like these, because upper management do not care. They think about their own product here and now, not what's good for the web as a whole 10 or 15 years into the future.</p>
<h3>Let's apply pressure on Apple</h3>
<p>This is primarily not about <em>blame</em>, but applying <em>pressure</em> where it is <em>most useful</em>.</p>
<p>Let's create and uproar in the web development world strong enough to create bad will for Apple, forcing upper management to do the right thing!</p>
<p>Apple (and to a lesser extent Google) are sitting on the solution. Not Microsoft, not Mozilla, not Opera.</p>
<p>If they are getting away with acting badly it is because we are letting them, letting love for the products they make get in the way of the higher goals, letting them behave in ways that perhaps was OK when the iPhone was launched and Webkit had 0 % market share on mobile, but not changing their way according to <strong>the present situation</strong>.</p>
<p>Apple initially supported SOPA and PIPA – which speaks volumes about the default mind set within the company – but back peddled. So even if they have claimed that they will never remove the support for prefixes, let's create enough pressure on Apple that they will <em>benefit</em> from back peddling again!</p>
<p>Right now <a href="http://www.change.org/petitions/microsoft-mozilla-opera-dont-make-webkit-prefixes-a-de-facto-standard">the pressure is applied to Mozilla, Opera and Microsoft</a> to do the right thing, even if it will hurt their market share – and by extension their ability to fight for a free and open web in the long run. <strong>We are asking those companies to sacrifice themselves for the common good and for higher ideals.</strong></p>
<p>But Apple is either loved too much for anyone to act against them – or seen as a lost cause, an unfixable problem, the IT equivalent of North Korea.</p>
<p>As long as the web development community is stuck in that love/hate relationship with Apple, we can never act sensibly.</p>
<h3>Who can afford it?</h3>
<p>Apple has just had a <a href="http://www.macnewsworld.com/rsstory/74269.html">another record quarter</a> and even may <a href="http://www.infopackets.com/news/business/apple/2011/20110331_apple_to_surpass_hp_ibm_in_sales_by_2013_analyst_says.htm">surpass IBM and HP</a> in a few years.</p>
<ul>
<li>Still they won't hire evangelists like Opera, Google and Mozilla <em>that teach best practices</em>.</li>
<li>Still they won't hire full time spec writers to get their proprietary extensions through the standardization process.</li>
</ul>
<p>The takeaway from every Apple keynote I've heard the last years is "concentrate on the iPhone and iPad".</p>
<p>This message need to change!</p>
<p>The other main stakeholder in Webkit is Google. And <a href="http://investor.google.com/earnings/2011/Q4_google_earnings.html">their business is not shabby either</a>. In fact it is Android and Chrome that has made Webkit the most popular browsing engine in the world.</p>
<p>But Google embraces open more than Apple. Google may very well be quite easily persuaded to stop supporting prefixed properties for <em>mature</em> technologies, in my opinion.</p>
<p>It is Apple that primarily needs to be pressured.</p>
<h3>What's at stake?</h3>
<p>Since Mozilla not only develops their browser openly, but has an open process for just about anything I stumbled upon their internal discussion about supporting -webkit- prefixes already a few months ago. First of it is quite clear that nobody within that organizations likes the idea of supporting -webkit- prefixes. Even those that support the idea do so with the utmost distress.</p>
<p>But except for some Gnu/Linux distros Gecko is not the default rendering engine anywhere. Opera is in a similar position. For the majority of users their is but one incentive to switch: <em>A better user experience.</em></p>
<p>That is the bottom line.</p>
<p>Not ideology, but my experience as a user <strong>today</strong>, is what makes people switch.</p>
<p>However, since Mozilla and Opera to a high degree are <strong>value driven</strong> organizations it is easy to think that it is "their job" to keep the web open. But if right decisions comes at the cost of minuscule market shares they won't have much power to wield anyway.</p>
<p>And please remember that Opera and Mozilla did go down the path of ideology concerning video codecs. Would that have been possible today when their market share is falling?</p>
<h3>It's time for Apple to pay back</h3>
<p>Apple has never been a true champion of the open web or indeed anything open. Despite the fact that open technologies saved Apple from ruin. That, and two important gifts from Microsoft: Cash in return for stock that gave no voting power and a commitment not to stop developing Office for Mac OS.</p>
<p>Back in the 90's Apple struggled to develop a modern and technologically sound operating system. <a href="http://en.wikipedia.org/wiki/Copland_%28operating_system%29">Copland</a> failed. <a href="http://en.wikipedia.org/wiki/Taligent">Taligent</a> failed. And so did a bunch of other efforts.</p>
<p>The number one option was to buy <a href="http://en.wikipedia.org/wiki/BeOS">BeOS</a> and that deal almost came through. (Imagine the world if it had! Steve Jobs return would probably not have happened...) </p>
<p>However, what Apple could not develop in house they found in open source:</p>
<ul>
<li>The <a href="http://en.wikipedia.org/wiki/Mach_kernel">Mach kernel</a>.</li>
<li><a href="http://en.wikipedia.org/wiki/Berkeley_Software_Distribution">BSD</a></li>
<li><a href="http://en.wikipedia.org/wiki/KHTML">KHTML</a> from which Webkit is forked.</li>
</ul>
<p>But also this might not have been. KHTML developers came very close to throwing in the towel and switching to Gecko.</p>
<p>Once again, what if they had? What if they had not persisted thanks to <strong>ideology</strong>, not business considerations?</p>
<p>Projects driven by ideology provided Apple with the core technologies from which they have built Mac OS X, iOS and the Safari browser.</p>
<p>And Apple also benefited from Firefox. It was Firefox that wrestled the web away from Microsoft. It was Firefox embracing standards that provided the opportunity to develop a browser like Safari. Remove Firefox from the equation and there would never have been a superior browsing experience on the iPhone. Those experiences were made possible from developers embracing standards thus eliminating the Microsoft monoculture.</p>
<p>So why should Apple help the world? Because the world first helped Apple!</p>
<p>Once again, we should apply pressure where pressure is due.</p>
<p>Unconditional love or unconditional hate bestowed upon Apple will both just make the company worse. And as for the latter (hate), did you notice that Apple actually pack peddled concerning SOPA and PIPA? Given enough pressure the company actually can abandon bad ideas.</p>
<p>If the web development community keeps praising Apple as if the company does nothing wrong – or at least nothing wrong that can't be excused – or if we treat Apple like a lost cause, a closed brainwashed sect incapable of change, then by all means, put all pressure on Mozilla, Opera and Microsoft.</p>
<p>But please acknowledge that in so doing we are forfeiting our best chance to keep the web open. Remember, this is not so much an issue of who is to blame, as it is an issue of how it could be fixed.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com1tag:blogger.com,1999:blog-17809600565735611.post-53882922027790319982011-11-20T14:46:00.007+01:002011-11-20T15:07:00.869+01:00Still using Firefox because privacy matters<p>I am still using Firefox as my number one browser, occasionally switching to Opera, and occasionally trying out Chrome (on my Laptop). Why am I so stubborn, some Chrome fans will ask? And why am I not using the default Android browser on <a href="http://www.lenovo.com/products/us/tablet/thinkpad/">my slate</a>? And why did I not end up buying an iPad?</p>
<p>It all boils down to two points: The browser ecosystem and the browser <a href="http://en.wikipedia.org/wiki/Ethos">ethos</a>.</p>
<h4>The web is more important than apps</h4>
<p>
Sometimes I hear people say <q>it's all about the apps</q>. I disagree. The web is the only one truly open and life changing platform. I did not chose Android over iOS because of usability or design concerns. I'd say it is still slightly – but only very slightly – behind. My new phone is a <a href="http://en.wikipedia.org/wiki/Nokia_N9">Nokia N9.</a> Neither Android or iOS, but Meego! And yes, it has a few hundred apps, including <a href="http://www.meegoexperts.com/2011/10/dropn9-qt-based-free-dropbox-client-nokia-n9-n950-meego-harmattan/">a Dropbox client</a> and <a href="http://www.meegoexperts.com/2011/04/google-reader-client-newsflow-v1-4-symbian-maemo/">a Google Reader</a>.</p>
<p>
(By the way, the user interface on the N9 is just fantastic, it beats both the iPhone and Android!)
</p>
<p>
However, both the Android Tablet and the Meego Phone lets me run Firefox. And that is nowadays a <a href="http://en.wikipedia.org/wiki/Sine_qua_non">sine qua none</a> for me when choosing a device.
</p>
<h4>Every major browser has an ecosystem nowadays</h4>
<p>
Of course all browsers can surf the web and in that regard the web is their ecosystem. But in addition to that they come with additional features.
</p>
<ul>
<li>Internet Explorer's ecosystem is that of corporate intranets, Windows and the occasional web site that still requires ActiveX. I know of few people who enters this ecosystem by choice, except gamers, but it is easy to get support. And all your games are playable on the hardware that is far cheaper than anything from Apple. And Windows does really have the best graphics drivers and infrastructure for sound.</li>
<li>Chrome's ecosystem is of course Google products: G-mail, G-cal, G-reader, G-docs and G+. You're at least considering getting an Android phone and think that Chrome OS has a lot more potential than it has shown so far. You are obviously not so concerned with <a href="http://gawker.com/5419271/google-ceo-secrets-are-for-filthy-people">the privacy of your data</a>.</li>
<li>Safari's ecosystem is of course the Apple products. If you are into Apple, you're using a Mac, and every program in sight that starts with an <q>i</q>. You had an iPod and now have an iPhone and you will get an iPad, not because you need it, but because its made by Apple. In short, you enjoy the shiny prison of being locked in to Apple. Censorship and authoritarian control of the platform be damned – the bars are golden!</li>
<li>Opera thrives on the mobile and on devices. They have managed to make web surfers out of millions of people who never could afford a modern smart phone. In some ways though, they struggle since the entire web universe basically is their ecosystem – except for sites made by incompetent developers that shut Opera out for no good reason. There are things like <a href="http://www.opera.com/link/">Opera Link</a> and <a href="http://unite.opera.com/">Opera Unite</a>, but they have not got the buzz they so rightfully deserve. The fact that Opera pioneered many things now common to all browsers, like tabs, and have always been a true champion of standards, even before Mozilla appeared, makes them worthy of tons of respect.
</li>
</ul>
<p>So, what makes Firefox ecosystem so special? It boils down to one thing. Firefox is everything!</p>
<ul>
<li>It is not the oldest champion of web standards among browser vendors, as that honor goes to Opera, but they are a good runner up, and it was Firefox that de facto <em>wrestled the web away from Internet Explorer</em>, providing room for all other browsers to exist as well. Firefox <strong>paved the way</strong> for both Safari and Chrome!</li>
<li>It is not the true speed king, as that title goes to Chrome or perhaps Opera, that are faster on most – but not all – benchmarks as far as I can tell. <strong>But it is fast enough.</strong> And it championed the cause of being lean – once upon a time! Even today it consumes far less system resources than most other browsers.</li>
<li>It is, however, the true champion of add-ons. And it has the best add-ons <a href="https://addons.mozilla.org/en-US/firefox/collections/itpastorn//">for my needs</a>.</li>
<li>Firefox has the <strong>best sync</strong>. First of all it is <strong>client side encrypted</strong>, meaning no data mining opportunities for Google or anyone else. But what makes it stand out is the <strong>syncing of tabs</strong>. It's a time saver and a life improvement factor! I sue it all the time, moving between computers, my phone and my tablet.
</li>
</ul>
<h4>The right focus for the future</h4>
<p>
The economy of the future in IT is data driven. In a world of <a href="http://en.wikipedia.org/wiki/Ubiquitous_computing">ubiquitous computing</a> stewardship of our data in the cloud is the main prize for all big players to fight about. Through <q>pads, tabs and boards</q> data will be accessible in lots of places. But whoever is in control of the cloud is the winner of the future.
</p>
<p><strong>But will cloud stored data be accessible to all? Or only a select few that use the right brand?</strong></p>
<p><strong>And will it be <em>inaccessible</em> to anybody except those that I chose to share my data with? Or will the host continually mine my data and in the worst case scenario share it without my consent?</strong></p>
<p>
In this regard, Apple's guiding principles fail totally. The company shows close to zero interest in interoperability and since the margins go down when selling cheap devices this becomes a <strong>global problem</strong>. By building digital walls around the data in the richest countries, we are once again failing all non-western countries.
</p>
<p>
By the way, the Arab spring was not brought to the world by Apple, but by Nokia…
</p>
<p>
Google might not have failed yet. Interoperability is high on their agenda and so far their data mining seem to be <em>mostly</em> anonymized. But when <strong>one single entity</strong> sits on too much data and control the complete surrounding ecosystem, we are providing someone with enormous temptations. Sooner or later that temptation will become too strong!
</p>
<p>
Therefore we need truly anonymized cloud technologies. We need <strong>user owned and controlled</strong> data.
We need stuff like <a href="https://browserid.org/">browser id</a> to replace the usage of id-solutions provided by Google, Facebook, Twitter, Microsoft or Apple.
</p>
<p>
In short, we need what Mozilla and Opera are championing. And for me personally that means that if you see me using a browser for anything but testing, that will still be Firefox for the foreseeable future, unless I change to Opera!
</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com1tag:blogger.com,1999:blog-17809600565735611.post-45694888213180802302011-06-20T23:03:00.005+02:002011-06-22T01:22:02.343+02:00Will my next laptop be a Thinkpad?<p>It’s time to move on from my trusty old Thinkpad z61p. It has been a dear friend, but its simply not anywhere near state of the art anymore. Still, having lasted over 4 years and many thousand hours of heavy duty use is high praise indeed.</p>
<p>
So what do I want? I had hoped for an upgrade of the <a href="http://www.thinkwiki.org/wiki/Category:W701">Thinkpad W701</a>,
to use <a href="http://en.wikipedia.org/wiki/Sandy_Bridge">Sandy Bridge</a> and
<a href="http://www.intel.com/technology/io/thunderbolt/index.htm">Thunderbolt</a> – but instead the series seems canceled.
<a href="http://shop.lenovo.com/us/notebooks/thinkpad/w-series/w701">Where is the follow up to the W701?</a>
Why, oh, why have you forsaken me Lenovo? (I actually don’t know. Lenovo’s web site is basically useless.)
It takes a ton of work to find the information I actually want.
</p>
<p>I want a workstation, movable but not ultra portable. More power. And it may weigh a few kgs.</p>
<h4>Stuff the computer <em>must</em> have</h4>
<ul>
<li>A trackpoint – a high quality, usable Trackpoint. Does any other line of Laptops except Thinkpad have those?</li>
<li>A really good keyboard. Once again, can I trust any other manufacturer than Lenovo?</li>
<li>Preferably 17 inch, high resolution (1920px wide), high contrast – matte. Not glossy!
(Maybe I must settle for 15 inch, but it would be very disappointing.)</li>
<li>A high speed SSD, as big as possible.</li>
<li>It should run Linux with no hickups. My distro of choice is Fedora. For testing purposes I may shrink and keep the Windows partition,
but it will see very little usage. (If buying an OS-less laptop was an option, I’d chose it.)</li>
<li>Firefox and Chrome should be able to run WebGL on Linux, thus the graphics drivers must be on their
<a href="https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#OpenGL_on_X11_in_Firefox_6_and_newer">whitelist</a>.</li>
<li>Display port or HDMI</li><li>Service should be available in Sweden, so lesser known brands are out of the question.</li>
</ul>
<p>All of the above are top priorities. And I am prepared to spend quite a lot of money on this purchase.</p>
<h4>Then there are a few things that goes without saying</h4>
<ul>
<li>High end modern CPU, like the <a href="http://www.intel.com/consumer/products/processors/corei7-extreme.htm">2920XM</a> or one step down from that one.</li>
<li>At least 8GB of RAM DDR3 or better.</li>
<li>Gigabit Ethernet.</li>
<li>IEEE802.11abgn.</li>
<li>Bluetooth 3.0.</li>
<li>At least one USB 3.0 port,</li>
<li>Large and high performance SSD,</li>
</ul>
<h4>And there is also a list of <em>nice to have</em> features on my wish list</h4>
<ul>
<li><a href="http://www.youtube.com/watch?v=SmBXU9Jz7qM">Spill proof keyboard</a>.</li>
<li>Back lit keyboard.</li>
<li>Thunderbolt</li>
<li>2nd drive for storing large files that I do not use very often, video, images, sound. (Yes, the W701 had 2 drives...)</li>
<li>A Firewire interface</li>
</ul>
<p>
I prefer a 2nd drive to optical media. If there is only room for one drive, chances are high I will ditch the
optical drive and use that space for an extra hard drive.
</p>
<h4>So, what are my choices? Right now the list looks like this:</h4>
<ol>
<li><a href="http://newnotebookinfo.com/lenovo-thinkpad-w520-review-specs-price">Thinkpad W520</a>, but it has only got an 15 inch screen…</li>
<li><a href="http://h10010.www1.hp.com/wwpc/se/sv/sm/WF25a/321957-321957-64295-4307559-4307559-5071180.html">HP EliteBook 6760w</a>, but will the Trackpoint be good enough… (and I can't find a model with the 2920XM processor, <abbr title="On the other hand">OTOH</abbr> I can get it with a better graphics chip, up to the <a href="http://www.notebookcheck.net/NVIDIA-Quadro-5010M.47195.0.html">Quadro 5010M</a>, but that GPU consumes a whopping 100W and is probably a bit too much, even for me.)</li>
<li><del><a href="http://news.softpedia.com/news/Fujitsu-Celsius-H910-Mobile-Workstation-Review-203134.shtml">Fujitsu Celsius H910</a></del> The specs looks nice. I can have up to 2 x 250 GB SSD but the keyboard and Trackpoint is not comparable to a Thinkpad.</li>
</ol>
<p>Given my set of requirements, what other options do I have?</p>
<p>And the key question: Is there any hope for a <em>17 inch Thinkpad W7xx</em> to be released within the next 3-4 months?</p>
<p>(And no Mac is not and never has been an option. And, yes, I have plenty of experience with Macs and know perfectly well how they compare to Thinkpads.)</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com1tag:blogger.com,1999:blog-17809600565735611.post-16505708231410751202011-05-11T21:23:00.000+02:002011-05-13T22:33:20.491+02:00Firefox Aurora and Nightly on LinuxAutomated download and install Firefox Aurora and Nightly on Linux
<h4>ffupdate.sh</h4>
<pre><code>
#!/bin/bash
FTPDIR="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly"
AURORA="firefox-5.0a2.en-US.linux-i686.tar.bz2"
NIGTHLY="firefox-6.0a1.en-US.linux-i686.tar.bz2"
DLDIR="Hämtningar"
#
cd ~/${DLDIR}
rm -rf firefox*
test -d /opt/aurora || sudo mkdir /opt/aurora
wget ${FTPDIR}/latest-mozilla-aurora/${AURORA}
test -f ${AURORA} && tar xjf ${AURORA} || \
( echo "Aurora download fail" && exit 1 )
sudo rm -rf /opt/aurora/*
sudo mv firefox/* /opt/aurora/
rm -rf firefox*
test -d /opt/minefield || sudo mkdir /opt/minefield
wget ${FTPDIR}/latest-trunk/${NIGTHLY}
test -f ${NIGTHLY} && tar xjf ${NIGTHLY} || \
( echo "Nightly download fail" && exit 1 )
sudo rm -rf /opt/minefield/*
sudo mv firefox/* /opt/minefield/
rm -rf firefox*
</code></pre>
<p>
To be improved and adjusted when new versions appear, but it does the job for now.
</p>
<h4>Excerpt from .bashrc</h4>
<pre><code>
alias ff36="/usr/bin/firefox -no-remote -P ff36 &"
alias ff4="/opt/firefox4/firefox -no-remote -P ff4 &"
alias ffclean="/opt/firefox4/firefox -no-remote -P clean &"
alias ffbeta="/opt/ffbeta/firefox -no-remote -P beta &"
alias ffaurora="/opt/aurora/firefox -no-remote -P aurora &"
alias minefield="/opt/minefield/firefox -no-remote -P minefield &"
</code></pre>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com2tag:blogger.com,1999:blog-17809600565735611.post-45130702158376731152010-11-26T15:03:00.006+01:002011-11-19T11:08:25.648+01:00Tidy5 aka the future of HTML Tidy<p style="margin:10px;border:2px solid green;border-radius:3%;padding:10px"><strong>UPDATE 2011-11-19: </strong> The most immediate of my concerns
<a href="http://lists.w3.org/Archives/Public/www-archive/2011Nov/0007.html">have been addressed by Björn Höhrmann</a> who has submitted basic support for HTML5 in Tidy to
<a href="https://github.com/w3c/tidy-html5">a forked version available on Github</a>.</p>
<p>I have been a long time fan of <a href="http://tidy.sourceforge.net/">Tidy</a>, a tool to clean up and do some basic checks on the code. However, the tool is not really being updated any more, and since I have moved to using HTML5 and ARIA on all my new projects, it has lost much of its usefulness.</p>
<p>I also see no momentum picking up and thus think it should be considered folding Tidy into <a href="http://code.google.com/p/html5lib/">html5lib</a>. By that I mean using html5lib to get Tidy like functionality.</p>
<p>Today I wrote a mail that I cross posted to <a href="http://lists.w3.org/Archives/Public/html-tidy/2010OctDec/0015.html">the discussion list for Tidy</a> and <a href="http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-November/000689.html">the help list for WHATWG</a>. This blog post is essentially a longer version of that email.</p>
<h4>Tidy must go HTML5</h4>
<p>Here is the deal with HTML5. Pretty soon every browser will have an HTML5 parser. Except for IE, browsers do not have multiple parsers.</p>
<p>This means that tokenization and DOM tree building will follow the rules defined in HTML5 – as opposed to not really following any rules at all, since HTML 4 never defined them.</p>
<p>Simply put, there is no <q>opt out</q> of HTML5. An HTML 4 or XHTML 1.x doctype is nothing more than a contract between developers. Technically all it does is to set the browser in standards compliance mode.</p>
<p>Thus, I do not see any future in a tool that does not rely on the HTML5 parsing algorithm. Tidy can not grow from its current code base, but needs to have the same html5lib at its core that is in the HTML5 validator, which basically is the same as the one being used in Firefox 4.</p>
<p>Additionally, Tidy suffers from:</p>
<ul>
<li>Implementing WCAG 1 checks in a world that has gone <a href="http://www.w3.org/TR/WCAG20/">WCAG 2.0</a>.</p>
<li>Not recognizing <a href="http://www.w3.org/WAI/intro/aria">ARIA</a>, which is an extremely valuable technology on the script heavy pages of today.</li>
<li>Not recognizing SVG and MathML.</li>
</ul>
<p>I know one can set up rules to enable Tidy to recognize more elements and attributes, but for full HTML5 + ARIA + SVG + MathML (and perhaps RDFa), that is simply not doable without superhuman efforts.</p>
<h4>The merge</h4>
<p>A basic <q>Tidy5</q> implementation could look like this:</p>
<ol>
<li>Parse the tag soup into a DOM.</li>
<li>Serialize HTML from that DOM.</li>
<li>Compare the start and the end result.</li>
</ol>
<p>Perhaps any error reporting can be made <em>during</em> the parsing process. <a href="http://hsivonen.iki.fi/">Henri Sivonen</a> could probably answer the question if that is possible.</p>
<p>However, there is also <a href="http://itpastorn.blogspot.com/2009/09/pedagogic-validation-of-html.html">talk about having a lint like tool for HTML</a>, that goes beyond what the validator does. So in addition to the above, there can be settings for stuff like:</p>
<ul>
<li>Implicit close of elements. Tolerate, require or drop all closing tags?</li>
<li>Implicit elements – tolerate, require or drop (maybe require body but drop tbody...)?</li>
<li>Shortened attributes – tolerate, require or drop?</li>
<li>HTML 4 style type attributes on <script> and <style> – tolerate, require or drop?</li>
<li>Explicit closing of void elements – tolerate, require or drop?</li>
<li>Full XHTML syntax (convert both ways)</li>
<li>Indentation. Preferably with an option not to have block elements with a very short text content not to be broken up into 3 rows as in Tidy today.</li>
</ul>
<p>Besides purification and linting, such a tool/library can be used for:</p>
<ul>
<li>Security. This will require the possibility of white and/or blacklisting elements and attributes. And preferably also attribute values.</li>
<li>HTML post processing. This will enable authors to see indented code, that is explicit, while at the same time such "waste" can be removed before gzipping. This would be akin to JS minification and it could be performed on the fly from within PHP, Python, Java, Ruby, C#, server side JS or whatever. It can also be done manually before uploading from the development environment to production - or it could be integrated into the uploading tool!</li>
</ul>
<h4>Checking templates</h4>
<p>The <strong>main</strong> feature that Tidy has today, is the ability to handle templates, by preservering/ignoring PHP or other server side code. To what extent the HTML5 parser can be modified to handle that feature I do not know.</p>
<p>From a maintenance and bug fixing point of view, I see <em>huge</em> wins in having a common base for Tidy, the HTML5 validator and HTML parsing in Gecko.</p>
<p>In fact, a very radical idea for Firefox (or any other browser using html5lib) would be to actually integrate these tidy-inspired features directly in their development tools, re-using the existing parser! A Firebug extension that lets me validate as well as tidy up my code directly within the browser would be super awesome!</p>
<p>But the actual possibility thereof is beyond my technical knowledge to evaluate, so I need to hear from people who know this stuff better than I do.</p>
<h4>Integration with accessibility checking</h4>
<p>Although automatic testing can not not substitute manual tests, they can give a developer an <q>in the ball park</q> idea about the accessibility of a page and fix the most obvious mistakes.</p>
<p>The fact that Tidy today do integrate WCAG 1.0 is better than nothing and any implementation of <q>Tidy5</q> should strive to integrate WCAG 2.0 in a similar fashion. That really is a no brainer. Having to use only one tool and getting all errors in the same buffer (for programmers) or the same console (for manual checks) is certainly convenient.</p>
<p>OK, that was my two cents. What do you think?</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com11tag:blogger.com,1999:blog-17809600565735611.post-84476618188401891892010-10-18T15:04:00.011+02:002010-10-18T20:50:06.032+02:00How to know if you are watching a bad JavaScript tutorial for beginners<p>Answer: <strong>You are watching it.</strong> There are no good tutorials for beginners anywhere!</p>
<p>
People who actually know enough to teach JavaScript properly either don't have the time to teach, since they get paid
to work for clients and when they do teach, they do so at conferences or seminars in front of their peers, not to
newbies. That means that what's available on-line for beginners is stuff taught by people who do not know enough
to actually teach.
</p>
<p>
For me as a professional teacher that means that I have to devote considerable time to warn my students about bad habits,
thus wasting valuable lesson minutes, which turn into hours. And there are always someone who missed a class, and
tried to compensate by Googling or YouTubing – something teachers normally would encourage – but will turn
in bad work, that I have to give a lower grade. Thus, the worst case scenario is <strong>that students are actually
punished in a way for taking an initiative</strong>.
</p>
<h4>Bad pedagogy</h4>
<p>
One of the things I've learned developing for the web for 15 years and teaching it the last 9, is that it is way more
effective to learn things the right way from the start, and then be warned about some bad or outdated habits to avoid.
Learning bad stuff, <strong>and then un-learning</strong> will harm students' motivation, confidence (<q>how can I trust
anything I read?</q>) and slow down the learning process.
</p>
<p>
Also, to a newbie it is not immediately apparent why a particular way of doing things is bad, so they tend to stay with
their bad practice, even though they may hear that they shouldn't. <q>But it works!</q> of course I answer something
like <q>Yes, but <a href="http://www.jibbering.com/faq/names/event_handler.html">it's fragile</a>, not scalable, hurts
performance and violates good style</q>, but it will take a very long while until I can actually <strong>show</strong>
them that this is the case, and a demonstration is more worth than a thousand words.
</p>
<p>
And habits, once formed, have a tendency to become automatic, instinctive. They are hard to un-learn.
</p>
<p>
Don't believe me? Look at the <em>praise</em> in the comments for this
<a href="http://www.youtube.com/watch?v=Bp0lcXlF7xc" rel="nofollow">super crappy JavaScript tutorial on YouTube</a>.
People are saying thing like <q>now I know how to do it</q>, when they should be saying that now they know how
<strong>not</strong> to do it.
</p>
<h4>What's out there?</h4>
<p>
My students belong to the YouTube generation. They prefer videos to words, demonstrations to articles, images to text.
Thus, nowadays the first place I look for material to use is on sites like YouTube or Vimeo, but every single beginners
tutorial I've found so far is crap. They all exhibit most of the following <q>features</q>:
</p>
<dl>
<dt><code>documen.write()</code></dt>
<dd>All by itself, <code>document.write()</code> is bad and should be avoided. This is way more important than
keeping the "hello world" tradition alive. If you really must do that, at least use <code>alert()</code> since it
does not alter the DOM and thus does not give a wrong impression…</dd>
<dd><code>document.write()</code> is giving the impression that JavaScript has a linear execution model and that
<code>document.write()</code> works like <code>echo</code> in PHP, or <code>cout</code>.</dd>
<dd>The faster students get into an
<a href="http://www.yuiblog.com/blog/2010/08/30/yui-theater-douglas-crockford-crockford-on-javascript-scene-6-loopage-52-min/">event-loop/event-driven programming mindset</a>, the better!</dd>
<dt>Inline event handlers</dt>
<dd>As PPK says,<a href="http://www.quirksmode.org/js/events_early.html">Don't use it</a>.</dd>
<dt>Hiding JavaScript from old browsers using HTML-comments</dt>
<dd>Yup, in the year 2010 some wannabe teachers think you should still be nice to
<a href="http://www.holgermetzger.de/Netscape_History.html">Netscape 1.2</a> and early versions
of <a href="http://en.wikipedia.org/wiki/Mosaic_(web_browser)">Mosaic!</a> Monkey sees, monkey does.</dd>
<dt>Setting the language attribute on script tags</dt>
<dd>Now that we are learning that even the <strong>type</strong> attribute is
<a href="http://doctype.com/html5-optional-type-property-script">not needed any longer</a>, I still see people
use the <strong>language</strong> attribute.</dd>
<dt>It is OK to omit semi-colons on the end of a statement</dt>
<dd>This is telling students that it is OK to rely on
<a href="http://robertnyman.com/2008/10/16/beware-of-javascript-semicolon-insertion/">automatic
semi-colon insertion</a>.</dt>
</dl>
<p>
I am teaching this stuff for a living and you really <strong>do not need</strong> any of the <q>features</q> listed
above as an intermediate step to learning. When I teach my students, I only mention these in passing, saying that:
</p>
<ul>
<li>If you use them, I will fail you on the course, or at least give you a low grade. (Yes, I will!)</li>
<li>If you receive a tip from someone on a forum, or by Googling, suggesting that they are used, do not listen any more
to that person. Learn to use these only as a sign of bad advice.</li>
</ul>
<p>Which brings us right back to our problem. Where is the good advice?</p>
<p>
There are <a href="http://www.opera.com/developer/wsc/">some good things to <strong>read</strong></a>, but as I've said,
I want videos as well.
</p>
<h4>What I do as a teacher today</h4>
<p>
I recommend watching the way too advanced videos, but only the first couple of minutes, originally meant as a rehash
only by the speaker. I tell my students to watch <q>the first 20 minutes</q> of
<a href="http://vimeo.com/8718165">this video with Robert Nyman</a> and <q>the first 18 minutes</q> of
<a href="http://www.youtube.com/watch?v=hQVTIJBZook">this one with Douglas Crockford</a>.
</p>
<p>
That is not something they do instead of listening to me or reading, but this semester I have occasionally been called away
on <a href="http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=sv&tl=en&u=http%3A%2F%2Fwww.skolverket.se%2Fsb%2Fd%2F193%2Furl%2F0068007400740070003a002f002f0077007700770034002e0073006b006f006c007600650072006b00650074002e00730065003a0038003000380030002f00770074007000750062002f00770073002f0073006b006f006c0062006f006b002f0077007000750062006500780074002f0074007200790063006b00730061006b002f005200650063006f00720064003f006b003d0032003400320033%2Ftarget%2FRecord%253Fk%253D2423">other business</a> and also missed a few days due to illness (nothing serious).
</p>
<p>
If not for these, I might as well let my <strong>Swedish</strong> students look at this one. At least they won't
be taught something bad!
</p>
<iframe title="YouTube video player" class="youtube-player" type="text/html" width="480" height="390" src="http://www.youtube.com/embed/4O5or3zFc6I?rel=0" frameborder="0"></iframe>
<p>(No, I do not speak Hebrew and I have no clue if that is a good video or not.)</p>
<p>And I enforce the following rules:</p>
<ul>
<li>You shall validate your HTML early and often.</li>
<li>You shall validate your CSS early and often.</li>
<li>You shall learn how to use <a href="http://www.jslint.com/">JSLint</a> and use it early and often.</li>
</ul>
<p>
Linting is <strong>not</strong> an advanced topic. It is an essential tool to encourage good habits for newbies.
Besides, validation and linting are not something you do at the end of your development process just to get a stamp
of approval. They are tools to help you along the way.
</p>
<p>
In a similar fashion, I introduce <a href="http://pear.php.net/PHP_CodeSniffer">PhpCodeSniffer</a> very early in my
teaching of PHP. In fact, with every year of teaching, introducing these tools have come earlier and earlier. My web design
students this year were introduced to the HTML validator the very first lesson that I devoted to HTML.
</p>
<h4>Cursing darkness or lighting candles?</h4>
<p>
This blog post basically is me ranting again. However, I do have have put in some considerable effort (if I may
say so myself) to make the JavaScript teaching world a better place, by my work on
<a href="http://interact.webstandards.org/curriculum/front-end-development/dom-scripting-1/?overview">the InterACT
curriculum for DOM-scripting</a> for the Web Standards Project.
</p>
<p>
If you are somewhat knowledgeable about unobtrusive JavaScript, and the
<a href="http://www.youtube.com/watch?v=hQVTIJBZook"><q>good parts</q></a> of the language,
please take a look at the
<a href="http://interact.webstandards.org/curriculum/front-end-development/dom-scripting-1?comp">competency table</a>
and provide a video explaining one or two bullet points from it. You do not have to be Douglas Crockford,
but should at least have heard a couple of his speeches and have read
<a href="http://oreilly.com/catalog/9780596517748">his book</a>.
</p>
<p>
In so doing you will not get the reputation of being a ninja or guru. You won't get a chance to show how clever you are,
but guess what? Rookies eventually grow up to become intermediate programmers, and they may very well evolve to become
rather advanced one day. They will go to conferences and hear you speak on the advanced topics – one day. If you did
provide them with something of real value when they took their first steps, they might just value that experience and
return to hear some more in the future.
</p>
<h4>Bonus teaching tip</h4>
<p>
Use <a href="https://developer.mozilla.org/en/Introduction_to_the_JavaScript_shell">the JavaScript shell</a>, while
talking about basic things like types, variables, operators, expressions, statements and blocks.
</p>
<p>
Since the students are not in the browser environment, they are less likely to transfer bad habits to real work.
The fact that they are in a shell makes it very clear that what they are seeing is not definitive. Even so, <strong>I
will nevertheless point that out</strong> to them, again and again. One must never take stuff like this for granted,
and as a teacher one always have to repeat oneself…
</p>
<p>
Oh yes, when teaching PHP I use <a href="http://php.net/manual/en/features.commandline.interactive.php">the PHP
shell</a> as well.
</p>
<h4>The better version of this post</h4>
<p>
Chris Williams talks about how JavaScript education must be revolutionized (and other things)
in this talk from JSConf.eu 2010. (<a href=http://jsconf.eu/2010/communityjs_by_chris_williams_1.html">transcript</a>)
<p>
<embed height="333" width="540" allowfullscreen="true" allowscriptaccess="always"
type="application/x-shockwave-flash" src="http://blip.tv/play/hq0KgoPNFQA"></embed>
</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com0tag:blogger.com,1999:blog-17809600565735611.post-23396052138411849582010-09-04T11:05:00.007+02:002010-09-04T14:31:56.582+02:00Why H.264 is disqualified from being a web standard<p>In short: H.264 can never become a standard for web video as long as the patents are not released according to <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">W3C patent policies</a>.</p>
<p>The MPEG-LA consortium so far has showed <a href="http://createdigitalmotion.com/2010/08/apple-centric-observers-get-the-facts-wrong-h-264-still-isnt-free-for-firefox/">no interest whatsoever</a> to release their patents in a W3C compatible way. Thus the question is answered, H.264 is not even a candidate for becoming a web standard. It can't win that race, since <a href="http://blogs.computerworlduk.com/simon-says/2010/08/hold-the-h264-celebrations/index.htm">it's not even in the running!</a></p>
<h4>The W3C patent policy</h4>
<blockquote><p>The goal of this policy is to assure that Recommendations produced under this policy can be implemented on a Royalty-Free (RF) basis.</p></blockquote>
<p>You see, it's not a case of <a href="http://shaver.off.net/diary/2010/08/27/free-as-in-smokescreen/">Mozilla</a> and Opera being obnoxious. In fact they are only fighting for the same thing as the W3C is: An open web. Video should be open just like HTML, CSS and the DOM is open.</p>
<p>Yes, the W3C mandates that all standardized web technologies should be free for all and for all types of usage and that as far as they are affected by patents, the owners of those patents legally commit to not stopping such usage.</p>
<h4>But H.264 is implemented natively in the browser</h4>
<p>Yes, it is. In fact there is no law against implementing anything that is not a standard or being considered for standardization. Google implements Flash, <em>within the browser</em>, but that does not make Flash a web standard.</p>
<p>H.264 is usable, and since the drivers are mature technically still the best option for delivery on mobile platforms (more on that later). In fact, would the MPEG-LA consortium consider releasing their patents in a W3C friendly way, it would be an excellent web standard. I don't see that on the horizon, though.</p>
<p>The fact remains that H.264 is a proprietary, patented and closed technology. Some vendors have bought themselves the right to use that technology and others perhaps could, <strong>but that is not the kind of <q>freedom</q> web standards should be made of</strong>. I find it very ironic that people fighting for free and open web standards for markup and stylesheets, for scripting and for graphics (PNG, SVG, etc) and for net neutrality and universal access are so quick to sell out their ideals when it comes to video.</p>
<p>Since H.264 video is implemented natively is some browsers, we can do stuff with it that we otherwise perhaps could not. But there is still precious little we can do that could not be done in Flash. Really. At least when you look at the end result, not at how it's done.</p>
<p>Don't get me wrong, I like having native video in the browser, but <q>native</q> does not equal open.</p>
<h4>An aside: The bigger issue</h4>
<p>There is one ideal solution to this problem of course. The USA should change its patent system, that is flawed and broken beyond usefulness. Patents are granted for user interface ideas, algorithms and all kinds of obvious stuff.</p>
<p>If I'd been an American I'd write my congressman and ask him or her what they are doing about this. And if I'd not be content with that answer I'd vote for somebody else, and I'd let everybody know i DID. If the USA would change its laws, most of the world would follow.</p>
<p>However, since a change in US patent laws not is going to happen soon, we are stuck in this mess for the foreseeable future. So what do we really do about it?</p>
<h4>Could the MPEG-LA consortium be persuaded to change its mind?</h4>
<p>Here is an idea: Let's have <a href="http://ln.hixie.ch/">Hixie</a> add H.264 to the <a href="http://www.w3.org/TR/html5/">HTML5 spec</a> and release that spec in such a way as to start the W3C patent clock. That would mean that any patent holder who feels that their patent is being infringed must protest.</p>
<p>There could be two outcomes. The MPEG-LA could show its true colors and protest or they might succumb to the pressure and actually change its policies. The first alternative would perhaps silence everyone who thinks H.264 is <q>free enough</q>, the second alternative would really make H.264 free enough!</p>
<p>I doubt Hixie would include H.264 in the spec in order to float a balloon like this, though. But it's a fun thought.</p>
<h4>The real solution: Solve problems that can be solved</h4>
<p>The one strong argument in favor of H.264 is hardware acceleration, especially on mobile platforms like phones, netbooks and pads. But bringing VP8 to a comparable state is within our grasp. The hardware acceleration problem can be solved and it is an easier problem to solve than flawed US patent laws or changing the minds of stubborn MPEG-LA patent bureaucrats.</p>
<p>In order to understand this we must consider two things: What exactly is hardware acceleration and what is the expected lifespan of a web standard compared to the lifespan of current chip sets?</p>
<p>I'll start with the former. Video codecs will probably improve over the next couple of years, regardless of them being standardized. Smart people will conjure up better ways to reduce file size while increasing quality, or at least improving one of the two without hurting the other too much.</p>
<p>The question thus becomes, has H.264 been implemented in the layout of the transistors of modern GPUs in such a way as to make any other algorithm, or any variation of the algorithm impossible? That is, are the calculations required to encode or decode H.264 implemented in silicon in every minute detail and will electrons flow from transistor to transistor in a sequence that exactly matches H.264 encoding or decoding?</p>
<p>If that's the case, we have really dug ourselves into a hole. If that's the case, we've made it impossible to improve anything at all! Since new ideas can not use the GPU, they are doomed to be bad ideas!</p>
<p>But since it still takes a whole lot of code to actually write an H.264 encoder or decoder, the answer is of course no. <strong>Hardware acceleration of H.264 is not a magic black box.</strong></p>
<p>A GPU is just a slightly different processor, optimized for some kinds of arithmetic that a normal CPU is not. There is no magic to it. It's just a layout of transistors. In the 80's and early 90's most CPU's could not do floating point arithmetic effectively. One had to buy a separate piece of silicon to get that (the 8087, the 287 and the 387). <a href="http://en.wikipedia.org/wiki/IBM_System_z10#New_Features">IBM recently introduced a CPU</a> that has a core for decimal (sic!) arithmetic and does cryptography <q>in the hardware</q>.</p>
<p>It's actually not about doing some stuff <q>in the hardware</q> as opposed to other stuff in software. <em>Last time I looked, the CPU was a a piece of hardware!</em> It's a matter of letting the right piece of hardware perform the kinds of computational stuff it does best. It's matter of writing and compiling your programs to use the integer part of the CPU when that's appropriate, the floating point part when that's appropriate and the GPU when that is the most effective solution.</p>
<p>There is no technical barrier preventing VP8 or ogg/theora, or indeed any other software, from using the GPU. In fact, Microsoft is using the GPU to speed up core JavaScript arithmetic in Chakra. That's just one example of modern programs using the power of the GPU to do calculations that are not graphics related at all. So if that's possible, what says it's impossible to move arithmetic calculations to the GPU in the case of non H.264 encoded Video?</p>
<p>Mozilla has gotten CPU usage decoding ogg/theora down from 100 % on the Nokia n900, to just 20 %. And the main thing preventing that number to drop is the fact that the sound is decoded only in the CPU. But that's an obstacle that can be overcome as well.</p>
<p>Lack of so called <q>hardware support</q> for ogg/theora or WebM <strong>is in fact not really a hardware problem, but a software problem</strong>. The decoders (and encoders) have not been written in such a way as to optimally harness the arithmetic power of the GPU &ndash: yet! I expect this to change rapidly, though.</p>
<p>But maybe current hardware has been made with H.264 in mind, making it impossible for VP8 to fully catch up? Well, if the web industry would show a clear support for the VP8 codec, AMD, NVIDIA and Intel will soon implement some alterations to their transistor layouts in the next generation of chip sets, making the playing field even.</p>
<p>In a very short time we will see WebM video implementations that move <em>enough</em> calculation to the GPU to make it usable in portable devices, using today's silicon. But for the sake of argument, let's suppose that looking at WebM video would drain the battery of your cell phone 10-20 percent more than H.264. How bad is that? It is still within a reasonable limit, I say. And HTML5 still let's you provide H.264 as progressive enhancement to any client. But what's being argued (at least in this article) is what we should consider as a baseline, what can become a true <strong>standard</strong> for web video.</p>
<p>Let me say this as emphatically as I possibly can. Even if H.264 could be considered somewhat better than VP8 from a technical point of view, it still is not a good enough reason to let go of our freedom. Anyone who is valuing a slight short term technological advantage over long term freedom, needs a reality check and an ethical wake up call!</p>
<h4>What about submarine patents?</h4>
<p>Microsoft and Apple keep talking about <q>submarine patents</q>, that it is a hazard to everyone implementing ogg/theora or WebM and the MPEG-LA likes everyone to believe that they soon will smack down on the VP8 codec used in WebM video. Since not everyone smells the FUD, let's argue about this for a while.</p>
<p>If indeed VP8 is trespassing on H.264 patents does that mean that <strong>anyone</strong> implementing a VP8 encoder or decoder can be sued? Could Microsoft be sued? Could Apple?</p>
<p>The premise for such a thought is that the patents for H.264 not only stipulate algorithms but prohibits anyone licensing those patents from doing any kind of alteration not only to individual patents, but to the exact combination of those patents.</p>
<p>This is thus a legal variation of the hardware argument. It stipulates a lock-in mechanism to H.264 that prevents any kind of experimentation or improvement. All by itself that would be a bullet proof case against H.264. Who would like to lock the web into such a solution?</p>
<p>But of course this is not the case. One may use individual algorithms from H.264 together with new or altered algorithms. Anything else would be plain stupid!</p>
<p>And since Apple and Microsoft are licensees of the MPEG-LA patent pool (as well as contributors to it, although Apple has not really contributed as much as Microsoft has), they are authorized to use those patents. <strong>They have bought themselves the right to write software that use those patents!</strong> So even if we admit – for the sake of argument – that the VP8 codec indeed does infringe on H.264, what risk does that pose to Apple or Microsoft? None whatsoever!</p>
<p>If Mozilla and Opera are willing to take the risk of implementing VP8, without licensing anything from MPEG-LA, what risk is that to Apple? In what way is that a threat to Microsoft? Having bought themselves the right to use all MPEG-LA patents that risk is absolutely zero.</p>
<p>Bottom line: MPEG-LA will not sue Apple if they implement the VP8 codec. Nor will they sue Microsoft.</p>
<p>(Of course, one option for Apple would be to let anyone submit any driver they'd like to IOS. If it was a truly open platform, we would see a WebM enabled version of Mobile Safari tomorrow, without Apple lifting a finger, without Apple programmers having to write a single line of code!)</p>
<h4>H.264 advocates can not both have the cake and eat it too</h4>
<p>On one hand we hear that VP8 is so similar to H.264 that it <q>probably</q> infringes on the patents guarding that codec. On the other hand we hear that it is so vastly different that we can not get <q>hardware decoding</q>. <strong>But which one is it?</strong></p>
<p>If the algorithms are so similar, that there is a patent infringement going on, it goes without saying that GPU accelerated VP8 encoded video must not be hard to implement. If that's the case, the silicon has been wired to do these exact calculations.</p>
<p>On the other hand the algorithms are so different that decent GPU accelerations is impossible, what makes anyone think that the MPEG-LA could sue you for using them?</p>
<p>I wish H.264 advocates would chose which of these two <q>dangers</q> we are supposed to be afraid of, because they are <em>mutually exclusive</em>.</p>
<p>Another example of mutually exclusive claims is that MPEG-LA supposedly owns so many patents that is is virtually impossible to write a video codec that does not infringe on their patents and the fear that there might be some third party, that is not participating in WebM or Theora video, nor in the MPEG-LA, but holds patents in secret, waiting for someone to implement it. A <a href="http://www.groklaw.net/article.php?story=20100829012006847">Paul Allen</a>, but with an actual case. A troll with infinite patience that will strike just when WebM has taken off.</p>
<p>But if VP8 is so akin to H.264 that it infringes on their patents, what space would that leave for this third party troll? Very little I'd say.</p>
<p>Once again, I am not saying that the one of these propositions is true. In fact I believe them both to be untrue. But I wish that H.264 advocates would agree on one argument, when mere logic dictates that one being true by definition means that the other one is not.</p>
<h4>What kind of power does Apple and Microsoft wield within MPEG-LA?</h4>
<p>Speaking of lawsuits, the MPEG-LA is a consortium and it must act according to the will of its members. So if Microsoft and Apple really cared about open video, I have suggestion for them. Use your muscle within that consortium, that you are part of, and convince your fellow members that truly open video is a good thing™. Convince them to release H.264 in a <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">W3C patent policy</a> compliant way. Show us that you are submitting such proposals to the board, show us that you are arguing the case. Only then will your opinion be worthy of consideration.</p>
<p>Until that happens, H.264 can not be a web standard. Until that happens, it can in fact not even be considered for standardization.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com19tag:blogger.com,1999:blog-17809600565735611.post-81205021716954316692010-08-10T10:24:00.005+02:002010-08-10T20:12:20.250+02:00Chrome's auto update argument has just been disabled<p>A short note: <a href="/2010/07/no-browser-supports-html5-yet-part-1.html">When I have criticized Chrome</a> for putting out half baked features on the web, the usual defense is that Chrome auto updates and that the release cycle is so short that developers will not be locked in to a version where the feature is half baked only. OK, but now Chrome is <a href="http://www.google.com/chrome/eula.html?msi=true">available as an MSI packet</a>, and that changes everything!</p>
<p>I was anticipating that move, having experience not only in web development, but also in network administration. <strong>The key</strong> to getting into any organization is deployment through <a href="http://support.microsoft.com/kb/816102">Active Directory group policies</a>. Setting up and deploying an MSI-packet is expensive and not something an organization will do on a bi-monthly basis, unless there is some <strong>really critical</strong> security fix needed. They will not do it in order to fix a broken <q>HTML5</q> feature.</p>
<h4>What does this mean</h4>
<p>If corporations, universities, schools, hospitals and other organizations decide to use Chrome, we will see a significant rise in the usage of old versions.</p>
<p>So providing an MSI-package makes it more appealing for corporations to roll out Chrome, but it still is work to do all local modifications, like setting proxies and home page. That's a hurdle big enough to discourage most organizations from updating on every release. Such aggressive updating <strong>will not happen</strong>. Are we clear on that?</p>
<p>Ergo: Rolling out half baked features in Chrome just became a really important problem for us all and failure to see that from the Chrome team is simply irresponsible. You can't have the cake and eat it too, and that simple rule applies to Google as well as everybody else.</p>
<h4>Update</h4>
<p>It seems that <strong>the Chrome MSI-package is half baked as well!</strong> How ironic. It's basically just a wrapper around the install exe-file. Furthermore, this means I've not yet been able to determine if the auto-update feature is disabled. But if not, what sysadmin in his or her right mind would allow self-updating software on the computers of the network?</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com0tag:blogger.com,1999:blog-17809600565735611.post-11624742051634717662010-07-15T19:58:00.009+02:002012-05-03T20:59:50.042+02:00Rotating table headers now in 4 of the top 5 browsers<p id="upnote" style="margin:10px; border: 2px solid green; border-radius: 3%; padding: 10px">
<strong>Update May 3, 2012.</strong> Demo link fixed. + Firefox 14+ (Aurora, Nightly) no longer skews text.
Apparently the CSS Working Group have recently decided that Webkit behavior was better and Mozilla has <q>fixed</q>
their code. <strong>I think this was a bad decision,</strong> but that is how things stand.
Other stuff seem to be happening in the CSS WG with regards to <em>skew</em> and I have unfortunately
been unable to keep track of this. Note that <strong>skewX</strong> does not seem to be in jeopardy, though.
</p>
<p>
A little more than a year ago <a href="/09/05/rotating-column-headers-using-css-only.html">I
wrote about a technique I have developed to rotate table column headers</a>. (If you have not,
you had better read that article to understand this one correctly.) Back in May 2009, this could
be done in Firefox 3.5 and Safari 4. Now browsers have evolved and it's doable in all major
browsers, except Internet Explorer. So, with Firefox, Chrome, Safari and Opera all supporting
this, has the time arrived to use this on production sites?
</p>
<p>
The sad answer is no, there are still a few issues to that needs to be sorted out in my opinion.
First of all, one really can not ignore Internet Explorer, and even if
<a href="http://www.useragentman.com/blog/2010/03/09/cross-browser-css-transforms-even-in-ie/">we
can rotate content</a> using
<a href="http://msdn.microsoft.com/en-us/library/ms532847%28VS.85%29.aspx">-ms-filter</a>, that
is not an optimal solution. I have also seen reports that these filters will not work in IE9 in
its strictest standards mode. Removing them, while not adding CSS transformation, gradients and
a few more things, will make it near impossible to achieve true cross platform effects. I hope
that won't be the case, though. (More thoughts on this in my conclusion.)
</p>
<h4>Updates to my code</h4>
<p>
The full demo is at
<a href="http://keryx.se/lab/rotating-th/rotate-th-2.html">keryx.se/lab/rotating-th/rotate-th-2.html</a>
</p>
<p>
Today I revisted my code. The first thing I did was simply to slam on -o- prefixed rules,
identical to all -moz- rules. The result looked like this. Click the image to see it in
full size.
</p>
</p>
<p>
<a href="http://www.flickr.com/photos/keryxgunther/4798074745/sizes/o/">
<img src="http://farm5.static.flickr.com/4119/4798705530_c9095b5e54_o_d.png"
alt="Screenshot of Opera, firefox and Chrome, showing bad alignment" />
</a>
</p>
<p>
Not nice. Firefox, Opera and Chrome (the 3 browsers I could test on my Linux driven Thinkpad)
all got the horizontal position differently. Admittedly, Chrome got a slightly different rule,
thanks to a Webkit CSS filter. But this worked as intended in my tests one year ago.
My code was largely experimental and not really calculated anyway, so I was not surprised
that it broke. It was intended as a proof of concept, not as production ready code.
</p>
<p>
Before I started to investigate the differences in earnest,
<a href="http://twitter.com/itpastorn/status/18597033437">I tweeted</a>, and soon
<a href="http://twitter.com/KuraFire/status/18597265710">Faruk Ateş chipped in</a>
and had some helpful thoughts. First we removed my line "top: 1em" for all browsers.
Note, that it must be removed. Manually setting it to 0, will still mess things up in Firefox.
I suppose that's a bug, since the <em>calculated value</em> is 0 with that line
removed…
</p>
<p>
The line that was removed:
</p>
<pre><code>th > span > span {
…
<del>top: 1em;</del>
…
}
</code></pre>
<h4>Stability issues</h4>
<p>
Next problem, subpixels. I had used the em unit to set heights and widths. But 1.3em is not
the same in all browsers. In my code it's 23.4 pixels in Firefox, but only 23 in Opera and
Chrome. The latter two does not translate ems into subpixels. At least not on Linux and Windows.
So I made some changes to the code, to use pixels almost everywhere.
</p>
<pre><code>th > span > span {
…
padding: 9px;
height: 23px;
width: 120px;
…
}
td {
padding: 5px;
text-align: right;
width: 36px;
}
</code></pre>
<p>
All values above were set in ems in my original version. Now I was getting close to a working
version. There was one thing that bugged my designer eye – and I am really
<strong>not</strong> a designer. The line in between table columns did not align
perfectly with the column header lines in Firefox. Once again, this was a sub-pixel problem.
So I added this rule, explained in the comments:
</p>
<pre><code>th > span > span {
…
position: absolute;
left: -0.5px;
/*
So far only Firefox does subpixel positioning =
ignored by Opera, Chrome and Safari.
But they got this right (visually) in the first place.
This rule puts the rotated span exactly in place for Ffox
(tested on Linux and Windows July 2010)
*/
…
}
</code></pre>
<p>
Should Opera and/or Webkit add support for subpixel positioning, it is my hope that it will
affect their rendering just like it does in Firefox. But this is a fragile hope!
</p>
<h4>Webkit text skew (not a) bug</h4>
<p style="margin:10px; border: 2px solid green; border-radius: 3%; padding: 10px">
Update May 3, 2012. Firefox 14+ now treats text the same way as Webkit.
</p>
<p>
To make the text as legible as possible it is skewed back to being non-skewed. Let me explain.
There are three spans. The outermost is simply an anchor for the middle one, where the real
magic happens. That span is rotated and skewed. That leaves the text a bit…
<i>skewy</i>(?) To remedy that, I use a third span, only used to skew the text back again.
</p>
<pre><code>th > span > span {
…
-moz-transform: rotate(-65deg) skewX(25deg);
-o-transform: rotate(-65deg) skewX(25deg);
-webkit-transform: rotate(-65deg) skewX(25deg);
-moz-transform-origin: 0% 0%;
-o-transform-origin: 0% 0%;
-webkit-transform-origin: 0% 0%;
…
}
th > span > span > span {
/* Rotate the text back, so it will be easier to read */
-moz-transform: skewX(-25deg);
-o-transform: skewX(-25deg);
<strong>-webkit-transform: skewX(-25deg);</strong>
/*
Safari and Chrome won't skew back, so the above
line is actually redundant right now
(checked July 2010 on Linux and Windows)
*/
}
</code></pre>
<p>
<del>I suppose this is a Webkit bug, that needs to be filed.</del> This image illustrates the problem.
The red line shows the actual angle of the stroke in the letter "l" (small "L").
The green line shows what angle it was supposed to be.
</p>
<p>
<img src="http://farm5.static.flickr.com/4079/4798103727_66b12d81a0_o_d.png"
alt="Text is still skewed in Safari" />
</p>
<p>
Screenshot of my table from Safari on a Mac, graciously provided by
<a href="http://meirish.com">Matthew Irish</a>. This problem affects
all Webkit based browsers, on Windows, Linux and Mac.
</p>
<h4>Opera text blurriness and zoom bug</h4>
<p>
Opera gets the <q>skewiness</q> right. (Being a non native English speaker, I love the word
<q>skew</q> and will jump at every opportunity to <em>skew</em> it!) However, Opera looses
the smoothness of the text, once it has been rotated. It will look blurry. The following image
compares Opera to Firefox. The text is not perfect in Firefox either, though.
</p>
<p>
An even bigger problem with Opera is that it really will mess the text up when zooming the page,
to the point where it becomes totally illegible. The image below is zoomed to 300 % and one can
not read the text at all, since the bottom (=left) margin has widened and pushed the letters
on top of each other.
</p>
<p>
<img src="http://farm5.static.flickr.com/4136/4798735076_cd4cd20285_d.jpg"
alt="Messed up text in Opera when zoomed" />
</p>
<h4>Gaps between cells in Firefox</h4>
<p>
The image above illustrates another problem in Firefox, perhaps also
caused by subpixel positioning. At some zoom levels small gaps appear between
the <q>cells</q>. Note that we are not drawing lines on the actual table cells
but a box around the edges of a <em>span</em>. We are just visually emulating
rotated table headers.
</p>
<p>
From previous testing I also found these gaps also when not zooming the page.
One has to be really precise in the measurements to fix this. Right now I basically
get the visuals right by having the line from one cell on top of the line from the
previous cell.
</p>
<p>
If I'd fine tuned my technique, I think these gaps could be avoided. Not
drawing both lines both left and right (= top and bottom in CSS) and extending
the top (= right) line a bit might do the trick.
</p>
<h4>On subpixels</h4>
<p>
A small aside: It might seem like subpixel positioning is all bad. I believe it
generally is a feature, not a bug. I wish all browsers could agree
on Firefox' behavior. But in this context it seem to be problematic.
I will ping a few people at Mozilla and see what their take on this is.
</p>
<h4>Conclusions and some thoughts about the future</h4>
<p style="margin:10px; border: 2px solid green; border-radius: 3%; padding: 10px">
Please see <a href="upnote">the top note</a> about things being unstable in CSS WG, when it comes to skew.
</p>
<p>
I really think there should be a CSS-rule that would make this super easy.
Rotating column headers is a really common technique in spreadsheet programs
like Excel and LibreOffice Calc. I use it all the time. It would be a great
feature for Google and Zoho Docs and similar on-line products. So far, however,
the CSS Working Group and browser vendors have shown very little interest.
</p>
<p>
All browsers display an issue of some kind with my current technique:
</p>
<ul>
<li>Killing: Bad rendering of the text in Opera, especially when zooming.</li>
<li>Bad: Gaps in Firefox between the <q>cells</q>, when zooming.</li>
<li>Slightly annoying: Skewed text in Safari and Chrome (and probably Firefox 14+).</li>
</ul>
<p>
Internet Explorer 9 is a big question mark. My current idea is to capability detect
for CSS transforms and replicate this behavior in SVG, if available, or using -ms-filter
as a third option. That should cover all bases = MSIE 6-9, Firefox 3.5+, Opera 10.51+,
Safari 4+ and Chrome (always at the latest version, at least until it comes to the
corporate environment – a subject worthy of a blog post by itself).
</p>
<p>
Having to limit oneself to pixels as a unit and fixed width for the columns is a major
obstacle. For this reason, as well as the Internet Explorer problems, I think that the
only sane way of doing this at the moment and the foreseeable is using JavaScript.
Perhaps this could be my first official JQuery plug-in. (Please feel free to beat me to it!)
</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com2tag:blogger.com,1999:blog-17809600565735611.post-89248838801449849502010-07-09T12:30:00.005+02:002010-07-18T11:15:54.500+02:00No browser supports HTML5 yet. Part 2. Technology.<p>
In <a href="/2010/07/no-browser-supports-html5-yet-part-1.html">the first post</a> I questioned the perception that a particular browser supported HTML5, whereas other browsers do not,
according to some misguided fan boys.
I pointed out that browser vendors are quick to claim that a particular feature is
supported, when in reality that support is half-baked and far from complete. And that is not a good thing!
</p>
<h4>History repeating itself</h4>
<p>
My main gripe with browser vendors not using solid <strong>shipping criteria</strong> for stable versions, but releasing flawed and incomplete implementations of HTML5,
is that it may lead to flawed and incomplete web sites. The <a href="http://code.google.com/intl/sv-SE/events/io/2010/">message from Google</a>,
Apple and numerous others is not, <q>go forth and experiment</q>, but <q>go forth and <strong>use</strong></q>.
<strong>Today!</strong> Knowing very well that the HTML5 input range in Chrome or Safari <a href="https://bugs.webkit.org/show_bug.cgi?id=14444">is not
accessible</a>, they still encourage actual real world usage. Knowing very well that Chrome exposed the JavaScript form validation
API only, and had no real constraints for invalid data, the implementation was shipped – and lo, it <a href="http://www.findmebyip.com/litmus#target-selector">looked good in the support
charts!</a>
</p>
<p>
So what happens when the spec changes? And what happens when real world usage will make needed spec changes not an option?
<strong>Being responsible is way more important than being first.</strong> But once again, that does not look as cool on the support charts…
</p>
<p>
By putting half baked implementations into non-beta software Chrome and Safari actually do harm to the web. Why are we cursing Internet Explorer 6.
It was <em>not for lack of innovation and standards support</em> when it first shipped. It is because that standards support was buggy and incomplete –
that's right, it was half baked. And now we see Chrome and Safari releasing unfinished implementations as well.
</p>
<p>
In one way, we are at a better place right now. Chrome is aggressive in its updating of itself and Safari versions also have
relatively short shelf life. But when real world web sites appear that lock in to today's versions and break when bugs are
fixed, things will not look so rosy any more.
</p>
<p>
And please consider this. Back in the earlier 90's Netscape released new versions at an equally frantic pace.
The <q>web year</q> was supposed to be five months and <em>every web year should mean a major update</em> to Netscape navigator.
So JavaScript shipped even long before the implementation was mature, and because of this we are still stuck with some really
bad api's and bugs, that could have been squashed given a few more months of time, can not be squashed, because sites soon depended
on them to work correctly. As long as Chrome was a niche browser it might not have mattered, but now that it has received a descent
and <em>well earned market share</em>, it will matter. (Not to mention the mobile space, where Webkit based browsers are ubiquitous.)
</p>
<h4>Exhibit A: Web forms</h4>
<p>
Web forms are really the starting point for all things HTML5. In spite of that fact, it is not until now that
work has begun in earnest to implement all new cool form features. Except for Opera, of course,
who implemented most of this a few years ago!
</p>
<p>
The work to get the HTML5 additions to web forms into Webkit is tracked in <a href="https://bugs.webkit.org/show_bug.cgi?id=">bug 19264</a>.
The work to get it into Gecko is tracked in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=344614">bug 344614</a> and on a
<a href="https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms">wiki planning page</a>. The most important part being the shipping criteria.
(I subscribe to these bugs to keep myself informed, but then perhaps I don't really have a life…)
</p>
<p>
I could go on and explain details about what is lacking
in browser A, B or C, but I will not make this blog post any longer than necessary. Look at the tracking bugs and see for yourself.
At the moment neither Webkit nor Gecko (nor Opera) is nowhere near having a complete HTML5 web forms support.
They all lack some features and <strong>they all lack accessibility</strong>.
(The Webkit bug is a bit deceptive, since it does not seem to list all features like the Mozilla bug does.)
</p>
<h4>Exhibit B: Sectioning elements</h4>
<p>
Some new HTML5 elements seem really easy to understand. They are not hooked into browser behavior, JavaScript API's or some
other esoteric behind the scenes weirdness. They just seem to be turbo-charged divs, divs with real semantic meaning.
Furthermore, they are a part of the HTML5 spec that is reasonably mature and thus ripe for implementation in browsers.
</p>
<p>
Yes, there is one talked about crux. It is <a href="http://adactio.com/journal/1654/">not super duper easy</a> to
<a href="http://html5doctor.com/happy-1st-birthday-us/">differentiate
between article and section</a>. Perhaps the spec will need some further explanations, or perhaps that will be taken care
of in the <q>for dummies</q> version.
</p>
<p>
But there is one further matter, a point that seem to be universally missed. Even by browser makers! And that is the fact that
sectioning elements affect <a href="https://developer.mozilla.org/en/Sections_and_Outlines_of_an_HTML5_document">document outline</a>
and that should in turn <strong>be exposed</strong> to seeing users through varying sizes on the headings and to non-sighted users through their assistive technologies.
Headings are used when scanning a page – both by sighted and non-sighted users. Being able to tell at what level a heading is,
is therefore a critical part of any implementation.
</p>
<p>The real deal breaker is not if you can set <code>display: block</code>
on <code><article></code>. The real deal breaker is if you can easily set an <code><h1></code> within any sectioning element to
resemble <code><h2></code>, or setting it to resemble <code><h3></code> if it's one step further down in the document hierarchy. Etc.
</p>
<p>
Being able to style a sectioning element is actually a bullshit claim. HTML5 mandates that one should be able to style
<strong>any</strong> unknown element. That is, a browser vendor could claim that they <q>support</q>
the <foobar>, <my_cat> and <steve_jobs_is_god> elements, since according to HTML5, they should!
At least in the sense that they make those elements part of the DOM and therefore styleable through CSS.
</p>
<h4>-moz-any() to the rescue (somewhat)</h4>
<p>
The only browser to have any reasonable way of styling headers, depending on how deeply nested they are within sectioning content,
is Firefox 4, currently in early beta only. This is done through the brilliant any() selector, being implemented, as it
should, with a vendor prefix, until all details are agreed upon.</p><p>(The hardest part to figure out, before this can go CR, is
how this selector should handle specificity. What happens if you mix type, class and id selectors inside one parenthesis?)
</p>
<p>
Nevertheless, try and write the following CSS selectors so that they work in any browser but Firefox 4:</p>
<pre><code>
h1 {}
h2, -moz-any(section, article, nav, aside) h1 {}
h3, -moz-any(section, article, nav, aside) \
-moz-any(section, article, nav, aside) h1 {}</code></pre>
<p>And so on. You will get tired of typing really quick.</p>
<p>
Thus, only Firefox 4 can claim to support HTML5 sectioning elements in any usable fashion.
<strong>The point of these elements</strong> is not that they should serve as styling hooks.
We already have <div> for that. The point is that they should affect the
<strong>styling of headers</strong>, and that's simply not doable in a generic fashion in any
browser but Firefox – <a href="https://bugs.webkit.org/show_bug.cgi?id=38095">so far</a>!
</p>
<p>
But Firefox also have a long way to go, since they've not begun on working on the accessibility side of this.
Until support for the any selector is universal, these elements can only be used in experiments or with fallbacks,
such as always using <h2> when one level down into sections, <h3> when two levels down, and so forth.
Actually, this is current recommended best practice.
</p>
<p>
But by not using <h1> all the time, we are missing out on one of the main advantages of this new outline model,
namely <strong>cut-and-paste-ability</strong>. We still have to re-calculate the heading level depending on what page a piece of
content appears. E.g. a blog post might have its heading as <h1> on the dedicated page, but it should be
<h2> on the home page of the blog. Sub-headings should be <h2> on the dedicated page and <h3>
on the home page, etc.
</p>
<p>
Until there is universal and accessible support for headers within sections,
support charts may say that the elements are implemented and marketing may make a big noise about their presence.
But right now, the only way to use these elements is through scripted hacks.
</p>
<p>
And that, my friends (and all enemies I've made by posting these two posts) is a non negotiable fact.
</p>
<h4>Exhibit C: <hgroup> and <nav></h4>
<p>
This is a no brainer. The point of <code><hgroup></code> is to <em>hide the subtitle from the outlining algorithm</em>.
Thus there care only two requirements to call this feature supported. Make it available in the DOM. As explained above,
that's the easy part. The hard part is the accessibility issue. When a blind user scans through a page by jumping between
headers, an <code><hgroup><h1 /><h2 /></hgroup></code> should be presented as exactly one heading,
not as two. And it is a reasonable expectation that the subtitle is read out along with the main heading. In a perfect world
even perhaps prefixed with the word <q>subtitle</q> to indicate that relationship. At least, when jumping to the next heading
it should be skipped, since it really is not <q>next</q>, but part of the main heading.
</p>
<p>
In the same way, the nav element should be presented to blind users in a way that will let them skip over navigation or jump to
navigation. (Also a no brainer, really.)
</p>
<p>
There is no browser on the market that supports thees behaviors. Indeed, to my knowledge, no browser even has begun working in earnest
on this. But my point is not that browser X is better than browser Y. My point is that it is premature to claim support for
this feature, when indeed <em>one is missing the whole point of that feature</em>.
</p>
<h4>So, is there no value in using these HTML5 elements?</h4>
<p>
There might be. First of all, they do no harm. And on that day when browser support really has been properly implemented,
you will automatically get added benefits over using a div. Furthermore, they might be picked up by other software than browsers, or browser
extensions, like <a href="https://addons.mozilla.org/sv-SE/firefox/addon/46442/">Readability</a> (I love it) and
<a href="http://www.apple.com/safari/whats-new.html#reader">Safari Reader</a> (technically not an addon, but a feature).
Presently, this kind of functionality must rely on educated guesswork – some kind of software algorithm that
analyzes the page and looks for ids, classes or patterns that usually would indicate
the main content of a page. With HTML5 markup that algorithm will be simpler and therefore execute faster.
</p>
<p>
So this is my point. Knowledgeable web developers can use any HTML5 feature they like today. With progressive enhancement and graceful degradation,
perhaps through JavaScript libraries. If you've come this far and think that I am discouraging any use of recent additions to the
<a href="http://meyerweb.com/eric/thoughts/2010/05/19/the-web-stack/">web stack</a>, you are wrong. Just take
<a href="http://www.brucelawson.co.uk/2010/cross-browser-future-proof-css-3/">reasonable care in how you do it</a>,
and do not trust browser marketing! One example of such care is to use WAI-ARIA everywhere, to address the accessibility issues.
Since no browser offers <em>built in</em> accessible implementations of HTML5, we must resort to <em>bolt on</em> accessibility.
</p>
<p>
Browser support for HTML5 is not boolean, and neither should your usage of this be today.
Thus <q>can I use HTML5</q> is a stupid question. It is all about the <strong>how</strong> you
use HTML5 and more specifically, <em>what parts of it you use</em>.
</p>
<p>
I am not a foe of HTML5 usage – but I am a <em>friend of caution</em>. After all, I'm over 40 years of age!
</p>
<hr />
<p>
P.S. Firefox 4 <a href="http://www.reuters.com/article/idUSTRE65N20Y20100624">does not look like Chrome</a>, it looks like Opera!
And of course there are <a href="http://my.opera.com/haavard/blog/2010/07/09/wsj">several reasons behind Chrome's growth in market share</a>.
</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com4tag:blogger.com,1999:blog-17809600565735611.post-71421440714310863852010-07-08T15:55:00.006+02:002010-07-18T11:17:16.126+02:00No browser supports HTML5 yet. Part 1. The rant.<p>Yes, you've read that headline correctly. There are so many websites that measure <a href="http://html5readiness.com/">HTML5
readiness</a> in <a href="http://caniuse.com/">one way</a> or <a href="http://www.findmebyip.com/litmus/#html5-web-applications">another</a>,
and so many marketing pitches that claim HTML5 support for browser X, Y or Z. But the crux of the matter is this. Supporting HTML 5,
regardless of definition, is not a boolean proposition. I.e. It's not something you do or do not, it is something you do
<strong>more or less</strong>.</p>
<p>
This discussion will consist of two posts. The first is an anti-webkit fan boy rant, probably only useful as <em>self-therapy for me</em>.
The <a href="/2010/07/no-browser-supports-html5-yet-part-2.html">second part</a> is my technical discussion about the subject matter at hand.
</p>
<h4>Rant begins here</h4>
<p>
Whenever a major browser vendor releases a new version, or preview version, you can bet a month's salary on the fact that comments will
appear on forums, Twitter or blog posts that asks <q><a href="http://www.google.se/search?q="does+it+support+html5"">does
it support HTML5</a></q> (it used to be CSS 3).
Some other browser is then hailed as if it does, usually Safari or Chrome, since they have either
<a href="http://www.0xdeadbeef.com/weblog/2010/06/intellectual-honesty-and-html5/">the most obnoxious marketing</a>
or the dumbest fan boys(?) And sometimes the comment is made complete in its stupidity by an argument that vendor X should just
<a href="http://www.drawar.com/articles/dear-microsoft-please-use-webkit/210/">“use Webkit”</a>.
</p>
<p>
I do not intend to throw cheap jabs at Webkit, in any incarnation, be it Chrome, Safari, Froyo, S60, Web OS,
<a href="http://wiki.forum.nokia.com/index.php/Category:Web_Runtime_(WRT)">Nokia WRT</a>, QTWebkit or WebkitGtk. Webkit is a really good
rendering engine, or perhaps nowadays more aptly described as the core of a rendering engine. OK, maybe I'd like to throw a jab at
Froyo and Adobe AIR for the dumb ass decision not to enable SVG, but that's beside my point, and not Webkit's fault at all.
</p>
<p>
Other comments like <q>Mozilla is lazy</q> or <q>have stopped inventing</q> are
<a href="http://www.neowin.net/news/firefox039s-upcoming-javascript-engine-uses-webkit-code#comment-1017003">not hard to find
either</a>. But it's hard to claim that Opera is not inventing, so non Opera fan boys just tend to ignore them. After all,
that makes it much easier to claim originality, even though one has just copied Opera.
</p>
<p>
I am not saying that Firefox is without it's gang of fan boys. Perhaps they are equally loud and obnoxious, but it's been a
long time that they've been in <a href="http://twitter.com/itpastorn/following">my vicinity</a>. (Or perhaps I am that fan boy?)
</p>
<h4>Source of confusion number one: Browser vendors</h4>
<p>
It is reasonable to expect the upstarts to be more aggressive in their marketing, but marketing tends to turn into blatant lies when exaggeration
is becoming the norm. Consider this support chart for Safari 5 from Apple:
</p>
<p>
<img src="http://3.bp.blogspot.com/_KnOn6Z8lFzA/TDXZHZWGmSI/AAAAAAAAAB8/rofUfpKAZVU/s320/stupid-safari-5-html5-support-chart.png" alt="Apple claiming that Safari 5 supports several HTML5 elements" />
</p>
<p>
Source: <a href="http://www.apple.com/safari/whats-new.html">http://www.apple.com/safari/whats-new.html</a> [checked 2010-07-08]
</p>
<p>
Problem is, once someone has started to claim support for a feature, even though that support is half baked and incomplete,
everyone else has to answer in kind, and claim support even when their implementations are equally half-baked. Or even worse,
rush out such half baked implementations to the market to show everyone that they are also a <q>leader</q>.
</p>
<p>
(I'll explain why Apple's claims are false in part 2 of this discussion.)
</p>
<h4>Source of confusion number two: Well intended web developers</h4>
<p>
Why is this a source of confusion? Because we tend to put up demos of new cool technologies that are not really examples of best practice, e.g. even
though transformations and transitions work in the latest versions of <a href="https://developer.mozilla.org/en/CSS/CSS_transitions">Firefox</a> and
<a href="http://dev.opera.com/articles/view/css3-transitions-and-2d-transforms/">Opera</a>, many demos use the webkit prefix only. Heck, I've even seen
demos of rounded corners, something that's been in Firefox since 2004 (3 years ahead of Webkit) that used the only the -webkit- prefix!
(Yes, I know there are <a href="http://css3.bradshawenterprises.com/">good examples</a> as well.)
</p>
<p>
I am not surprised that Apple browser sniffs for Safari in <a href="http://www.apple.com/html5/">their HTML5 demos</a> –
even though I am annoyed at such <strong>blatant disregard for best practice</strong>.
<em>After all, that's not technology, that's marketing</em>.
(And yes, I know there are a few things that one can do in Webkit based browsers only, such as CSS Animations (not transformations) – a
technology still in need of a <strong>valid use case</strong>, BTW – and CSS perspectives, but that's also beside my point.)
</p>
<p>
When the WebGL Quake demo originally worked in Chrome only, thanks to <a href="http://code.google.com/p/quake2-gwt-port/issues/detail?id=26">flaws
in the demo</a> code, not in Firefox itself, it was claimed that Firefox was
<a href="http://blog.vlad1.com/2007/11/26/canvas-3d-gl-power-web-style/">”too slow”</a>, even before such a claim could be tested.
That was not marketing (I hope), that was developers not doing their job. And when someone is demoing
<a href="http://www.phpguru.org/webkit-css-reflections">reflections in Webkit</a>, without at least discussing
that <a href="http://weblogs.mozillazine.org/roc/archives/2008/07/fun.html">Firefox can do the same thing</a>, albeit
with a <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=506826">different technique</a>, which is more powerful,
BTW, it might be lack of knowledge. But the lasting impression on readers, equally lacking in knowledge, is that Webkit
based browsers are <q>soo far ahead</q>, when in reality they are not.
</p>
<p>
Another example is gradients. They <a href="http://webkit.org/blog/175/introducing-css-gradients/">first appeared
in Safari</a> and for a while they could not be demoed in any other browser. But since 3.6
<a href="https://developer.mozilla.org/en/using_gradients">Firefox supports gradients as well</a>.
Doing an gradient demo today using the webkit syntax only is not only bad practice because it is limiting
the demo to a few browsers. It is also cheating oneself and one's audience of the syntax that is much more likely to be
<a href="http://dev.w3.org/csswg/css3-images/#gradients-">the upcoming final W3C standard</a>. I.e. If you are limiting your demo to one syntax only,
the Firefox version is <em>the more future proof one</em>, the one web developers really should be looking at in earnest.
</p>
<p>
A real problem caused by too many Webkit-centric demos on the web, is Microsoft
<a href="http://snook.ca/archives/html_and_css/vendor-prefixes-competing">contemplating
supporting -webkit- prefixed CSS properties</a>. Luckily they back paddled on that one, but it still serves as a nice illustration of the problem.
</p>
<p>
To alleviate this problem Mozilla has proposed a set of best practices for demos, that includes being as cross browser as possible, using graceful
degradation ,etc. <a href="http://www.0xdeadbeef.com/weblog/2010/06/intellectual-honesty-and-html5/">Read (at the end of the post) and learn, people!</a>
</p>
<h4>Where innovation happens = everywhere</h4>
<p>
Even Internet Explorer, that I've cursed so many times, did <a href="http://msdn.microsoft.com/en-us/library/ms532847(VS.85).aspx">tons
of stuff already in the 90's</a> that's only recently have been picked up by others. Yes, there is one big difference.
The filters in IE were not being put forward for standardization, but was an
attempt to <q><a href="http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish">embrace and extend</a></q>,
Microsoft of the 90's primary way of competing in unjust ways. But from a pure innovation standpoint, IE was first in doing many things.
</p>
<p>
And for all Webkit fan boys I have a home assignment.
Please investigate where the following technologies were invented:
</p>
<ul>
<li>WebGL</li>
<li>HTML5 video and audio</li>
<li>Using any element as CSS backgrounds</li>
<li>Applying SVG effects on non SVG content</li>
<li>Full page zoom</li>
<li>Canvas text</li>
<li>Compiled JavaScript</li>
<li>Hardware accelerated SVG and Canvas</li>
<li>Audio Data API</li>
</ul>
<p>
Hint: The answer is <strong>not</strong> one and the same, but never Safari or Chrome.
</p>
<p>
I am not saying this to diminish the considerable achievements by Webkit browsers, but wishing for a Webkit monoculture is plain stupid. Just like
<em>it was plain stupid to wish for a Gecko based monoculture five years ago</em> – when Webkit hardly was a blip on the radar and had
tons of bugs (JavaScript in Safari 2 anyone?). And what if KHTML never had been developed? It could hjave happened since lots of people thought it
would be better for Konqueror to switch to Gecko. Well, Webkit is based on KHTML, so if that advice had been heeded, we would not have had Webkit
today.
</p>
<h4>End of rant – sort of</h4>
<p>
All of the above is not me saying Chrome is a bad browser. It is not. <strong>In some ways it's the best browser – but not in every way!</strong>
My primary reason for not using Chrome in my daily work? I think monoculture is bad and even though I sympathize with Google using Chrome to push
the competition into being faster, <strong>I do not want to see a world where one company is the dominant player at every tier of the web
experience</strong>. Such power will inevitably corrupt, no matter how hard the company in question tries to avoid being evil. Add to that
<a href="http://blogs.computerworld.com/15234/google_ceo_if_you_want_privacy_do_you_have_something_to_hide">a leader that is absolutely clueless
about integrity</a> and that by far outweighs the fact that Firefox currently is a few milliseconds behind Chrome in some JavaScript benchmarks.
</p>
<p>
Oh, yes, I use Linux, so Safari is not an option at all.
And Apple is every bit as evil today as Microsoft was in the 90's.
</p>
<p>
My primary reason for supporting non Webkit based mobile browsers like Opera or Fennec (Firefox) is not that they are clearly superior.
In many ways they are not – and again in some ways they are! (At least they do SVG, Froyo!) But once again it comes back to this.
<strong>Monoculture benefits no one in the long run</strong>. For a moment the idea might seem to be appealing – as when developing
a specific web app – but holding on to such an idea in the long run is just showing lack of vision and lack of historical knowledge.
</p>
<p>
To round things off, here is a video (HTML5 video was an Opera idea) of WebGL in Firefox 4 – a
<a href="http://www.0xdeadbeef.com/weblog/2010/04/innovation-in-browsers/">technology invented mostly by Mozilla</a>.
(Oops! I just gave away two answers in my home work assignment.)
</p>
<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/VogPUTdAkyU&hl=sv_SE&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/VogPUTdAkyU&hl=sv_SE&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object>
<p>
OK, therapy session is over. Glad to have gotten that off my chest. Tomorrow I promise to be productive!
</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com5tag:blogger.com,1999:blog-17809600565735611.post-22672032366638646722010-04-23T00:27:00.004+02:002012-10-22T21:04:37.954+02:00Why declarative animation should be in the DOM and not in CSS<div style="border: 1px solid red; border-radius: 5px; padding: 1em">
Note: This blog post did reflect my opinion at the time of writing. Since then technology has evolved and now this has become less of an issue. I will leave the post online, but if you came to learn about how to do animation today, reading will be a waste of your time.
</div>
<p>
A little more than a year ago <a href="http://webkit.org/blog/324/css-animation-2/">Safari introduced experimental
support for CSS based animations</a>, to compliment transformations and transitions. I have no gripe with transitions
and transformations, but I think animations belong in the DOM and not in CSS. My main argument is that animations will
most of the time be triggered by DOM-events, and during at least the next five years most CSS-based animations will be
duplicated using classic DOM-methods anyway. The purported separation of animation (for designers) who are supposedly
scared away from scripting <a href="http://lists.w3.org/Archives/Public/www-style/2010Apr/0154.html">is not a valid
argument</a>, since they are going to use libraries anyway. (And, frankly, the CSS animation syntax in itself looks
quite scary to most people!)
</p>
<p>
Originally, this started out <a href="http://lists.w3.org/Archives/Public/www-style/2010Mar/0469.html">mostly as a gut
feeling</a>, and the arguments that I've made on the W3C mailing list
<a href="http://lists.w3.org/Archives/Public/www-style/2010Mar/0525.html">are varied</a>
and admittedly <a href="http://lists.w3.org/Archives/Public/www-style/2010Apr/0277.html">a bit confused</a>.
I was thinking out loud more than I was presenting a coherent argument. Hopefully this blog
post will come across as more reasonable!
</p>
<p>
I also believe that this discussion needs to be known outside of the CSS working group and the participants on the www-style
mailing list. Specifically, it needs the input of developers of JavaScript libraries and normal web developers. These are
the people who will be affected the most by any decision. (I am providing an abundance of links to the discussion on the mailing
list for context.)
<h3>CSS animation – the good parts</h3>
<p>
A few aspects of the CSS animation proposal are brilliant and
<a href="http://lists.w3.org/Archives/Public/www-style/2010Mar/0523.html">not of dispute</a>:
</p>
<ul>
<li><b>Declarative syntax.</b> Designers specify what effect they want, not how the browser should achieve it.</li>
<li><b>Hardware acceleration.</b> Animations get smoother, faster and less CPU-draining. The GPU is optimized for this
and can perform the calculations using only a fraction of the power and time a CPU would take to do the same number crunching.</li>
</ul>
<p>
When I am asking the CSS working group to reconsider CSS animations I am not in any way trying to take away these two strong points.
<strong>I am firmly pro having GPU-accelerated, declarative animations in the browser.</strong>
I just think the DOM is a better fit for them.
</p>
<h3>What will be animated?</h3>
<p>
CSS has no events, it has <dfn>states</dfn>. Basically it knows the focused and unfocused state on links and widgets and if a pointer
is hovering, clicking ("active") or not hovering over an element. While exeperimenting with the CSS animation syntax,
the working is producing examples using these states. Ironically mobile devices are one of the main reasons why CSS animations
were originally thought up, and they rarely have a pointer, and CSS is not really equipped to handle touch events.
</p>
<p>
It can safely be assumed that 99 % of all real world use cases for animation will be the result of user or server interaction on some
part of the document that is <em>not being animated</em>. The user clicks a button and a div will slide into view. The user
presses a key on his keyboard and text will wiggle and bounce. Data is sent back from an AJAX request, and the received data will
appear through an attention grabbing sliding effect.
</p>
<p>
Currently the only way to achieve these real world use cases is by adding or removing class attribute values. Thus we have scripts that
will trigger animation in the DOM and the actual design of the animated effects in CSS. Conceptually this is nice. Separation of logic
is a good thing™. However, in real world practice this will not be so neat.
</p>
<h3>Events confusion</h3>
<p>
Even though there are no events in CSS, <a href="http://lists.w3.org/Archives/Public/www-style/2010Apr/0016.html">there
is discussion about</a> having animations running upon <em>entering</em> a state,
while <em>being</em> in a state and when <em>leaving</em> a state. These are not events in a technical sense, but outside
of the W3C working group, most developers will be <a href="http://lists.w3.org/Archives/Public/www-style/2010Apr/0155.html">really
confused about the difference</a>. Such precise knowledge is not found
in abundance! If a specific application need to differentiate between these, it is by far easier for developers to use the
more familiar DOM events.
</p>
<p>
Having some animations run because they are affected directly, e.g. on hover, some animations run because they are triggered by
a scripted change of className, and in both cases also have animations that may run <q>entering</q>, <q>during</q> and
<q>leaving</q> states looks like a recipe for unmaintainable and confusing development. It is way much better to trigger all
events from one place only, and that place can only be the DOM.
</p>
<h3>How to implement animations in a library</h3>
<p>
OK, you are building a little library to animate stuff. What do you do? I suppose the following:
</p>
<ol>
<li>
First you capability detect support for declarative animation. That in itself would be easier if it was in the DOM, but
it is at least doable now. But not in a neat fashion. Score one against having animations in CSS.
</li>
<li>
If CSS-animation is indeed supported, you will wrap your animate function around className switches. Doable, but not neat.
</li>
<li>
If CSS-animation is unsupported, you fall back to old school timed manipulation of the style attribute.
<ul>
<li>
However, using the animation parameters from the CSS-file is a huge impracticality. You must find a way to read all CSS-files,
parse them and interpret the cascade, the specificitivity of all animation rules and convert that information into timed
logic. This is impractical, slow and CPU-draining and fragile.
</li>
<li>
The CSS Object Model (CSSOM) will not alleviate this problem. Browsers that need to parse the animation rules are the
ones that neither implement animations, nor the corresponding CSSOM.
</li>
</ul>
</li>
</ol>
<p>
Alternatively, the author is required to re-specify the animation once again, now using a syntax for the fallback. We thus
get <strong>code duplication</strong>, with all the error proneness and maintenance problems that follows from that approach.
But it is the only approach currently available with reasonable results.
</p>
<p>
It can safely be said, that CSS-animations are <em>not</em> backwards compatible in any reasonable way. And we are going to
need backwards compatible solutions for almost another decade or so.
</p>
<h3>What about progressive enhancement?</h3>
<p>
Using progressive enhancement we can deliver CSS-based animation to browser that support it, and non-animated but still usable
content to the rest. Problem solved, is it not?
</p>
<p>
I like progressive enhancement. I
<a href="http://interact.webstandards.org/curriculum/front-end-development/dom-scripting-1/?overview">teach it</a>
and I practice it. However, there will be a great number of real world customers that
will insist upon having animations in both the brand new cutting edge browsers and the legacy ones. As least as long as more than
10 % of their visitors use them. We can preach all we want. This scenario will face the real world developer way too often.
</p>
<p>
Animations will be used to convey information as well as for eye candy. Not having a scripted fall back will not be an
option for such use cases either. In real world web development, progressive enhancement can not be called upon to be a
panacea, how appealing that thought ever may be.
</p>
<h3>What else will be hard to do using a CSS approach?</h3>
<p>
In real world use cases developers are also going to want to manipulate animation and keyframe properties, as well as
programmatically create animations from scratch. Using the CSSOM this can probably be done in browser that support animation
but once again the fallback for legacy browsers will be very hard to achieve.
</p>
<h3>What is my counter proposal</h3>
<p>
I have barely begun thinking about this issue, so any propsal I have at the moment should not be regarded as a final suggestion.
In order to keep the separation of concern between designers and developers – for those situations where one has the
luxury to keep them separate – animations must be easy to define with a CSS-like syntax.
<a href="http://lists.w3.org/Archives/Public/www-style/2010Apr/0245.html">JSON fits that requirement</a>
quite well. The method to start an animation could be called runAnimation. It might return a value that I can store in a variable
in order to manipulate or cancel the running animation. Another way to manipulate it would be by altering the animation properties.
For convenience, there should also be a method to stop all running animations on an element.
</p>
<p>
Here is an example, recreating the effect from <a href="http://webkit.org/blog/324/css-animation-2/">Surfin' Safari's announcement</a>:
</p>
<pre><code>
// Keep the JSON objects in a separate file for designers to fiddle with
var bounce = {
"from" : {
"left" : "0px"
}
"to" : {
"left" : "200px"
}
}
var myAnimation = {
"animation-name" : "bounce",
"animation-duration" : "4s",
"animation-iteration-count" : "10",
"animation-direction": "alternate"
}
// Keep these lines in another file for the JavaScript guy/girl to fiddle with
document.getElementById("foo1").onclick = function() {
document.getElementById("bar").runAnimation(myAnimation);
}
document.getElementById("foo2").onclick = function() {
document.getElementById("bar").stopAllAnimations();
}
// Example 2
// Keep the JSON objects in a separate file for designers to fiddle with
var pulse = {
"0%" : {
"background-color" : "red",
"opacity" : "1.0",
"transform": "scale(1.0) rotate(0deg)"
}
"33%" : {
"background-color": "blue",
"opacity" : "0.75",
"transform" : "scale(1.1) rotate(-5deg)"
}
"67%" : {
"background-color": "green",
"opacity": "0.5",
"transform": "scale(1.1) rotate(5deg)"
}
"100%" : {
"background-color": red,
"opacity": "1.0",
"transform" : "scale(1.0) rotate(0deg)"
}
}
var pulsedbox {
"animation-name": "pulse",
"animation-duration": "4s",
"animation-direction" : "alternate",
"animation-timing-function" : "ease-in-out"
}
// And here comes the DOM-parts, this time using JQuery for easy iteration
$(".pulsedbox").each(function() {
this.runAnimation(pulsedbox);
});
</code></pre>
<p>
As stated above, my counter proposal is not a finished product in any way. It merely is intended to serve
as an illustration to an alternative approach. The technical merits or defeciencies of that proposal is in
itself not really something that should guide the general discussion about how to implement declarative animation.
The principles on which I draw the conclusion that the DOM is a better fit is the true talking point here.
</p>
<p>
Now I am especially interested in hearing the opinions from the DOM-scripting community!
</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com8tag:blogger.com,1999:blog-17809600565735611.post-86902299473286709592010-03-22T15:28:00.005+01:002010-03-22T20:13:38.097+01:00PPK is wrong, vendor prefixes are a necessary evil.<p><a href="http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html">Yet another considered harmful essay has hit the web</a>. This time it is PPK, a well known JavaScript guru and very influential author that has written it. And I get to disagree with another one of my heroes. (Just recently I have disagreed with Rasmus Leerdorf on the naming of the next major PHP version...)</p>
<p>Basically PPK is like many others fed up with writing the same rule 2, 3 or even 4 times. You know the drill:</p>
<pre><code>
-moz-border-radius: npx;
-webkit-border-radius: npx;
border-radius: npx;
</code></pre>
Add in a few (-ms-)filter as well and it's a nightmare. And the CSS-validator is not configured to ignore these, even though they are not errors per se. It is sure easy to echo PPK's sentiment. But I believe he is wrong, and <a href="http://snook.ca/archives/html_and_css/not-supported">fortunately I am not the only one</a>.</p>
<h3>Proposals do change</h3>
<p>Case in point is border-radius and gradients. Mozilla could not just drop -moz- from border radius, since their 6 year old implementation is not aligned with standards. Webkit can not drop the prefix from their gradients rules, since the standard probably - please note that word, probably - will look like Mozillas implementation.</p>
<p>I also note that he has put the non-prefixed version of a rule before the prefixed ones, which is not optimal for the very same reason. A problem <a href="/2009/06/do-not-put-experimental-features-last.html">I have dealt with in an earlier blog post</a>.</p>
<p>Experimental versions are needed for things to move along. Without them very few people will be able to experiment and improve the proposal. This is a real need, this is a real problem.</p>
<p>Contrary to what PPK says, vendors do not simply copy each other. They often start that way, end then they run into questions like <q>what about...</q> and they will have to discuss and test and decide and make changes. Both to the implementation and the spec. Such discussions take place on the W3C mailing lists all the time.</p>
<h3>Standards must be standards</h3>
<p>PPK dislikes vendor prefixes because they seem to be the opposite of standards: Vendor specific rules, code forks, similar to browser sniffing in JavaScript.</p>
<p>But what he is proposing is effectually doing away with the entire W3C process. Yes, it is slow and burdened by politics. But if we drop vendor prefixes that will mean that as soon as a browser puts out a new technology it, by virtue of being first, has decided unilaterally what the syntax should look like and how it should work in every browser. This is not a standards process, this is in fact the opposite. First to market rules and everyone else be damned!</p>
<p>Experimental versions of future standards are a good thing, since they allow for real discussion and much more thorough standardization. One of the reasons standards are moving slowly is that today they are much more detailed, much more tested and therefore much more reliable.</p>
<p>This is not unique to web standards. Consider IEEE802.11n and the fact that we for a couple of years had <q>draft</q> version equipment on the market. Good or bad? It made the final implementation better, so yes it was good. And a necessary evil as well.</p>
<h3>There must be room for errors</h3>
<p>Webkit has not copied Mozilla's implementation of border-radius and Mozilla has not copied Webkit's gradients. Having discussed the proposals changes have been made, lessons have been learned and this has happened in real life.</p>
<p>If a vendor must not use prefixes it would take forever to get to a place where they would be confident enough to put out a new technology. Opera and Microsoft may skip the prefix for border radius, since thanks to Mozilla that 6 years ago put out an experimental implementation and thanks to Webkit, that 3 years ago put a out a slightly different experimental implementation, the standard has now reached Candidate Recommendation status and web authors demand the technology, <strong>because we have been able to experiment with it!</strong></p>
<p>If it had not been for prefixes, only a very few people would actually have bothered to download experimental browsers and try this out. That is our only other option. The word would not have spread and demand had not been built up.</p>
<p>Is summary. PPK, I love your work and have tons of respect four you. But in this case you are wrong. I will not shout <q>long live the prefixes</q>, since I wish that every prefixed CSS rule should have <strong>short</strong> life. But I want that short life to be productive.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com2tag:blogger.com,1999:blog-17809600565735611.post-51466334803167701622009-09-10T00:07:00.006+02:002009-09-10T00:27:25.918+02:00Pedagogic validation of HTML<p>I have been trying to make HTML5 better for education by participating in the HTML5 effort at <a href="http://whatwg.org/">WHATWG</a> for a few years. Recently also joined the <a href="http://www.w3.org/html/wg/">W3C HTML5 Working Group</a>. One of the things that might come out of this effort is an option in the HTML5 <a href="http://validator.nu/">validator</a> for pedagogic validation. I will try to explain what such an option should check for, and how it will be beneficial to teaching web development.</p>
<p>I have <a href="http://www.blogger.com/2009/07/value-of-false-xhtml.html">previously written</a> about what I call the value of <q>false</q> XHTML. Now I have been joined by the <a href="http://www.zeldman.com/superfriends/">HTML5 superfriends</a>, who <a href="http://www.zeldman.com/superfriends/guide/#validation">request an option</a> for easy polyglot validation. Henri Sivonen, who no doubt is a parsing rules genius and exceptionally knowledgeable, basically replied that such a thing is very hard, and contains so many minute details, that it might be of no value. Did you know that a line feed immediately following the starting pre-tag is forbidden, when using XML parsing rules? I most certainly did not. (And I am still a bit unsure if I got it right...)</p>
<p>I usually also skip the tbody-tags when I do tables, but they are nevertheless automatically inserted into the DOM in HTML, just like head and body is. That will not work for a true polyglot document, since in XHTML the DOM will not be the same. Henri also suggests that using XHTML syntax might lead to a false understanding, as if one would believe that <code><script /></code> would be possible to write in normal HTML.</p>
<p>I <a href="http://www.zeldman.com/2009/08/31/loving-html5/#comment-48124">commented on Zeldmans blog</a> that from my perspective these are non issues. Let me tell you about the everyday problems I encounter as a teacher of markup languages, in addition to what a normal validation would reveal:</p>
<ul>
<li>Students forgetting to quote attribute values, even though they contain multiple words.<code><img alt=My dog></code></li>
<li>Students messing up the balance of the quotation marks: <code><img src="foo.jpg alt=My dog"></code></li>
<li>Students messing up the DOM since they do not (yet) know all the rules for when an element is implicitly closed by another elements starting tag.</li>
<li>Students using document.write (and eval) in their scripts - yes I explicitly tell them not to, but they don't always listen, do they?</li>
</ul>
<p>For reasons like these I tell them to use XHTML syntax today, since that will catch most of these errors.</p>
<p><code>document.write</code> and <code>eval</code> is outside the scope of HTML validation, but ECMAScript 5th edition strict mode and JSLint will take care of most such problems. What I would like is for HTML validation to have similar checks, checks that enforce good habits and helps to avoid rookie mistakes.</p>
<h4>What's the problem with true polyglot documents then?</h4>
<ul>
<li>The minutiae. The stuff Henri Sivonen rigthly reminds us of. The stuff that should be saved for a later class, since it is so highly technical and frankly will scare some away from coding by hand.</li>
<li>The boolean attributes. Some HTML5 form elements may have a lot of those! Allowing them to exist in their shortened form would mean less markup to type (= happier students, less bandwidth required).</li>
</ul>
<p>As you see, I do share some of the concerns about XHTML syntax. But today the benefits clearly outweigh the drawbacks, from a pedagogic perspective. But this naturally leads me to the conclusion that there should be some middle ground, a way to specify a pedagogic profile for validation - and voila - <a href="http://intertwingly.net/blog/2009/09/08/First-Polyglot-Validator-Check-Deployed#c1252443777">Sam Ruby has started to work on such a feature!</a>
</p><p>I will now explain what features such additional checks should have, according to my experience, and how they are beneficial. I will grade my suggestions from 1 to 5, in rising order of importance.</p>
<h4>Avoid implicit rules</h4>
<p>But check that what's explicit comply with them. One should as a newbie see a 1:1 correlation between the DOM and the markup.</p>
<h5>All elements should be explicit</h5>
<p>This would mean that:</p>
<ul>
<li>Root-element (html), head and body tags should not be optional (grade 5).</li>
<li>tbody tags should not be optional (grade 1).</li>
</ul>
<p>In order to avoid making classes boring, I usually teach HTML together with some CSS from day one. I do not teach HTML first for a few weeks, and then I teach CSS. Besides being boooring, this will lead to some students starting to use presentational elements and attributes, because they will <strong>really want</strong> to have design features from day one.</p>
<p>CSS rules (usually) apply to the DOM, and not the markup, e.g. you can not have have a <code>table#foo > tr</code> selector even if there are no tbody-tags in the code. The student would think that a tr is a child element of table, since implicitly added elements might not be taught until later. It is, however, not usually so that one starts using tables early on - since they are not used for layout when I teach CSS in conjunction with HTML, so I can live this particular check not being implemented, hence it is graded at 1 only.</p>
<p>Explicitly grouping meta data about a document in the head section, and specifically being able to put some scripts in the head and other scripts in the body, is however very essential. In HTML5 we might also see scoped style-elements, which makes the use of explicit head and body tags even more important.</p>
<h5>All elements must be explicitly closed</h5>
<ul>
<li>All normal elements must have closing tags.(grade 5)</li>
<li>Void elements must have a trailing slash. (grade 3)</li>
</ul>
<p>The use case for closing tags is really simple. Besides making things easier to understand, it also alerts students about implicitly closed elements. If they would try to include a table in a paragraph the validator would complain when it encounters the closing p-tag. For such reasons I tell my students that closing tags are mandatory, and I want a simple way to enforce that behavior.</p>
<h4>All non-shortened attributes must have their values quoted. (grade 5)</h4>
<p>As I've said above, this is a very common error. In the worst case scenario it might lead to very unexpected results. Look at this example, where the value attribute is supposed to contain the words <q>Login name</q>:</p>
<pre><code><input type=text value=Login name name=login></code></pre>
<p>This code snippet actually produces a DOM as if the markup had read:</p>
<pre><code><input type="text" value="Login" name=""></code></pre>
<p>Arguably, enforcing quotation marks also leads to better readability.</p>
<p>There are a few attributes that <em>might</em> be exceptions to this rule:</p>
<ul>
<li>If the only possible value is an integer.</li>
<li>If the only possible value is a keyword containing only US-ASCII letters.</li>
</ul>
<p>However, enforcing good habits takes precedence over any other concern. I always start teaching the hardest possible rules, and the I gradually relax them. This works better than doing it the other way round.</p>
<h4>Attribute values that contain > or = probably are errenous (grade 3)</h4>
<pre><code><abbr title="Et cetera>etc</abbr>
<abbr title="Et cetera class="foo>etc</abbr></code></pre>
<p>These are two examples of mismatched quotation marks., Yes, it happens a lot that I look over a shoulder of a student and say that they have forgotten to close the attribute - even though they have syntax highligthing on in the editors. (Not everyone's a genius and some are color blind!) If I could have tools that took care of the easy stuff, I'd be able to spend more time explaining the real issues and everyone in my classroom would be happier.</p>
<p>Since at least the second error might be confused with valid use, this behavior probably should generate a notice, not a real error. <q>Using the equal sign in an attribute value might be an indication of a real error, please check that your markup is correct.</q></p>
<p>Many of these errors would probably get reported even with todays validation rules. I am gunning for those edge cases where two errors even each other out so that they mask each other.</p>
<h4>Language must be specified (grade 5)</h4>
<p>This one is self-explenatory. There really should be a lang-attribute set on the root element. This actually should be a regular conformance critera, but since such a rule will wreck a lot of currently valid sites, that is probably not doable.</p>
<h4>The alt attribute must always be present om images. (grade 5)</h4>
<p>While the jury (maybe) still is out on whether this should be a regular conformance criteria (as I think it should) or not, at least the following could be said without any hesitation or doubt: <strong>No single argument against a mandatory alt-attribute applies to the learning situation</strong>. Even if we say that sites like Flickr should be able to be conformant even if users do not spply usable alt text and having considered every other option it is decided to make the alt attribute optional, those use cases for sure do not apply in the class room! If HTML5 eventually would go down that route, for this reason alone a pedagogic profile in the validator has earned its right to exist.</p>
<p>I am actually a bit reluctant to add this point. I fear it might re-open a can of worms and be taken as an argument against having alt as a mandatory attribute, since those who wish would now have a way of checking for its existence. However, I hope that everyone realizes that this is not the same discussion. My only point is, that <strong>if</strong> worst should come to worst, this feature is necessary.</p>
<h4>What else?</h4>
<p>I am going to give this some thought — and Sam Ruby a few initial test cases… After which I might revisit this subject and alter my list of things to test. Of course all feedback is welcome!</p>
<p>One thing that I've thought about is a check for code indentation. But first of all it is probably not possible to check for this in a reasonable manner. And would it be possible to agree on a standard? Nah! I don't think so.</p>
<p>P.S. If someone wonders why my blog has the word <q>Thinkpad</q> in its name, I do still have an ambition to document my joys and woes about using Fedora Linux on my Z61p (and on my still un-bought W700…). Patience, patience.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com16tag:blogger.com,1999:blog-17809600565735611.post-51246256748952691502009-08-21T17:38:00.003+02:002009-08-23T21:18:24.852+02:00Web Education Rocks Indeed<p><img style="float:right; margin:0 0 10px 10px; width: 320px; height: 240px;" src="http://1.bp.blogspot.com/_KnOn6Z8lFzA/SpGLYQqU9nI/AAAAAAAAABY/zcqKZr7UXGY/s320/we-rock-09-088.JPG" border="0" alt="Aarron's hand pointing to the OWEA vision taking shape" />I had the privilege and pleasure to attend the <a href="http://webeducationrocks.com/"><abbr title="Web education">WE</abbr> Rock Summit</a>. To me the meeting was a perfect illustration about the power and limitation (sic!) of the Internet. Living in Sweden and working for a public school where one does not have access to an abundance of money (to say the least), I have not been able to participate in <a href="http://sxsw.com/">SxSW</a> or similar conferences in the USA. In fact, my only contact with the other participants, except for Chris Mills from England, had been through the net. That fact had no stopped us from getting to know each other and organize around the vision of bringing the best possible standard for Web education to schools, colleges and universities around the world.</p>
<p><img style="float:right; margin:0 0 10px 10px;width: 320px; height: 240px;" src="http://3.bp.blogspot.com/_KnOn6Z8lFzA/SpGU2vKJzAI/AAAAAAAAABw/QXQ7a2AMf8k/s320/we-rock-09-065.JPG" border="0" alt="OWEA Summit in progress onboard the Delta Queen" />
Meeting in person was a lot like meeting old friends. We did not need to connect instantly, we were already connected! We did not need to get off to a flying start in our work. We had already started. The fact that a lot of discussions were tentative and that a lot of resolutions still remain to be done, is not an indication about anything but the fact that what we are trying to do is to a large extent an adventure into unchartered territory. To launch a Web Education Organization at this level is simply an undertaking that no one has made a realistic attempt to do before <a href="http://www.w3.org/2005/Incubator/owea/">OWEA</a>.</p>
<p><img style="float:right; margin:0 0 10px 10px;width: 320px; height: 240px;" src="http://3.bp.blogspot.com/_KnOn6Z8lFzA/SpGNDRM-E7I/AAAAAAAAABg/95pHM4LvO7k/s320/we-rock-09-111.jpg" alt="Leslie Jensen and her team at the Hunter Museum" border="0" />At the same time being able to meet in person took our productivity to a whole new level. There simply is a level of interaction that is made possible by being in the same room. For this opportunity I am deeply grateful to our sponsors. What they made possible was perfectly realized through the skills and the personal care of the local hosts in Chattanooga. Thanks to their welcoming attitude, personal warmth, attention to detail and zeal for our common vision, our meeting never felt like an ardous task. Productivity in discussions remained the product of enthusiasms. Yes, it was intense, and yes, we got tired. But we had fun all the time!</p>
<p><img style="float:right; margin:0 0 10px 10px;width: 320px; height: 240px;" src="http://4.bp.blogspot.com/_KnOn6Z8lFzA/SpGRMTo_zqI/AAAAAAAAABo/krjRTD6qZog/s320/lookout-mountain-point-park-030.jpg" border="0" alt="Me at Point Park leaning against a gun from the Civil war" />When the summit was over I stayed a couple of days. I attended a service at <a href="http://www.obcministries.org/">Olivet Baptist Church</a> — since I wanted to experience real gospel worship. I looked at city sites like <a href="http://www.bluffviewartdistrict.com/">Bluff View</a> and a few parks. I also went to the Tennesse Aquarium and <a href="http://www.nps.gov/chch/index.htm">Point Park</a> on Lookout mountain. To round things off I was met with great hospitality from Aaron and Cathy Gustafson during Monday. When our faithful driver, Shaun, left me at the airport on Tuesday, it felt like I'd been away for a month, not a week.</p>
<p>What I bring home is fond memories of meeting wonderful people, renewed passion for Web Education and a great hope that OWEA will make a difference, yes, even make the world a slightly better one! And a longing to return for another visit to Chattanooga!</p>
<p>P.S. More photos are posted on my <a href="http://www.flickr.com/photos/keryxgunther/">Flickr page</a>.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com3tag:blogger.com,1999:blog-17809600565735611.post-18839363114718382632009-07-19T21:19:00.014+02:002009-07-22T18:35:41.376+02:00The value of false XHTML<p><a href="http://twitter.com/itpastorn/status/2502477428">I believe there is a value</a> to using <abbr title="Extensible Hyper Text Markup Language">XHTML</abbr> syntax for documents sent to the browsers as <dfn>text/html</dfn>. That seemed like the normal thing to do just a short time ago. Now it is increasingly being met with skepticism and even ridicule. I believe I've encountered every <abbr>XHTML</abbr> myth busting argument there is from the good people in the
WHAT WG cabal, but I still see a value in using <abbr>XHTML</abbr> syntax.
My arguments are not centered around forward compatibility, extension mechanisms or
<abbr title="Extensible Style Sheet Transformations">XSLT</abbr>, even though they could apply — server side. My reasons for using <abbr>XHTML</abbr> syntax is to avoid errors, misunderstandings and rookie mistakes. Since I teach web development for a living <a href="http://twitter.com/itpastorn/status/2510856882">I encounter a lot of those</a>.</p>
<h4>The issues</h4>
<p><abbr>HTML</abbr> 5 is clarifying what <abbr>XHTML</abbr> really is. A lot of web sites are using an <abbr>XHTML</abbr> doctype, even though the code will be parsed as just like ordinary <abbr>HTML</abbr>, i.e. they use <em>false</em> <abbr>XHTML</abbr>. But draconian error handling, including Unicode errors, altered CSS applicability, the breaking of 99 % of all JavaScript code in existence, including all major libraries, and of course, Microsoft's not implementing true <abbr>XHTML</abbr> at all, all of this will continue to make <em>true</em> <abbr>XHTML</abbr> a non option for anything else but experiments and edge cases for the foreseeable future.</p>
<p>Put in one sentence: Specifying an <abbr>XHTML</abbr> doctype does not make a document <abbr>XHTML</abbr>. As we know by now, the doctype serves only one purpose in the browser and that is to trigger standards mode (assuming a good doctype). And if a browser treats <abbr>XHTML</abbr> 1.0 strict <em>exactly the same</em> as it treats <abbr>HTML</abbr> 4.01 strict, why not opt for the latter? And as <abbr>HTML</abbr> 5 has no other mechanism to specify <abbr>XHTML</abbr> other than the MIME-type, what one might chose to call <em>false</em> <abbr>XHTML</abbr> is no longer possible to use.</p>
<p>On the other hand, <abbr>XHTML</abbr> syntax that previously was illegal in <abbr>HTML</abbr>, like explicitly closing void elements (br, hr, input, meta) with a trailing slash, is now fully permitted, although described as a transitional feature. Judging from the fact that most new sites still use a transitional doctype we can safely assume that there is nothing stopping us from using an <abbr>XHTML</abbr>-like syntax even in <abbr>HTML</abbr> 5. I will proceed to argue that it often even is a very good choice.</p>
<h4>polyglot documents</h4>
<p>Pages using such syntax have even got a recently popularized name: <a href="http://dev.w3.org/html5/html-author/#polyglot-documents">polyglot documents</a>. Let us consider a few features a polyglot document will lack, being sent as <em>false</em> <abbr>XHTML</abbr>:</p>
<ul>
<li>No namespace support, but <abbr>HTML</abbr> 5 will (probably) special case <abbr title="Scalable Vector Graphics">SVG</abbr> and <abbr title="Mathematical Markup Language">MathML</abbr>, so the most sought after compound documents will still be possible to author.</li>
<li>No draconian errors. A <q>feature</q> most developers won't miss at all.</li>
<li>XML parsers that rely on the MIME-declaration will fail or refuse the document. There should be easy workarounds for that.</li>
</ul>
<p>The list can be expanded. I just want to illustrate the fact that in the near future, any benefits of using <abbr>XHTML</abbr> syntax will only to small degree be related to XML technical features. Indeed, when <a href="http://code.google.com/p/html5lib/">HTML 5 lib</a> has become widely available and integrated with all server side scripting languages, we are promised that all of today's XML-server side tools, will work equally well for non-polyglot <abbr>HTML</abbr> documents.</p>
<h4>The continued benefit 1: <abbr>XHTML</abbr> syntax works like a <a href="http://en.wikipedia.org/wiki/Coding_conventions">coding convention</a></h4>
<p>Every major project that involves more than one programmer will soon run into the need of following agreed upon standards for things like indentation, placement of braces, usage (or non-usage) of a space between arguments in function calls and definitions, etc. A programmer that does not know or care about this will quickly see his contributions be rejected and is probably considered non-employable.</p>
<p>Douglas Crockford <a href="http://javascript.crockford.com/code.html">has introduced coding conventions</a> for JavaScript to many and his <a href="http://www.jslint.com/">JSLint</a> tool has options that will ensure that you follow them. <abbr>HTML</abbr> Tidy has options to clean up code, but other than that I know of no common code convention for <abbr>HTML</abbr>. I know that for many of my friends the beauty of <abbr>XHTML</abbr> has been the clean syntax. For reasons like the following:</p>
<ul>
<li>Enforcing lower case element and attribute names are easier on the eye than code that SHOUT.</li>
<li>Enforcing citation marks around attribute values makes errors easier to avoid or spot.</li>
<li>Explicit closing of elements like li, tr, th, td and p, also make code easier to read. No guessing the intention (was the implicit close intended or just sloppiness?) makes it easier to work with other peoples code, or even code that I've written myself a while ago.</li>
</ul>
<p>Let me elaborate that second point. One particular nasty problem occurs when attribute values are generated using server side scripts. Let's say that for a few iterations in an applications life a particular value is always a single word, like in "login". Suddenly another developer (or you) decide that it is better to use two words, like "login name". And since the code that generates this value might be miles apart, like in another file and module, from the template that outputs the actual <abbr>HTML</abbr>, one can not take for granted that such a change would not break anything. In a sentence: Quoting attribute values makes code more robust!</p>
<h4>Counterargument: You can do that equally well in regular <abbr>HTML</abbr></h4>
<p>The primaryu counterargument usually sounds like this: <q>But you don't need <abbr>XHTML</abbr> syntax. Nothing is topping you from using lower case tag names and attributes or the optional closing tags in regular <abbr>HTML</abbr>, if you wish.</q> True. But nothing is <strong>enforcing</strong> it either! And there is no tool available for testing it, at least none that I know of.</p>
<p>Neither does this counterargument apply too all aspects of my second argument.</p>
<h4>The continued benefit 2: <abbr>XHTML</abbr> syntax is good for beginners!</h4>
<p>A few years ago <a href="http://lachy.id.au/log/2005/12/XHTML-beginners">Lachlan Hunt wrote that <abbr>XHTML</abbr> is too hard for beginners</a>. There is basically two things that make me take a stance that is exactly opposite of his. The first is that he is talking about true <abbr>XHTML</abbr>, I am talking about false. The second would be that my main job for almost a decade has been to teach complete newbies about web development. I would not presume to know even half of what he knows about the minute details of markup languages. I dare say, however, that I know much more about teaching this stuff to students.</p>
<h5>Coding conventions should be taught from day one!</h5>
<p>Here is a rule for all teachers of all things coding. Demand that students should use strict coding conventions from day one. Do not think that it can be introduced at a later stage. Sloppy habits are formed from day one, and are much harder to get rid of once they have formed. Often when I look over the shoulder of a student, and see ghastly looking code, the student will say that it will be fixed later. Judging from nearly a decade of experience I know that <em>it will not happen</em>!</p>
<p>Bad habits get picked up from day one. They should therefore be punished from day one. Requiring <abbr>XHTML</abbr> syntax is one way to enforce such practice.</p>
<h5><abbr>XHTML</abbr> is the more pedagogic syntax</h5>
<p>Requiring students to close void elements is a very effective way of teaching them what elements are indeed void. In the days when we use named anchors for intra-page navigation (as opposed to setting the id attribute on any element) I had students that forgot, or lazily omitted the closing tag. Their pages worked just fine. The only downside was a more complex DOM and that was not discernible for their pages. In fact, some of them believed that such an anchor was a void element. It even took a while for me to grasp that it was not. <abbr>XHTML</abbr> helped me understanding that, and I've seen it help other people come to grips with similar issues.</p>
<p>Explicitly closing elements helps making students understand the concept of semantics. You do not insert an li just to get a bullet point, all things between the starting and ending tag is a list item. You do not insert a p-tag to get some space between your lines. All text between the starting and the ending tag is a paragraph. Etc. Being forced to constantly ask oneself where something should start and where it should end is a good for learning.</p>
<p>I also would like to add, that requiring <abbr>XHTML</abbr> is good for the mental health of me as a teacher, since a lot of errors will be caught by the students themselves during validation, and their code will be easier to read for me.</p>
<h4>The true dowsides of false <abbr>XHTML</abbr></h4>
<p>Nothing in life is so rosy as to have no negative downsides. With every medicine has its side effects. The two most immediate ones for newbies both involve scripting:</p>
<h5>Tag names are <a href="https://wiki.mozilla.org/Firefox:3.0_DOM_Case_Sensitivity">sometimes uppercased in the DOM</a></h5>
<p>Such things happen when an organization badly applies the biblical principle of <a href="http://www.biblegateway.com/passage/index.php?search=matthew+6:3">the left hand not knowing what the right hand is doing</a>. However, this confusion will exist, no matter which syntax you chose. Using <abbr>HTML</abbr> syntax with all uppercase element names is not common practice and it won't be long until the principle has to be explained to a student anyway.</p>
<h5>Technically redundant closing tags will cause un-intuitive text nodes to appear in the DOM</h5>
<p>Consider this code:</p>
<pre><code><ul>
<li>foo</li>
<li>bar</li>
</ul></code></pre>
<p>How many child nodes to the ul-element are there in the DOM? To a newbie (and Internet Explorer) it looks like 2. To the trained eye it is 5. But once again new technology comes to the rescue. By <a href="http://hacks.mozilla.org/2009/06/dom-traversal/">introducing new DOM-walking APIs</a> we can (in the future) ignore those white-space only text nodes, in a cross browser consistent manner, using native API-calls.</p>
<p>Note that the first white-space only redundant text node would still be left, even if we had omitted the closing tags. And lets say for a moment that a student had authored a script that relied upon there being no closing tags. How confused would he/she not be when it suddenly stopped working because someone suddenly used closing tags? How bristle would such code not be in real use?</p>
<h4>The future</h4>
<p><a href="http://my.opera.com/jax/blog/html5-xml-stealth">Maybe there are some technical benefits</a> of <abbr>XHTML</abbr> as well, but I hope to have shown that even without them, the syntax has clear benefits — enough to tell my students that they should use it, either as <abbr>XHTML</abbr> 1.0 strict or as <abbr>HTML</abbr> 5 polyglot. So where do I want to go from here? This is my wishlist for the future:</p>
<ol>
<li>The (X)HTML 5 spec should be strictly serialization and syntax neutral. <abbr>XHTML</abbr> syntax is not only something that should be allowed for <q>transitional</q> reasons.</li>
<li>I would love to have a (X)HTML coding convention tool, that could check for even more details than <a href="http://validator.nu/">the current validator</a> does. Things like indentation, or allowing shortened attributes for boolean attributes, while enforcing citation marks for all non-bolean ones, ought to be testable. Such a tool might even make me think that there can arise even better alternatives than polyglot documents.</li>
</ol>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com2tag:blogger.com,1999:blog-17809600565735611.post-38261536867756318082009-07-13T11:55:00.005+02:002009-07-13T21:27:43.915+02:00No backwards compatibility = XHTML 2 was doomed to failure<p><abbr title="Extensible Hyper Text Markup Language 2">XHTML 2</abbr> is the Itanium of web technologies. You remember Intel and <abbr title="Hewlett Packard">HP</abbr> celebrating the <a href="http://en.wikipedia.org/wiki/Itanium">Itanium</a> architecture as the new super-duper technology, that should leave all <a href="http://en.wikipedia.org/wiki/Reduced_instruction_set_computer">RISC-based</a> competitors in the dust. <a href="http://en.wikipedia.org/wiki/Very_long_instruction_word"><abbr title="Very Long Instruction Words">VLIW</abbr></a> (re-branded as <a href="http://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing"><abbr title="Explicitly parallel instruction computing">EPIC</abbr></a>) was touted as a disruptive innovation. The future was Itanium.</p><p>But it was not! Forget the marketing speak from Intel and its only Itanium customer worthy of being mentioned, HP. Itanium has flopped. Yes, other <abbr>RISC</abbr> architectures, are struggling. <a href="http://en.wikipedia.org/wiki/MIPS_architecture">MIPS</a> no longer power high end servers from Silicon Graphics. <a href="http://en.wikipedia.org/wiki/SPARC">SPARC</a> is loosing market share. Only IBM Power PC seems to be holding its ground in the server space. But the <abbr>x86</abbr> architecture, that was supposed to die, is reigning more dominantly than ever.</p><h4>Backwards compatibility is everything</h4><p>Being backwards compatible is not only a nice feature. It is a prerequisite that simply seems non negotiable. Let's look at a few successful products to get an idea.</p><h5>Windows 95 and DOS-based games</h5><p>Before Windows 95 all high end games were run from the DOS-prompt. Windows 3.x was only a nuisance for game developers. In order to achieve the highest possible speeds they often tweaked the hardware interaction in every possible way. Getting these games to run under Windows 95 proved a challenge, to say the least. Microsoft solved this by special-casing game after game. The operating system would recognize a particular piece of software, know that it required special handling and adjust accordingly. Even in ways that broke protocol.</p><h5>Punch cards</h5><p>When were <a href="http://en.wikipedia.org/wiki/Punched_card">punch cards</a> invented? 1725. When did they become a big success? 1890. When did they become surpassed by other technologies. In the early 1960's. When did IBM drop support for punch cards from their operating systems? Not for another 30 years. I would not even be surprised if it was possible to attach a punch card reader to a brand new <a href="http://www-03.ibm.com/systems/z/">z-series</a> computer today, and actually have it work.</p><h4><abbr>XHTML 2</abbr> was Dead <em>Pre</em> Arrival</h4><p>It did not die as a markup language for the web. It never lived. The day the decisions was made not to be backwards compatible, it was doomed. It never really mattered that it had every conceivable shiny new feature. Technical merits are simply not enough. Therefore it simply does not matter <a href="http://www.sitepoint.com/forums/showthread.php?t=610459">how much you shout about them</a>, or how much you disdain the fact that <abbr>HTML 5</abbr>, due to its legacy, is <q>awful</q> and badly designed.</p><p>Yes, I use <abbr>PHP</abbr> too, and no matter how much one shouts the relative technical merits of Ruby or Python, <abbr>PHP</abbr> seems not to grow weaker. Ugliness just is not that big a factor. A strong user base, re-use of code and know-how, ability to find advice and support, such things matter. Sociology always trump technology.</p><h4>The future for <abbr>XHTML 2</abbr></h4><p>I have friends who prefer <abbr>XHTML 2</abbr> to <a href="http://www.docbook.org/">DocBook</a>, for data storage on the server. Reading <a href="http://www.pemberton.nl/vandf/2009/07/xhtml2-not-dead.html">Steve Pembertons thoughts about the future</a>, he seems to believe that is a viable niche and that it can make a comeback that way. And why not, in a controlled environment the improved semantics of <abbr>XHTML 2</abbr> over legacy <abbr>HTML</abbr> may provide significant benefits. Pushing <abbr>XHTML 2</abbr> as a progressive enhancement, server side, might work.</p><p><a href="http://blog.halindrome.com/2009/07/w3c-you-ignorant-slut.html?showComment=1246995521903#c2474691374247972450">Encouraged by none other than Ian Hickson himself</a> <abbr>XHTML 2</abbr> will continue to be developed in a working group outside of the <abbr title="World Wide Web Consortium">W3C</abbr>. Can it make a comeback? Once upon a time the W3C decided to axe <abbr>HTML</abbr>. Many developers, myself included, thought it was the end of HTML. I was wrong. I therefore will not say, good bye <abbr>XHTML 2</abbr>, but <span lang="fr">a revoir</span>.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com0tag:blogger.com,1999:blog-17809600565735611.post-31720959530074100082009-06-28T09:58:00.004+02:002009-06-28T10:36:18.399+02:00Do not put experimental features last in your CSS<p>Today's blog post will be short one. I have lately <a href="http://forabeautifulweb.com/blog/about/five_css_design_browser_differences_i_can_live_with/">seen code</a> like this on more than one occasion:</p><pre><code>#foo {
border-radius : 10px;
-moz-border-radius : 10px; /* Mozilla */
-webkit-border-radius : 10px; /* Webkit */
}</code></pre><h4>What is the problem?</h4><p>Right now only one line will have an effect. In Gecko-based browsers, like Firefox, the one starting with <code>-moz-</code>, in recent Webkit based browsers, like Safari and Chrome, the one starting with <code>-webkit-</code>, as indicated in the comments. These are the two current <strong>experimental</strong> implementations of the coming <abbr>CSS</abbr> 3 border radius property.</p><p>Hopefully in the near future the specification will thanks to these two implementations reach a level of maturity, where browsers may start to implement it in a non-experimental version. If so one thing is to be expected. <strong>The non-experimental implementation will most likely differ (somewhat) from the experimental one!</strong> And as a developer you will most probably want the final version to be the one that browsers actually use. And when two rules affect the same property like this (equal specificity, equally placed in the cascade), the last one will override the first one. Therefore you should put things in this order:</p><pre><code>#foo {
-moz-border-radius : 10px; /* Mozilla */
-webkit-border-radius : 10px; /* Webkit */
border-radius : 10px;
}</code></pre><h4>Why is this better?</h4><p>During a transition phase, lasting at least a few years, Webkit and Gecko can be expected to support <strong>both</strong> implementations. There are sites that use the experimental versions <em>only</em> and in order to give them a grace period, dropping support as soon as the final version is implemented is not an option. Historically Mozilla has let such grace periods last for 2-4 versions of Firefox.</p><p>So this is the bottom line. Put experimental features first, standard features last. That will ensure a better forward compatibility.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com0tag:blogger.com,1999:blog-17809600565735611.post-57068413117620011122009-06-27T13:00:00.011+02:002009-07-13T10:57:33.661+02:00Validation and doctype myths and (inconvenient) truths<p>People like me who support web standards often talk about validation and doctypes. Yet, even within our camp, there seem to be a lot of confusion. I will try to address a few misconceptions, especially a few new ones that has come out of the ongoing debate about <abbr>HTML 5</abbr> and accessibility and <abbr title="Resource Description Framework (in) attributes">RDFa</abbr>.</p><h4>Background: How a browser processes markup</h4><p>Most people tend to think in two stages. There is markup and there is a rendered page on the screen. In reality this is a a more complex process.</p><p>First comes <dfn>parsing</dfn>. The purpose of this is to convert the markup into an representation inside the program that is so to speak "understandable" to the computer and usable for rendering on the screen as well as to assistive technologies, like a screen reader. This internal representation is accessible also to manipulation through the <abbr title="Document Object Model">DOM</abbr> <abbr>API</abbr>. Indeed it is often talked about as the <q>internal <abbr>DOM</abbr> representation</q> of the document. From now one I will simply call it the DOM. Just bear in mind that I refer to this internal functionality as a whole, and not to the API in the rest of this article.</p><p>Parsing in itself is a multi-step process. It involves the simple mapping of the <abbr>HTML</abbr> markup, but also the applying of <abbr>CSS</abbr>, handling events, etc.</p><p>The <dfn>rendering</dfn> (painting on the screen) is in turned made from the <abbr>DOM</abbr>. As is the <em>exposure of the page to assistive technologies</em>.</p><p>Personally I've found it helpful to think about this process in three stages:</p><ol><li>The code (<abbr>HTML</abbr>, <abbr>CSS</abbr>, <abbr>etc</abbr>) arrives as a <dfn>network stream</dfn>.</li><li>The <abbr>DOM</abbr>, constructed by the parsing.</li><li>The perceivable results (on the screen, in the speakers, in the braille terminal, on paper from print, etc.)</li></ol><p>With this knowledge we can formulate the purpose of validation:</p><ul><li>Validation provides a secure mapping between the markup and the <abbr>DOM</abbr>. You as a developer know what you are going to get.</li><li>Validation provides easier development, including easier error detection and better maintainability through cleaner and consistent code.</li></ul><p>Browsers have always had mechanisms to handle badly written <abbr>HTML</abbr>. Indeed they have reverse engineered each other in this regard so much that invalid, tag-soup, piece of shit code usually renders just fine. And the <abbr>HTML 5</abbr> spec goes to great length to explain just how such code should be handled by a browser. If one has supreme knowledge about every little detail of how browsers work internally, one can therefore get predictable results even with code that does not validate at all.</p><p>Web developers should, however, not be required to have such in-depth knowledge. Validation is a tool that helps us stay within safe boundaries. Stepping outside them might work, but it will always lead to extra work in the end.</p><p>With this in mind we can formulate a few spin-off effects of validation, such as:</p><ul><li>Validation is an act of courtesy towards other people who one day might be charged with taking over your code base, or indeed only be asked to take a look on a mailing list or forum, to help you solve a problem.</li><li>Validation is a mark of professionalism, a sign that you care about code quality.</li></ul><p>But the main effect is that validation is a <strong>tool</strong> that helps you as a developer get to your desired results. I always tell my students to validate early and validate often. After every major change to the code, re-run the validator!</p><p>Or to put it differently. Valid code is not the end goal, it is a very good tool in order to reach the end goals of predictability, consistency, maintainability and effectiveness.</p><h4>Myth: <q>You must validate in order to be accessible</q></h4><p>Wrong. Validation is advisable of course, but in a pure technical sense not a requirement. It is perfectly possible to write unsemantic code, without proper hooks for assistive technologies, that still validates. And it is perfectly possible to do the other way round, although validation — especially to a strict doctype — will be <em>one help</em> towards accessible web sites.</p><p>Validation can check for the presence of accessibility features, such as alt-attributes, table column headings, etc. It can never ensure that the contents within those attributes and elements have been written in a usable way. Valid code is a good starting point for accessibility, not a guarantee of accessibility.</p><p>This is especially true for the non-strict versions of <abbr>HTML 4.01</abbr> and <abbr>XHTML 1.0</abbr>. These 4 (2 * 2) <abbr>(X)HTML</abbr> versions contain a lot of elements and attributes, that should not be used. The validator will complain that they are <dfn>deprecated</dfn>, but it will still give the page a green light. Anything but strict doctypes or conformant <abbr>HTML 5</abbr> (see below) should have been <span lang="de">verboten</span> long ago for any professional web developer.</p><h4>Myth: <q>There is no penalty for not validating</q></h4><p>There is one camp, primarily accessibility experts, who would like browsers not to render pages that contain markup errors, or at least give clear warnings that they do. Recently it has been advocated that e.g. the <abbr>HTML 5</abbr> canvas element should not render anything to sighted users unless there is a fallback for the blind. They also have argued that any refusal to incorporate <abbr title="Accessible Rich Internet Applications">ARIA</abbr> or <abbr>RDFa</abbr> into <abbr>HTML 5</abbr> can simply be overridden because <q>validation does not matter</q>.</p><p>In this context it is true. As long as browsers and assistive technologies support <abbr>ARIA</abbr> and Google, Yahoo and other search providers will honour <abbr>RDFa</abbr>, it will work. User agent behaviour is always the bottom line, the true de facto standard in practice.</p><p>This takes us back to my main theme for this article. <em>Things might work when using code that is not valid.</em> But you can be much more confident that it will, if it validates. In my experience, the most common error that I catch using a validator is spelling errors in tag and attribute names. Such errors may wreck your page in many ways, maybe even in unseen ways because you have misspelled an <abbr>ARIA</abbr> attribute. And such errors are easier to spot if they are not hidden behind hundreds of other validation errors, that by themselves actually are benign.</p><p>Let me repeat that. Many validation errors are benign: An un-encoded &, an unnecessary closing tag, and, with <abbr>HTML 4.01</abbr>, forgetting to specify the type attribute for a script. In themselves these errors will not harm the execution of the parser, the construction of the DOM or the rendering of the page on the screen and exposure of its contents to assistive technologies.</p><p>Actually, one may find oneself in a position <strong>where it is beneficial not to be valid</strong>. This applies both to <abbr>HTML</abbr> and <abbr>CSS</abbr>. New features, often available only in their experimental first forms, can be quite useful and add to a page's usability, esthetics or accessibility.</p><p>However, the problem with benign errors is that they often obscure the malicious errors. A page that contain several hundred validation errors is much harder to debug, than one that only has a few. It is therefore imperative that one chooses the best possible validator for one's purpose. E.g. validators can be configured to ignore vendor specific CSS-rules or to include <abbr>ARIA</abbr>.</p><p>Actually, the main reason I use an <abbr>HTML 5</abbr> doctype for all my new sites, and gradually change my own sites to do the same, is so that I can use a validator that supports these new technologies.</p><h4>Myth: <q>You can use JavaScript to cheat the validator</q></h4><p>Technically this is not a myth. Yes you can. Most validators will work on the raw <abbr>HTML</abbr> and will not process any scripts. However, the purpose of validation is not validation. The purpose is predictability, consistency, maintainability and effectiveness. Inserting or altering markup through scripts, or to put it better making changes to the DOM, should be made in such a way as not to jeopardize the very reasons we wanted or code to be valid in the first place.</p><p>This is just like school. Cheating may get you the grade, but you won't get the benefit of the knowledge. Cheating the validator means that you render the validation practically useless.</p><p>There are <a href="https://addons.mozilla.org/en-US/firefox/addon/60">tools available</a> that will let you see the <em>generated</em> <abbr>HTML</abbr>, that is the <abbr>HTML</abbr> as the browser has understood it too be, post parsing and post scripts being run on the page. This is sort of like going back from step 2 above to the first step. That code should be equally valid, and not differ from the original input in any unexpected way.</p><h5>Follow up question: Is it OK to use JavaScript instead of the target attribute?</h5><p>One of the most common uses of JavaScript to cheat the validator is to replace this:</p><pre><code><a href="http://..." target="_blank">linktext</a></code></pre><p>With this:</p><pre><code><a href="http://...">linktext</a>
<script>
// JQuery code that attaches event to all presumed external links
$("a[href^=http").click(function() {
window.open(this.href);
return false;
});</code></pre><p>I belive this is good practice. Not because we are cheating the validator, but because we are using DOM-scripting to handle behaviour. We are using the right tool for the right job.</p><h5>Follow up question: Is it OK to use JavaScript to defeat browser bugs?</h5><p>My first answer is, is that really necessary? For example, it is quite possible to have the object element work in all browsers, including Internet Explorer 6, to serve Flash or Java Applets. Most JavaScript techniques to include Flash on a page have been obtrusive and not degraded gracefully. And they have used outdated browser-sniffing, potentially making them unlikely to work as newer browser versions or alternate browsers like Chrome get released. Using unobtrusive DOM-script to <a href="http://www.vimeo.com/4281939">enhance the plugin experience</a> is of course OK.</p><p>There are however bugs and lacking support for modern standards in some browsers (yes, we all know I primarily talk about MSIE now) that can only be alleviated through scripting. Chose carefully what scripts to use, though! And remember that there are many users that might not get your scripts, perhaps since a corporate proxy has stripped out all content from your script elements.</p><h4>Does the doctype matter?</h4><p>Tied in to the question about validation is the choice of doctype. It serves two purposes:</p><ol><li>It declares what vocabulary a developer intends to use.</li><li>It is the main way in which all sane browsers chose their rendering mode. <a href="http://hsivonen.iki.fi/doctype/">I defer this topic to Henri Sivonen</a>, while asking people to note that Internet Explorer 8 is not sane in any way...</li></ol><p>As regards the first point the doctype is of value to other people with whom you co-operate, a social contract between all developers in the team. But its main value is helping the validator see what rules to validate against.</p><p>Except for rendering mode switching, the doctype does not in any really discernible way affect how the browser will treat the functionality of your markup. E.g. even if you declare a strict doctype, it will happily honour elements like <dfn><font></dfn>, attributes like <dfn>target</dfn> or even the marquee-element! To a (sane) browser, there is no such things as different versions of <abbr>HTML</abbr>. <abbr>XHTML 1.0</abbr> strict or <abbr>HTML 4.01</abbr> frameset or <abbr>HTML 5</abbr> is all the same. Any content sent with the <abbr title="Multipurpose Internet Mail Extensions">MIME</abbr> declaration <dfn>text/html</dfn> is treated the same.</p><p>By dropping the DTD, <abbr>HTML 5</abbr> makes explicit, what so far has been implicit. There are different editions of the <abbr>HTML</abbr> standard, but in practice (inside the <abbr title="user agent">UA</abbr>) there is but one <abbr>HTML</abbr>.</p><p>Even if you have used <abbr>XHTML</abbr> syntax and have an <abbr>XHTML</abbr> <abbr>DTD</abbr>, the markup still will be parsed as usual. To trigger <abbr>XML</abbr> parsing, one must change the <abbr>MIME</abbr> declaration, which of course will fail miserably with Internet Explorer and thus never happens except for niche web sites. It has also been conclusively proven that there is no benefit in switching modes depending on the <abbr>UA</abbr>. The speed difference between <abbr>HTML</abbr> and true <abbr>XHTML</abbr> is first of all negligible and it only really concerns the first step (parsing), which from a performance perspective is only a fraction of time, compared to whats going on in step 2 (the DOM) and step 3 (rendering). (There may be good reasons to use <abbr>XHTML</abbr>, but they are related to workflow, tools and data-exchange.)</p><h4>Myth: <q><abbr>HTML 5</abbr> re-introduces bad markup</q></h4><p>OK this is not exactly a validation or doctype myth, but it is related. the short answer is of course that <abbr>HTML 5</abbr> does not force bad markup down anyones throat. All good practices are still doable.</p><p>This myth started in the early days of <abbr>HTML 5</abbr>, when authors started to look at the spec and saw monstrosities like <code><font></code>, or even <code><marquee></code>! The dual purpose of writing a spec on how to handle bad markup, part of the <q>browser requirements</q>, together with a spec about how to produce good markup quickly turned into a communications debacle. The core team behind <abbr>HTML 5</abbr> is perhaps not the ones with the best people skills in the world. Communication has broken down repeatedly. (On the other hand they are unlikely to change any bad behaviour, perceived or factual, through being bashed.)</p><p>In practice, though, <abbr>HTML 5</abbr> has <dfn>conformance</dfn> requirements — which basically is a new term to describe validity — that are even more far reaching than the ones in </abbr>HTML 4.01<abbr> strict or <abbr>XHTML 1.0</abbr> strict. Being conformant should ensure that you are closer to adhering to best practice and accessibility principles. Validation thus is not less important, it is even more important than ever. Just remember that validation never really has been about anything else but getting a predictable DOM from your markup and encouraging best practices. The conformance criteria in <abbr>HTML 5</abbr> are being written in such a way as to take your code even further towards these lofty goals.</p><p>This is one of the reasons there is no DTD for <abbr>HTML 5</abbr>. These new rules for validity are sometimes so precise or require such processing logic, that they can not be expressed through an DTD. As a side effect we get a doctype one actually can learn by heart:</p><pre><code><!DOCTYPE html></code></pre><p>That will make my students very glad!</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com7tag:blogger.com,1999:blog-17809600565735611.post-40077963163152150442009-05-04T19:44:00.007+02:002010-07-18T11:06:32.929+02:00Rotating column headers using CSS only<div style="border: 2px solid red; margin: 1em; padding: 1em">Note: This article now has <a href="/2010/07/rotating-table-headers-now-in-4-of-top.html">a follow-up from July 2010</a>, explaining how to get this working in more browsers and in a more reliable way.</div>
<p>For a while I have wanted a solution that would rotate table column headers on web pages. In Excel or <a href="http://www.learnopenoffice.org/CalcTutorial10.htm">Open Office Calc</a>, this is a breeze. However, the only way to do it in todays browsers is using images, or perhaps <abbr title="Scalable Vector Graphics">SVG</abbr> or even the Canvas element from the HTML 5 spec. However, this is a pure design issue, and therefore falls into the domain of CSS. And I think that I've come up with a solution, or at least an idea for a solution.</p><p><img src="http://farm4.static.flickr.com/3661/3500999819_e1e1c27fc8.jpg" alt="Screenshot of Firefox 3.5b4pre and Safari 4.0 beta showing column rotated headers" /></p><p>The image above should give you an idea about what I mean. The benefits of this design is that one can keep all columns relatively narrow, while at the same time use long words to describe them in their headers. If you use Firefox 3.5 or Safari 4.0 or another browser that supports <code>-moz-transform</code> or <code>-webkit-transform</code> you can also look at <a href="http://keryx.se/dev/rotate-th-2.html">my experimental page</a>. View its source to get the full picture of what I have done.</p><h4>The technique</h4><p>One can not simply rotate the th-elements. It will look like this:
<img src="http://farm4.static.flickr.com/3348/3501878876_d2c8358489.jpg?v=0" alt="Screenshot of failed solution. Only text rotated."></p><p>There is a number of problems:</p><ul><li>The rotation is applied after the browser has allocated width for the columns. Our intention was to save horizontal space. We need to remove the text content out of the normal flow, using absolute positioning.</li><li>Any borders and background color will not be rotated. The text will extend out on top.</li></ul><p>My solution is to wrap the text in three spans. Yes that's an awful lot, but they each serve a purpose. The first span is the holding area, relative to which the second span will be absolutely positioned. Its CSS is as follows:</p><pre><code> th > span {
position: relative;
}
</code></pre><p>The second span is rotated as well as skewed. Rotation is counter clockwise, hence it's set to a negative degree. The skewX is set so that the border originally to the left, now to the bottom, is completely horizontal. Mathematically the formula is abs(rotationdegree) + skewdegree = 90.</p><p>In order for all headers to be of equal height, we set a width. Remember that the visible height is the un-rotated width. For some yet un-investigated reason Firefox will put the span a bit further up than Safari, so I'll add a CSS filter to fix that. Border and color is added, as well as some padding, just for the appearance.</p><pre><code>th > span > span {
/* Must remove span from normal flow in order to keep columns from widening */
position: absolute;
white-space: nowrap;
top: 1em; /* Firefox 3.5. Safari is reset below */
-moz-transform: rotate(-65deg) skewX(25deg);
-webkit-transform: rotate(-65deg) skewX(25deg);
-moz-transform-origin: 0% 0%;
-webkit-transform-origin: 0% 0%;
border: 1px solid;
padding: 0.5em;
height: 1.3em;
width: 120px;
/* Illustrate where it's at with color */
background-color: yellow;
/* If one wants centered text, this is the place to reset it */
/* From a design point of view it might not be desirable */
text-align: center;
}
/* CSS filter for Safari */
@media screen and (-webkit-min-device-pixel-ratio: 0){
th > span > span {
top: 0;
}
}
</code></pre><p>
The text will be a bit hard to read. I therefore un-skew it in a third span. This does not work, however in Safari 4.0 beta:</p><code><pre>th > span > span > span {
/* Rotate the text back, so it will be easier to read */
-moz-transform: skewX(-25deg);
/* Safari 4.0 beta won't skew back, so the next line is actually redundant right now */
-webkit-transform: skewX(-25deg);
}
</code></pre><p>For the full HTML and CSS, look at <a href="http://keryx.se/dev/rotate-th-2.html">my experimental page</a> and view source.</p><h4>Problems</h4><ol><li>This solution is quite fragile. Widths and heights, margins and paddings might mess things up. Columns must not be of a flexible width.</li><li>For pixel perfection, there is a slight nuance, where Firefox positions the spans 1 pixel further to the right, than Safari.</li><li>As I said, there is an awful lot of spans...</li><li>And worst of all. So far I have not developed a fall back for browser that do not support CSS transformations. In those the table will just look awful and the table headers will be unreadable.</li></ol><p>Anyway, I think this solution has some potential. Until the CSS WG and browser vendors gives us an even better solution, this is my best effort. Is there a better solution somewhere, please let me know!</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com6tag:blogger.com,1999:blog-17809600565735611.post-67727128122530666322009-04-05T11:18:00.014+02:002009-04-05T15:44:50.668+02:00Blogger and accessibility<p>Starting to edit my new blogger-blog, I see some glaring mistakes done by the developers. There is a ton of inline CSS for example. Even worse is the fact that they are hiding the skip-links from screen readers. It is a well known fact that "display: none" in your CSS will make all the block disappear not only from sighted users view, but also from what is being exposed to a screen reader. Thus, the following in my template is bad code:</p><pre><code> <span id="skiplinks" style="display: none;">
<a href="...">skip to main </a> |
<a href="...">skip to sidebar</a>
</span>
</code></pre><p>I decided to improve upon that. Here is my agenda:</p><ul><li>Begin removing inline CSS.</li><li>Make the skip-links accessible as they should be.</li><li>Add <a href="http://www.standards-schmandards.com/2009/wai-aria-landmark-roles-in-cms-themes/">ARIA-landmark roles</a>.</li></ul><h4>Fixing the skip links and the CSS</h4><p>Notice that the skip links are still part of the page tab order. In order to avoid confusion I want to make them reappear visually when they receive focus. And while we are at it, lets experiment with some new CSS-techniques as well:<p><pre><code>#skiplinks {
position: absolute;
top: -100em;
left: -100em;
}
#skiplinks a:focus {
position: absolute;
top: 103em;
left: 100em;
background: yellow;
width: -moz-max-content;
width: -webkit-max-content;
width: -o-max-content;
width: max-content;
}</code></pre><p><a href="http://dbaron.org/log/20080613-firefox3-css">Max-content</a> is a planned addition for the CSS 3 box model. Currently it is only supported by Firefox and that through the preliminary -moz- prefix. I suppose Opera and Webkit will add support in a similar fashion, so I have anticipated that in my code.</p><h4>ARIA Landmark roles</h4><p>The breakfast on Saturday that concluded <a href="http://eafra.eu/">European Accessibility Forum</a> I sat next to Peter Krantz and Steve Faulkner, as they discussed ARIA Landmark roles. Steve has written <a href="http://www.paciellogroup.com/blog/?p=106">a nice wrap-up about them</a>. In the future they will make skip-links redundant, as this is a much better solution. Look at the source code on this blog, and you'll see my contribution. Look for all "role" attributes. I have yet to add the role "navigation", but that seem to be impossible without using JavaScript. Since landmarks do not define dynamic content, I think static additions to the HTML is the preferred solution.</p><h4>HTML 5 doctype</h4><p>I have changed the doctype as well. Personally I am a fan of HTML 5, at least in comparison to many of my friends. The reason now however is that I intend to use <a href="http://validator.nu/">Henri Sivonens conformance checker</a>, that includes ARIA and RDFa support, instead of the W3C validator. Adding subheadings to my blog posts also really makes me wish that I could use <a href="http://blog.whatwg.org/is-not-just-a-semantic">HTML 5 sections</a> in order to make them work even if the document structure changes drastically. Right now I am using h4, as that seems appropriate on the front-page, but will h4 be the correct choice also on other pages or in the future?</p>
<p>Update: Blogger keeps messing with the doctype. Aargh! Will leave it as is for now, but it does not help me stop thinking that Blogger's CMS is really annoying.</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com0tag:blogger.com,1999:blog-17809600565735611.post-23219451573076187472009-04-03T14:42:00.008+02:002009-04-03T15:53:16.015+02:00Declaration of dependence<p><img style="float:left; margin:0 10px 10px 0;width: 250px; height: 194px;" src="http://1.bp.blogspot.com/_KnOn6Z8lFzA/SdYMWnSaCwI/AAAAAAAAAAM/8CWfeSVBqYQ/s320/ThinkPadZ61p.jpg" border="0" alt=""id="A Thinkpad z61p" />
I am starting this blog to document the joys and woes of using my Thinkpad (currently a Z61p, dreaming of a W700ds).</p><p>This documentation might be of use for someone stumbling across similar issues and through the magic of search engines he or she might find my solutions.</p><p>I also need a place where I can regularly communicate in English. My main domain, <a href="http://keryx.se/">keryx.se</a> , should remain a Swedish language site.</p><p>Finally I wanted to experiment with blogger. What is it like, usability and accessibility wise? Soon I'll know.<h4>Why now?</h4>I recently upgraded my Thinkpad from the standard 100G drive to a 320G drive. I chose a Seagate Momentus 7200 rpm drive, since it offered both superb specs and a reasonable price.</p><p><a href="http://forums.lenovo.com/lnv/board/message?board.id=Z_Series_Thinkpads&message.id=550">The discussion I had on Lenovos forums</a>, leading up to my decision confirmed my suspicion that it was no problem at all chosing a drive from a non-Lenovo source.<h4>Very first impressions of Blogger</h4>Why can I not turn off automatic insertions of br-tags? It would have been soo easy for them to look for two line breaks and wrap things between p-tags instead. And inserting an image means a whole lot of intrusive and unnecessary JavaScript. I'll stick to manual editing of all my HTML!</p>Lars Gunther (itpastorn)http://www.blogger.com/profile/11544012919049072827noreply@blogger.com0