Elsewhere on the 'Net - Theory
Theory elsewhere on the 'Net.
21 May 2009
Andy Clarke discusses possible solutions to the IE6 problem, and then highlights his own: create one Universal Internet Explorer 6 CSS file that will give any page a nice-but-basic typography and margins, but no layout or grid at all.
Interesting idea. We'll have to see what clients want (or whether they'll notice), but it sounds like an excellent intermediate solution between "don't bother with IE6" and "make IE6's rendering pixel-perfect".
CSS, IE, Theory
| Permalink
14 May 2009
Kangax writes about testing methodology.
Initially he proposes reading out support for certain CSS declarations in JavaScript (i.e. if the browser supports element.style.marginLeft it supports margin-left). I disagree strongly: you're only testing whether a certain JavaScript object exists, and that does not necessarily say anything about CSS.
Fortunately Kangax is aware of this limitation:
A mere existence of a CSS property doesn’t tell us about an actual implementation and its conformance to a specification. A browser might have “borderRadius” property with a proper string value; it could allow to assign to that property and even set its value to a specified one after assignment; yet, it could never make borders rounded.
As far as I'm concerned this means that the testing method Kangax proposes is unusable in practice.
If you want to test border-radius or margin-left, create a CSS test case and look at it. You'll quickly see if it works or not. Don't try any automated testng, though. It's just not reliable enough. Ever.
This rule is especially important on mobile phones, where we can't be sure of anything. I will continue to test exclusively by hand.
Theory
| Permalink
12 February 2009
A call for treating IE6 as we once treated NN4.
We should not actively block IE 6 users or completely disregard what happens when an IE 6 user comes along. What we should do is spend less and less time working around IE 6 bugs unless they seriously affect functionality or accessibility – only fix the showstoppers.
As long as we make sure to use progressive enhancement, content and base functionality will still be there, like for all other antiquated browsers.
Agree.
IE, Theory
| Permalink
1 February 2009
Bruce Lawson argues against creating separate mobile sites.
Perhaps one reason [for having separate mobile sites] is cultural? Mr Boss walks in one day and demands "a mobile site". All your competitors have a domain like mobile.acme.com, so that’s got to be the way to do it, right? Simply coax your CMS to squirt out the information that you think your mobile customers want, and job done.
It’s also hard to make web pages that work across devices and hard to find information. The web standards movement built up a huge bank of best practice on how to build cross-browser sites (and not sweat the minor rendering differences) but there isn’t that corpus of best practice yet for cross-device development.
The total lack of best practices is indeed becoming a problem.
Mobile, Theory
| Permalink
30 April 2008
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.
Theory
| Permalink
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.
Theory
| Permalink
18 March 2008
Joel Spolsky's take on the IE8 versioning default.
Standards are a great goal, of course, but before you become a standards fanatic you have to understand that due to the failings of human beings, standards are sometimes misinterpreted, sometimes confusing and even ambiguous.
The precise problem here is that you're pretending that there's one standard, but since nobody has a way to test against the standard, it's not a real standard: it's a platonic ideal and a set of misinterpretations [...]
Spolsky also says almost every site he visited in IE8 is broken. This is likely to be true, but it's not entirely fair, since this is the very first beta of the new browser, and historically Microsoft's very first version of any browser have always been quite bad. I, for one, will only make such comparisons once beta 2 has been released.
So you see, we have a terrific example here of a gigantic rift between two camps.
The web standards camp seems kind of Trotskyist. You'd think they're the left wing, but if you happened to make a website that claims to conform to web standards but doesn't, the idealists turn into Joe Arpaio, America's Toughest Sheriff. "YOU MADE A MISTAKE AND YOUR WEBSITE SHOULD BREAK. I don't care if 80% of your websites stop working. I'll put you all in jail, where you will wear pink pajamas and eat 15 cent sandwiches and work on a chain gang. And I don't care if the whole county is in jail. The law is the law."
On the other hand, we have the pragmatic, touchy feely, warm and fuzzy engineering types. "Can't we just default to IE7 mode? One line of code … Zip! Solved!"
Secretly? Here's what I think is going to happen. The IE8 team going to tell everyone that IE8 will use web standards by default, and run a nice long beta during which they beg people to test their pages with IE8 and get them to work. And when they get closer to shipping, and only 32% of the web pages in the world render properly, they'll say, "look guys, we're really sorry, we really wanted IE8 standards mode to be the default, but we can't ship a browser that doesn't work," and they'll revert to the pragmatic decision. Or maybe they won't, because the pragmatists at Microsoft have been out of power for a long time. In which case, IE is going to lose a lot of market share, which would please the idealists to no end, and probably won't decrease Dean Hachamovitch's big year-end bonus by one cent.
He's right in his thumbnail sketch of the web standards camp; we LOVE the big stick the IE team is handing us on a silver platter, and frankly I'm not sure if having that stick is good for us in the long run. There are too many web standard fascists already.
As to the IE team changing the default again, who knows ... ? If they do I, for one, will fully understand that decision.
IE, Theory
| Permalink
24 February 2008
Chris Wilson spars with Aaron Gustafson, Faruk Ates and Porter Glendinning of WaSP. Interesting ideas were proposed.
IE, Theory
| Permalink
21 February 2008
Eric reminds us of an important point that seems to be forgotten in the versioning switch debate:
We all care about the same thing.
[...] The disagreement is over how best to get there given the situation we face now, as well as how we perceive that current situation. [...]
Sometimes what binds us is strong enough that the few differences seem sharper by comparison. That shouldn’t keep us from remembering what we have in common, and the importance of that commonality.
I have nothing to add.
IE, Theory
| Permalink
Richard Rutter agrees with the versioning switch and the default.
Pity the Internet Explorer developers working their arses off to add great standards support to their browser, only for that work to manifest itself on but a tiny proportion of web sites. Bit of thankless job, if you ask me, but I hope they stick at it.
Exactly! It's commonly forgotten that the versioning switch was introduced because the IE team wants web standards.
IE, Theory
| Permalink
Zeldman once more defends the versioning switch.
With DOCTYPE switching, “off by default” means “in (non-standards) quirks mode.” With version targeting it means “the same way IE7 rendered this content.” The behavior is the same in both cases: if you want improved rendering, you opt in.
Exactly! True, doctypes are also used to define the flavour of (X)HTML you're using, but that means that the IE versioning switch is better than doctype switching, since it's only meant for determining a browser version to run in.
The more I think about it, the more I feel that standards-aware web developers behave like little children. They want what they want, and they want it now!
IE, Theory
| Permalink
Jeremy continues the argument against the versioning switch. Although he agrees that versioning switching by itself will be a useful tool, he still disagrees with the default.
This strategy is doomed to failure. Standards-aware developers, by their very nature, will object to adding a line of unnecessary markup to their documents just to get one single browser to behave as it should by default.
My question is: why do they object? What's the problem with adding a single line of code to placate IE? Right now we're writing whole style sheets with that goal in mind. (Besides, not all standards-aware web developers object.)
All in all he does not entirely convince me.
IE, Theory
| Permalink
11 February 2008
Chris explains the five steps you have to take before turning any of your own scripts over to the next guy.
- Put all style definitions in the CSS file and just change class names.
- Rewrite all code that might impair execution speed.
- Put all class names and other configurable data in a separate config object.
- Make sure your variable names are human-readable.
- Comment (including your name)
I suppose that most of my scripts don't obey every single of these five steps. Let's keep them in mind when I publish a new one.
JavaScript, Theory
| Permalink
John talks about performance testing JavaScript libraries and how not to go about it.
JavaScript, Performance, Tests, Theory
| Permalink
28 January 2008
Bruce points out the accessibility problems the versioning switch will cause: large amounts of the Web will be stuck in IE7 mode.
Although that's undeniably true, the solution is obvious: if accessibility is really an issue, switch to IE8 mode. Yeah, I know there are plenty of people who don't know how to do that or what to do once they arrive there, but how is that situation worse than today's?
Even today, you need a serious web developer in order to make your site really accessible. Serious web developers know about the switch and can estimate its accessibility impact, once enough research has been done.
Contrarily, unaware developers won't be aware of the switch, but they won't be aware of the latest and greatest in accessibility, either, so their not knowing about the switch or the difference between IE7 and IE8 mode pales into insignificance.
All in all I'm not convinced that accessibility will suffer. Even if IE8 had been a normal browser with a normally upgraded engine, we'd still have to cater to IE7 and its accessibility problems for the foreseeable future.
IE, Theory
| Permalink
Jeremy's reaction to Zeldman. He hasn't changed his position substantially.
IE, Theory
| Permalink
David Storey disagrees with the versioning switch. In fact, he attributes it to a alleged Microsoft "Divide and Conquer" strategy; something I cannot agree with.
While I understand Chris Wilson's position on "Don't break the Web", and very much understand that this is an incredibly hard nut to crack (I work on similar issues every day), it feels like this proposal is more "break the web for others". There must be a better solution.
I'd like some more information on this. Exactly how will this break the Web for non-IE browsers? I've heard this argument now and then, but have never yet gotten a good reply.
IE, Theory
| Permalink
Eric offers an older example from the time he still worked at Netscape. Webmasters simply weren't interested in the "you're doing it wrong so that's why your site breaks in our new version" argument—and they're right, from their point of view.
IE, Theory
| Permalink
Drew McLellan takes a look at JavaScript libraries and the versioning switch.
With version targeting, IE7 will never go away. Just as browsers are born, they must also die and make way for the next generation.
That's an interesting thought I haven't yet seen anywhere else. Good argument.
IE, Libraries, Theory
| Permalink
Liorean agrees with the versioning switch.
Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all?
Exactly!
IE, Theory
| Permalink
Eric takes the argument a step further.
I think a lot of people are discounting the fact that version targeting is absolutely nothing new in the standards world, let alone the web development world. Conditional comments, CSS hacks, and the DOCTYPE switch itself are all examples of version targeting.
That's certainly something I feel people are generally disregarding. The difference between the doctype switch (and CSS hacks) on the one hand, and the new version switch on the other, is, of course, that the first is widely known and the second one is new. Conservatism?
IE, Theory
| Permalink
Mark Pilgrim disagrees with the versioning switch, but at least he's funny.
Fun, IE, Theory
| Permalink
23 January 2008
Peter Nederlof disagrees with the versioning switch.
[The other browsers] don't need a meta tag in addition to a proper doctype, why would IE?
IE has a specific problem the other browsers don't have: Intranets maintained by people who are not (and maybe do not want to become) web developers, let alone standards-aware web developers.
And what's to prevent us from automatically adding meta tags anyway?
Nobody's going to prevent us, but why would you (unless you know what you're doing and WANT IE8 mode)? Doctypes were also necessary to create valid (X)HTML; the meta tag does not have such an extra function. Therefore it will only be added because web developers want to switch IE to a certain mode.
The argument about expected rendering behavior is even more absurd. No serious developer still believes that what IE renders is actually correct.
This is the key point where I feel the No camp is making a serious mistake.
We automatically define "web developers" as "standards-aware web developers". Unfortunately there are plenty of other web developers around. Feel free to denounce them as incompetent, but do not deny that they're an important factor, especially for Microsoft. They are the ones who maintain Intranets created specifically for IE, and any implementation of the standards in IE must take their needs into account, or fail miserably for business reasons.
IE, Theory
| Permalink
Roger Johansson disagrees with the versioning switch—for now. He keeps open the option of changing his mind in the future, though.
IE, Theory
| Permalink
Alex Russell agrees with the versioning switch, though he has quite a few important questions about details.
IE, Theory
| Permalink
Dean Edwards disagrees with the versioning switch, and also objects to using WaSP as a front. That last criticism rings true: WaSP as a whole wasn't involved in this decision, and it shouldn't be pretended that it was.
IE, Theory
| Permalink
Rachel Andrew disagrees with the versioning switch, quoting (again) the default behaviour.
IE, Theory
| Permalink
The Safari team (Maciej Stachowiak speaking) explains why the versioning switch will not be implemented in Safari any time soon, though they do not pass judgement on IE for implementing it.
IE, Theory
| Permalink
Ian Hickson disagrees with the versioning switch. I can't resist the temptation to reply to some of his arguments.
If Web authors actually use this feature, and if IE doesn't keep losing market share, then eventually this will cause serious problems for IE's competitors — instead of just having to contend with reverse-engineering IE's quirks mode and making the specs compatible with IE's standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves. It might actually be quite an effective way of dramatically increasing the costs of entering or competing in the browser market. (This is what we call "anti-competitive", or "evil".)
I believe Ian paints the current situation too black. True, other browsers will have to take some IE bugs into account when updating their rendering. However, one of the points of the versioning switch is to allow IE to become more standards compliant, so the difference between IE's higher rendering modes and the other browsers would become smaller and smaller as time progresses—which means less and less implementations of IE bugs are necessary.
An ideal situation, true, but not an impossible one.
It will also increase the complexity of authoring by an order of magnitude. Big sites will become locked in to particular IE version numbers, unable to upgrade their content for fear of it breaking.
Unless they decide to redo their sites and hire competent web developers, who'll switch to IE's highest feasible mode. OK, that won't happen everywhere, but in general those sites that won't be updated to a higher IE mode won't be updated today, either, so the situation will not get worse.
Besides, this is the other point of the versioning switch: if you don't want to update, you don't need to. Eventually this will go for Intranet sites more than for Internet, where the existence of other browsers will have a mitigating effect.
Imagine in 18 years — only twice the current lifetime of the Web! — designers will not have to learn just HTML, they'll have to learn 4, 5, maybe 10 different versions of HTML, DOM, CSS, and JS, just to be able to maintain the various different pages that people have written, as they move from job to job.
Or they could decide to upgrade to the highest feasible IE version. In fact, I feel that the situation Ian sketches could increase the standard-awareness of web developers.
- Web developers will have to know about several IE modes; Ian's right about that.
- Therefore they have to study web standards as well as the various modes, since without knowledge of web standards the modes are incomprehensible.
- Once they gain enough insight in web standards, they'll want to work with the highest feasible IE mode, and will switch the sites they maintain to that mode.
The alternative is that they don't want to learn anything and will stay locked in IE7 mode permanently. That would be a pity, but again we're not worse off than we are today. Today, plenty of web developers don't want to learn the standards, either.
All in all, I think Ian may be too negative.
IE, Theory
| Permalink
Nicholas Zakas tentatively agrees with the versioning switch.
Microsoft is in a really tough position. They have really been trying to listen to web developers clamoring for better standards support. They are also listening to their partners, big corporations with thousands of Internet and intranet pages that would cost them millions to upgrade. Microsoft got slapped when IE7 broke some pages by fixing layout bugs; they couldn't afford to repeat that mistake. Whether we like to admit it or not, there are tons of web sites that are designed to work specifically for IE6. They were written at a time when IE had over 95% market share and haven't been updated since.
There literally is no good move for Microsoft to make in this vein. Either they do nothing and don't break the Web but garner the ire of web developers everywhere, or they pacify web developers by forcing standards on everyone and break tons of web sites and web applications. This is the literal rock and hard place scenario. Microsoft is trying to satisfy both conditions and I honestly feel that this is a huge step forward for IE.
I tend to agree with this summary of Microsoft's position.
IE, Theory
| Permalink
Andy Budd sees the point of the versioning switch, but disagrees with the default behaviour. Fortunately he offers actual arguments:
Clueless developers won't know about this behaviour so every new site they build will automatically be rendered as IE7. Clued-up developers will use this as an excuse to freeze support for IE and turn their attentions to better browsers. Users will see less benefit from upgrading and will be more likely to turn to other browsers.
- Clueless developers: correct; that's the point of the default behaviour.
- Clued-up developers: this is an interesting scenario that I hadn't thought of yet. It would lead to massive IE7-only style sheets, but that's kind of OK, I suppose.
- Users: I'm afraid this is a common misconception. Users don't care what browser they're using.
Anyway, good to see some arguments in the No camp.
IE, Theory
| Permalink
Sam Ruby takes a practical approach to the versioning switch: he has engaged the edge value. If you trust your coding skills and believe in progressive enhancement, that's exactly what you should do.
IE, Theory
| Permalink
22 January 2008
John disagrees strongly with the versioning switch. He raises a few technical points:
- Cross-window scripting. What if one window uses one version mode and another one another? A very valid point.
- Security issues. I don't know anything about security, so I really can't judge.
Unfortunately he, too, is making insubstantial claims:
The fundamental issue is that Safari, Firefox, and Opera will all be harmed by attempting to implement this.
I'd love someone to explain this to me. What possible harm can a <meta> tag that they're going to ignore anyway do to Safari, Firefox, and Opera? I suspect an underlying philosophical issue, but I'd like to get it into the open, too. What, besides "it's Microsoft so it must be Evil", is the problem?
IE, Theory
| Permalink
Isofarro disagrees strongly with the versioning switch. So strongly, in fact that I'm wondering if he isn't overshooting his target.
Standards compliant pages must always carry a Microsoft passports that identify the holder as a standards compliant page. Sounds like a ghetto to me.
That's what we are being asked to do. We're segregated from the rest of the Web, and forced to carry identity documents that prove we are standards compliant, and earn the dignity to be rendered in a standards compatible way.
Just comparing something you disagree with to something most people feel negative about is too easy—especially when the comparison makes no sense at all. I call this playing for effect, and not serious debate.
IE, Theory
| Permalink
Zeldman replies to Jeremy and explains that we've got precious little choice. It's either versioning, or no more web standards.
IE, Theory
| Permalink
Andrew Dupont mostly agrees with the versioning switch, though he has some doubts.
IE, Theory
| Permalink
Jeremy might agree with the versioning switch, if it weren't for the default behaviour.
Personally I feel that this default behaviour is the whole point of the switch, and besides I wonder whether the situation will become much worse with the versioning switch in place. It may not become better, but I don't see how it will get worse.
IE, Theory
| Permalink
David Baron disagrees with the versioning switch, pointing to this mail he wrote back in April.
IE, Theory
| Permalink
Robert O'Callahan of Mozilla disagrees with the versioning switch, and asks some interesting technical questions.
IE, Theory
| Permalink
Jonathan Snook agrees with the versioning switch.
IE, Theory
| Permalink
Anne van Kesteren disagrees with the versioning switch. (Note: disagreeing is fine, but assigning ideological blame to people who happen to agree with the plan is not.)
IE, Theory
| Permalink
Chris Wilson talks about the problems the new versioning switch has to solve. Basically, IE6 was broken, but when IE7 was released and solved a lot of CSS bugs, everybody (except for a few standardistas) still expected it to work exactly as IE6.
Of course, it didn't work that way. Sites optimised for IE6 broke in IE7. That was a major problem for Microsoft, and it's the reason they've added the versioning switch to IE8.
IE, Theory
| Permalink
Eric discusses his initial and later reaction to the new IE versioning switch. I agree on the basics: when I first heard of it I wondered if it was such a good idea, but on thinking it over I realised this is probably the best way of handling multiple browser versions now and in the future.
IE, Theory
| Permalink
Aaron Gustafson unveils the new versioning switch in IE8, and discusses why the doctype switch is broken.
IE, Theory
| Permalink
15 November 2007
Chris unveils a few easy-to-learn rules for learning unobtrusive JavaScript.
Theory
| Permalink
6 November 2007
Fascinating as always.
Theory
| Permalink
1 November 2007
Dave Hyatt announces the lastest addition to Safari's CSS: animations.
div {
opacity: 1;
-webkit-transition: opacity 1s linear;
}
div:hover {
opacity: 0;
}
Now this sounds great, but I have to agree with Shaun Inman and Jonathan Snook that these new properties blur the line between presentation and behaviour even more.
Behaviour and presentation have to be separated somewhere; there has to be some sort of line dividing the two. The problem is that on the CSS side of things there are plenty of people who want to slowly push back the line, integrating more and more functionalities that once were JavaScript-only into CSS (content, for one).
Now animations. Where will it stop? Presentation is presentation, and behaviour is behaviour.
Besides, didn't we decide that we should attempt to follow the W3C standards? For sure, "following" has acquired the secondary meaning "implementing declarations W3C is considering but hasn't yet made up its mind about", but just about all new CSS additions actually have some sort of basis in some sort of spec. Animation hasn't.
All in all I wonder whether this is a good idea.
CSS, Safari, Theory
| Permalink
11 October 2007
Nate has started working on a kind of checklist for ascertaining site quality. Each site initially gets 100 points, but points are subtracted for, among others, missing doctypes, href="#", and other problems.
The list still has to grow a lot, but it's a very interesting concept that neatly ties in with some things we're going to try over here, even though we want to check web developers, and not sites.
In any case, I'll be following Nate's initiative with interest.
Theory
| Permalink
28 September 2007
Jeff Croft proposes a new and daring theory of the layers of web development. According to him, the structural layer is not HTML but the database, and he says HTML is about presenting the data (and structures) in a certain way.
This idea was touched on two years ago at Particletree, and it has always been in the back of my mind.
Maybe we could compromise by saying that seen from the back-end, HTML is about presentation, but seen from the front-end it's about structuring data. On the other hand, maybe that's a cop-out.
In any case this is an interesting idea that deserves to be discussed further.
(Via Naar Voren.)
Theory
| Permalink
2 September 2007
A few rather interesting ideas.
[...] the core ideas behind microformats were about inverting several conventional assumptions.
Tantek proceeds to list these inversions.
Theory
| Permalink
11 April 2007
Andrew Dupont divides browser issues into two groups:
- Capabilities (does this browser support
canvas?), which are addressed by object detection.
- Quirks (bugs), which may have to be addressed by browser detection.
I don't like browser detection for beans, but I'm forced to admit he has a point. The article also contains a few interesting technical details about the browser detection used in Prototype.
Browsers, JavaScript, Theory
| Permalink
8 April 2007
Definitions of some interaction design terminology. Quite useful, since it feels as if new terms and definitions are invented every year.
(Via Naar Voren.)
Reference, Theory, Usability
| Permalink
2 April 2007
Jeremy on Ajax and Flash, and the continuum between web sites and web applications. When you're working on the application side, Flash becomes a serious option, while Ajax is generally harder to code and less accessible.
Data Retrieval, Flash, Theory
| Permalink
20 March 2007
Dan talks about Flash vs. Ajax, and takes Jonathan's presentation at SxSW as a starting point. Dan investigates the reasons he decided to quit Flash programming, and notices many of these reasons have meanwhile been solved.
Data Retrieval, Flash, Theory
| Permalink
23 February 2007
Always an interesting question: should high end personal sites of web developers still support IE6 fully? QuirksMode.org doesn't, but I dropped IE6 support as much to save time as for any other reason. Maybe it's time to discuss this question more formally and in more depth.
Browsers, Theory
| Permalink
20 February 2007
Steve Yegge, who cannot be accused of being un-opinionated, talks about the Next Big Language, without revealing exactly which language he means. Curiously, many people seem to assume he talks about JavaScript 2.0 . I don't think I agree; social factors heavily weigh against JavaScript becoming an important server side language any time soon. Nonetheless it's an interesting thought.
(Via Web Graphics.)
Theory
| Permalink
14 February 2007
Interesting entry on the difference between graceful degradation and progressive enhancement.
Briefly, graceful degradation starts with a whistle-and-bells page and then makes sure it can be viewed without the whistles, without the bells, and without the whistles and bells.
Progessive enhancement starts with a bare-bones page and slowly adds new layers of functionality for those who happen to support it.
Although the net result should be roughly the same, all in all progressive enhancement seems like the way to go.
(Via Naar Voren.)
Accessibility, Theory
| Permalink
10 February 2007
Useful overview of where JavaScript and accessibility stand.
Accessibility, JavaScript, Theory
| Permalink
29 September 2006
About software development in general, and software development at Google in particular.
Fortunately I've never heard of Agile Programming, and after reading this article I'll give it a wide berth whenever I encounter it.
Incidentally, Google's way of working (as portrayed here) reminds me of the heady hype days when I worked for a fast-growing Web site creation company. Looking back, I can see we were trying to do something akin to what Google's doing, but it didn't quite work out; especially because just at the time I felt I began to understand how the company should operate, the Dot-Bust happened, project and other managers finally subdued the last spots of engineer resistance, and working at the company became boring.
I wish this article had been written back then. It'd helped me a lot convincing my bosses that we were on the right track.
Theory
| Permalink
12 September 2006
Bobby van der Sluis on Flash and progressive enhancement.
Flash, Theory
| Permalink
25 August 2006
About object and embed tags, and serving plug-ins in a standard compatible way.
HTML, Theory
| Permalink
18 July 2006
Andy Budd says web standards are no longer important, because they're ubiquitous. We can now concentrate on other stuff. An interesting opinion that's bound to raise some eyebrows.
Theory
| Permalink
Useful tips and tricks from Chris Heilmann. Maybe not surprising for senior gurus, but definitely worth a read if you rank lower than that.
JavaScript, Theory
| Permalink
17 July 2006
About definition-list-fundamentalism, float-exegesis, and other undesirable offshoots of the Web standards revolution.
CSS, HTML, Standards/W3C, Theory
| Permalink
12 June 2006
List of Ajax patterns; similar to what I myself am looking for in my QuirksBlog entries, but a bit more low-level.
Data Retrieval, Theory
| Permalink
4 February 2006
I've often wondered the same.
CSS, Theory
| Permalink
18 January 2006
Dan Webb studies JavaScript coding styles and gives a list of his own preferences. Might be an interesting starting point for a discussion.
JavaScript, Theory
| Permalink
John Allsopp continues to search for web patterns. He asks for types of sites. What type would this site be?
Theory
| Permalink
15 December 2005
Always interesting.
Theory
| Permalink
As promised, John Allsopp publishes his first PatternQuiz to map emerging webpatterns.
Theory
| Permalink
12 December 2005
Why not another technology instead of Ajax?
Theory
| Permalink
27 November 2005
Tantek on CSS hacks.
'It is actually a good thing that a hack be visually ugly from a coding aesthetic point of view in the hopes that the ugliness will be a reminder that the hack is a hack, and should incite a tendency for people to a) minimize its usage, and b) remove its usage over time.'
CSS, Theory
| Permalink
18 November 2005
John Allsopp on patterns for XHTML/CSS development. Rather long, rather interesting, and I haven't yet read it in detail. It seems very useful and I'll return to this idea some day.
Theory
| Permalink
18 October 2005
Jeremy Keith takes a stab at dispelling the myth that the myth of JavaScript degradation can be dispelled. If your Ajax application does not degrade and is inaccessible, you made the wrong choices during the design phase. Simple as that. ANY application can become accessible, although I admit there's quite a lot of work to be done in defining best practices.
JavaScript, Theory
| Permalink
Particletree adds a fourth layer to structure, presentation and behaviour: the data layer. Although I'm not quite sure XSLT is the best tool for mixing data and structure, I think I agree with the concept of the fourth layer.
All this requires more thought, though, especially since on simple, non-database-driven sites structure and data are one.
Theory
| Permalink
11 October 2005
Over on Digital Web Jeremy explains once more what has gone wrong with the way JavaScript was used (DHTML!) and how we can clear up the situation.
History, JavaScript, Theory
| Permalink
28 September 2005
Isolani offers a comparison between Ajax, XUL and Flash. Which will deliver the best web applications? Personally I'm not sure about XUL, it's still a bit of a grey area for me, and besides right now it's insufficiently supported. That might change, of course.
Theory
| Permalink
15 September 2005
Useful set of slides (using, of course, S5) about the basics of unobtrusive JavaScript.
JavaScript, Theory
| Permalink