A while ago I asked about the exact relationship between progressive enhancement and accessiblity. What were the responses?
The theory of web development.
Part of Archives.
| Browser testing | HTML5 | Standards/W3C | ToughQuiz |
A while ago I asked about the exact relationship between progressive enhancement and accessiblity. What were the responses?
This article asks a question I don’t know the answer to: What is the exact relationship between progressive enhancement and accessiblity?
Everyone who’s ever messed around with dates knows that they are terribly user-hostile — not only for software developers, but also for users. True, users will be able to tell you their date of birth or today’s date without trouble, but ask them to fill them out in a web form and they will encounter problems.
Month first, day first, or year first? And what about slashes, dashes, and other separators? Usually the website engineer has a strong personal preference and enforces it religiously upon unsuspecting users with stern and incomprehensible error messages in a lurid shade of red that are too tiny for anyone over 25 to read.
(This article was originally published on Samsung Internet’s Medium channel. Since I do not believe Medium will survive in the long run I re-publish it here.)
During my research of modern input types such as email
, date
, and number
I stumbled upon the Hello World
JavaScript detection technique. After fairly extensive testing I concluded that it should be added to the customary type === 'text'
detection, mostly in order to cater to Android WebKit, although it also solves a few other problems.
From last Thursday to earlier today I held a simple one-question poll about which advanced input types such as date
and number
web developers are using.
The results are surprising, while I expected date
and number
to end in first and second place, the most popular type was actually email
.
Yesterday W3C announced the new webplatform.org initiative of W3C and several browser vendors. I’d like to add something: I’m going to be involved.
Yesterday Mark Zuckerberg said (paraphrased):
The biggest mistake we made as a company was betting too much on HTML5. While building native apps that were basically just a wrapper for the mobile web standard let it experiment quickly, it made the apps run way too slow. We burnt two years.
Two quick notes:
So all in all, this remark doesn’t say as much as you’d think; only that Facebook will switch from web to native on Android because the Android browser does not allow web to emulate native.
But will they also create BlackBerry, Windows Phone, Symbian, bada, and S40 apps? I think not.
BTW: here is the full quote. Facebook to forget about HTML5? Nah.
Oh, and one reason Zuckerberg said this is because investors want to hear this. Investors are a bunch of clueless people who only run after buzzwords, and Facebook’s delicate position on the stock market makes it necessary to placate them.
11 July 2012
Last week I got annoyed at the large differences in syntax for vendor-prefixed device-pixel-ratio media queries. I said, half in desperation and half as a threat, that it might be better to have only the WebKit rendering engine and ditch the rest.
Meanwhile I’ve had some time to think about it, and I find that I still support the idea of multiple rendering engines. Competition is still good, just as it was ten years ago.
HOWEVER. There’s an important exception.
OK, I’m now officially fed up with vendor prefixes, and to a lesser extent with Firefox and Opera who’ve gone batshit crazy on us all once more.
I’ve been going through my CSS tests last week, and thought I’d jot down some notes on how the browser treat vendor prefixes. It’ll bring some much-needed practicality into the discussion.
This does not prove that vendor prefixes are either good or bad. It’s just one more data point to consider.
My article yesterday about the vendor prefix mess garnered quite a few interesting comments, and today I’d like to respond to those that object against my proposal to replace the current system by a universal -beta-
prefix by proposing an additional -alpha-
prefix.
This is one of those weeks where everything happens simultaneously. I think that the vendor prefix discussion is the most important topic, so that’s what will get my attention.
Daniel Glazman, co-chair of the CSS WG, posted a call for action that warned of the dire consequences of web developers using only -webkit-
prefixed CSS declarations: IE, Mozilla and Opera would also implement -webkit-
.
I will argue that the proposed solution of making web developers aware of the problem may be technically and ideologically correct, but does not address the true causes of the problem: the developer-hostility of vendor prefixes, and the lack of mobile test devices.
So here’s the thing with responsive design and JavaScript:
On Monday and Tuesday I did some heavy-duty research into the new HTML5 input types and attributes, and I published a desktop and a mobile compatibility table.
Let’s start with some good news. The readonly
attribute, which makes a form field read-only, is supported by all browsers, both mobile and desktop. Even IE9. Cool, huh?
The rest of the input story is worse. Much worse. Let’s put it like this: Obigo WebKit, a browser nobody but me has ever heard of, outperforms iPhone and Android.
Months ago I concluded that “HTML5” means whatever you want it to mean. This week, Jeffrey Zeldman and Jeff Croft took up the discussion, with Tantek Çelik and Bruce Lawson commenting.
A while ago I asked what HTML5 means to you. I got a lot of replies, but would like to gather more. That’s why I’m repeating the question today. What’s in your HTML5 spec? Please add your personal top three of cool new features to the comments.
Right now nobody’s interested in a mobile solution that does not contain the words “iPhone” and “app” and that is not submitted to a closed environment where it competes with approximately 2,437 similar mobile solutions.
Compared to the current crop of mobile clients and developers, lemmings marching off a cliff follow a solid, sensible strategy. Startling them out of this obsession requires nothing short of a new buzzword.
Therefore I’d like to re-brand standards-based mobile websites and applications, definitely including W3C Widgets, as “HTML5 apps.” People outside our little technical circle are already aware of the existence of HTML5, and I don’t think it needs much of an effort to elevate it to full buzzwordiness.
Technically, HTML5 apps would encompass all websites as well as all the myriads of (usually locally installed) web-standards-based application systems on mobile. The guiding principle would be to write and maintain one single core application that uses web standards, as well as a mechanism that deploys that core application across a wide range of platforms.
Last Friday I found evidence for increasing confusion about what the HTML5 spec actually is. I don’t have any doubts on that score: HTML5 is anything you want it to be as long as it’s new and cool.
After spending about a day and a half in testing I am forced to conclude that the HTML5 drag and drop module is not just a disaster, it’s a fucking disaster.
The module should be removed from the HTML5 specification straight away, and conforming browsers should disable it at their earliest opportunity pending a complete rewrite from the ground up.
Web developers MUST NOT (in the sense of RFC 2119) use HTML 5 drag and drop. They should use old-school scripts instead.
Before we continue I’d like to say that in general I thoroughly approve of the HTML5 specification. Exactly because the spec has such an overall quality I was so surprised (and, frankly, a bit confused and hurt) to find drag and drop a steaming pile of bovine manure.
In fact, it’s so outrageously bad that I’ve gone on strike. I refuse to do any more research on drag and drop. Go do it yourself. Or don’t bother. Whatever. I don’t care.
What follows is a rant laced with profanity. No apologies. Drag and drop deserves no better.
17 August 2009
Permalink
| in Browser testing
25 comments
(closed)
A few weeks back I did some DOM speed tests on mobile browsers (results forthcoming). The most important result of these tests is not the actual values (although they’re interesting), but the fact that I could finally prove a theory that I’ve had in the back of my mind for at least two years now.
Basically, when setting up a speed test you should be very careful to allow the browser to render the result on screen before you close the test by reading out the second timestamp.
I have started an HTML5 compatibility table today. For now it only contains a test of HTML5 Storage in all desktop browsers, and a short report is in order. I also retested the DOM HTML; no changes.
In his recent Feature testing CSS properties entry, Juriy Zaytsev (Kangax) discusses the possibility of detecting CSS support by means of JavaScript. Although he rightly points out that this method has its drawbacks, as far as I’m concerned he doesn’t go far enough.
This sort of testing should not be used at all. Ever. The methodology is plain wrong. Browser compatibility tests are to be done by hand. Any automated system is useless, because it will give false information.
The HTML 5 spec introduces the <time>
element to mark up a date or time. Although I support the inclusion of these semantics in HTML, I believe that the current specification of the <time>
element is vague because it avoids the question whether the element is safe for historians. Right now it hurts historical research more than it helps. In this entry I’ll explain why.
Although I will concentrate on the HTML5 syntax here, what I have to say also applies to the microformats datetime design pattern. The Microformats site adds one important detail to the discussion that the HTML5 spec overlooks: the point of having a <time>
element (or a datetime design pattern) at all:
Use the datetime-design-pattern to make datetimes that are human readable also formally machine readable.
Who needs machine readable dates? As far as I can see there are two target audiences for this operation. The first is obviously social applications that have to work with dates, and where it can be useful to compare dates of two different events. An app must be able to see if two events fall on the same day and warn you if they do.
However, as a target audience social applications are immediately followed by historians (or historical, chronological applications). After all, historians are (dare I say it?) historically the most prolific users of dates, until they were upstaged by social applications.
This raises the question whether the <time>
element should be tailored for historical use at all. When I started writing this entry I was convinced that it should.
In keeping with the definition of its purpose I the see the <time>
element as a tool for an Internet-wide chronological search-and-compare system. Such a system will be a boon to historians, who would be allowed to quickly and easily look up events that happened around the same time as the event they’re writing about.
In history, just as in other academic disciplines, serendipitous discoveries are the meat of exciting new theories. A history-compliant use of the <time>
element that allows automatic search and compare would broaden the horizons of historians.
However, now that I’ve reviewed some of the more common problems that have to be solved in order to decrease potential harm, I’m starting to doubt whether the <time>
element can easily be made to fit history.
Right now, though, the specification is a vague compromise that doesn’t make the <time>
element useful for historical research, but still allows it to be used historically.
I feel this ambiguity should be removed. I feel that the specification should clearly state whether the <time>
element is meant for historical use or not. The current vague, implied “No” should be changed to a clear answer. I prefer Yes, but I can live with No.
If the <time>
element should be made safe for historians, there’s quite a bit of work to be done; some of which is discussed in this article. If it should not be made history-safe, we have to add a cut-off date to the specification. Dates before this cut-off date would be ignored.
2 April 2008
Permalink
| in IE, Opera, Safari, Theory
24 comments
(closed)
Currently I'm working on a big revision of the Events Compatibility Tables. And no the new table is not yet online because I'm not ready yet.
Testing event support is really awesomely complicated. I've been working steadily for two weeks now, and I still find new bugs and oddities daily, and twice on Sundays.
In any case, I discovered something remarkable when I studied the mousemove event. It sheds light on the way browser vendors keep track of each other's implementations nowadays, and on things that can go wrong.
Update: The bug described in this entry is an OS problem, and not a browser bug.
3 March 2008
Just now the IE team announced that it's reversing its policy on the default behaviour of IE8, which shows that it has been paying close attention to the discussion of its versioning proposal. I admit that I hadn't expected this reversal, but I welcome it.
A week ago W3C published the first working draft of the W3C CSSOM View specification (written by Anne van Kesteren), and I must say I'm very happy with it. Since I was testing stuff anyway I created a new compatibility table for most of the methods and properties specified in this document, and browser compatibility is already excellent.
That's no coincidence. This specification contains definitions for many properties (and a few methods) that browsers have already been supporting for ages (such as offsetWidth
), and W3C has paid scrupulous attention to the current implementation. No more theorizing into the blue — just check what browsers do and describe it in the specification. Excellent idea.
28 January 2008
Even clinically dead web developers will by now have seen the announcement of IE8's new versioning switch, and many bloggers I read have already reacted—most of them negatively. See the IE page of my linkblog for an overview.
All in all I am in the Yes camp, and in this entry I'd like to offer a few arguments in favour of the current default of the switch. In my opinion, defaulting to IE7 in the absence of a switch is the correct behaviour.
I won't be offering practical arguments, since these are not received too well right now. Instead, I'm hoping to appeal to our collective sense of honour.
23 January 2008
Now that the versioning switch debate is in full swing (see the IE page of my linkblog for a partial overview), I'd like to move attention from lofty goals and aspirations that may or may not be trampled by the new switch to everyday practicalities.
So here's a quiz for you. Please assume that at some point in the future the following will be the case:
22 January 2008
The announcement of IE8's new versioning switch is generating heated debate—and nobody could have expected otherwise. Whether you feel this is a great or a terrible idea, it will change the way we web developers work. I encourage everyone to form his or her own opinion on this matter.
However, there's one point that has to be made right away. Eric Meyer already touched on it in his opinion piece, but repeating it won't hurt.
One argument used by detractors of the new switch is that it's nothing more than a browser detect. This comparison is factually false and it shouldn't be allowed to cloud a debate that promises to be complicated enough even without false arguments.
3 October 2007
Currently I'm working on the HTML of a ministry site, and I encountered one persistent problem that I don't know the "right" answer to: subtitles. Which tag do we use for them? A header, or not? I don't really know, and I'd like to ask your opinion.
24 July 2007
<blockquote>
?The website of a Dutch ministry has been tested for compliance with the Web Guidelines. I have been asked to supply a second opinion, which I'm currently writing. I came across a complicated semantic point that I'm not quite sure of; hence I'd like to ask your opinion.
Well, the new W3C HTML Working Group is slowly getting into gear. It seems as if W3C has learned from past mistakes, since right now the openness surrounding the new WG is commendable. There's a blog for sharing information, anyone can join the mailing list as an Invited Expert, and even if you don't you can still read the list. Good!
The conference was split into two tracks, and there have been quite a few discussions about whether this was a good idea. I think it is because it allows for more specialisation. In any case, here are a few notes on some of the presentations I attended.
20 June 2006
Permalink
| in Coding techniques, Conferences, Theory
9 comments
(closed)
Well, I'm back from @media, and it was as wonderful as last year. I met lots of interesting people, talked about lots of geeky stuff, drank the amount of beer required by British law, and went on stage at a web conference for the first time—but I hope not for the last.
Well, my previous entry Is asynchronous communication really being used? has certainly elicited some interesting comments. The answer was a resounding "Yes"; and the replies allow me to take a first stab at defining a few Ajax use patterns.
9 June 2006
Yesterday I attended the 10th Sigchi.nl conference in Amsterdam, during which I had the pleasure of seeing Jared Spool, Jesse James Garrett, Bill Scott, Martijn van Welie, and Steven Pemberton in real live action. (Note to self: Jared and Steven are stiff competitors of Joe when it comes to being The Funniest Man at Web Conferences).
I'm not going to describe the conference in detail. Instead, I'd like to discuss an asynchronous communication question that popped into my head during Jesse James' presentation.
While I was busy writing largish amounts of JavaScript for money and not paying attention to the wider world, everyone suddenly started talking about footnotes on the Web, a subject I happen to be highly interested in.
Back in 1998 I created my very first site, a summary of my research into the Thidrekssaga, and since it was supposed to be a scientific publication I needed a footnote system. I ended up using a footnote frame, and back then I was pretty impressed by my own creativity. Meanwhile the wow-factor of this solution has decreased rather dramatically.
Seven years later, four articles about footnotes caught my eye within about an hour.
A document uses XHTML 1.0 Strict. It contains a few <blockquote>
s, and in Strict they are not allowed to have text nodes as children. Instead, any text in the element should be marked up in a block level element, for instance <p>
. Initially the document satisfies this requirement.
After the document has loaded a script similar to Simon Willison's Blockquote Citations runs in the document and adds the content of the cite
attribute of each <blockquote>
to the visible text of the quote. Due to an oversight of the programmer the script does not put this text in a block level element of its own. Now the <blockquote>
has a text node as a child.
Last Sunday the Amsterdam JavaScript meeting was a moderate success. Among others, Bobby van der Sluis, Anne van Kesteren and Faruk Ateş attended, and we had some interesting discussions.
22 June 2005
It's getting busy on the JavaScript front. For a good overview of what's happening right now you should read the three articles I mention below. They discuss different aspects of the change JavaScript is going through at the moment. As an extra I've thrown in a little trick I've been using quite a lot lately.
Again a question about foldout menus. These menus fold out when the user mouses over a main link that contains a submenu. This is a sacred tradition, and therefore mandatory: users who know these menus expect them to work onmouseover, and will get confused when they don't.
The question for today is: when should the submenus fold in? You can pick more than one answer.
There seems to have been a (badly covered) "Ajax Summit" organised by O'Reilly and Adaptive Path. Could be interesting. Scott Andrew has the details.
In the past few days three excellent JavaScript articles have been written that I agree with so completely I have to mention and quote them. In addition, there's one excellent JavaScript site that I discovered months ago but haven't yet come around to mentioning.
While creating a mainstream site, the development team discusses ways and means of adding a foldout menu to the site. There are four opinions. Which one is correct?
Two questions revolving around the :after{content: }
construct. There are three possible answers that apply to both questions. Remember that this construct doesn't work in all browsers.
A product page contains many products and their descriptions, plus one element with an order form. A script hides the order form by means of element.style.display = 'none'
. Does this action change the page structure?
When I first read Jesse James Garrett's article Ajax: A New Approach to Web Applications my reactions were "What a silly name", and "Not really new, is it?" Although both points of critique have been repeatedly and heatedly mentioned in the ensuing discussion, the concept seems to be taking the Web development community by storm. This can mean one of two things: either it's a promise or it's a hype. To decide the case, I offer an annotated link dump.
My JavaScript triggers article and J. David Eisenberg's accompanying Validating a Custom DTD article, have caused quite a few comments, both on and off the ALA forums. Some of these comments are interesting enough to repeat and to discuss further in a rather long entry.
In his DHTML is dead. Long live DOM Scripting entry, Jeremy Keith proposes to rename "DHTML" to "DOM scripting", because "DHTML" is a buzzword and because (apparently) DHTML and DOM are roughly the same.
I don't agree. I see DHTML and DOM as two more-or-less separate layers of JavaScript that have more-or-less separate purposes.
As to the buzzword problem, that's our own fault. We should solve it ourselves, and not by changing names.
With http://map.search.ch for a case study, Simon Willison announced, and Dave Shea confirmed, that 2005 is going to be the year of JavaScript, that our beloved language is going to hit the big time again, though, one hopes, in a more responsible way than in 1998. I fully agree, but I'd like to add a few comments, and try to narrow down the questions a bit.
The new buzz word is definitely "Web Applications". Unfortunately, recent publications on this topic are extremely confusing. Web applications require a massive deployment of JavaScript, but everybody skilfully pretends they don't. Besides, I haven't yet found out what Web applications are because no one has bothered to define them.
Are Web Applications here to stay, or are they just another hype?
See Dave Shea's Web Apps are Hot for an overview of recent publications. See also Joel Spolski's perceptive How Microsoft Lost the API War article.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories: