Elsewhere monthlies
This is the monthly archive for January 2007.
30 January 2007
Jeremy points to the "Snap feature". Onmouseover, a screenshot of the site the link points to is shown. Extremely annoying, and even otherwise sensible sites seem to fall for it.
Let's make this "feature" ridiculous, OK? I mean, who needs it? It's kind of saying your visitors are too stupid to handle links. "Oh dear, this nasty thing leads AWAY from my site, but it'll bring you to this page, which is, like, ANOTHER site! Take care, or you might become confused."
Yech.
Annoyances
| Permalink
28 January 2007
Jeremy's New Media Company Generator remains a golden oldie, but new, desperate times ask for new desperate measures. The Web 2.0 names are even less descriptive than the new media ones.
(Via Simon.)
Fun
| Permalink
24 January 2007
About newly supported CSS3 selectors.
CSS, Opera
| Permalink
23 January 2007
A call for screen reader users willing to test the recently published virtual buffer update trick (see under 20 January).
Accessibility, Data Retrieval, Screen readers, Tests
| Permalink
Intriguing piece. Officially it's about why Java applet interfaces "look like a Soviet tractor built on a Monday." Be this true or not (I tend to agree), the real treat is in the three point approach to creating UIs that is mentioned later:
- You need to lay out the user interface components visually, by hand, with total control over where they go. [...]
- You need to be able to change the UI around really easily during development [...] even after you’ve attached a lot of code to it. That means no [...] tools that write code for you, because once their code mingles with your code, it gets hard to disentangle.
- Changing the UI around also requires being able to change your own UI code easily. As the Ruby and Agile Programming zealots always point out, strict type checking can really get in the way of this. [...]
Isn't this a perfect description of how we create websites? We must be doing something right.
(Via Simon.)
Server side, Usability
| Permalink
20 January 2007
How XMLHTTP came to be. By the inventor.
Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn't have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).
Interesting read all in all, especially because it shows once again that this sort of stuff isn't planned: you create something for your own reasons, but suddenly it takes on a life of its own.
(Via Nate.)
Data Retrieval, History
| Permalink
About some interesting Jaws features. Summary:
Popular screen readers use a virtual buffer to allow users to interact with web content, whereby the virtual buffer provides a mechanism for screen reader users to interact with web content. This article uncovers undocumented behaviour in JAWS 7.1 and later, which allows web developers to build Ajax applications that update the virtual buffer without any interaction from the user.
Delves deeply into Jaws's bowels. Not for the fainthearted.
Accessibility, Data Retrieval, Screen readers
| Permalink
19 January 2007
Useful linkdump of CSS techniques you're going to need one day.
(Via Naar Voren.)
CSS, Linkdumps, Showcases
| Permalink
18 January 2007
Apple's complaints about the new HTML Working Group charter.
- We strongly object to the 10% market share threshold in the Success Criteria. Effectively, this gives Mozilla Firefox and Microsoft Internet Explorer veto power over the spec. In general historically there have only been two browsers at a time that have been above this market share threshold.
- We request that the charter call for a formal relationship with Web Hypertext Application Technology Working Group (WHATWG), even though the group itself is informal.
- We request that there be no Member-only mailing list; such lists risk being abused for non-public decision making for what should be a public group.
Makes sense, doesn't it?
HTML, Standards/W3C
| Permalink
Perfect little history lesson. Netscape -> Yahoo -> Google -> Mozilla, and the circle is complete.
Business, History
| Permalink
16 January 2007
Useful overview of where Americans can go wrong in designing sites for an international audience. Most of the guidelines apply to Europeans as well.
Internationalisation
| Permalink
Chris Heilmann on sucky JavaScript books and tutorials. Includes a few interesting thoughts on the nature of education and why it's sometimes important to quickly give a simple example, even when that requires you to use document.write() or similar junk.
JavaScript
| Permalink
15 January 2007
Jeremy announces his new book: Bulletproof Ajax. In a general sense I knew it was coming, but now that I have the actual introduction and table of contents to admire, I'm sure that this book will help web developers to take the next step in mastering accessible Ajax.
Bulletproof Ajax is [...] aimed at front-end developers and designers: the kind of people who are already well-versed in web standards; CSS, (X)HTML, and maybe a dab of JavaScript. But it’s certainly not aimed at hardcore programmers.
Just to be clear: this book is not a cookbook of code. Yes, there is code in there to illustrate the concepts but it’s the concepts that are really important. The code is meant simply as a starting point. I go into far more detail on the design challenges and philosophical implications of Ajax. That’s why I think people will either love this book or hate it.
Right now I assume I'll love it.
Books
| Permalink
12 January 2007
Chris Wilson turns out to be considered for the role of (initial) chairman of the new HTML Working Group, but Daniel Glazman disagrees. In this entry Chris responds to Daniel's points.
The main argument against Chris's chairmanship seems to be a fear for undue Microsoft influence on the new HTML spec. In other words: it's a trust and confidence issue. Although Microsoft's record in implementing standards isn't exactly squeakily clean, the past year or so has seen a significant reversal, and that's partly due to Chris.
I hope the trust issue gets resolved soon. If not, the new HTML working group will start on the wrong foot and nothing will be resolved.
Standards/W3C
| Permalink
John Allsopp creates a list of HTML tags and their semantic meaning. No surprises here for web developers who've followed the discussions of the past few years, but such a list is always very useful for newbies who want to do it right but lack some information.
HTML
| Permalink
...and Jeremy again.
Building up your own library, on the other hand, is something I wholeheartedly approve of. I’m pretty sure it’s something that just about every developer does anyway, but it really is a great way of accumulating wisdom… wisdom being knowledge over time.
Agreed. In fact, I'm steadily working on a few useful functions of my own, and although I'll never call it a library (I'm thinking of "utility file"), I'll publish it when I'm ready.
Libraries
| Permalink
Dan Webb on JavaScript libraries.
I’m a firm believer, especially with JavaScript, that simple is best. File size / download time arguments aside, the less code you can get away with having the browser parse and execute the better off you are. Less for the browser to do. Less to go wrong. Less to try to understand.
Agreed. Dan continues by listing a few essential functionalities that are so totally useful that it's worth having a library for.
Libraries
| Permalink
Some tips from the MSIE team.
Core
| Permalink
So true: JSON can be used in any environment; it's not restricted to JavaScript.
However, there's an important social issue here, which is reflected in Dave Winer's post on JSON: people outside the front end community aren't (yet) used to it, so they will tend to underestimate it.
That problem will solve itself, although it might take a few more years.
Data Retrieval
| Permalink
The Yahoo! team shares some of its data on optimizing web pages by using caching.
Eye opener:
~20% of all page views are done with an empty cache. To my knowledge, there’s no other research that shows this kind of information. And I don’t know about you, but these results came to us as a big surprise. It says that even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. This goes back to the earlier point that reducing the number of HTTP requests has the biggest impact on reducing response time.
Interesting indeed.
Tests
| Permalink
Older
See the December 2006 archive.