Google unveils its new project: Google Doctype; a reference for web developers. They've decided on the wiki format, which means that anyone can add content. And that's good, obviously. Speaking from long experience I know how hard it is to create proper documentation pages and test pages, so I wish Google the best of luck with this venture. And who knows, later I might start adding stuff, too. (Many pages already refer to this site for more information).
Speaking from long experience I know how hard it is to create proper documentation pages and test pages, so I wish Google the best of luck with this venture.
And who knows, later I might start adding stuff, too. (Many pages already refer to this site for more information).]]>
Derek and me disagreeing.
A list of known user agent strings and their meaning. Impressive!
... and Opera, too, unveils its own CSS/JavaScript debugger. Haven't studied it closely yet, but this is obviously a step in the right direction.
Exactly how does line-height: normal work? It's a confused mess. I'm SO glad we've got Eric Meyer to figure this out for us; I wouldn't want to do it.
Chris Heilmann hits quite a few nails on their respective heads. Part of the problem is causd by software firms: Well, the truth is that we have been preaching far too long to the choir. I've been in the web accessibility and standards preaching community for a long time and whenever I asked what about enterprise development and CMS I was told that it is not worth fighting that fight as "We will never reach them". Part of the problem is caused by the web developers: When people ask for accessibility or Ajax usability advice you’ll get a lot of bashing and “go validate then come back” answers but not much information that can be used immediately or even questions that ask what lead to the state of the product. All in all a must to read if you want to follow this discussion. I'll repeat my comment here: What's the fundamental problem? Software developers refuse to see front-end programming as a separate discipline. All other problems you (and others) mention are just refinements on that central theme. What we say doesn't count because we do web development instead of software development, and somehow that's "less". The next step the web standards revolution has to take is quietly, patiently positioning front-end programming as a separate technical discipline that other disciplines have to argue and compromise with; instead of just being the guys who do colours and graphics and Ajax and such.
Well, the truth is that we have been preaching far too long to the choir. I've been in the web accessibility and standards preaching community for a long time and whenever I asked what about enterprise development and CMS I was told that it is not worth fighting that fight as "We will never reach them".
Part of the problem is caused by the web developers:
When people ask for accessibility or Ajax usability advice you’ll get a lot of bashing and “go validate then come back” answers but not much information that can be used immediately or even questions that ask what lead to the state of the product.
All in all a must to read if you want to follow this discussion.
I'll repeat my comment here:
]]>What's the fundamental problem? Software developers refuse to see front-end programming as a separate discipline.
All other problems you (and others) mention are just refinements on that central theme. What we say doesn't count because we do web development instead of software development, and somehow that's "less".
The next step the web standards revolution has to take is quietly, patiently positioning front-end programming as a separate technical discipline that other disciplines have to argue and compromise with; instead of just being the guys who do colours and graphics and Ajax and such.
Steve Souders brings us a useful tool to check page performance. Create an HTML page with a few assets and see how quickly (or slowly) it loads. Now if I could only find the time to run lots of tests...
Now if I could only find the time to run lots of tests...]]>
James Edwards think we should stop using Ajax. I agree that it's over-used, but abolishing it altogether is not the solution. What we need is the hype to end, so that we can review Ajax's usefulness and uselessness in peace.
Another DOM vs. innerHTML test. This series of tests suggests that DOM is faster in Safari and Opera, though innerHTML remains faster in Firefox and IE.
James Edwards repeats a few arguments against JavaScript libraries that are never far from my mind. In this case, his annoyance seems to derive from script authors who don't know how their own scripts work; and that's something I wouldn't like, either. Nonetheless the whole To Use or Not To Use discussion remains extremely complex. I used to speak against libraries at every opportunity; nowadays I'm not so sure any more. But while reading James's piece I again feel myself sliding back to a strict No Libraries approach. The final word hasn't yet been spoken.
Nonetheless the whole To Use or Not To Use discussion remains extremely complex. I used to speak against libraries at every opportunity; nowadays I'm not so sure any more. But while reading James's piece I again feel myself sliding back to a strict No Libraries approach.
The final word hasn't yet been spoken.]]>
Jason Ryan of the New Zealand State Services Commission has posted an interesting ten-principle approach to blogging by public servants. (Via Web Directions Blog.)
(Via Web Directions Blog.)]]>
Jonathan Snook explains why he doesn't use a CSS reset. I'm okay if one browser displays an H1 a few pixels larger or smaller than other browsers. If one browser defaults to circle bullets and another to squares, that's usually not a problem. [...] One of the principles I took away from the Web Standards community was the concept that pixel perfect precision across the various rendering engines was impractical and a remnant of the table-based layouts of yesteryear. With CSS and progressive enhancement, it was okay that things might look a little different from one browser to the next because of variations in what they supported. Interesting argument.
I'm okay if one browser displays an H1 a few pixels larger or smaller than other browsers. If one browser defaults to circle bullets and another to squares, that's usually not a problem. [...]
One of the principles I took away from the Web Standards community was the concept that pixel perfect precision across the various rendering engines was impractical and a remnant of the table-based layouts of yesteryear. With CSS and progressive enhancement, it was okay that things might look a little different from one browser to the next because of variations in what they supported.
Interesting argument.]]>
Two and a half year after my failed addEvent recoding contest, filosofo posted an ultra-short function that mends the this problem. Also, he explains why my contest failed: my requirements were too strict. Filosofo used a trick that precludes a removeEvent function from working, because he never needs one. Truth to tell, I rarely need one either, though it's absolutely indispensable in my recent events test pages. All in all this is interesting to read, for all its brevity. (Via Scott Andrew.)
this problem.
Also, he explains why my contest failed: my requirements were too strict. Filosofo used a trick that precludes a removeEvent function from working, because he never needs one. Truth to tell, I rarely need one either, though it's absolutely indispensable in my recent events test pages.
All in all this is interesting to read, for all its brevity.
(Via Scott Andrew.)]]>
John Resig unveils a new JavaScript performance test. Very interesting.
An overview of the W3C standards IE8 will and will not support. I'm gratified that the most serious bugs I found are present in the IE team's To Do list.