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.
The theory of web development.
| Browser testing | Standards/W3C | ToughQuiz |
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.
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.
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:
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.
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.
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, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Upcoming speaking gigs:
Categories:
Monthlies: