Floating ideas onto the CSS working group can be a frustrating experience, possibly almost as frustrating as seeing the same questions come up every few months! I take a look at why it would be useful to be able to identify text nodes.

There is an elephant in the corner type of problem in the accessibilty world, that of WYSIWYG editors. In the first of a three part series, I outline this problem. The later posts will define what a solution would be, and see if it exists yet.

Some people need a history lesson. I’m not a Microsoft evangelist, but the anti-Internet Explorer comments are getting ridiculous. The following is why people should back off, for now.

Since November 2004 when Firefox 1.0 was release, it has become the main ‘other’ browser, stinging Microsoft into updating Internet Explorer. I try out the new version, running several installs separately so as not to ruin my current set up.

It’s been something that designers have wanted better control of ever since CSS started to be considered the best way to layout HTML pages: table style grids. A quick review of the options shows there could be a few drawbacks of the method.

With the advent of Internet Explorer 7, there is now little choice but to create separate style sheets for different browsers, at least for a moderately complex visual design or layout. This post explores the need for change, and where this approach could go.

At work a client received an email from someone asking why their site wasn’t “speech enabled”. This person said they were blind, and found the talking-browser product helpful, and why wasn’t the site speech-enabled. Should it be?

Some of the things you have to deal with in terms of browser/system compatibility are just getting stranger and stranger. It’s not just code, you have to be careful what words you use. Find out which famous anti-virus product invisibly removes web content.