Check Boxes and Radio Buttons Conquered by DHTML

Philip Howard writes "Pretty much every form element has been conquered by CSS so far, letting us create stylish, integrated forms to tie in closely with our site designs for that UI polish graphics artists love to have. Radio Buttons and Check Boxes, however, have resisted most attempts to style them consistently, accessibly and elegantly- perhaps because nobody cares enough to come up with the solution. However, these elusive form elements have finally been conquered with a simple combination of CSS and Javascript and a little HTML wrapper. The solution is easy and quick to implement, is accessible (working with tab and space) and elegantly degrades where CSS and/or XHTML is not available."

Comments

Not really new, but interesting

[AKAImBatman]

In reading TFA, it seems that the author hasn't done anything actually new. He's just inserting styled DIV tags with click handlers attached to them. His primary concern (and what he believes he's invented) is a method to be backward compatible with browers that have JavaScript turned off, and/or browsers that lack CSS support. (You actually want to support those guys?)

His solution is very similar to what mine would be. I'd just walk the DOM looking for checkboxes, then replace them with some inline element creation code. His solution is to get a list of all links, then find any with a special class. He then goes on to replace the contents of the links via the innerHTML property. Clunky, but it does work.

To the author: You can achieve your goal much more easily by attaching the className to the checkbox directly. Use getElementsByTagName to get a list of INPUT tags, then loop through those. When you find one you want to replace, use the

document.createElement()

function to build the replacement tag on the fly. You can then use

checkbox.parent.replaceChild(newCheckbox, checkbox)

to swap out the tags in a hurry.

Oh, and using an anchor tag for event handling is very 1990's. Try doing something like this instead:

newCheckbox.onclick = function(e) {
toggleCheckbox(newCheckbox, '', 'StyledCheckbox'+checkboxIndex+')
};

Note that you don't actually need the "StyledCheckbox" name, because you would be passing the actual element through to the event handler.

Good luck on your work. :-)

Re:Not really new, but interesting

[hacker]

"His primary concern (and what he believes he's invented) is a method to be backward compatible with browers that have JavaScript turned off, and/or browsers that lack CSS support. (You actually want to support those guys?)"

Yes, you most certainly do.

• Cellphones, pagers, "always-on" mobile Internet devices
• PDAs and handhelds, handheld browsers
• Devices for the blind, text-to-speech readers
• WAP devices
• Screen scrapers
• RSS syndication

If CSS delivers the style, and the HTML still delivers the content, then those will continue to work.

Once you start using Javascript or CSS to deliver the CONTENT, then you're doing something wrong, and breaking lots of your visitors.

Many Flash developers don't seem to understand this either (modulo the huge list of problems with using Flash). HTML should deliver the Flash, not the reverse.

Re:Not really new, but interesting

[TheViciousOverWind]

I don't really see what's new about this solution - isn't this what web-developers have been doing for years?

I know that I and several other developers I know have made "standard" Javascript libraries to do just this. - It's not rocket science, and this solution even lacks the "SELECT" element, which can't be styled very much, and is a "heavyweight component"[1], which makes it a prime candidate for swapping with a DHTML component.

[1] Meaning that it's "on top" of everything else

Re:Not really new, but interesting

[Psychic Burrito]

So, in other words, the code is incompatible with text-only browsers that understand javascript, as the form element get replaced with pictures on display, making this solution pretty nice but not really very correct.

Re:Not really new, but interesting

[Otter]

Note that "obvious in hindsight", or even "easily improvable upon" isn't at all inconsistent with "new".

(I have no idea whether or not it actually _is_ new.)

Re:Not really new, but interesting

[svanstrom]

His primary concern (and what he believes he's invented) is a method to be backward compatible with browers that have JavaScript turned off, and/or browsers that lack CSS support. (You actually want to support those guys?)

No, you don't want to support those guys; people using cellphones, some public terminals, Lynx or have turned off javascript are to be avoided... letting them use your site is bad, esp. if they actually could end up giving you money by clicking ads or buying services/products.

Remember that kids, you want to make it as hard as possible for people to use your services, otherwise anyone could end up giving you money... eeeew... that's just sick...

Re:Not really new, but interesting

[mattwarden]

Not only is it clunky, but it's incorrect. Classes are for CSS behavior, not JavaScript behavior. See: http://www.alistapart.com/articles/scripttriggers/

And, innerHTML is evil.

And of course you're right, this isn't new.

Re:Not really new, but interesting

[hhghghghh]

His primary concern (and what he believes he's invented) is a method to be backward compatible with browers that have JavaScript turned off, and/or browsers that lack CSS support. (You actually want to support those guys?)

Yes. Yes, you do. Many portable devices don't have those features. Think (smart)phones, PDAs, etc. Many times JavaScript is shut off because of a security policy, or because it's just plain abused too many times to make websites even more annoying.

In fact, I'd go so far as to say that webdesigners who insist their audience should have javascript switched on are annoying. Quit it, already.

Re:Not really new, but interesting

[thirteenVA]

Here we go...

Why is it that amongst web developers there is only considered to be 'one way to do things'.

Standards compliance is a good guideline, but it is not law.

Web developers only need to cater to those devices in which they expect their content to be viewed. I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA.

Yet, people wear their xhtml compliant gif's like medals of honor.

Write your pages with compliance in mind, but never lose site of refining your apps and pages for your target audience, regardless of it if bends the standards.

Re:Not really new, but interesting

[AKAImBatman]

In fact, I'd go so far as to say that webdesigners who insist their audience should have javascript switched on are annoying. Quit it, already.

I was actually referring to the CSS in specific, but even a lack of JavaScript is a big issue. There have been several times that I've written a DHTML application to improve the user interface. The non-Javascript alternatives are simply too clunky and hard to use. So yes, when they're in my site I expect them to have JavaScript turned on.

That being said, I would only tend to deploy such JavaScript tricks in cases where I'm deploying an actual web application and not just a public information site. DHTML on new.com.com.com would be bad, but on sites that I work on (which you've never heard of because you're not our direct customer) the application is for a specific sub-set of users.

Re:Not really new, but interesting

[gstoddart]

Many Flash developers don't seem to understand this either (modulo the huge list of problems with using Flash). HTML should deliver the Flash, not the reverse.

This is my biggest problem with flash.

There is nothing more annoying than browsing to a site from a machine which doesn't have flash installed (don't want it) and realizing the site was written in such a way as to not be able to get past the into animation without flash.

People who make web-sites which can't be operated without flash need beatings.

Re:Not really new, but interesting

[hacker]

"Yet, people wear their xhtml compliant gif's like medals of honor."

And most, if not all of those XHTML compliant buttons on websites are incorrect, since they are sending the content as text/html, which is not an XML application, as XHTML was designed for.

If your XHTML isn't being sent as application/xhtml+xml, then it isn't XHTML, period. Yes, I'm a purist like that.

See Sending XHTML as text/html Considered Harmful for more detail on this.

Re:Not really new, but interesting

[KillerDeathRobot]

No, the author hasn't invented any new kinds of code or web controls or anything else. The entire point is to use existing technologies (you know, the ones that people's browsers will support) to address something that has been an issue for some time.

As far as I know, this IS new. I've certainly never seen checkboxes and radio buttons (non-Flash) styled like this before, and I try to keep up with that kind of thing.

I'm not that well versed in ECMAScript or the DOM but are your suggestions accessible like what he's created? In that they would be able to be manipulated with tab and the space bar?

Anyway, it's one thing to say "I could have come up with that, only better" after the fact, and entirely another to have actually come up with it.

Re:Not really new, but interesting

[Anonymous Coward]

... nor do I desire for someone to use my company's web apps from a cellphone or PDA.

And if you were the only guy at the company, that would matter. As for not expecting them to do it, maybe that would change if you didn't make it so they couldn't.

Re:Not really new, but interesting

[MarkEst1973]

Is anyone really browsing the web from their cell phone? PDA? The resolution and functionality in these things are terrible. We have a decade of hard experience behind us building good web browsers. Let's build one into devices that want to surf the web.

The same goes for screenreaders. I have to make my applications Section 508 compliant everyday because we're a gov't contractor. It sucks. If Mozilla and IE know what elem.innerHTML is and can render it, why can a screenreader not work like a real goddamned web browser? Then it too would know what my elem.innerHTML is and can read it accordingly aloud to the non-sighted user.

There are real 508 problems for blind folks. Implementing a "skip nav" hidden link to bypass the multitude of primary navigation links is standard. If we can pass the user around the page like that, why not include more dynamic pieces in the page and present a non-visible menu for blind people? "Press 1 for My Profile, Press 1 for ... blah blah blah". As they press a button, *javascript and dhtml* take them around the page, reading more parts of the menu.

In my mind, a very accessible app would be more like a phone VRU to a blind person. But what's the problem? JAWS doesn't know shit about a page beyond html markup. It was only in the past few years that they managed to handle nested tables well. So blind people are lost when it comes to even Section 508 compliant websites, because screenreaders as they exist today suck.

Rich web applications (a la GMail, Google Maps, Flikr, Backpack, and other AJAX style applications) are a rennaissance of web programming. They are increasing usability at the expense of accessibility. The vast majority of users are sighted and on a PC. I don't think the solution is to code down to the lowest common denominator, but to build up the other dumber clients of web apps.

Re:Not really new, but interesting

[hacker]

"There is nothing more annoying than browsing to a site from a machine which doesn't have flash installed (don't want it) and realizing the site was written in such a way as to not be able to get past the into animation without flash."

I'll give you some more fuel to pour on that fire:

1. Can't change contrast (for those who might be colorblind and can't see light grey text on a white background. Who taught these kids color theory anyway? Barney the dinosaur?)
2. Can't change font size (whaddya mean you can't see my 6 point fonts, what are you, blind?)
3. No ability to search the text of a flash page using standard browser "Find" functions (yes, some search engines can index Flash now, with the proper hooks into the Macromedia Flash SDK, but its not exposed on the user end)
4. No fallback for non-Flash browsers, built into the Flash itself

It irritates me too, so I just don't use it, or recommend sites that do. Let's just make our entire site in PostScript, or better yet an OpenOffice.org .sxw or an OpenDocument .odp file format.

"Why not? You don't have the right plugin? Oh, too bad... get with the times!"

</sarcasm>

"People who make web-sites which can't be operated without flash need beatings."

People just need beatings anyway, just to let them know they can be beaten by anyone for any reason. This whole "Gimme" generation and the new business model of "Don't have a viable business plan? Sue someone! Profit!" needs to stop.

I'm going to have to start a new campaign called "Slap the Stupid out of Everyone" that does just that. Can't count change in the drive-thru? Find a new job, you're fired. Can't figure out how to answer questions about your product in the store? You're fired. Parking like an idiot? Towed.

I'm tired of just ignoring and tolerating stupidity and ineptitude and excuses. It has to stop.

Re:Not really new, but interesting

[Anonymous Coward]

Mods, that is not offtopic. Follow the link and you'll find that the grandparent's complaint was already answered.

Re:Not really new, but interesting

[hacker]

"They are increasing usability at the expense of accessibility."

Unfortunately, accessiblility is going to win this one out, thanks to web services and RSS and many other things. Eye-candy is great, but without a viable fallback, it will die off. That is the nature of evolution, and this will go the same route.

"The vast majority of users are sighted and on a PC. I don't think the solution is to code down to the lowest common denominator, but to build up the other dumber clients of web apps."

How do you know the vast majority of users are sighted on a PC? There are literally thousands upon thousands of users who are using a PC, who are legally blind or entirely blind. One of my colleagues uses 25+ point fonts because he can't see anything smaller than that, and he reads 8" from the screen.

The advent of the Internet is enabling people with disabilities to meet and join other communities of disabled people (visually, aurally and otherwise), and those communities are strong and growing. Elderly people are getting on the Internet, and many of them can't legally drive because of their sight.

While your own personal userbase might be fully-sighted, don't assume that your demographic expands to the rest of the world... it doesn't.

If the most-important part of your website is the presentation and not the content, you're doing something wrong. Yes, presentation makes the content look better (in some cases), but the users who are there won't be buying your product because you have pretty fonts or a spiffy intro in Flash. They'll be buying it because of what it DOES for them.

Re:Not really new, but interesting

[turchinc]

this styling trick for file input form elements impressed me much more than this:

http://www.quirksmode.org/dom/inputfile.html

oh how i hate the browse button!

Re:Not really new, but interesting

[cloudmaster]

That's not hindsight. Web devlopers (and sysadmins masquerading as programmers working on the web) have been doing that for a while now. It's a pretty obvious idea, but he did wrap it all up into a nice, clean package. For that reason alone, he gets some props - "web developers" don't generally do nice things like making their code readable or making it flexible - probably because most of them don't have serious programming background.

I've done similar things several times before, where you wrap the legacy object in something you can hide, and hide it in such a way that only browsers that support your new method do the hiding while the new stuff is wrapped in such a way that old browser will skip over the new stuff. Most CSS hacks essentially work that way, as do the large majority of browser workarounds. It's sort of like a slightly more flexible browser sniffing thats still bad because it depends on buggy behavior...

Re:Not really new, but interesting

[platos_beard]

Is anyone really browsing the web from their cell phone? PDA? The resolution and functionality in these things are terrible. We have a decade of hard experience behind us building good web browsers. Let's build one into devices that want to surf the web.

Hell yeah!

I've got a sidekick and find it surprisingly usable for web access -- Reading Slate on a train ride for example. Because of the Sidekick (aka Hiptop) limitations, some things I'd like to do are annoyingly difficult (e.g. checking traffic conditions where the only link to specific highways is a graphic map), and other things are AFAICT impossible (checking my ultimate team's schedule).

I don't expect web developers cater to those of use using smallish screens with no javascript or flash, but do think it reasonable that web sites not be hostile to such devices with no discernible benefit to the rest of the world.

Re:Not really new, but interesting

[Tet]

Is anyone really browsing the web from their cell phone? PDA?

Yes. Only a couple of days ago, I was in the pub with a few friends, and wanted to show them something. So we looked at it via the web browser built into a number of our phones. And because I'd made the site standards compliant, it all worked perfectly. That wasn't an isolated incident, either. A mobile phone may not be my preferred browsing platform, but it's still useful at times, and there's no reason to design a site that doesn't work with them (these days, it's pretty much a case of having to explicitly go out of your way to make the site not work on mobile devices -- unless you're using Flash, NightmareWeaver etc.)

Re:Not really new, but interesting

[mrchaotica]

Let's just make our entire site in PostScript, or better yet an OpenOffice.org .sxw or an OpenDocument .odp file format.

You know, that would actually be better than flash (although still horrible) because at least those are open formats with Free implementations.

Of course, they would still be horrible, because they lack semantic information (== accessibility). In fact, the whole idea of "word processing" documents is horrible: instead documents should be written in semantic XML, with a separate stylesheet (and by semantic I mean the equivalent of <em> instead of <i> and such).

Re:Not really new, but interesting

[Anonymous Coward]

"Yes, you most certainly do.

Cellphones, pagers, "always-on" mobile Internet devices
PDAs and handhelds, handheld browsers
Devices for the blind, text-to-speech readers
WAP devices
Screen scrapers
RSS syndication"

Who really cares about these anyway? If you are creating a page specifically for devices like this then don't do things like this, otherwise, do what you like... that seems to be the motto of the Internet these days.

Anyone using PDAs and cellphones to browse the web should go get a life anyhow...

And don't think I'm some fool without any knowledge of creating accessible web pages and the importance of separating content and style, if I had my way, JavaScript and Flash wouldn't even exist in the first place.

Re:Not really new, but interesting

[Pete]

Internal web application development is a bit different. For example, I've been working on a web application which (at the moment) only works on browsers using the Gecko renderer and Spidermonkey javascript engine. It should work on Safari/Konq and Opera, but they're still coming up short in a few places.

But it flat out doesn't work at all in IE. Doesn't even come close. Does this matter? No, not at all. Because the people I'm developing this for don't care what browser they're using. As far as they're concerned, they double-click on the Firefox icon to run this application, and that's all that matters.

It's kind of weird when you start thinking of webapp development in these terms, but you quickly get used to it. Intranet webapps are different (often very different) to internet websites.

Re:Not really new, but interesting

[Rycross]

Let's just make our entire site in PostScript, or better yet an OpenOffice.org .sxw or an OpenDocument .odp file format.

Sadly, I've actually seen a site made entirely in PDF.

Re:Not really new, but interesting

[drakaan]

Well, you're saying "incorrect", but that's also incorrect, since Peter-Paul's statement is an opinion of what he thinks *should* be the case.

That said, I generally agree with him, and that's a good article. I'm trying to decide whether to follow his advice...I guess I don't care about w3c validator's opinion if the code works well cross-browser without bugs.

Of course...creating a validatePage() function that checks what needs checking on a page-by page basis (with you saying "check this field for this and that", etc) gets around the issues mentioned, but is less elegant. Decisions, decisions...

Re:Not really new, but interesting

[godders]

Did you even TRY that page with js disabled?

No?

I didn't think so.

Why don't you give it a go before bleating like a girl about it.

Re:Not really new, but interesting

[AKAImBatman]

As far as I know, this IS new. I've certainly never seen checkboxes and radio buttons (non-Flash) styled like this before

Try again. I (and many others) have been doing checkboxes, radio buttons, and even select dropdowns in pure CSS and JavaScript for awhile. I actually have an internally deployed application that does this, and I checked out several existing JS Libraries before writing my own. Go here for some good examples.

I try to keep up with that kind of thing.

Obviously not as well as you think.

I'm not that well versed in ECMAScript or the DOM but are your suggestions accessible like what he's created? In that they would be able to be manipulated with tab and the space bar?

Yes. To obtain the tabbing, you'd still need to wrap the checkbox in an anchor, but this can be generated on the fly. He uses an "OnKeyPress" to capture the spacebar events, so that can easily be replaced with

anchor.onkeypress = function(e) {
toggleCheckbox(newCheckbox, e.keyCode, 'StyledCheckbox'+checkboxIndex+');
};

Same results, but it's more dynamic.

As I said, he hasn't done anything *new* here. His invention is really just a tutorial on how to be backward compatible while still providing fancy new DHTML controls. Such DOM walking schemes are in common usage today (ever see those pages that suddenly pop up hotlinks over key words while you're viewing them?), but the industry has begun to move away from concerning themselves with Netscape 4 era browsers.

Of course, if you need a checkbox, most sites still use plain old checkboxes. The only reason to replace them is if you need a web app on the level of GMail, in which case a lot more things are likely to break than just the DHTMLS checkboxes.

Re:Not really new, but interesting

[hjf]

Standards compliance is a good guideline, but it is not law.

quoth the Bill, nevermore.

Re:Not really new, but interesting

[newrisejohn]

Would your boss like it if your store rejected people who drove up in something *other* than a Ford or GM car?

But if you had to go completely out of your way to cater to those driving Yugos, would you? Especially if you knew that that 0.1% of those Yugo drivers have access to your site via the aforementioned Ford or Chevy?

Web pages are no different. You make them accessible to as many people as you can, because you don't want to alienate your customers.

I agree. Just because a very small segment uses alternative browsers doesn't mean you should shut them out entirely, but I wouldn't bend over backwards for them. Keep an eye on those server logs, and even with the reduced features, if your logs indicate an increase in PDA/Phone Browsers, then improve their pages look/functionality.

The end-all is why waste time/money if there isn't a return?

Re:Not really new, but interesting

[hacker]

You mustn't be talking to me, because the first thing I tried was using lynx and links2 -g... which worked fine.

I wonder who your reply was intended for.

Re:Not really new, but interesting

[Anonymous Coward]

i had to build 3 sites for content presentation (selling houses) and the layout and media was of utmost importance. I decided to use flash because its easy to integrate and modify the layout and I DONT HAVE TO MAKE A VERSION OF MY SITE FOR EACH BROWSER.

noncompliance of the standards is what makes me hate web developement. This is uttely stupid and it makes all your points against flash silly in comparison.
you want a find command? i can code one right in my swf! (im surprised its not built-in tho, ill give you that). same thing for font size. contrast? i think your monitor has that option.

the browser wars of back then created the incompatibilities that plague web dev these days and flash is a nice standard that makes developement fast and easy, powerwrful, no pain no hassle.

dont be so hasty to dismiss great tools because people can't use them right. a nice site made entirely in flash can pleasant to use. dont focus on the bad ones. . .

Re:Not really new, but interesting

[Anonymous Coward]

If it means I don't have to deal with IE quirks mode, I don't care.

XHTML without an xml-declaration at the top is the most standards compliant IE rendering you can hope for.

Re:Not really new, but interesting

[JimDabell]

Classes are for CSS behavior, not JavaScript behavior.

I don't know where you picked up that little nuggest of "wisdom", but it's completely wrong.

The class attribute is for grouping disparate elements. This is very useful in both CSS and Javascript, but it is not "for" either. It's a general mechanism - you can use it in custom written shell scripts that work with wget if you like, no Javascript, no CSS, still perfectly fine.

If you are confused about what an element type or attribute is for, consult the specification. It is quite clear in stating that it's for "general purpose processing by user-agents".

Re:Not really new, but interesting

[Anonymous Coward]

Accessibility laws apply to governmental organizations. Your comment is entirely irrelevant in this discussion.

And private groups can discriminate against you all they want. (Boy Scouts vs. gays, Augusta vs. women)

Re:Not really new, but interesting

[Anonymous Coward]

You mean, like your kids?
http://maddox.xmission.com/beat.html

Re:Not really new, but interesting

[hacker]

"But it flat out doesn't work at all in IE. Doesn't even come close. Does this matter? No, not at all. Because the people I'm developing this for don't care what browser they're using. As far as they're concerned, they double-click on the Firefox icon to run this application, and that's all that matters."

And instead of spending the time making it work with standards and standards-compliant browsers, you're going to have to add per-browser hacks, fixes, and possibly rewrite the whole thing over when/if a new browser comes out that doesn't work like the one you've coded your application specifically to work with.

Using standards, you can make sure your site or application is working today, and will remain future compatible, without any per-browser hacks, useragent detection, or anything of the sort.

It takes a little more time up front, but you save LOTS of time by not having to chase down little bugs in other browsers.

What if your company decides to move to all OSX machines, and your site doesn't work on Safari? Do you recode the site to work on Safari? What if you just broke it in Mozilla? What if your employer opens the site up to a new partner, which only uses MSIE? What now?

Granted, lots of "What-Ifs", but they matter when you do it right.. or do it wrong.

Re:Not really new, but interesting

[CaptainFork]

"Declaring things that clearly aren't terrorism AS terrorism IS terrorism!"

This sig is interesting because it accuses some straw-man of abusing the term "terrorism" by, er, abusing the word "terrorism".

Shame really, because I heartly agree with the rest of the article.

Re:Not really new, but interesting

[orthogonal]

"Is anyone really browsing the web from their cell phone? PDA? The resolution and functionality in these things are terrible."

Data point: for quite a while, I read Slashdot -- and even replied to comments -- on my Zaurus PDA.

As cell phones with decent screens become more ubiquitous, more and more people will be browsing from them, and you'll be locking out more and more potential customers.

Re:Not really new, but interesting

[Baby Duck]

innerHTML is beautiful and an effective macro for all those clunky DOM range operations.

Re:Not really new, but interesting

[Anonymous Coward]

I'm going to have to start a new campaign called "Slap the Stupid out of Everyone"

I find your ideas intriguing, and would like
to subscribe to your newsletter.

Re:Not really new, but interesting

[TuringTest]

Go here [blueshoes.org] for some good examples.

Which ones, those Checkbox and Radio controls that won't work if javascript is *disabled*?

Well, i'd say that definitely the article author actually *has* done something new here.

Re:Not really new, but interesting

[wodeh]

My primary goal is to make it accessible, easily degradable, cross browser compatible, and easy to use all in one go.

I tried an awful lot of methods using regular expression replacement of HTML to replace the form elements with the styled ones, this ultimately failed miserably.

As for adding onClick events, I tried element.onclick and never actually got anywhere- probably because I am not much of a JavaScripter. I will take your suggestion to heart and try again, anything to make it less clunky, more streamlined and easier to plug-in to web based projects is good for me.

I'm surprised this made Slashdot, but it will prove extremely helpful in perfecting the script- It's great to have the comments of a veritable army of discerning braniacs at my disposal.

Thanks for your comments!

Re:Not really new, but interesting

[Hamhock]

Then you're asking your company to be put out of business.

Hmmm. Is Google going to be put out of business if their maps application doesn't work on every (any?) cell phone or PDA? I think not. If your content is the app itself, and that app only works with JavaScript and CSS, then so be it. You're not doing anything wrong by requiring that of your users.

Re:Not really new, but interesting

[Shaper_pmp]

"Why is it that amongst web developers there is only considered to be 'one way to do things'."

My theory is that it's a combination of:

1. More complex up-front design considerations than many other development tasks - your code is written once, but should run perfectly (or degrade gracefully) on every browser for every operating system for every architecture it ever runs on. In the website design community we deal every day with headaches caused by bugged or incompatible-by-design APIs, sketchy standards support and incredibly customisable interfaces (what's the C/C++/Java equivalent of "disable stylesheets", eh?). When you find a technique that works perfectly/degrades well on all known implementations, you stick to it like glue, and disseminate the word so others don't have to rip their own hair out. CSS tricks are even more slavishly followed, because so many rely on precise, back-engineered quirks of different browsers' rendering algorithms.

2. A large segment of much less-educated community participants. A lot of web designers (even now) have come at it from a graphic design background, and fail to appreciate the complex requirements and difficulties inherent in javascript, XHTML, CSS and how they all interact. Solving a lot of common problems with one approach which can be copied by the less-knowledgeable is a big win when it stops people re-inventing the wheel (and making it square - Flash developers, I'm looking at you).

3. Look where pandering to IE/Netscape and coding to browser quirks got us in the 90s - sometimes it took longer to make a site work acceptably in all browsers than it did to design and implement the first complete version! Quite often these days you'll find the "one way to do it" is basically conforming to the standards, avoiding proprietary extensions and writing pages which validate. There's nothing wrong with it, it encourages browser-manufacturers to conform to the standards, it simplifies the job of the web designer/developer and it doesn't restrict creativity one jot.

"Standards compliance is a good guideline, but it is not law."

No, but it is the only thing that stops you unnecessarily spending twice as long on a job coding to browser quirks. And it does ensure that everyone will be able to at least see the information, even if it's not necessarily pretty (pretty is easy too, for a further small investment of time). And it does mean you can tell the difference between a skilled, professional webmaster and someone's kid nephew with a copy of Frontpage.

"Web developers only need to cater to those devices in which they expect their content to be viewed. I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA."

Then, with apologies, you fail to understand the fundamental nature of the web. The whole point of the web is that anyone should be able to access information (and web apps count as information), however they like.

"Not expecting" customers to use different browsers only shows that you're closed-minded or not very imaginative (especially for someone posting on Slashdot!). "I didn't expect it" is a pathetic justification when something doesn't work unnecessarily, and indicates a lack of professionalism in your execution.

"Not desiring" it (eg, coding to a specific browser as my company does - I don't) means you're effectively locking yourself and your customers into one company, and everyone knows vendor lockin is a pointless risk - even Microsoft's now paying lip-service to interoperability.

"Yet, people wear their xhtml compliant gif's like medals of honor."

Yes. They're proudly saying "Look - I'm a professional". Or "I care about doing things The Right Way". Or even "Fuck off browser-makers, unless you can make it work according to the standards". How are these a bad thing?

"Write your pages with compliance in mind, but never lose site of refining your apps and pages for your tar

Re:Not really new, but interesting

[Anonymous Coward]

a nice site made entirely in flash can pleasant to use.

Name one.

FYI: the browser knows my preferences (font size, for one). It has controls to perform the typical browsing tasks (history, back, print, etc) without having to look for the navigational instruments on a website.

Flash has its place, as a supplement, but a pure Flash site is a symptom of a society which favors looks over substance and will sacrifice efficiency for flashy effects.

Re:Not really new, but interesting

[Shaper_pmp]

It depends on the country you're in. Groups in the UK (and I believe Australia) have successfully sued (or at least, settled out of court) over websites that were inaccessible to the disabled.

Re:Not really new, but interesting

[Damek]

I'm tired of just ignoring and tolerating stupidity and ineptitude and excuses. It has to stop.

I think that's a stupid and inept idea.

Re:Not really new, but interesting

[poot_rootbeer]

I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA.

I, as a user, expect the web apps I use to be usable from any web browser available to me, including cellphones and PDAs.

If your company will not provide this ability to me, I will visit your competitors and see if they will.

Re:Not really new, but interesting

[computational super]

Would your boss like it if your store rejected people who drove up in something *other* than a Ford or GM car?

No, but if I ran a drive-through, I would prohibit people from inconveniencing everybody else by coming up in a horse and buggy.

Re:Not really new, but interesting

[AKAImBatman]

Which ones, those Checkbox and Radio controls that won't work if javascript is *disabled*?

KillerRobot said that he "hasn't seen non-Flash controls styled like this before."

I pointed him to examples of said styled controls.

An example of the DOM Walking techniques he's using are the annoying adverts like on this page. If your browser has JavaScript disabled, the links won't appear. But with JavaScript enabled, the links are automatically created from text extracted from the page.

My point is that this scheme has been known for awhile, but most developers don't bother with such attempts at backward compatibility. If your application is going to replace the standard controls with DHTML ones, then it's probably too complex to work without JavaScript and CSS anyway.

There's nothing really new here, but it is a nice tutorial on gracefully degrading functionality. :-)

Re:Not really new, but interesting

[computational super]

what's the C/C++/Java equivalent of "disable stylesheets", eh?

• C: disable( &stylesheets );
• C++: stylesheets->disable( );
• Java: stylesheets.disable( );

Hope this helps!

Re:Not really new, but interesting

[Shaper_pmp]

You've got a lot more flexibility in intranet development, but you're still voluntarily walking into vendor lock-in, even (as with Firefox) if the vendor vends for £0.

Stick to the standards, and all will be well. Even proprietary extensions from open-source apps aren't always perfectly safe - how would you feel if you'd invested in loads of Mozilla Suite-specific code, when Firefox came out? Or how about if (god forbid) Firefox dies on its arse, and the only options are Opera or (hackcoughspit) IE? You're voluntarily and short-sightedly stuffing yourself, for no real gain.

I really don't understand why people have a problem with sticking to standards. You can basically do anything you'll ever want or need to while still having validating code, but people persist in treating it like some kind of groupthink. Does anyone argue that C/C++ code doesn't have to compile? Or how about the ISO standards for C/C++ - pointless? Or are they the reason we still basically have one language each of C and C++, instead of hundreds of incompatible, balkanised rip-offs?

Re:Not really new, but interesting

[snorklewacker]

> (You actually want to support those guys?)

You run a commerce site, these guys have money, your job is to help them spend it. So yeah.

Re:Not really new, but interesting

[DavidTC]

And instead of spending the time making it work with standards and standards-compliant browsers...

Where, exactly, did he say anything about violating any standards? He said it didn't work on IE, which probably means it is using standards correctly, specifically CSS2.

Re:Not really new, but interesting

[Anonymous Coward]

"Many Flash developers don't seem to understand this either (modulo the huge list of problems with using Flash)."

That should be a Cartesian product.

Re:Not really new, but interesting

[Anonymous Coward]

innerHTML is beautiful and an effective macro for all those clunky DOM range operations.

Spoken like someone who's never written a DHTML application in his life. createElement calls can be wrapped up into APIs to make them easier to deal with. The advantage to doing this is that you have direct access to the element. Instead of littering your code with ugly "getElementById" calls, you can pass the JS Objects around and use them directly.

Stop thinking of JavaScript as some sub-par language for cute web effects. It's a fully featured environment under which HTML/CSS is the GUI rendering engine.

Re:Not really new, but interesting

[FLEB]

dont be so hasty to dismiss great tools because people can't use them right. a nice site made entirely in flash can pleasant to use. dont focus on the bad ones. . .

Well, for one, "Click to download the plugin" on a blank screen really isn't the pinnacle of usability. Flash isn't a "standard", it's a plugin. Granted, it's a very popular plugin, but it isn't a universal expectation.

I'm a fan of incidental or mixed Flash, but there still should be some way to get the meat, the information, of the site in plain HTML, especially with something as mass-market as a realtor's site.

That said, I've found very few cases where I can't execute a given layout that works cross-browser (with the exceptions of IE/Mac and NS4.0-, which fail to render most anything correctly). It might take some planning and forethought, but that's what makes one a web developer, as opposed to a Flash developer, or any other goob with a keyboard.

Re:Not really new, but interesting

[joshdick]

When I turn off Javascript, the page stops working properly.

Looks like someone's got more work ahead of him.

Re:Not really new, but interesting

[FLEB]

In AJAX's defense, however, look at the apps it's being used on: Maps, photo browsing, autocomplete, and a webmail app.

Okay, I'll grant you the webmail app (although, IIRC, GMail does degrade well), but many of the other apps AJAX is getting used for are advantages strictly for the sighted. They are either for easier browsing of graphical content (maps, photos), or assisting visual cues (autocomplete).

Re:Not really new, but interesting

[SComps]

I think you might be interested in this political party (please oh please identify the humor)

http://www.ironycentral.com/scorchedearth/faq.html

Re:Not really new, but interesting

[Anonymous Coward]

use the document.createElement() function to build the replacement tag on the fly.

FFS. You aren't creating a "tag", you are creating an element. You'd think the function name "createElement" would be a hint.

Your onclick attachment is stupid as well. It overwrites any existing onclick handler, which means you can't use that code in any generic page.

That and your "who needs to handle non-CSS user-agents" comment really shows how little your comment is worth. Really. You just know enough to be dangerous, like the average PHB who makes decisions based upon what some trade rag tells him.

Re:Not really new, but interesting

[Anonymous Coward]

No it wasn't. The grandparent post asks about text-only browsers that support JavaScript, the link sited by the redundant reply assumes text-only browsers do not support JavaScript.

Re:Not really new, but interesting

[Pete]

Well, I am actually coding it to be standards-compliant. And it is. It just doesn't YET work correctly in KHTML/KJS or Opera (believe it or not, neither of those engines are perfect - of course, neither is Gecko/Spidermonkey, but G/S is less imperfect :-)). But they're getting closer - it seems that every time I test a new Konq or Opera release, more things work correctly.

This is not your usual web application. It's all a single page, and almost every user action is handled with asynchronous XMLHttpRequests. It's pushing the envelope a fair bit, yes - but my boss is happy and so I'm happy too :). It is pretty amazing what you can do with Ajax when you don't have to be held back by IE limitations.

What if your employer opens the site up to a new partner, which only uses MSIE? What now?

Well, it's pretty damn simple. If they want to use the app, they use a supported environment *shrug*. Just like any other software vendor. Except it's about a billion times easier to install and run an alternative browser than it is to install and use an alternative operating system on your computer (when my boss was demonstrating to a potential client, it took him all of two minutes to (a) download, install and run Firefox and (b) get our app running on the newly-installed Firefox).

In some ways it's easier if you think of it like the web application is a "real" application. It's just that you install Firefox (or Mozilla, or K-Meleon) on your desktop to "run" the application (instead of, eg. a Java or .NET runtime environment). And of course in the near future our app will work with every major browser except IE.

Re:Not really new, but interesting

[mcfuddlerucker]

>> the guy who wrote it is either lazy, unprofessional, working to an unrealistic schedule or shit at his job.

Thankfully you put that middle one in there. I was about to cloud up and rain all over your ass.

Many of us want to do, and vocalize the importance of doing the right thing, but our hands are tied. Don't forget that.

Re:Not really new, but interesting

[yerfatma]

XHTML-compliant PNGs, thank you very much. Like gifs are copyrighted or something. To double up on my webdev street cred, why are my examples of prior art always under NDA?

Re:Not really new, but interesting

[khoury.brazil]

Well Said. In addition to all of this, I know that when I design for a client there is a good chance that it going to change in some way or another immediately or over time. Having a page structured correctly by separating content from design allows me to make small or radical changes to the layout for an entire site with ease. You can't beat that.

Re:Not really new, but interesting

[pocopoco]

>Yes, I'm a purist like that.

Anyone else find it amusing that these "purist" people haven't even read the official specification? It's clearly stated at http://www.w3.org/TR/xhtml1/ that you are allowed to send XHTML 1.0 (which is what most sites are using) as text/html and they even give you an appendix full of compatibility tips when doing so.

Re:Not really new, but interesting

[MarkEst1973]

"How do you know the vast majority of users are sighted on a PC? There are literally thousands upon thousands of users who are using a PC, who are legally blind or entirely blind. One of my colleagues uses 25+ point fonts because he can't see anything smaller than that, and he reads 8" from the screen."

Yes, there are many thousands, tens of thousands even, of blind, partially blind, and color blind web surfers. There are hundreds of millions of sigted users. Blind people are a minority group.

Section 508 to the rescue!

We cannot discrimate against people, says the US Gov't, so they mandate all gov't sites and applications be Section 508 compliant. I know more about color pallettes than you do, because a color blind person will not be able to read all the text. Blind people can't read it at all.

I've used JAWS. It sucks. It's awful. It's the worst browsing experience I've had in my life. And it could be made so much better for a blind person if JAWS had a DHTML capable browser built in.

Instead of "skip nav" like I mentioned above, why not present a non-visual menu for the screenreader? "Press 1 for My Profile" and DHTML renders that section (via innerHTML, CSS, etc.) dynamically. We could easily shuffle the user to that new DIV complete with its own non-visual submenu (Press 2 for Password, Press 3 for Listserv, etc).

But now? Blind users have to guess what is primary navigation and what is secondary. There is no easy way to group them to make it obvious that a section of links is secondary navigation.

DHTML, Javascript, and CSS built into JAWS could make for a much more accessible solution than we have today.

Re:Not really new, but interesting

[Anonymous Coward]

I agree with this parent.
I own a company that employs graphic artsists with web experience to design our pages and web developers who hack up their pretty little designs and make them work. If your design cannot gracefully degrade with less capable browsers, then you've failed your job as a developer. You would have gotten better results by using PHP to dynamically generate a jpeg image for your readers to view.

Anybody who preaches 100% standards compliance hasn't actually written a real world website. Likewise, someone who doesn't attempt to use standards where they can is similarly naieve.

I can't count the number of times I've had to do browser detection to make sure a specific "gee-whiz" feature works for both major browsers (Gecko & MSIE 5+). That being said, those Gee-Whiz features degrade gracefully with less than optimal browsers. When you're coding a dynamic language like PHP or ASP, it's nothing to present in lightly formated plain text when you detect your readers are using NS 2.0.

I have to laugh every time I see a splash page on a site that just has some fancy flash animation in it's code. If you're going to put an obnoxious splash page on your website, at least have it do something usefull like preload images and do browser and resolution detection so your visitors recieve the optimal presentation based on their capabilities. Go ahead and open your page on a Blackberry, if you can't get to the product your selling (and every website sells *something*) then you've failed. Yahoo.com degrades very well even down to text only cell-phones.

I'm working with a company now that is busting their asses to ensure their intranet is Gecko compatible because they've decided to push firefox as their corporate web browser (for security concerns)

If you're designing a website with the look of the site more important than the practicality of the site and your site is only viewable from MSIE6 with Macromedia Flash installed, then you're not a web developer, you're a graphic artist who's obviously out of their element.

Re:Not really new, but interesting

[los furtive]

You're gonna have to wait a bit. Even IE 6 doesn't treat XHTML as anything but plain old text/html

Re:Not really new, but interesting

[FlynnMP3]

Name one.

Homestar Runner

Is it pleasant to use? Meh. Depends on your web eccentricity. The site itself is pretty easy and fun.

Flash has it's place, and some flash designers know the good uses, but others just need to beat on the head with a web standards stick.

-FlynnMP3

Re:Not really new, but interesting

[Anonymous Coward]

Ditto. I was the webmaster of a Deaf organisation at a university. I have my own Sidekick II and used it to see how well the website scaled back--to my suprise, very well! I was satisfied, everyone could check on the website for lists of upcoming events, upcoming open captioned movies and so on.

So yes, it's useful even on a small screen! THINK DIFFERENT!

Re:Not really new, but interesting

[ray-auch]

Would your boss like it if your store rejected people who drove up in something *other* than a Ford or GM car? The answer is (quite obviously) "NO".

Not obvious at all.

Plenty of businesses discriminate on vehicle. Car parks are for parking cars - you think they should all accomodate trucks, buses, bikes, planes ?

Plenty of roadside restaurants (at least here in UK) ban trucks and/or coaches and/or cars towing caravans.

In all cases it is not a question of whose money is good or not, but on whether it is economic to support them. If you have limited car parking for a restaurant, you probably don't want truck drivers there - no matter how good their money is they aren't going to eat as much as the passengers from the several cars who can't park because of the truck.

Re:Not really new, but interesting

[Anonymous Coward]

"In some ways it's easier if you think of it like the web application is a "real" application. It's just that you install Firefox (or Mozilla, or K-Meleon) on your desktop to "run" the application (instead of, eg. a Java or .NET runtime environment). And of course in the near future our app will work with every major browser except IE."

Except that the web and the http protocol, are not "real applications" at all. They are intentionally made to be stateless, which applications are not.

Hack around all you want, but the web was not meant to provide a stateful "application" experience to end-users.

Re:Not really new, but interesting

[Ed Avis]

And all this is needed for... what exactly? To make a kewl-looking user interface that is inconsistent with all the other programs on the user's system and with other websites?

Re:Not really new, but interesting

[AKAImBatman]

Hi Wodeh,

My primary goal is to make it accessible, easily degradable, cross browser compatible, and easy to use all in one go.

And you've suceeded. Congrats. :-)

As for adding onClick events, I tried element.onclick and never actually got anywhere- probably because I am not much of a JavaScripter.

It's a bit tricky, but not as hard as you might think. The "onclick" *mus* be in lower case. I can't count how many times this has bitten people in the rear.

Also, when you're doing JavaScript, always use Mozilla/FireFox for development. Typing "javascript:" will bring up one of the most useful debugging tools at your disposal. Often when something seems wrong, your initial guess to the problem is likely wrong. The JS Debugger will tell you what the issue *really* is. :-)

Here's a working example with the "onclick" handler:

<html>
<head>
<style>
.Checkbox, .CheckboxChecked {display:block;width:100%;height:20px;}
.Checkbox
{
background:url('http://www.gamingheadlines.co.uk/w od/formstyle/CheckboxUncheckedA.gif') no-repeat center center;
}
.CheckboxChecked
{
background:url('http://www.gamingheadlines.co.uk/w od/formstyle/CheckboxCheckedA.gif') no-repeat center center;
}
</style>
<script>
function toggleCheckBox(element, keyCode)
{
if(keyCode && keyCode != 0x20) return;

if(element.className == "Checkbox") element.className = "CheckboxChecked";
else element.className = "Checkbox";
}

function initCheckBoxes()
{
var checkboxes = document.getElementsByTagName("input");
var checkbox;

for(var i=0; i<checkboxes.length; i++)
{
if(checkboxes[i].type = "checkbox")
{
checkbox = document.createElement("a");

checkbox.href = "#";
checkbox.className = "Checkbox";
checkbox.onclick = function(e) {
toggleCheckBox(checkbox);
};
checkbox.onkeypress = function(e) {
toggleCheckBox(checkbox, e.keyCode);
};

checkboxes[i].parentNode.replaceChild(checkbox, checkboxes[i]);
}
}
}
</script>
</head>
<body>
<div><input class="ImageCheckBox" type="checkbox"></div>
<script>initCheckBoxes();</script>
</body>
</htm l>

(Watch for Slashcode inserting random spaces above.)

Thanks for your comments!

No problem. If you have questions about advanced JavaScripting, my door is always open: akaimbatman@gmail.com.

Re:Not really new, but interesting

[ray-auch]

What if your company decides to move to all OSX machines

They will consider the cost of porting / replacing the app, just as they will have to for the other windows apps they use.

For a web based app, the port may well be a lot simpler than a thick-client / desktop app (but not guaranteed).

When developing the app in the first place you balance the extra cost of portable development (you think if you write to w3c standards you don't have to at least test in every browser??) vs. the risk of a future platform move.

Re:Not really new, but interesting

[alienw]

Please STFU. I doubt you've ever made a single website or written a single line of javascript code. Otherwise, you would know that "standards-compliant" just means that it doesn't work correctly in any browser, since no browsers are 100% standards-compliant.

Re:Not really new, but interesting

[Pete]

Well, as I clarified in my response to hacker, I am actually sticking to the standards :). It's just that so far the Gecko renderer and the Spidermonkey Javascript engine are the only ones that handle this app correctly. In its original form 18 months ago, Opera and Konqueror were both totally unable to handle it - massive rendering bugs (though both still did better than IE *grin*). Now they're both very close to correct in the rendering department, but now both seem to be having trouble with the Javascript.

Mind you, even if it only ever works on Gecko/Spidermonkey, that's a pretty solid cross-platform browser environment. Hell, I was originally considering making it an XUL application - if I'd done that then it'd only ever run on Mozilla and/or Firefox. Thankfully I realised that I didn't need to go that far, so now we have a good wholesome application for which the target platform is any reasonably standards-compliant web browser. As long as our clients are happy with that (and they are (so far)), that's Good Enough(tm).

Re:Not really new, but interesting

[AKAImBatman]

Ah! A perfect learning example. This, my good Slashdotters, is an example of a troll. Trolls almost always post as AC, and pretend to know their head from their ass when they are really looking to make people mad. Let's pick this one apart, shall we?

FFS. You aren't creating a "tag", you are creating an element. You'd think the function name "createElement" would be a hint.

This is a perfect example of nit-picking, while being completely wrong. "Element" is a generic term for all objects that can be in the document structure. "Tag" is a more specific type of element. Thus the two are interchangable in this situation. But Mr. Troll would rather pick at nits because he can make people mad. Isn't that right Mr. Trolly-wolly?

Your onclick attachment is stupid as well. It overwrites any existing onclick handler, which means you can't use that code in any generic page.

Again, Mr. Trolly-Wolly doesn't know what he's talking about, but professes that he does. He is intentionally confusing a document-level click handler with an element level click handler. For the record, the element level click handler does not replace the document level handler. Document level handlers are BAAAAAD, and should only be used in specific circumstances.

And since we're creating the tag element from scratch, we don't have to worry about any prior events being attached.

That and your "who needs to handle non-CSS user-agents" comment really shows how little your comment is worth.

And again, Mr. Trolly doesn't actually understand this issue, but he feels that he must use it to anger people into submission. If Mr. Troll was a little more educated, he'd know that all non-CSS compliant browsers are deprecated and can no longer be used if one wishes to follow the "standards". CSS is particularly important to small devices and screen readers, which are supposed to use CSS hints for small-screen or aural rendering.

That's it for this edition of "Make the Trolls Look Stupid!" Join us next time when we show you how to get your pet troll to do tricks!

Re:Not really new, but interesting

[pere]

just two more points.

* search engines. Most search engine bots do not understand javascript. Your pages will most likely not be index if they require javascript, or you end up with a poor rating. This might cost you a lot more customers than those viewing the pages with javascript off.

* the future. Even if you plan to update your pages every friday at noon, in real life lots of pages will be unmaintained. The life expectancy of a javascript page is however much less than a compliant html page. In five years you might have problem finding a browser that can read the page. My guess is that a compliant xhtml1.0 page can be read perfectly with the newest browser 30 years from now (if they still use browsers....)

Re:Not really new, but interesting

[pspinler]

Gosh, you mean in a markup language, say, like Tex/LaTex ?

Gee, it's a shame no-one ever came up with _that_ idea before.

Oh, but then, you'd actually have to learn something in order to produce documents.

It's just too damn bad that early word processer architects never grokked that easy to learn gui != broken file format.

-- Pat

Re:Not really new, but interesting

[BridgeBum]

You mean like (La)TeX? Hardly a new idea...

Re:Not really new, but interesting

[jacksonj04]

We need more people like you who go "Screw the rest, we'll code to standards and if it doesn't work then tough". The standards are there to be used as such, and if a browser doesn't play along with the standards then it's safe to be ignored.

Re:Not really new, but interesting

[AKAImBatman]

As far as I'm concerned, the degrading isn't necessary due to the areas where these DHTML controls would be used.

The DHTML controls are necessary for much more powerful applications where DHTML can be used to deliver a networked form of Desktop application. Google has been in the spotlight with their GMail and Google Maps interfaces, but they're not the only ones producing powerful software in JS/HTML/CSS.

In some of these applications, you may have no choice but to replace the standard controls. The standard controls are heavyweight, and often cannot be covered over, clipped, or otherwise not/partially shown. Lightweight components don't have those issues. In addition, lightweight component can improve the user experience by allowing the developer to modify the behavior of the controls. For example, the standard HTML button is not a toggleable control. But a DHTML button can be made toggleable. Same with three state checkboxes, on-demand dropdowns, styleable text areas, and other control modifications that HTML doesn't allow.

Re:Not really new, but interesting

[Pete]

*sigh* Look, I'm not going to make fun of you - it'd be too easy :). Just go have a quick game of Weboggle, hopefully that will clarify your understanding of the kind of applications (yes, real live applications) that can be built with Javascript and run inside a web browser.

Asynchronous XMLHttpRequest has really opened a lot of doors for this sort of stuff, and there's still a great deal of scope for new and interesting web applications.

Re:Not really new, but interesting

[Anonymous Coward]

If you don't follow compliance, you are saying disabled users aren't good enough to see your page. Blind people would like to be on the web, too.

You got a problem with that?

Re:Not really new, but interesting

[AuMatar]

So, screen readers suck? Sounds like a market. Make a better one instead of complaining.

Re:Not really new, but interesting

[Anonymous Coward]

How do you know the vast majority of users are sighted on a PC? There are literally thousands upon thousands of users who are using a PC, who are legally blind or entirely blind.

Are you serious? There are literally billions of PC users that have fine vision (possibly corrected.) You're just taking political correctness too damn far here.

Re:Not really new, but interesting

[alasdair]

If Mozilla and IE know what elem.innerHTML is and can render it, why can a screenreader not work like a real goddamned web browser?

Remember that a screen reader has to handle many other applications other than yours: Word, Excel, Powerpoint, Outlook, Windows Explorer, all with different Document Object Models, accessibility APIs, data and presentation models... And every new version of Windows changes how the screen reader has to operate. And every new funky application needs some new approach: sure, you can handle HTML, but now here comes Flash and it'll be four years before they address accessibility...

One alternative is to piggy-back on existing applications: I write a web browser for blind people (http://www.webbie.org.uk/) that uses the Microsoft Internet Explorer WebBrowser ActiveX component internally, so it does all the heavy lifting in terms of parsing, handling events and so on. Of course, I still can't do anything about websites that demand that onmouseover is the way to operate their pages! (There is a Mozilla equivalent (http://www.iol.ie/~locka/mozilla/mozilla.htm) but it does not appear to support all the (proprietary?) DOM features I need to use to handle complex websites designed for sighted people.) Even with this component doing all the hard work it's still difficult to present a web page in a way that is usable, not just accessible.

If you're designing a website, remember: blind people will try to use your website and if you help them out you're doing the Right Thing, even if it takes more time and effort. You have printed and other alternatives to the Web: blind people often don't. Only 5% (RNIB UK figures) of print sources get produced in an accessible format. Compare that to billions of (potentially) accessible web pages and you can see how the web can be great for blind people. Please do your bit!

Re:Not really new, but interesting

[Victor_Os]

I doubt you've ever made a single website or written a single line of javascript code. Otherwise, you would know that standards-compliant" just means that it doesn't work correctly in any browser

If you can't, it doesn't mean others can't too.
Grow up boy.

Re:Not really new, but interesting

[Anonymous Coward]

Oi, nice one.

Someone with points mod this guy up :)

Re:Not really new, but interesting

[Pete]

Thanks for the vote of confidence :). It's certainly nice to be able to say "we code to standards, if it doesn't work for you then it's your problem", but it wasn't me that made that call - it was my project lead. And, sadly, few developers are lucky enough to have a boss who'd make a decision like that.

But if he hadn't, then this app would probably never have existed at all - or at least not in its current form *shrug*. It's kind of funny to think of how much hung on those words a couple of years ago:

Me: I don't think we'll ever be able to get this to work in Internet Explorer.
Boss: *pause for thought* Fuck Internet Explorer.

:-)

Re:Not really new, but interesting

[loucura!]

I decided to use flash because its easy to integrate and modify the layout and I DONT HAVE TO MAKE A VERSION OF MY SITE FOR EACH BROWSER.

It is possible to design a page in HTML/CSS that works properly with every browser. That you are incapable of doing so is a testament to your incompetency, bravo!

Re:Not really new, but interesting

[Anonymous Coward]

I decided to use flash because its easy to integrate and modify the layout and I DONT HAVE TO MAKE A VERSION OF MY SITE FOR EACH BROWSER.

You don't have to do that without Flash. That kind of thing was popular in the mid-late-nineties, but even then it wasn't necessary.

noncompliance of the standards is what makes me hate web developement.

And you create noncompliant websites? Hypocritical much?

you want a find command? i can code one right in my swf!

Did you? Or are you saying that it's a possibility and that anybody wishing to search will have to contact you and wait for you to code it? And will it work with the same key combination as searching on other websites? Remember, Ctrl+F isn't find in all browsers. It isn't even consistent across the same browser in different languages.

What about find-as-you-type? Will you code that too? What about middle-clicking to open in a new tab? Will you code that too? Ooops, my browser is configured to open in a new window when I middle-click a link. Guess it'll work for some people but not others. What about right-click, open all links in tabs? Will you code that too?

In order for a Flash presentation to supplant an actual website properly, you have to duplicate all the browser features that work with normal HTML but don't work with Flash.

The trouble is, this is not only a shitload of unnecessary work, but it's actually impossible, because different browsers work in different ways.

So it's impossible to go Flash-only without breaking actual browser features. The fact that you can - theoretically ('cause we all know you didn't actually do it) - add a search function to a Flash presentation, does not change this fact.

a nice site made entirely in flash can pleasant to use

Name one.

Re:Not really new, but interesting

[colinrichardday]

Hey, I like TeX/LaTeX, but is LaTeX as structured as XML? Does it have the equivalent of (as opposed to )? Does TeX/LaTeX allow readers to import their own stylesheets in viewing it (OK, if they have the source as opposed to just the *.dvi file)? Can TeX/LaTeX be rendered aurally rather than visually?

For producing printing output, TeX/LaTeX is excellent.

Re:Not really new, but interesting

[CTachyon]

Is anyone really browsing the web from their cell phone?

Yes.

Re:Not really new, but interesting

[mrchaotica]

No! I have nothing against GUIs; the problem is that the most popular ones happen to suck because they encourage people to think in terms of "bold text" instead of "heading" or "emphasis." It's WYSIWYG that's (mostly) the problem. Instead of straight WYSIWYG, it would be nice if each element in the document were bordered by a colored rectangle (or something similar) indicating its meaning so that you could see the semantic structure as you edit. Also, instead of a toolbar with buttons like "bold," "italic," and "align [left|center|right]" the buttons should be "emphasis," "heading," "citation," etc.

Then, at any time you can switch to a "publishing" view where you can deal with the layout and style. However, instead of your actual document you'd see a "lorem ipsum" document with the styles applied, and it wouldn't be editable. That's an important bit: you couldn't edit the text and the style at the same time.

It would produce an XML + CSS file, of course. : )

Re:Not really new, but interesting

[Anonymous Coward]

While your own personal userbase might be fully-sighted, don't assume that your demographic expands to the rest of the world... it doesn't.

Oh yeah? Well don't assume it doesn't... it does.

Re:Not really new, but interesting

[advocate_one]

Just go have a quick game of Weboggle,

ahh..shoot... yet another game that'll capture my life for the next few months...

Re:Not really new, but interesting

[thirteenVA]

Too bad you really don't know what your talking about, you're obviously not a real world web developer or a business owner. Read on.

Your saying i should make my app accessible to as many people as possible but follow it up with something about alienating my customers.

If I spend time making sure the app works on a cell phone when it does not need to (because my clients do not want that feature) then i am alienating them when I do make it work, because there are higher priority feature sets they want.

Time is not unlimited, resources are not expendable. I have the manpower to cater to my clients needs. That is all. Not add features for 1% of the population to enjoy from their cellphone.

You have failed as a developer and failed as a business if you spend valuable time and resources on fruitless ventures.

Re:Not really new, but interesting

[Stankatz]

Oh, and using an anchor tag for event handling is very 1990's. Try doing something like this instead:

newCheckbox.onclick = function(e) {
toggleCheckbox(newCheckbox, '', 'StyledCheckbox'+checkboxIndex+')
};

That method's fine if you only want to support IE. The standard way is:

var checkboxListener = new Object();
checkboxListener.handleEvent = function(e) {...};
newCheckbox.addEventListener('click', checkboxListener, false);

Of course, if you want to support IE 5.x, you need to fall back on this when addEventListener isn't available:

newCheckbox.attachEvent('onclick', checkboxListener.handleEvent);

Re:Not really new, but interesting

[Anonymous Coward]

People who make these vile "Flash only" websites need the ends of their fingers removing before each individual nerve is subjected to remoreseless, unrelenting torture.

Once the pain receptors for this part of their body has been saturated to the point it can't take any more we can start on the eyeballs. Next up it's the genitals etc. etc.

Of course, for maximum effect, all this should be done in public with a clear description of why this is happening to them.

Fuck off flash. What a fucking waste of electons.

Re:Not really new, but interesting

[mattyrobinson69]

i find khtml and opera seem to be more standards compliant than gecko, at least with the parts of the standards that i play with.

Re:Not really new, but interesting

[Anonymous Coward]

"Element" is a generic term for all objects that can be in the document structure. "Tag" is a more specific type of element.

Completely and utterly wrong.

Elements are nodes in the document tree. Tags are merely the delimiters that tell the parser where the elements begin and end. Don't believe me though, read the HTML 4.01 specification.

One example of something that fits your definition of "element" but doesn't fit the reality is an attribute. Attributes are objects in the document structure, but they are properties of elements, not elements themselves. And the HTML specification actually says "elements are not tags".

Basically, you are full of shit. Read the specifications. Learn a little about SGML. You are wrong and have resorted to name-calling ("trolly-wolly"? How old are you?) and inventing your own definitions instead of admitting you are wrong.

He is intentionally confusing a document-level click handler with an element level click handler. For the record, the element level click handler does not replace the document level handler.

That whooshing sound is my point sailing over your head.

Simply assigning a handler to the onclick property of an element node overwrites whatever previous handler has already been installed there. This makes your style of code unsuitable for generic scripts. The correct appropach is to use attachEvent and addEventListener. Some discussion of the brokenness of onclick assignment here.

Sure, in some situations it doesn't matter, but why bother with learning two ways of doing it when one way works fine all the time and your way breaks some of the time? Like I said, it's a stupid way of doing things.

If Mr. Troll was a little more educated, he'd know that all non-CSS compliant browsers are deprecated and can no longer be used if one wishes to follow the "standards".

You're just making this shit up as you go along, aren't you? Compatibility with non-CSS user-agents is a design principle of CSS. Again, you are full of shit. Want more? The W3C, which published the CSS specifications, also published WCAG, which states Organize documents so they may be read without style sheets..

I've backed up my argument with links to explanations, hints on where to find more information, and authorative quotations from specifications. You've just blown a lot of hot air and called me names. Who's the real troll?

Re:Not really new, but interesting

[leoboiko]

Which is why I like to serve XHTML 1.1, and use a xslt script (good for Sablotron, btw) to generate fallback .html versions. Tie with Apache content negotiation and that bad browser will get his plain HTML 4.01 files, while browsers which are cool will ask for nice, valid application/xhtml+xml XHTML 1.1.

XHTML 1.0 is bogus. If you're going to serve text/html tag soup, you might as well serve plain HTML.

Re:Not really new, but interesting

[Brandybuck]

Why is it that amongst web developers there is only considered to be 'one way to do things'.

Maybe it's because they're not really developers? They like to pretend they are, but they're not. Writing javascript no more makes them developers than writing shell scripts would. And of course, HTML and CSS are *NOT* programming languages!

Real developers test their code. Web "developers" do not. At best they'll make sure their pages work with Internet Explorer and Firefox. As if those are the only two browsers in the world. Test on last years Firefox? Hah! Don't make me laugh!

The people working on the back end database and CGI interfaces might be developers, but those who write the HTML/CSS are not. Yes, there are some exception, but that only validates the rule.

Re:Not really new, but interesting

[hesiod]

> If you don't follow compliance, you are saying disabled users aren't good enough to see your page

I realize you're trolling, but it's not that they aren't good enough, it's that they aren't equipped to look at it. I mean, that's like saying people who don't have Flash installed aren't "good enough" to look at my site (actually, I don't use flash... not the point). If I don't have a working nose, can I sue perfume makers for not catering to my special needs?

Re:Not really new, but interesting

[Silicon Jedi]

Yes, but Homestar Runner is essentially an access portal for... Flash movies. Therefore requiring Flash is now big deal.

Re:Not really new, but interesting

[Stankatz]

How do you know the vast majority of users are sighted on a PC? There are literally thousands upon thousands of users who are using a PC, who are legally blind or entirely blind.

You're trolling, right? Thousands? Guess what, there are hundreds of millions of sighted PC users accessing the Internet too.

While your own personal userbase might be fully-sighted, don't assume that your demographic expands to the rest of the world... it doesn't.

Is there some huge nation of blind people who only browse the web using cellphones that I don't know about? Now if you're developing for HotBlindSingles.com, that's another matter.

If the most-important part of your website is the presentation and not the content, you're doing something wrong.

If you read the grandparent post, you'll see he wasn't talking about flashy presentation as much as he was about usability. Google Maps could be implemented with static HTML, but it's a lot easier to navigate with all the fancy DHTML.

And what about the illiterate? Using text on your webpage makes it hard for them to use. You should only illustrate concepts with simple ASCII art diagrams. That way, the blind, the stupid, and the illiterate can all understand them.

Re:Not really new, but interesting

[pocopoco]

> Is anyone really browsing the web from their cell phone? PDA?

Definite yes for PDA here. I have a VGA resolution Zaurus and am constantly using the browser. Even when offline I have entire websites and books saved in HTML ready for use.

One thing it's been particularly good for is going to big conventions and events, but still having the entire contents of the event's website (including forums if any) in my pocket.

Re:Not really new, but interesting

[mattwarden]

I guess I don't care about w3c validator's opinion if the code works well cross-browser without bugs.

I don't know if you meant to imply that the markup would be in any way invalid, but just in case you did: it wouldn't be. If the W3C validator says anything, it would be that it cannot validate the page, as the page uses a custom dtd (which would likely be an extension of xhtml). But, the page would be perfectly valid, and there are validators out there that can validate custom dtds.

Re:Not really new, but interesting

[russx2]

When I turn off Javascript, the page stops working properly.

On what browser/platform?

I highly doubt this is the case because, as the author explains, all 'magic' extras are written AFTER the normal elements have loaded. So without javascript, nothing changes.

What I suspect you have done is disabled Javascript in your browser and then tried to use it - without refreshing the page. I've just tried in this in Firefox and it seems to be the case. I don't think the chances of someone disabling Javascript mid-way through using the page are worth worrying about ;-)

Please correct me if I'm wrong though.

Re:Not really new, but interesting

[mattwarden]

I don't know where you picked up that little nuggest of "wisdom", but it's completely wrong.

Um, from the specification (which you even linked to):

The class attribute has several roles in HTML:

• As a style sheet selector (when an author wishes to assign style information to a set of elements).
• For general purpose processing by user agents.

I guess you think JavaScript is "general purpose processing by user agents."

Re:Not really new, but interesting

[AKAImBatman]

Completely and utterly wrong.

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Elements are nodes in the document tree.

Exactly what I said. Thank you for agreeing with me, Mr. Troll.

And the HTML specification actually says "elements are not tags"

Precisely. Tags are represented by a sub-set of elements. Thus in certain cases, the two words can be used interchangably. Cases like, I don't know, the one I was using originally?

But wait! We have to keep on trolling!

That whooshing sound is my point sailing over your head.

Simply assigning a handler to the onclick property of an element node overwrites whatever previous handler has already been installed there.

That whooshing sound is you trolling right on by. Think, Mr. Troll. The element is created dynamically. Just WHO do you think would have a handler on it?

The correct appropach is to use attachEvent and addEventListener.

Except that attachEvent is an IE quirk, and addEventListener is not supported by IE despite the DOM 2 Event Standard having existed for quite a long while now.

But wait! You're TROLLING! Why bother with little details like alternate implementations?

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Compatibility with non-CSS user-agents is a design principle of CSS.

Backward compatibility is a design principle, not the primary purpose. CSS enhances the document presentation so that the document can render in alternate environments. This is in direct opposition to the HTML concept, which was designed only for screen usage. For example, you're ignoring this entire section from your link:

Accessibility. Several CSS features will make the Web more accessible to users with disabilities:

* Properties to control font appearance allow authors to eliminate inaccessible bit-mapped text images.
* Positioning properties allow authors to eliminate mark-up tricks (e.g., invisible images) to force layout.
* The semantics of !important rules mean that users with particular presentation requirements can override the author's style sheets.
* The 'inherit' value for all properties improves cascading generality and allows for easier and more consistent style tuning.
* Improved media support, including media groups and the braille, embossed, and tty media types, will allow users and authors to tailor pages to those devices.

Not to mention the section on device independence!

Vendor, platform, and device independence. Style sheets enable documents to remain vendor, platform, and device independent. Style sheets themselves are also vendor and platform independent, but CSS 2.1 allows you to target a style sheet for a group of devices (e.g., printers).

But you go right on trolling, Mr. Troll. You seem to enjoy it SOOOOOOO much.

You've just blown a lot of hot air and called me names. Who's the real troll?

I've called you a troll. Which you are. Why? Because you initiated an uncalled for attack, ignored the complexities of the issues, picked at nits, carried a holier-than-thou arrogant attitude, made sure your post was content free, and now just tried to call me a troll. (To you folks back home, pay attention. Trolls will often accuse you of trolling in an attempt to remove the spotlight from themselves. Don't fall for this utterly stupid ruse!)

Enjoy your trolling day, Mr. Troll. Oh, and don't let the door hit you on the way out. :-)

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Re:Not really new, but interesting

[Anonymous Coward]

Yet, people wear their xhtml compliant gif's like medals of honor.

Gifs? Hah. Who uses those?

Any standards conscious person uses PNG, of course.

Re:Not really new, but interesting

[falconwolf]

We need more people like you who go "Screw the rest, we'll code to standards and if it doesn't work then tough". The standards are there to be used as such, and if a browser doesn't play along with the standards then it's safe to be ignored.

I wish this were true but if your website is in ecommerce when you exclude visiters you exclude possible sales. The same if you provide content you what disemminated as much as possible.

Falcon

Re:Not really new, but interesting

[jZnat]

I myself tend to make all my webpages compliant and in such a way that if you were to view the site on a text browser, cell phone, PDA, or whatnot, you'd still be able to see all the content cleanly without affecting the overall presentation of the site. Not only is valid XHTML important, but so is writing it in a logical way. That way, you can write your page nicely in XHTML, apply a stylesheet, and the final product looks great on both GUI and non-GUI web browsers.

I also avoid JavaScript completely (unless I'm designing a web-app that uses it a la Google's usually do, but in those cases, I like to screw around with XUL at the same time) because I just find that it adds no particular value to most sites. Do I really need JavaScript to click a fucking picture in order to see the full-sized version (fapomatic, I'm looking at you)? The "a" tag was invented for that reason, dipshits! JavaScript has generally been the backbone for spawning ads or fixing browser quirks that are only caused by the fact that the site was written using FrontPage and gobs of JPEGs (those of which would be better off as PNG or even GIF) with things that might seem cool at the time but actually aren't. I even have No-Script installed to avoid enabling JavaScript for at least 99% of the sites out there.

Also, I'd like to mention how CSS3 adds on almost any "cool effect" you get from JavaScript hacks in a small snippet of code. Examples include 'border-radius', 'text-shadow', and a lot of pseudo-classes such as :nth-child().

Love the W3C; don't fight them.

Re:Not really new, but interesting

[hojitas]

uh.. i really don't have the numbers at hand but.. i would bet the majority of pc/internet users are sighted. of course you can say otherwise. but that would mean there's a *major* conspiracy around, as most infotechnology devices are designed and built for sighted persons. so in the end, all you retro-cannot-go-beyond-txt leet users can blame the big man for flash and feel good about yourselves. i use flash for some stuff and i like it. especially now there's open-source tools to develop with. but for you i guess the free software foundation has been possessed by the man also, supporting the gplflash project. the devil is just anywhere. i for one applaud progress and new media and am also thankfull that retro-yada-yada people like you are a minority (again, sadly, i don't have the numbers to back me up).

Re:Not really new, but interesting

[CrackHappy]

And what about all of us who write the:
HTML
CSS
JS
XSLT
ASP
SQL
COM+

from end-to-end - what the hell are we? :)

Re:Not really new, but interesting

[Anonymous Coward]

Anybody who preaches 100% standards compliance hasn't actually written a real world website.

Er, what? It's certainly possible, trivial in fact, to develop a "real world" website while adhering to standards. The main reason why people don't is through ignorance, not because conformance is particularly difficult.

Re:Not really new, but interesting

[falconwolf]

Please STFU. I doubt you've ever made a single website or written a single line of javascript code. Otherwise, you would know that "standards-compliant" just means that it doesn't work correctly in any browser, since no browsers are 100% standards-compliant.

There are work arounds that you can validate for. When I took classes in html, xhtml, and javascript our code had to be valid, we were supposed to validate our pages with CSE HTML Validater and in xml we used XMLSpy . We even were supposed to have valid code when I took Dreamweaver.

Falcon

Re:Not really new, but interesting

[Shaper_pmp]

Yeah. I was going to perjoratively leave it at the other three, but then I remembered some of the piles of festering crap that have been uploaded to our web server in the past, while I knelt in the background crying and beating my head against the desk.

Seriously - what is it with managers who hire you to be "the expert" in something, then refuse to listen to your advice on scheduling?

Re:Not really new, but interesting

[Paradox]

Maybe it's because they're not really developers? They like to pretend they are, but they're not.

Some of the most talented developers I know work heavily with web applications. Are they any less programmers because you're suffering from reverse domain envy?

Writing javascript no more makes them developers than writing shell scripts would. And of course, HTML and CSS are *NOT* programming languages!

Would it shock you to know that, on the spectrum of languages, Javascript is actually much closer to Smalltalk, Ruby, Lisp and OCaml than Java is? Javascript is a fully Object Oriented language, complete with anonymous functions and a prototype-based class system that is extremely powerful?

And XHTML is just XML by another name. Get over yourself.

Would it hurt you if I told you that it's probably a better language design than C++ and Java? Imagine what a developer like you and I has to go through migrating a C++ project from GCC2.95 to GCC3. Now do that every day just to make things work.

Some of them may be graphic design weefles, but not all. Web engineers deserve respect, be they EJB Machines or Rails Honchos.

Real developers test their code. Web "developers" do not. At best they'll make sure their pages work with Internet Explorer and Firefox. As if those are the only two browsers in the world. Test on last years Firefox? Hah! Don't make me laugh!

I assume you mean the HTML, CSS and JavaScript? Because the backends are usually tested very well. Java stacks and Rails have great unit test support.

It's unfair to compare the two. How exactly do you test a page layout? It's easy when I work on C++. I unit test things that have easily controllable inputs, easily recognizable outputs, and work in only one environment.

How the hell are you supposed to automate testing of HTML layouts? What heuristic makes a 1px border okay in some places, but not others? And if you can't automate the testing, then it costs A Lot of Money. When I do web consulting, I ask the customer what They Want To Pay for, and adhere to that.

The people working on the back end database and CGI interfaces might be developers, but those who write the HTML/CSS are not. Yes, there are some exception, but that only validates the rule.

Who can afford to have a separate web designer anymore?

But thanks for making arbitrary decisions on who and who is not a programmer. I'm sure loads of people appreciate it. Like the people who worked in Python in the 90s who weren't "real" programmers because they worked in a "scripting language."

Re:Not really new, but interesting

[Anonymous Coward]

ouch, no kidding

Re:Not really new, but interesting

[Brandybuck]

I don't know, what are you? Your list doesn't include any programming languages. Javascript is close, but surely you can do better. Even Visual Basic qualifies. XSLT does not.

But I will admit you're much much closer to being a developer than the average "ooh it has flash!" front end guys.

Re:Not really new, but interesting

[ubernostrum]

Anyone else find it amusing that these "purist" people haven't even read the official specification?

Those "purists" actually have read the specification, and then they've gone on to read the Note on Media Types which upgrades the lower-case "may" in the XHTML 1.0 spec to an upper-case RFC2119 "MAY" in the case of "compatible" XHTML 1.0 and adds a "SHOULD NOT" for any other XHTML. Of course, that "compatibility" is imposed by fiat, not by any actual compatibility of the XHTML and SGML-based HTML syntaxes. There are actually some important incompatibilities even if all the guidelines in Appendix C of the XHTML 1.0 spec are followed. But I'm sure a "purist" like yourself has read up on that, right?

And I'm not just talking about problems with XHTML's minimized tag syntax conflicting with SGML's SHORTTAG. For an example, consider the example of point 1 in the HTML Compatibility Guidelines. It says, in part:

Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.

Sounds nice, but it's wrong and can actually lead to well-formedness errors which will be detected by strict XML parsers. This is because any text/* media type, when sent with an HTTP Content-Type header which did not include the charset parameter, is defined as being encoded in US-ASCII. So if you write your XHTML in UTF-8 or UTF-16, and follow the recommendation to leave out the XML declaration, then you should expect to see well-formedness errors related to the character encoding of the document. Whoops. For added fun, note that this problem crops up when you send text/xml, too; the only way you can guarantee an assumption of UTF-8 or UTF-16 by the parser is to use application/xml or application/xhtml+xml, because then RFC 3023 will mandate those to be the default encodings.

Re:Not really new, but interesting

[Anonymous Coward]

... I will visit your competitors and see if they will.

That's what all my users say, smugly with a smile, as I'm sure you had. Then they have a fit when I tell them "Well, that's fine and good, but our intranet doesn't have any competitors."

Re:Not really new, but interesting

[Shaper_pmp]

Maybe you didn't read my post(s) carefully enough. Using standards-complient code doesn't mean you have to use every bit of markup, and that every element has to work perfectly in every browser. It means writing code that doesn't contravene the standards. IE, no proprietary HTML tags/CSS markup, every page validates, scripts don't cause errors in other browsers, etc, etc. It's not hard.

With absolutely standard HTML/CSS you can do about 95% of everything you'll ever need. For the other 5% there's CSS browser hacks or javascript workarounds (eg, onmouseover instead of :hover CSS rules).

Javascript presents more of a problem (due to differing DOMs), but a simple bit of DOM sniffing (not browser-sniffing) and sensible code-design means that every browser should either (a) support the advanced behaviour or (b) fail silently but usably.

This is not a position held in ignorance - I've been developing for the web since about 1994, and since the advent of XHTML/semantic markup/CSS 2.x/javascript 1.x I've never had a problem doing anything in standards-compliant ways.

That includes converting a site from presentational tables-based HTML 4.? (they didn't even know themselves) produced in Frontpage to one hand-coded in XHTML Strict 1.0/CSS 2.1/Javascript 1.5. In the end (as requested) it was pixel-perfect in IE, and had some small (<10 pixel) margin differences in Firefox/Opera.

Again, and sorry to sound insulting, but if you think standards-compliance can't be done you're either disagreeing with my definition of standards-compliance or just not experienced enough at web development.

Re:Not really new, but interesting

[Brandybuck]

And XHTML is just XML by another name.

XML is not a programming language, so I fail to grasp your point. Markup languages (the "ML" in "XML") are not programming languages. I know people who can't tell the difference between integers and floating points but are able to write valid XHTML pages by hand.

Would it hurt you if I told you that it's probably a better language design than C++ and Java?

What? XML? Puh-leaze!

In case you were meaning "javascript", then it's possible you may be correct. But that's still irrelevant to a webpage, because the javascript there is 90% snippets stuck in the middle of markup. I can count on one hand the number of times I've seen a complete real world application written in javascript.

Imagine what a developer like you and I has to go through migrating a C++ project from GCC2.95 to GCC3.

Actually, that migration took me all of thirty seconds. If you have correct code for 2.95 it will build without problem on 3.x. The hard part is migrating 3.x code to 2.95. But even there if you use a subset of C++ you're still not going to run into problems.

If you're writing for Internet Explorer, then OF COURSE it won't work with Firefox, Safari or Opera! That's because you're not writing with a proper subset of the standard. You can't use the full standard, because not everyone supports it, but you can write to a subset of the standard and have everyone support it. You might not be able to do flash-happy pages this way, but that won't stop you from delivering actual usable content.

I assume you mean the HTML, CSS and JavaScript?

No, I mean testing as in "it's been tested on the browser I use". All too many of you web developers think that if you've tested on Internet Explorer then you're done. A few of your more enlightened peers will even test on Firefox. But hardly any of you test on Opera, Safari, Konqueror, any of the various PDA/phone browers, Lynx, Links, etc.

How the hell are you supposed to automate testing of HTML layouts?

You can't. But don't use that as an excuse to do no testing at all. Roll up your sleeves and test it your damned self!

Re:Not really new, but interesting

[Shaper_pmp]

Flawed analogy. One person browsing the web doesn't inconvenience another in any way, unless they DoS the server (which was rather out of the scope of the discussion).

Writing a page in standards-compliant code doesn't inconvenience the IE browser at all, it just allows everyone to use it.

A better analogy would be making the entrance road extra-wide, in case anyone wanted to come down in a horse-buggy (or tank, or whatever). This doesn't inconvenience normal car drivers, and while it may take a tiny fraction more land (to accommodate the wider road), the first time someone comes driving through your drive-in in a tank and buys thousands of dollars-worth of burgers you otherwise wouldn't have sold, it's worth it.

Not to mention the fact that other architects will respect you more for producing such an accessible design, and you'll have that lovely warm glow of knowing you've done your bit to keep road-width-standards open and non-proprietary... (to stretch the metaphor to breaking-point).

Re:Not really new, but interesting

[ubernostrum]

Too bad you really don't know what your talking about, you're obviously not a real world web developer or a business owner. Read on.

Too bad you're apparently not a real-world developer either. Or someone who understands the English language. Read on.

If I spend time making sure the app works on a cell phone when it does not need to (because my clients do not want that feature) then i am alienating them when I do make it work, because there are higher priority feature sets they want.

So the client knows more about development than you do? That's reassuring. Here's a hint: clients are stupid and often don't have the faintest clue who their target audience is or what that audience will expect. Your responsibility, then, is not to blindly implement whatever the client dictates, but rather to determine what best suits the client's stated goals and develop to that. If providing an accessible site or application will better accomplish the client's goals (and it almost invariably will), then your responsibility as a professional is to get the client to understand that, and then implement the accessible solution.

Time is not unlimited, resources are not expendable. I have the manpower to cater to my clients needs. That is all. Not add features for 1% of the population to enjoy from their cellphone.

So in other words, implementing a site in a way which renders well in all modern graphical browsers, in text browsers, on cell phones, on PDAs, in screen readers and on devices which have not yet been invented is not worth your time. Because that's only like one percent of the population, right? Wrong. By developing a clean site structure in semantic HTML, styling it with CSS and adding behavior with JavaScript which uses the W3C DOM, you can do just that. So don't give me any BS about "I don't have time to support it", because the same methods which are the foundation of compatible design for modern web browsers are also the foundation of device-independent accessibility.

Re:Not really new, but interesting

[ubernostrum]

I mean, that's like saying people who don't have Flash installed aren't "good enough" to look at my site (actually, I don't use flash... not the point). If I don't have a working nose, can I sue perfume makers for not catering to my special needs?

Think of another common accessibility issue: blind users and images. Blind users can't see images, of course, but HTML provides "alt" and "longdesc" as a way of providing a textual equivalent (and accessibility guidelines mandate their use). Similarly, in the case of Flash HTML provides the "object" element which has the ability to fall back to alternative content nested within it.

So the only excuse for not providing content which is accessible regardless of the user's abilities or installed plugins is ignorance.

Re:Not really new, but interesting

[Shaper_pmp]

Fair play. Even in the case of IE bugs, you can generally code around them with either the odd CSS hack or some creative javascript.

When I say standards-compliant code, I mean "validating where possible and not causing errors in other browsers" - there's nothing dangerous (IMO) about javascript code like:

var theelement;
...
if(document.getElementById)
theelement = document.getElementById("results");
else if(document.all)
theelement = document.all["results"];
...

Ok, that code might actually cause errors (I haven't got any tested examples to hand to cut-and-paste from), but you get the idea - document.all (IIRC) isn't according to the W3C DOM, but since the script tries to do it the W3C way first (and the non-W3C bit is wrapped in a DOM-detection if statement), it's standards-compliant.

I always find that retrofitting the (standards-working) site to work with IE generally consists of a small number of additional if() statements (like above) in a few low-level functions (generally getters and setters), and some creative CSS hackery to sort out the presentation.

Re:Not really new, but interesting

[jonzawada]

A) It would be nice if one day developers would realise that communication is not always words. B) You can't tell people what to want or like and how they should like it. C) A developer building a website is often just as inappropriate as a graphic designer building one. There is a whole world of graphic design concepts, branding concepts and advertising ideals out there which have existed for decades before the internet and they are defended with just as much zealousness but unfortunately they are totally ignored and construed as insignificant or unimportant by the online development community, who often see communication as a stark, soulless and mechanical activity.

Re:Not really new, but interesting

[ubernostrum]

If Mozilla and IE know what elem.innerHTML is and can render it, why can a screenreader not work like a real goddamned web browser?

Actually, one of the biggest real-world problems with screen readers is that some of them (I won't name names, but they know who they are) just use IE to render the page, and then read it out loud. So if you spent a lot of time on, say, carefully putting your columns in order in the page source so that the navigation came last, well, that screenreader may move it back to being first because that's how it renders visually. At least one screen reader (Jaws) does notify the user of JavaScript-driven events which change the page, but that's sketchy at best.

In any event, there is a strong mindset in the screen-reader development community that a proper screen reader should mimic a visual browser as closely as possible; but of course that's about the worst possible way to think if you want to design something visually-impaired people can use. See Eris Meyer's "Don't Read; Speak!" for more on that. Who knows? Maybe someday screen readers will even support the CSS media type that was defined just for them...

If we can pass the user around the page like that, why not include more dynamic pieces in the page and present a non-visible menu for blind people? "Press 1 for My Profile, Press 1 for ... blah blah blah". As they press a button, *javascript and dhtml* take them around the page, reading more parts of the menu.

So... apparently you think access keys don't exist (they do, and screen readers will pick up on them; to be extra safe you can add an accessibility statement which outlines your site's accesskeys and how they can be used for navigation. Several groups have also published recommendations for "standard" sets of accesskeys to accomplish common tasks), and you think the only way to navigate to different parts of the same page is with JavaScript (apparently you're unfamiliar with that "anchor" concept that's only been around since about the beginning of the Web)? Perhaps you should read more about this stuff, since you apparently try to do it for a living.

Re:Not really new, but interesting

[ubernostrum]

Gmail doesn't degrade well at all, but it offers a non-JavaScript-dependent version.

Re:Not really new, but interesting

[Anonymous Brave Guy]

If your company will not provide this ability to me, I will visit your competitors and see if they will.

<shrug>

Some customers are more trouble than they're worth. That's not derogatory, it's simply a statement of business fact.

Re:Not really new, but interesting

[Paradox]

In case you were meaning "javascript", then it's possible you may be correct. But that's still irrelevant to a webpage, because the javascript there is 90% snippets stuck in the middle of markup. I can count on one hand the number of times I've seen a complete real world application written in javascript.

Google Maps, GMail and many Rails sites beg to differ.

Actually, that migration took me all of thirty seconds. If you have correct code for 2.95 it will build without problem on 3.x. The hard part is migrating 3.x code to 2.95. But even there if you use a subset of C++ you're still not going to run into problems.

Err, uh.. GCC2.95 let you get away with a lot of stuff that GCC3 called you on. Same with GCC3->4. Anyone with a large legacy codebase felt what our shop felt.

... That's because you're not writing with a proper subset of the standard. You can't use the full standard, because not everyone supports it, but you can write to a subset of the standard and have everyone support it.

Err... umm... how does this relate to your point that web developers are not real developers? If anything, you're defending them. Who decided what "proper subset" is correct? How do you even know? Many bugs only appear when combined with others. And the worst part is the muderously inconsisten rendering of IE. I've seen people with nearly identical XP machines, but script.aculo.us crashed IE on one, but worked fine on the other.

You might not be able to do flash-happy pages this way, but that won't stop you from delivering actual usable content.

Since when has "content" been the primary goal of modern web development? It cracks me up when people talk this way. Look, we all can deliver content. It's easy. The hard part is delivering web applications. If you want to buy and sell things online, you're in for a whole new ballgame.

No, I mean testing as in "it's been tested on the browser I use". All too many of you web developers think that if you've tested on Internet Explorer then you're done.

First, I develop C++ apps for Linux by day. Web Development is a sidejob. And second, since most web work is done by consultants, we give our clients what they paid for. I'd strenuously object when someone says, "We only want IE support." It's just bad practice. But at the end of the day, it's their money to spend.

A few of your more enlightened peers will even test on Firefox. But hardly any of you test on Opera, Safari, Konqueror, any of the various PDA/phone browers, Lynx, Links, etc.

Firefox, IE6 and Safari are the base targets these days. Most everyone tests on these (IE or Safari may be left out depending on the machine bias of the shop or consultant). Heck, I even snuck in a check with Konqueror.

But no one is going to test for PDA and phones unless they're an important target. That cruft accumulates and washes away with the regularity of the tides. Everyone has different firmware versions. Clients don't care about them. Why should they? Why should I test on a PDA or Cellphone that won't even react the same way in 3 months? Or that will be old news and replaced in 6? My fallback plan is plain-jane HTML, no frills. If you don't like the look of it, get on a real web browser and stop complaining.

Or if you want to bitch at someone, bitch at your firmware vendor for making a browser that deviates so far from the standard that it's impossible to target reasonably.

To me, your stance is every bit as stupid and smallminded as the stance of folks who ridiculed perl hackers back in the mid-ninties for "not being real programmers." Those folks built the foundation of IT and the Web as we know it, all the while being made fun of by smug, self-satisfied people with your attitude.

Re:Not really new, but interesting

[Diabolus777]

just check the time difference it takes between the two developments.

Re:Not really new, but interesting

[accessdeniednsp]

Gen Y is the 'gimme' generation. Spoiled brat bitches who've had everything handed to them, and STILL don't care.

I know many 'solid Gen Y' people. They scare me.

(then again, Gen X scares the boomers. and the boomers scared the pants off the WW II crowd.)

Yet we still move on somehow. Freaky. But they still scare me.

Re:Not really new, but interesting

[lav-chan]

Google Maps, GMail and many Rails sites beg to differ.

How many hands did it take you to count those?

Re:Not really new, but interesting

[Artega VH]

What the fuck do you think ASP is? Okay sure its a pile of junk (unless he means .NET which he probably doesnt). But get over yourself.

Re:Not really new, but interesting

[CrackHappy]

That raises a question for me - what does qualify as a programming language per se? Does it have to be compiled, or have a certain syntax, or what? Does that mean Perl isn't a programming language?

And I erroneously left VB, C# and Perl out of my list - what a dipshit I am sometimes. :)

Re:Not really new, but interesting

[Anonymous Coward]

depends on how many rails sites, doesn't it?

Re:Not really new, but interesting

[Anonymous Coward]

Elements are nodes in the document tree.

Exactly what I said. Thank you for agreeing with me, Mr. Troll.

No. You said:

"Element" is a generic term for all objects that can be in the document structure.

This is not the same thing as "elements are nodes in the document tree". There's a big difference between "nodes in the document tree" and "objects in the document structure". "All objects that can be in the document structure" include attributes, which are not elements. I even gave that as an example, which you ignored in favour of repeating your point and misrepresenting me as agreeing with you. You also said:

"Tag" is a more specific type of element.

Which is so bone-headed I can't even imagine where you got the idea. Here's some HTML:

<table>
<tr>
<td>Foo</td>
</tr>
</table>

Count the tags. Count the elements.

There are six tags - an opening table tag, an opening tr tag, an opening td tag, and the closing tags that match them.

There are four elements. A table element, a tbody element, a tr element and a td element.

Elements are part of the document structure. Tags are part of the syntax that describes the structure. By confusing tags and elements, you are muddling up two different ideas - syntax and structure.

If tags are a specific type of element, then please explain how it is that there are more tags than elements in the example I gave.

Please, read the HTML specification's explanation of how elements, element types and tags relate to each other. You might find it informative yet embarrassing.

The element is created dynamically. Just WHO do you think would have a handler on it?

You ignored my pre-emptive answer to that. Feel free to go back and read it.

Except that attachEvent is an IE quirk, and addEventListener is not supported by IE

Learn the meaning of the word "and". Or look up Scott Andrew's generic addEvent script.

Backward compatibility is a design principle, not the primary purpose.

See that's funny, because you stated that non-CSS user-agents are "deprecated" (not mentioning by who exactly). The fact that the publishers of the CSS specification take pains in pointing out that non-CSS user-agents should be catered for in multiple places kinda blows that claim out of the water, wouldn't you say?

This is in direct opposition to the HTML concept, which was designed only for screen usage.

"It is required that HTML be a common language between all platforms. This implies no device-specific markup..." That's a quote from the very first HTML specification. If it was designed for screen-only, how come the very specification says that it's intended to be device-independent?

For example, you're ignoring this entire section from your link

WTF are you talking about? It has no bearing on the current discussion, which is why I didn't call attention to it. It certainly doesn't contradict me - where did I say that CSS wasn't device independent?

I've called you a troll. Which you are. Why? Because you initiated an uncalled for attack,

I was correcting you because you clearly don't know what you are talking about.

ignored the complexities of the issues,

Actually, it's you that is completely *unaware* of the complexities of the issues. It's quite obvious to anybody with a grounding in SGML that you are simply making shit up as you go along.

Come on. Admit it. Be the bigger man. You assumed I was just a troll so you misrepresented your uninformed speculation as the truth to shut me up, and now you've been caught with your

Re:Not really new, but interesting

[Brandybuck]

Google Maps, GMail and many Rails sites beg to differ.

Those are the exceptions. How many sites are comparable to those three? Not very many. And STILL Google Maps and GMail don't support my browser!

Err, uh.. GCC2.95 let you get away with a lot of stuff that GCC3 called you on. Same with GCC3->4. Anyone with a large legacy codebase felt what our shop felt.

In the grand scheme of things, gcc 2.95 is still a youngster. The word "legacy" is a misnomer. I know what you're trying to say, but it doesn't wash. "Getting away with a lot of stuff" is the fault of the programmer not the compiler. I helped port a million+ line code base from gcc 2.7 to 2.9 (not 2.95) not that long ago, and it only took about one man week to do, with only two bugs founds in SQA linked to the migration.

In other words, if you're experiencing pain migrating from 2.95 to 3.x, you're doing something wrong.

I'd strenuously object when someone says, "We only want IE support." It's just bad practice. But at the end of the day, it's their money to spend.

I keep hearing stories like this, but it still boggles my mind. Even though my current project is specified for Solaris, for example, I STILL keep it portable to other platforms. Are your customers *really* going to hold up payment because the site works in Firefox? Really? Don't mistake a non-requirement as a negative requirement.

Heck, I even snuck in a check with Konqueror.

Even if you're in a Windows-only shop, a Knoppix or Kubuntu live CD is free-as-in-beer-and-pretzels! There's no excuse not to test on Konqueror. In fact, because Konqueror does not code in workarounds for bad html, you'll actually find more bugs testing under Konqueror than under other browsers. Pop in the Kubuntu CD, reboot, and start testing!

There are no excuses for not testing under IE, FF, NS, Safari, Opera and Konqueror.

To me, your stance is every bit as stupid and smallminded as the stance of folks who ridiculed perl hackers back in the mid-ninties for "not being real programmers."

Actually, most perl hackers back in the early nineties weren't "real" programmers. Back then perl was treated as just a fancy awk. It took a while for them to figure out that perl was a real full blown language that they could do real stuff with. I have to maintain some of that early perl code, and most of it is just plain nasty. Whenever I get the chance I recode most of it in plain vanilla sh because that's all that was really needed. ...smug, self-satisfied people with your attitude.

As a Konqueror user, every day I encounter several sites that have the moral equivalent of "fuck you for not using internet explorer." If you want me to drop the attitude, stop calling those people "developers". If I did as a software developer what they did as web developers, I would be fired.

Re:Not really new, but interesting

[Paradox]

Not very many. And STILL Google Maps and GMail don't support my browser!

It's not like someone is forcing you to not upgrade. It's not even like they could reasonably downgrade to make Konqueror work, it just doesn't support everything that they require to work at a basic level. This is tantamount to complaining that Doom3 doesn't run on your Amiga. Duh! It's not like upgrading costs any money.

How does your choice of minority browser make Web Developers any less programmers? It's not their fault they have a quadzillion target platforms. Something has to give, and targets like the Zaurus or Konqueror are first to go.

In other words, if you're experiencing pain migrating from 2.95 to 3.x, you're doing something wrong.

My original analogy, which I expressed poorly, was that it's like going back and forth between the two. But the "wrong thing" in our case was having a legacy codebase written by a crappy subcontractor (yay politics!).

Making websites layout properly is harder than unit testing many kinds of conventional software in most cases. It cannot be automated, it tends to be very sketchy, targets change frequently, and the fixes for some tools breaks others. The "proper subset" of features that you mentioned earlier is a massive step backwards for the web, back to old HTML4. I don't think anyone wants that.

There are no excuses for not testing under IE, FF, NS, Safari, Opera and Konqueror.

Many people you're calling 'programmers' don't even unit test. I think that it's unethical to try and even sell a product written in C++ that doesn't have at least a minimal-requirement checking unit test suite. Hell, I won't even publish open source work without one!

If your argument is, "People who don't test don't deserve to be called programmers." then I'm with you, sure. Testing is important. But that's not what you said. You said "Web Developers" are not programmers. It's an uninformed, biased, incorrect stereotype that harkens back to the old "scripting language" silliness.

Actually, most perl hackers back in the early nineties weren't "real" programmers. Back then perl was treated as just a fancy awk.

I said mid-ninties. By 1996, people were catching on to what Perl was and how important it was.

As a Konqueror user, every day I encounter several sites that have the moral equivalent of "fuck you for not using internet explorer.".

Actually it's more like, "Fuck you for not using Firefox. It's free, it's fine. What the fuck is your problem?"

No one is forcing you to use Konqueror. You can sit here and praise it to the skies, but the simple truth is that it's feature poor, and you know it. If Google could support Konqueror, you know they would, and they'd crow about it. It'd score big points with the Slashdot crowd. But they can't.

If you want me to drop the attitude, stop calling those people "developers".If I did as a software developer what they did as web developers, I would be fired.

You realize that carpenters say something similar about software developers too, right?

Our job is easy. Support a few platforms. You're probably only writing with one GUI toolkit. Maybe a few font rendering errors or layout errors with the GUI. One two three binary targets for most projects. Maybe 5 if you're really streching for legacy hardware.

Application & System Development is older, and has more refined tools. We also have to worry less about how things "look" under the covers. A good webapp not only has to be fast, scalable, multi-platform and bug-free... it has to be pretty as well.

They're developers. Some of them suck, some of them are good. Like our field, it's chok full of people who suck. We have Java-Wageslaves, they have PHP-teens. We have Alan Cox, they have Eric Meyer. It all works out.

Re:Not really new, but interesting

[It'sYerMam]

You need to evaluate which ones carefully. As PDAs become more prevalent, a larger subset of customers will require access to websites with said device. If you ignore them, you'll lose revenue and at some point, it will be more than it would've cost to "port" the site.
Do it early and lose less money :)

Re:Not really new, but interesting

[Anonymous Coward]

it took him all of two minutes to (a) download, install and run Firefox

don't forget about portable firefox (I'm a lazy AC, so google it) : )

Re:Not really new, but interesting

[Brandybuck]

When Firefox is fully and completely integrated into my desktop, I'll upgrade to it. Until then using it is a downgrade.

There may be features Google Maps needs that Konqueror doesn't have, but it's a huge stretch to say the same about GMail or Blogger. Sheesh, if you can make it work in ancient Internet Exploders, you can make it work in Konqueror and Safari!

Google has rejected me as a customer, so I feel justified in rejecting them as a vendor. I won't apologize about it either. Make a chipset that won't work on the number two Linux distro and you'll never hear the end of it, but write website that won't display on the number two Linux browser and you get praised for your business acumen. Go figure.

Re:Not really new, but interesting

[Anonymous Coward]

I decided to use flash because its easy to integrate and modify the layout and I DONT HAVE TO MAKE A VERSION OF MY SITE FOR EACH BROWSER.

It is possible to design a page in HTML/CSS that works properly with every browser. That you are incapable of doing so is a testament to your incompetency, bravo!

I second that. I make sites like that all the time. Learn XHTML, CSS, Javascript and some design and User Interface basics, principles of graceful degradation and verify that your site is still accessible using lynx.
Yes, lynx - I've made several eye-popping bling bling sites that degrade gracefully and are perfectly accessible in lynx and w3m.
I write the code by hand and use either a dynamic system to generate it on the fly or a templating system for static sites.
The "I can only do this for IE 12.2" crowd are a bunch of lame-ass GUI tool wizard idiots. I don't even do this professionally (well, not as part of my full time job - it's a nice way to supplement my income.. :) and my sites are rock solid. Not just the backwards compatibility, but decently future-proof *and* they're optimized for search spider access.
Using flash violates so many principles of design, and elements of human computer interface basics that I don't even know where to begin.
Oh, and while we're at it - if you're a professional web designer and your site makes validator.w3.org puke - YOU SUCK ASS! It shows that you don't know what the hell you're doing and are probably using autogenerated HTML shite splattered over other people's poorly ripped CSS.

Re:Not really new, but interesting

[Paradox]

When Firefox is fully and completely integrated into my desktop, I'll upgrade to it. Until then using it is a downgrade.

Funny. My desktop environment integrates with any browser. You seem to have a collection of me-too feature-poor software. Which is not to say that KDE isn't getting there, but it's telling that you still have to use Konqueror.

but it's a huge stretch to say the same about GMail or Blogger. Sheesh, if you can make it work in ancient Internet Exploders, you can make it work in Konqueror and Safari!

It does work in Safari. That's the sad part. XMLHttpRequest() is important, and Konqueror's implementation is different enough that it doesn't work. Sorry, that's where the buck stops.

Google has rejected me as a customer, so I feel justified in rejecting them as a vendor. I won't apologize about it either. Make a chipset that won't work on the number two Linux distro and you'll never hear the end of it, but write website that won't display on the number two Linux browser and you get praised for your business acumen. Go figure.

Difference being, you can change to a compliant browser for free!. You claim it'd be a downgrade, but obvious the marginally better desktop integration with your feature-poor desktop environment is worth more to you than compatibility with these products.

Google hasn't rejected you as a customer. They never gave you a bill to begin with. For you to have the nerve that they come beat down your door to give you a free product is telling about your personality.

You are in the fringe of the desktop world, and it's not the leading edge. It is the Free Edge, and you're going to pay a price for it. When I ran Linux as my primary, I had to give up things too, like playing movies.

I got fed up. Maybe you'll come to the same conclusion, eventually.

Re:Not really new, but interesting

[ahdeoz]

20 years ago those flash animations you dismiss took the very best programmers to write, in assembly, for the Atari 800. 15 years ago, those GUI controls you're so proud of being able to hand-code took a genius to keep track of their APIs. 10 years ago, centering a button becaome as simple as typing:

And it's gotten a little easier than that. I'm thinking you're just feeling your obsolescence because HTML WYSIWYG editors are getting as good as your C++ GUI builder that you think separates you from the flash animator.

Re:Not really new, but interesting

[ahdeoz]

Tell me you've coded to standards when you write a proper test suite for the standard. I'll bet your life that you didn't understand the standard AND that you didn't code to the standard as you thought you understood it.

What was that? You don't have a working implementation that implements the standards completely and correctly?

It's awfully easy to claim you code to a standard you can't test against.

Re:Not really new, but interesting

[Pete]

Erm... first of all, you don't have my life to bet :).

Second, there is this thing known as the W3C validator... and last I checked, it seemed to think that my HTML was valid XHTML 1.0 Strict and my CSS was fine.

Third... well, it runs as it should on Gecko/Spidermonkey, which has a reputation as a fairly standards-compliant browser (albeit a bit permissive in some areas).

If it makes you happy, I'll acknowledge that it's a little difficult to be absolutely sure that the DOM interaction with Javascript is correct and standards-compliant. And I'll be a lot happier when I can get it to work on at least one other renderer+javascript implementation.

What was that? You don't have a working implementation that implements the standards completely and correctly?

Surprisingly enough, no, I don't have my own superstrict web browser to test on. I considered doing that, but thought it might be just a bit too much work. :)

Re:Not really new, but interesting

[Brandybuck]

Funny. My desktop environment integrates with any browser.

And what desktop is that? It sure as hell can't be Windows. Because I have to use Windows at work, and Firefox does NOT integrate with it. At least not in the manner Konqueror does.

Is there something wrong with having a choice of browsers? It doesn't matter what ftp client I use to access an ftp site. Except for some Microsoft-only mail servers, it doesn't matter which email client I use to get my email. Do I need to worry about which news reader I use to access usenet? No! But when it comes to http, suddenly I start seeing "Best Viewed With Another Browser" buttons. As if they're somehow proud of it. Stupid.

XMLHttpRequest() is important

The XMLHttpRequest isn't a web standard. To quote w3c: "The XMLHttpRequest object is not a W3C standard."

Google hasn't rejected you as a customer.

I'm not talking about google, I'm talking about those sites who have a product to sell but which require specific browsers. I don't have this problem with Amazon or any of the other major retailers. But I find it every so often with the same guys. Like yesterday trying to buy a piece of software from this guy, where the "checkout now" button wasn't even a link. Did I need flash loaded? Was he trying to do something too fancy in javascript? I have no idea, and I wasn't about to read through the page source to find out. I simply left instead.

And before you blame Konqueror on this, I was using Firefox at the time.

It is the Free Edge, and you're going to pay a price for it.

I know I pay a price for it. If I didn't want to pay the price then I would be just another good little sheep with Windows and Internet Explorer eating McDonalds hamburgers and laughing at Friends episodes and listening to Britney Spears. The price to be a clone is oh so small...

But that has nothing whatsoever to do with the fact that most front end web "developers" aren't "developers". Consider the guy I mentioned above. Why should I have expected his shareware program to be in any way worthwhile when his webpage was such crap?

When I ran Linux as my primary, I had to give up things too, like playing movies.

First, I use FreeBSD instead of Linux. Second, I have no problems playing movies, either off of DVDs, or as quicktime/mpg/rp/etc files. Even within Konqueror if I wish.

Re:Not really new, but interesting

[Anonymous Coward]

You have my total agreement. The selfish retards of this world should be rendered down into glue. Each and every one of the fuckers.

Re:Not really new, but interesting

[Shaper_pmp]

That's very true - developer-lead sites tend to be ugly but functional, graphic designer-lead sites tend to be pretty, also tend to be badly-coded (or just don't work at all) on other browsers/OSs/days.

Personally (and maybe it's a developer-webmaster thing) I'd rather have a site which was ugly but functional/navigable than one which was pretty but very obviously broken. I've always thought the most important thing was to reach your audience with your message - too many designer-lead sites fail even to do this (or just frustrate users before they have time to absorb your message - I'm looking at you, Flash-only sites).

Regardless of how pretty they'd look if they worked, they still turn users off even faster than an ugly site if/when they don't.

Of course, I'm arguing stereotypes here, but I always design sites from a functionality/navigation angle first, then pretty it up once it's working.

As I've had to explain to wannabe-web designer Directors more times than I can count, "cut the wood and nail it together before you paint the table". ;-)

Re:Not really new, but interesting

[Anonymous Coward]

I don't think the solution is to code down to the lowest common denominator, but to build up the other dumber clients of web apps.

R skools in america have bean focussin on da lowest comon denomenater four decaids. Is'nt this just da next evolooshinary steep?

Re:Not really new, but interesting

[jacksonj04]

It's pointless coding to a standard you don't understand, and even more so to claim that you've implemented it.

All my recent code validates to the doctype it declares itself as, using the W3C validator. If a browser doesn't implement it as expected, tough.

Re:Not really new, but interesting

[It'sYerMam]

Thus proving the point that flash has its uses beyond movies. Interfaces can be designed successfully in it.

Re:Not really new, but interesting

[Anonymous Coward]

Interfaces can be designed successfully in it.

That depends on what you mean by "successful". I visited that site. I got a stupid, annoying "loading" animation a bunch of times. I tried middle-clicking a link to open in a new tab. It broke. I tried right-clicking a link to select "open in new window". It broke. I tried hovering over the e-mail link to see if it was a link to a form or an email address, but that broke too. So I went ahead and clicked on it, and got a page with a few links on it. One of them is an envelope with "Email us!" on it. I assume that is the Flash equivalent to a mailto link. I keep clicking it with the left mouse button, but nothing's happening. With normal HTML, I could right-click and copy the email address to the clipboard to paste into my mail client, but I can find no way of getting the email address out of that Flash presentation.

I can't call that a successful design. It outright broke on me pretty much every time I tried to do something.

So do you have any examples of good Flash design? In other words, Flash design that doesn't break whenever you try and do anything?

Re:Not really new, but interesting

[JimDabell]

And most, if not all of those XHTML compliant buttons on websites are incorrect, since they are sending the content as text/html, which is not an XML application

text/html is not for HTML alone. It's for XHTML too. Read the RFC. It explicitly states that it is permitted to send XHTML 1.0 documents following the "compatibility profile" (Appendix C) of the XHTML 1.0 specification.

The misconception that XHTML as text/html is wrong is popular, but incorrect. It might not be a good idea for most people to serve XHTML in this way, but it's not wrong or against the specifications in any way.

Re:Not really new, but interesting

[JimDabell]

Those "purists" actually have read the specification, and then they've gone on to read the Note on Media Types

Would that be the Note that states:

Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.

However, this document is not intended to be a normative specification.

?

which upgrades the lower-case "may" in the XHTML 1.0 spec to an upper-case RFC2119 "MAY" in the case of "compatible" XHTML 1.0 and adds a "SHOULD NOT" for any other XHTML.

So presumably you know what an RFC2119 "MAY" and "SHOULD NOT" means then? It doesn't mean "you must not do this" or "this is wrong". Even if the Note was a normative specification, it still wouldn't mean that it would be wrong to transmit XHTML 1.0 documents following Appendix C as text/html.

Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.

Sounds nice, but it's wrong

No, it's not wrong, it's a requirement. It doesn't state "this is how the document will be interpreted", it states "this are the encodings you must use to conform to this specification". The onus of working out how to use those encodings while still conforming to other specifications is on the author. Just like every other specification ever published, I would imagine.

So if you write your XHTML in UTF-8 or UTF-16, and follow the recommendation to leave out the XML declaration, then you should expect to see well-formedness errors related to the character encoding of the document.

Only if you ignore the specifications that dictate the default character encoding for text/* media. XHTML 1.0 doesn't say that following Appendix C automatically makes you conform to all relevant specifications; that responsibility has always been the publisher's. And the publisher who knows what he's doing will understand that the default character encoding isn't what he wants and will select UTF-8 or UTF-16.

the only way you can guarantee an assumption of UTF-8 or UTF-16 by the parser is to use application/xml or application/xhtml+xml

No, you can use the charset parameter to the text/html media type. In fact, that's the most common way of doing it.

Re:Not really new, but interesting

[JimDabell]

I guess you think JavaScript is "general purpose processing by user agents."

Yeah, I do. The class attribute is general purpose, not for any specific purpose like CSS or Javascript. You can do what you like with it. One of the things you can do is process it with Javascript. Another thing you can do with it is use it in a selector in CSS. Another thing you can do with it is pull it out with a shell script. You can do what you like with it. It's general-purpose.

Where's the disagreement here? What do you think the specification means by "general purpose"?

Re:Not really new, but interesting

[JimDabell]

But, the page would be perfectly valid

It would be perfectly valid, sure, but it wouldn't be perfectly valid XHTML. It would be a perfectly valid document in your own private markup language. Even PPK admits it. I can write a DTD that adds <marquee> to XHTML 1.1 - that doesn't mean documents using <marquee> are valid XHTML 1.1 documents.

Re:Not really new, but interesting

[mattwarden]

It would be perfectly valid, sure, but it wouldn't be perfectly valid XHTML.

What is your point?

Re:Not really new, but interesting

[mattwarden]

Unless your shell script is an HTTP user agent, you are using the class for a purpose other than it was designed. I can see you making the argument that JavaScript is "general purpose processing by user agents", but I don't see you making the case for the same with a shell script.

The disagreement is that the spec specifically indicates the use of the class attribute for CSS purposes and secondarily mentions that it can be used for "general purpose processing by user agents". And from that you say that calling the class attribute's intention to attach CSS behavior to an element as '"wisdom"' and 'completely wrong', which seems like quite a bit of an overstatement, if not also completely wrong.

But, I guess this is slashdot.

Re:Not really new, but interesting

[Paradox]

And what desktop is that? It sure as hell can't be Windows.

Mac OS X. Couldn't you guess?

The XMLHttpRequest isn't a web standard. To quote w3c: "The XMLHttpRequest object is not a W3C standard."

XMLHttpRequest is a de facto standard. Opera, Firefox/Mozilla, Internet Explorer and Safari support it. It can safely degrade to non-enabled browsers as regular GETs. Google is backing it. It will be a standard soon, since many people consider it to be superior to the Load And Save stuff that the W3C drafted.

I'm not talking about google

Then why did you mention them? Because you did... mention them.

I'm talking about those sites who have a product to sell but which require specific browsers. I don't have this problem with Amazon or any of the other major retailers. But I find it every so often with the same guys. Like yesterday trying to buy a piece of software from this guy, where the "checkout now" button wasn't even a link. Did I need flash loaded? Was he trying to do something too fancy in javascript? I have no idea, and I wasn't about to read through the page source to find out. I simply left instead.

Finding one people, or even a lot of people, who suck doesn't mean you have a rational basis in condemning the whole group. You were better off approaching the technical tack instead of showing off your own spite and prejudice.

His site sucked and he didn't get your money. What more do you want? That is economics at its best. Hopefully he'll get the message and shape up or ship out of the industry.

I know I pay a price for it. If I didn't want to pay the price then I would be just another good little sheep with Windows and Internet Explorer eating McDonalds hamburgers and laughing at Friends episodes and listening to Britney Spears. The price to be a clone is oh so small...

I fail to see how this supports your claim that Web Developers suck. If anything, it makes me believe that you have issues.

Contrary to popular Slashdot belief, you are not more deserving of oxygen, sex, or money just because you don't use Windows. Your choice of OS doesn't make you any less a follower.

First, I use FreeBSD instead of Linux. Second, I have no problems playing movies, either off of DVDs, or as quicktime/mpg/rp/etc files. Even within Konqueror if I wish.

Yay for you? Times change. Your platform choice gives you certain criteria for what you can and can't do. You also give up most games for Windows on that setup. If you decide to pay the price, it's considered in poor taste to bitch about it. When I was using Linux as my primary, the movie and P2P music scene was just blossoming and I couldn't participate. Accept it. You made the decision.

Let's sum things up here:

1. If your browser can't keep up with the de-facto standard, use a different browser. If you refuse to, then don't bitch because yours can't keep up.
2. Just because some web developers suck doesn't mean you get to condemn the whole lot. There are some talented people out there amongst the chaff. This is no different from the software industry.
3. Your OS does not make you a better or worse person. What you do with it is what counts.

Re:Not really new, but interesting

[JimDabell]

What's the point in conforming to a DTD if it isn't one of the DTDs that everybody else is using? The whole point of writing valid code is to aid interoperability. If you are using your own DTD, then it doesn't aid interoperability at all. You can redefine anything to be valid in your own private markup language. But what's the point?

Re:Not really new, but interesting

[mattwarden]

The point is to create markup that can be parsed as XML by the client. The choice in TFA is between XHTML that does not validate as XHTML because of custom attributes and a slightly extended version of XHTML that does validate and comform to a DTD, whether it might be located on the w3c's servers or elsewhere. Dig?

Re:Not really new, but interesting

[JimDabell]

Unless your shell script is an HTTP user agent

Did you mean HTML user-agent? HTTP has clients, not user-agents.

If a shell script processes HTML, it's an HTML user-agent. From the spec:

An HTML user agent is any device that interprets HTML documents. User agents include visual browsers (text-only and graphical), non-visual browsers (audio, Braille), search robots, proxies, etc.

I can see you making the argument that JavaScript is "general purpose processing by user agents", but I don't see you making the case for the same with a shell script.

Why not? Because you don't think it's an HTML user-agent? It is. It doesn't have to be a browser to be an HTML user-agent.

And from that you say that calling the class attribute's intention to attach CSS behavior to an element as '"wisdom"' and 'completely wrong', which seems like quite a bit of an overstatement, if not also completely wrong.

No. If I had said that, then I would be completely wrong. I didn't say that though. What I did say was that your assertion that the class attribute is for CSS but not Javascript is completely wrong. The class attribute is for general-purpose processing. This includes CSS, Javascript, shell scripts, and pretty much anything else you can think of.

Re:Not really new, but interesting

[JimDabell]

The point is to create markup that can be parsed as XML by the client.

No. If you RTFA, you'll see that there is already working code in place, and the solution of a custom DTD is solving the "problem" that it doesn't validate. I'm saying that solving that "problem" is pointless, because it's merely sweeping the problem under the rug.

You don't need a custom DTD to get your code to be parsed as XML.

The choice in TFA is between XHTML that does not validate as XHTML

If it doesn't conform to the XHTML specification and DTD, then it's not XHTML, is it?

The choice in the article is between a document that doesn't conform to any known DTD, and a document that conforms to your own custom DTD.

As far as I can see, the two choices are identical in terms of parsing as XML and in terms of interoperability. Which makes the extra effort of writing a custom DTD to be pointless.

Conforming to a DTD doesn't imbue your documents with magical interoperability goodness. Conforming to a DTD that lots of people know and use and which has an open specification aids interoperability.

Re:Not really new, but interesting

[mattyrobinson69]

s/goob with a keyboard/goob with a mouse and a 'typer'

Re:Not really new, but interesting

[mattyrobinson69]

javascript is nice for popup hyperlinks (aslong as the href is still set and the javascript function is put in the onclick property, like this:



this will run the function openpopup, which could, if you like, open the popup in a window that is the size you want (good for FAQ's and TOS's). if the user doesn't have javascript enabled/available, the onclick event will be ignored and the browser will follow the href.

Re:Not really new, but interesting

[mattyrobinson69]

hmmm, the site im working on at work at the moment (one man job so i control exactly whats going on) works perfectly in all the browsers ive tested on so far (konqueror, opera, firefox, IE6, lynx). im downloading ie5.5 and ie5 overnight (using ies4linux). didn't really take me any extra effort and my site is more accessible (user defined stylesheets, user's font preferences, etc)

Re:Not really new, but interesting

[mattwarden]

you'll see that there is already working code in place, and the solution of a custom DTD is solving the "problem" that it doesn't validate

Oh, so then by 'working' you didn't mean 'valid'. Okay.

The "problem" isn't that it doesn't validate. The problem is that it isn't valid. It isn't just the validator that can't figure out if the document is well-formed.

If it doesn't conform to the XHTML specification and DTD, then it's not XHTML, is it?

Wow, that's pedantic, even for /. I'm not sure what else you would use to describe markup that is XHTML save for a few attributes that I note, in a dependent clause, are not valid XHTML.

Conforming to a DTD doesn't imbue your documents with magical interoperability goodness. Conforming to a DTD that lots of people know and use and which has an open specification aids interoperability.

That's excellent logic. So, as you say, there's no reason to have a custom DTD because you don't need a custom DTD to have this markup parsed as XML (um, even though the XML would otherwise not fit the DTD declared in its own DOCTYPE, but whatever). And there's no problem because there's working code already. But, somehow, other client types are going to have ridiculous amounts of trouble accessing the "XHTML" document because of a couple of extra attributes in the DTD and this will seriously harm interoperability. Does this sound contradictory to you at all? Maybe I am processing your logic with the wrong DOCTYPE?

Re:Not really new, but interesting

[ubernostrum]

OK, think for a moment about Appendix C: the whole point of the compatibility guidelines is to provide a way to take something that's not traditional HTML and wasn't designed to act like it, but send it as traditional HTML without problems. This is a thorny problem (and, technically, following the recommendations of Appendix C will still get you into trouble if an actual XML parser ever sees your XHTML-as-text/html; that's why people go on about SHORTTAG), and the W3C wants to make people aware of potential pitfalls and provide clear, understandable guidelines.

And Appendix C is not comprehensive here; it makes no mention of the problem caused by assumptions of default character encodings, and in fact recommends using an encoding which will be the wrong one if default character encodings come into play. And there's a vicious catch-22 there: if I take Appendix C to be correct and consistent, then I leave out my XML declaration and write in either UTF-8 or UTF-16. But that means I'm not using the default character encoding for the media type I'm using, which means I have to specify my character encoding. Which means I have to have an XML declaration (remember that many people, even now, publish on the web with no access to change the HTTP headers sent by their servers). So if I don't have an XML declaration then I have ot have an XML declaration. And if I have an XML declaration then I'm not "compatible" with HTML 4 and so according to that W3C Note I SHOULD NOT use text/html.

Speaking of which, I love how you triumphantly point out that the W3C Note on media types is non-normative, but then make a case which assumes we should follow it anyway (and, really, if they're writing something that they don't endorse and that isn't normative, then why are they using RFC2119 language? Why are they writing at all?). So let's keep that assumption in place and look at that language in context. Yes, 'MAY' means what it looks like; nobody's forbidding you to send 'text/html'. But let's look at what else is in that table: even when you follow Appendix C they say you 'SHOULD' send 'application/xhtml+xml'. So the RFC language here, in context, says "You can send 'text/html' if you want to, but we recommend you send 'application/xhtml+xml' instead." Got that?

Re:Not really new, but interesting

[Anonymous Coward]

Some customers are more trouble than they're worth. That's not derogatory, it's simply a statement of business fact.

Yes, that's true. But which customer is more likely to have shitloads of disposable income - the guy using bog-standard Internet Explorer on Windows, or the guy surfing the web from his PDA? And don't forget that making it accessible benefits a number of different areas - e.g. search engine rankings.

A simple "this is more work" is naive; being accessible to everyone is hardly any extra work if you identify it as a requirement before you begin coding, and the cost of retrofitting an existing site is a business risk of hiring people who don't know what they are doing - in some sense, you've already incurred the cost of retrofitting by creating the first version of the site badly.

Re:Not really new, but interesting

[Anonymous Coward]

Accessibility laws apply to governmental organizations. Your comment is entirely irrelevant in this discussion.

You don't know what you are talking about. Your comments are entirely unqualified in this discussion. SOCOG, for example, were fined $20,000 for producing an inaccessible site.

Re:Not really new, but interesting

[Anonymous Coward]

Try something like Nokia 770; 800x480 pixels worth of resolution is getting close to that of dekstop computers had in the youth of the Web and is certainly sufficient for well-done web site.

Re:Not really new, but interesting

[JimDabell]

Oh, so then by 'working' you didn't mean 'valid'. Okay.

Browsers don't care if your documents are valid according to your own private DTD. Whether you comply or not is utterly irrelevent to the point - which, in your own words, is "to create markup that can be parsed as XML by the client".

The "problem" isn't that it doesn't validate. The problem is that it isn't valid.

Please, just stop and think for a second. Web browsers expect HTML or XHTML when they are served text/html, application/xhtml+xml or whatever.

You feed them something else. What's more important - that the document is valid according to a DTD they have never heard of and won't even read, or that it isn't what the browsers are expecting?

It isn't just the validator that can't figure out if the document is well-formed.

Well-formed != valid. We are talking about validity. If we were talking about well-formed, then writing a custom DTD would be even more pointless, because the documents are already well-formed without it.

Wow, that's pedantic, even for /.

So how do you determine what is and isn't XHTML then?

I don't consider calling a document that doesn't conform to an XHTML specification or validate with an XHTML DTD "not XHTML" to be pedantic. Pedantic, to me, is writing a DTD for your "not XHTML" to get a pat on the head from the validator even though browsers don't care and it doesn't help interoperability.

So, as you say, there's no reason to have a custom DTD because you don't need a custom DTD to have this markup parsed as XML

No, that's not what I am saying. I am saying that being valid according to a custom DTD is functionally equivalent to being invalid according to a custom DTD, as far as web browsers expecting HTML or XHTML are concerned. Valid or invalid customML, it's still not valid HTML or XHTML.

But, somehow, other client types are going to have ridiculous amounts of trouble accessing the "XHTML" document because of a couple of extra attributes in the DTD and this will seriously harm interoperability. Does this sound contradictory to you at all?

Don't overexaggerate my point to ridicule me. I never said "ridiculous amounts of trouble" or "seriously harm interoperability", they are just straw-man arguments.

People have been bitten before by "no browser is going to get confused by this" assumptions. Often, a new version of a browser comes out and gets confused and they have to scramble to fix up all their websites. The browser developers can check to see if it gets confused by HTML or XHTML before they release it. They have HTML and XHTML testcases. They can't check to see if it gets confused by any private document type you can trick it into viewing. They don't have testcases for your private document types.

Which media type are you serving these documents as? You are aware that the only form of XHTML that is suitable to be served as text/html is XHTML 1.0 documents following Appendix C of the XHTML 1.0 specification aren't you? If you are serving these documents as text/html (as pretty much every mainstream website must do to support Internet Explorer), then you might be conforming to your DTD, but you aren't conforming to the relevant RFCs.

Re:Not really new, but interesting

[mattwarden]

I didn't read all of your comment, because you divulge an assumption early: namely, that I said the document would be served with a content-type header indicating that it is HTML or XHTML. I have never said this, nor can I even parse out why you would have this assumption. I have said numerous times that the point is to have a valid XML document. Why you would think the content-type would be anything other than one indicating XML is beyond me.

Re:Not really new, but interesting

[JimDabell]

technically, following the recommendations of Appendix C will still get you into trouble if an actual XML parser ever sees your XHTML-as-text/html; that's why people go on about SHORTTAG

You mean SGML parser, not XML parser, right?

If you are blindly passing text/html documents to an SGML parser, you are ignoring RFC 2854, the text/html definition, because it states that some forms of XHTML are also suitable for transmission as text/html.

And Appendix C is not comprehensive here

Of course. This is why I said "XHTML 1.0 doesn't say that following Appendix C automatically makes you conform to all relevant specifications; that responsibility has always been the publisher's.".

it makes no mention of the problem caused by assumptions of default character encodings

Let's get this in perspective here. It's an appendix in a markup language's specification, intended to aid compatibility between different markup languages. Unsurprisingly, it focuses on the incompatibilities between the two markup languages, rather than transmission protocol issues.

And in fact you are wrong. It states:

In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers.

And when you follow that advice, the problem of default character encodings simply goes away, because you aren't using the default character encoding.

and in fact recommends using an encoding which will be the wrong one if default character encodings come into play.

Appendix C doesn't recommend a character encoding. Go and read it. It points out that one consequence of omitting the XML declaration is that you are restricted to UTF-8 or UTF-16, but it doesn't recommend one.

And there's a vicious catch-22 there: if I take Appendix C to be correct and consistent, then I leave out my XML declaration and write in either UTF-8 or UTF-16. But that means I'm not using the default character encoding for the media type I'm using, which means I have to specify my character encoding. Which means I have to have an XML declaration (remember that many people, even now, publish on the web with no access to change the HTTP headers sent by their servers).

If you don't have the means to change the HTTP headers, you don't have the means to serve non-ASCII XHTML correctly. This does not mean that serving XHTML as text/html is wrong, it means some people can't do it. The catch-22 is imposed by hosts that don't provide the ability to transmit correct HTTP headers. The catch-22 is not imposed by the specifications and does not apply to everyone (or even most people wanting to serve XHTML, I'd imagine).

Speaking of which, I love how you triumphantly point out that the W3C Note on media types is non-normative, but then make a case which assumes we should follow it anyway

You've read too much into my comment. I didn't make the case that the note should be followed.

even when you follow Appendix C they say you 'SHOULD' send 'application/xhtml+xml'. So the RFC language here, in context, says "You can send 'text/html' if you want to, but we recommend you send 'application/xhtml+xml' instead." Got that?

Er, I understood it a long time before you tried to explain it to me, thanks. Where, exactly, do you think I've said something to contradict it? It seems you're reading too much into what I am saying. Stick to replying to what I actually say.

Re:Not really new, but interesting

[override11]

yea, but when you are deploying an internal only app for a network that you completely control, you can develop for whatever you want. Personally I make sure by apps work with Firefox and IE 6, then we made sure everyone internally is using one of those. Piece of cake.

Re:Not really new, but interesting

[Anonymous Coward]

Guess you really can't admit that you made all this shit up, huh?

Not the first time, but nice idea

[hedgehog2097]

This is not the first time check boxes and radio buttons have been "conquered".

boo.com had quite groovy code if I remember rightly.

Suggestion to improve your version: onFocus="blur(this)"

Re:Not the first time, but nice idea

[P3NIS_CLEAVER]

wasnt boo completely done in Flash?

Re:Not the first time, but nice idea

[sharkb8]

Amazon has had something similar for some time with their ratings stars. As you move your mouse across the row of stars, all the stars to the left light up until you click.

Re:Not the first time, but nice idea

[Anonymous Coward]

This is a joke, right? +1, Funny for sure, but which crackheads are modding this Informative?

Hint A for the clueless: boo.com had atrocious usability, not least in part due to stupid tricks like this.

Hint B for the clueless: the suggested code is popular amongst clueless design-types, and destroys the ability to navigate with the keyboard.

Re:Not the first time, but nice idea

[bedroll]

I had to create an app for making internal surveys for the company. The initial survey was a survey of the IT Department's performance. After finishing the app and having done the survey myself some 200 times I decided that it was very bland looking and needed something to spice up the design.

I was using radio buttons for a 1 to 5 rating. So I decided that instead of just boring radio buttons I would use smiley faces with an increasing amount of happiness. I took the smilies from MSN Messenger (our official and only allowed IM, which sucks as much as it sounds). The radio for 1 gets replaced by a crying face, 2 with a frowning face, 3 looks a little confused, 4 is smiling, and 5 has a big grin.

The result was just enough pizzazz to make the form visually appealing as you filled it out. Oddly, I didn't stop to think of it at the time, being in a homogeneous environment, my solution is just as friendly to non-scripting browsers. I use a regular radio button and use the onlick event to put the image over top, a non-scripting browser just wouldn't overlay the image. The only side effect that I hadn't forseen: One employee put in the comments section that she loved the smilies so much she put one of each rating just to see them. She gave us inaccurate ratings (including bad ones) just to see the smilies, and didn't change them before submitting.

Nice

[Anonymous Coward]

Those are pretty nice. Makes me want to make a webpage that actually uses radio buttons just so I can implement those.

The real question is

[Rosco P. Coltrane]

Will Lynx render them correctly with ascii-art?

Re:The real question is

[AKAImBatman]

Will Lynx render them correctly with ascii-art?

Yes, actually. While I'm none to keen on the idea of supporting old browsers in DHTML/AJAX/Whatever-you-want-to-call-it-this-week applications, his solution is designed to allow for normal checkboxes to show in browsers that lack JavaScript. As a result, the normal "text" checkboxes would show in Lynx. At least until Lynx gets full JavaScript and DOM support. Then you have problems. ;-)

Re:The real question is

[m50d]

Links already has javascript support. This reader will be very annoyed if the checkboxes are all broken in links.

Re:The real question is

[niteice]

However, elinks doesn't. :( elinks is better though, if that got javascript and links2's graphical mode I'd be set, 132x43 just doesn't cut it (since the machine i run it on can't do the framebuffer console).

Re:The real question is

[Anonymous Coward]

You're stupid. DHTML is not ajax. DHTML is part of AJAX. AJAX involves communicating with the server without requesting a new page.

Re:The real question is

[runderwo]

Question to links users: how do you deal with sites (like slashdot) that generate images, and require you to type in the text contained in the image in order to continue? The best I can do is view the page source, load the link to the image and save it as a png/gif/jpg, and manually launch an external image viewer. Maybe there is some support for launching xv or something similar on image clicks? But I don't seem to find how to configure it.

Re:The real question is

[m50d]

I don't, I just keep myself logged in. Not sure how you can deal with things like that. Complain to cowboyneal, not that he cares.

Re:The real question is

[Anonymous Coward]

Question to links users: how do you deal with sites (like slashdot) that generate images, and require you to type in the text contained in the image in order to continue? The best I can do is view the page source, load the link to the image and save it as a png/gif/jpg, and manually launch an external image viewer. Maybe there is some support for launching xv or something similar on image clicks? But I don't seem to find how to configure it.

I know you asked for links(1), but here's how you do it with lynx:

/etc/lynx.cfg:

ENABLE_LYNXRC:make_links_for_all_images:ON
MAKE_L INKS_FOR_ALL_IMAGES:TRUE
VIEWER:image/gif:xli %s&:XWINDOWS
VIEWER:image/x-xbm:xli %s&:XWINDOWS
VIEWER:image/png:xli %s&:XWINDOWS
VIEWER:image/tiff:xli %s&:XWINDOWS
VIEWER:image/jpeg:xli %s&:XWINDOWS

Re:The real question is

[Anonymous Coward]

Elinks can be set up to lanch external programs for specific data types. Then you only have to select the image and press (I dont remember which key), and it will lanch the program that you have told it to start.

Personally I just stick to firefox as I'm usally in X. Browse by keybord works fairly well in firefox. However if Elinks would have used vim-style commands, I would probably been more interested in it. // Zuu

Re:The real question is

[(startx)]

`links -g` is your friend in such cases(added in version 2 I think)

Check Boxes and Radio Buttons Respond:

[Anonymous Coward]

This occupation won't stand! You may think you can apply your western styles upon us by force, but history will prove you wrong.

And, of course

[Anonymous Coward]

html as an "interface" still totally lacks some basic things... like, oh, I don't know... sliders...
Hey, here's a question-- Why do we [i]need[/i] styled checkboxes? I hear those words and I just get this mental image of style kicking contents in the nads over and over and over.

Re:And, of course

[Anonymous Coward]

Heh. I wonder how many people are confused when they use UBB code on /.?

Re:And, of course

[Rosco P. Coltrane]

Hey, here's a question-- Why do we [i]need[/i] styled checkboxes? I hear those words and I just get this mental image of style kicking contents in the nads over and over and over.

Not to mention - but it seems nobody really cares about this, and apparently bringing the subject up always generates a deluge of "we won't hold browser technologies back because of *this*" answers - web developers are so busy beautifying web pages and turning everything graphical and snazzy that you can always count on one category of people getting screwed with this trend: blind people.

They are the truly forgotten of this embelishment, and java[script]tization of the net. I wish web developers cared more about (1) complying strictly with W3C recommendations for accessibility and (2) not forgoing accessibility just for beauty...

Re:And, of course

[ChefInnocent]

Because internet customers won't look at your site for very long if you don't think about style. The public at large are like managers...show them the pretty pictures, don't tell them what it means; they won't get it anyway.

Re:And, of course

[Anonymous Coward]

Did you even RTFA? The whole point is that it degrades gracefully and is therefore compliant and accessible!

Re:And, of course

[nubnub]

Please don't mod this "+5 Politically Correct". Nice UI and accessibility aren't mutually exclusive. Your rant is about as germane to this topic as hot grits and Portman.

Re:And, of course

[Anonymous Coward]

While I haven't looked at this example myself, any solution for the web should absolutely support all visitors to the site, including the visually impared.

In the case of blind people, I've become interested in Aural Stylesheets. I need to find a good aural screen reader to start designing with sound in mind, though.

Re:And, of course

[Anonymous Coward]

Nice UI and accessibility aren't mutually exclusive.

In general they are not mutually exclusive. It appears that by this very hacky checkboxes solution, they quite probably are mutually exclusive. This solution does not degrade, it instead just makes some educated guesses about whether or not you can see images based on details of the browser you're using. It can guess wrong in corner cases, which is unfortunate because corner cases are exactly the thing that accessibility measures are supposed to benefit.

Please don't mod this "+5 Politically Correct".

Remember folks, politically correct speech is offensive, and must be stamped out! We must halt the disease of politically correct thinking and stop those who tolerate it, or else there will be no freedom of thought.

Re:And, of course

[s4f]

And if you treat everyone like an idiot, you'll live in a world full of idiots. People get the kind of government/work environment/customers they deserve.

Treat people with respect, and start by asuming they are intelligent. People will respond.

Re:And, of course

[srmalloy]

Heh. I wonder how many people are confused when they use UBB code on /.?

It makes it easier for the people writing the forum software to be able to parse out HTML tags and force the use of tags in a different format in order to control what posters can do in their posts; they can strip out all HTML tags, rather than making the parser smart enough to be able to identify malicious or subcompetent HTML coding. Of course, you then wind up with making people switch between thinking in HTML tags and thinking in your tag format. But if the rest of your functionality is good enough, people will use it -- and the ones who are good enough to be writing HTML directly into a text editor should be good enough to make the mental switch.

And, of course, if you don't bother to preview your post and actually look at it to make sure it looks like you think it should, then you deserve to look silly if you screwed something up.

Re:And, of course

[TripleE78]

You bring up a good point, but the blame is in the wrong place. It's not always web designers that feel the need to put up tons of JavaScript navigation and useless Flash all over the place. Quite often it's the PHB's and Marketing execs. of the world that are clamoring for it.

I do a lot of web application work, and constantly have managers asking me to "sexy it up" or "add some snazz". When I mention things like accessibility and standards, they get indignant.

That said, it is possible to make things accessible and still look good. It's a shame that the Netscape DevEdge site went the way of the dodo when AOL took over. That had a ton of good examples.

Even note that the solution from TFA, while not that useful in reality, does degrade nicely.

~EEE~

Finally...

[iamjoltman]

Finally, I can add stylish radio buttons and checkboxes to my sites! Wait, I'm a geek, not a graphic designer. I don't care about the style, just as long as it works ;)

Re:Finally...

[Schwartzboy]

I don't care about the style, just as long as it works ;)

Just keep repeating that over and over in the face of the warbling graphic designers, marketing droids, and/or management-types who come to you with the battle cry "We don't care if it works, just make it look pretty!"
Sadly, that quote comes very nearly verbatim from a couple of "important" meetings I've attended where the main event involved kicking the functionality of one of my systems directly in the nads until the whole thing fell down on the floor and cried.

WOW

[Anonymous Coward]

not... that's rediculous, as if its some sort of invention... obviously it can be done and has been done in the past. This is NOT news.

Re:WOW

[Anonymous Coward]

rediculous

It's RIDICULOUS goddamnit! Like RIDICULE! Sorry to be a spelling nazi and all, but FFS, when have you ever heard anyone "redicule" someone? Holy god ...

Why JavaScript?

[Anonymous Coward]

We need to kill that crap and never use it again yet people keep using it in new applications.

Javascript is dangerous, not standardized, and crap. Find another alternative please.

Re:Why JavaScript?

[Rosco P. Coltrane]

Javascript is dangerous, not standardized, and crap.

Javascript isn't necessarily crap if used correctly. However, the only times I get to "experience" it are when websites want to do something stupidly useless, like resizing windows or goofing with the mouse pointer, or bury me in multiple cascading popups.

So, I don't know if it's really dangerous or not standardized, but it's definitely annoying and therefore I turned it off, and I don't go to sites that insist on using it.

Find another alternative please.

Flash? same problem, it's annoying (and CPU-intensive).

Re:Why JavaScript?

[mrchaotica]

However, the only times I get to "experience" it are when websites want to do something stupidly useless, like resizing windows or goofing with the mouse pointer, or bury me in multiple cascading popups.

The corollary of that is that when JavaScript is used correctly, you don't notice it (e.g. Google's various pages).

Re:Why JavaScript?

[Doctor Crumb]

Javascript *used to be* crap. It's actually quite complete, well thought out, and well-supported these days.

Re:Why JavaScript?

[DeadMeat (TM)]

Javascript is [...] not standardized

Ecma International and The World Wide Web Consortium beg to differ.

Re:Why JavaScript?

[organum]

Javascript is appropriate for conscientiously enhancing the user experience, but it should *never* be required for functionality. When in doubt, always avoid it, but if you've got some time to kill and you want to add some fancy non-essential features, go for it. Just don't forget that it's extra.
(And don't forget to test it on every browser on every OS ...)

Click here

[FunWithHeadlines]

[ ] This is a good idea
[ ] This is a kludge
[ ] I didn't read TFA, but I like clicking boxes anyway

Re:Click here

[Anonymous Coward]

These checkboxes don't work. This is obviously another sign of just how borked slashcode really is...

Re:Click here

[Anonymous Coward]

the checkboxes work on the 'poll'

Re:Click here

[AKAImBatman]

These checkboxes don't work. This is obviously another sign of just how borked slashcode really is...

Really? They worked fine for me. Well, except for that little issue with the mark lagging behind the checkbox. Everytime I scroll the browser, I have to wipe off the existing mark, pull out my magic marker, and recheck the box! Someone should tell Taco that this is a really annoying bug. But you guys can see my answer, right?

Re:Click here

[Anonymous Coward]

[x] This is a good idea
[x] This is a kludge
[x] I didn't read TFA, but I like clicking boxes anyway
[x] Polls should use radio buttons.

Re:Click here

[ghee22]

am i the only idiot that instinctively clicked... saw it didn't work, and clicked 3 more times before... laughing?

Re:Click here

[arkanoid.dk]

erm... no.... you aren't
I did that as well

Re:Click here

[hcdejong]

Of course they do. Here's a screenshot of the form after I entered my choice:

[ ] This is a good idea
[ ] This is a kludge
[x] I didn't read TFA, but I like clicking boxes anyway

Re:Click here

[Ingolfke]

[] I only use XForms

Re:Click here

[Anonymous Custard]

worked for me too...

[ ] This is a good idea
[ ] This is a kludge
[ ] I didn't read TFA, but I like clicking boxes anyway
[X] CowboyNeal

Re:Click here

[Anonymous Coward]

I wish I had some mod points for that one...

Re:Click here

[93 Escort Wagon]

[ ] This is a good idea
[ ] This is a kludge
[ ] I di X ad TFA, but I like clicking boxes anyway

Sorry, I tried to use your form on IE but your code appears to be broken

Re:Click here

[WilliamSChips]

Then you shouldn't be posting as AC.

Old

[mfloy]

This is somewhat at old idea, but appears to becoming a more mainstream idea in web development. The main focus however should be making sites that follow standards so they are viewable on every type of browser and platform.

yay!

[fbartho]

That's pretty damn cool! I've been waiting for this for sometime actually...

Is this a good thing?

[AtariAmarok]

Is it a good thing to have controls that deviate from the standard so much that they aren't even recognizable anyore, like the green/grey round toggle button that replaces the checkbox on the sample page? Why disguise standard controls so the user will have to spend some time trying to find out what the standard controls are "hidden as"?

Re:Is this a good thing?

[op12]

Ideally, the context of your page would make the function obvious. The ability to change it to fit any page style is the major benefit. Sure it's nice to see the standard checkbox, but if it completely messes up an otherwise "clean" or different looking interface why not change it?

Re:Is this a good thing?

[mzwaterski]

Cause they look prettier.

Re:Is this a good thing?

[AstroDrabb]

I think it is. If you downloaded the sample code and played with it you would have seen that the code just uses images to replace the controls. You can replace his with what ever you like. If you have some artistic abilities (I don't), you could come up with very nice looking checkboxes/radio controls to fit better with a sites design. Or you could just check Google Images for radios and checkboxes. However, I do think that if you make them look too non-standard it could lead to user confusion. Though I personally leave the design up to the artistic types and just do the programming ; )

Re:Is this a good thing?

[AtariAmarok]

"The ability to change it to fit any page style is the major benefit. Sure it's nice to see the standard checkbox, but if it completely messes up an otherwise "clean" or different looking interface why not change it?"

Do you have an example of a page where the "Style" is such that usual controls would not be a good idea? Is there a possibility that the fancy page is really overdone if standard controls will be "out of place" in it, even if the colors are changed?

Re:Is this a good thing?

[TheRaven64]

Because making things look flashy is far more important than making them usable. Look at recent versions of Windows and any modern *NIX desktop environment for a few hundred examples.

Re:Is this a good thing?

[twocents]

For most Web pages, I think this is not a very good idea. From a design perspective, I can respect the desire to have control over elements on the page, but different interactive elements create more confusion than anything. There are very few things I hate more than having to figure out how to access parts of a DVD or Web page; it might look neat the first time, but I'm interacting with said interface for content, not just to interact with the interface.

Re:Is this a good thing?

[op12]

An example is http://www.chud.com/

I'm sure there are better examples, but basically when there is a theme to the website, the standard objects can disrupt the flow. In that above example, this can sort of be seen with the searchboxes.

Re:Is this a good thing?

[AtariAmarok]

"However, I do think that if you make them look too non-standard it could lead to user confusion."

The sample page actually does include round checkboxes which look more like option buttons than checkboxes. Yes, thanks to this breakthrough, we can make checkboxes that look like option buttons, and vice-versa!

Re:Is this a good thing?

[AtariAmarok]

"An example is http://www.chud.com/"

Thanks. It looks like they have a bad thing going on Chud, if they think "dark green on black" text is fun to read. They even have dark grey on black. IMHO, if you need to highlight the text and/or past it into a text editor to read the web content, they've already failed it. However, I don't think that having checkboxes and option buttons on the page (rendered in the typical colors) would spoil whatever effect they are aiming for. I did not see what you meant with the searchboxes.

Re:Is this a good thing?

[op12]

Well, I agree about the color scheme. But what I was aiming at is if you have an all-encompassing theme to your site, and the standard objects don't fit it (ie. the color or shape doesn't work), it'd be nice to be able to change it. The site I couldn't find that I was thinking of has absolutely everything rounded and shaded in a white/grey 3d effect. On such a site, a standard checkbox would look very out of place. If the color scheme were different, a standard radio button might also look out of place. It's just about cohesiveness.

Re:Is this a good thing?

[cecille]

"overdone" is really more of an opinion. It is possible that a page that uses these fancy controls is overdone, just in the same way that a page that uses any fancy new web design can be said to be overdone. In university, I worked with a prof who wrote all of his web pages in plain text with the same grey background because anything else would have been too fancy for him. It's all a matter of opinion.

While it does pay to give consideration to useability, I don't think you can automatically point to any site that happens to use fancy controls and say that there is something fundamentally wrong with the design or that it is overdone. If the controls are sitting where a control would normally be, there are a bunch of them there with options beside them and one of them is looking a little different, chances are good that user will recognize them as controls.

Look, I do understand your point - it makes sense to use controls that people recognize. But there's nothing to say that people would ONLY recognize the traditional style boxes as things that are clickable. It seems like you're saying that the GP should prove to you that these things are needed. I don't think it would be possible to do so - you're right. But at the same time, you can say the same things about most web page design ideas out there. Prove to me that you really do need to change your font family to have your page look great. Or that rollover buttons are really required. Or that a multitude of other things are "necessary" and don't make the page "overdone". These small things, on their own, are not "necessary". But fitting the small details to the overall style helps gives the page its character, and if styling your buttons helps, I personally can't see the harm. After all, it's their risk to take, right?

Re:Is this a good thing?

[nEoN nOoDlE]

or most cases, it probably won't be a good thing. But why stifle choice and design just so every checkbox and radio button can be standard?

Re:Is this a good thing?

[Lumpy]

no.

look at every windows app that the developer was "creative" and rewrote all the CLI widgets so they are all heavily stylized and different.

it makes your product look like a fisher-price childs toy and increases user frustration.

we were looking at several vertical apps last month here where one of them even went so far as to have the application window an OVAL instead of the typical rectangle and even allowed you to "theme" the app.

technically the app did what we needed for the sales department well and was cheaper that the alternatives...

but the Director of sales said "I will not have something that looks like a Honda CRX that a teen with too much money got his hands on."

and it did, it was only missing the ground effects lights and go-fast wing.... it looked silly.

Re:Is this a good thing?

[anomalous cohort]

"overdone" is really more of an opinion

Well, it can be an informed and research driven opinion. There have been perception based studies on the usability of different GUI style/elements. I can't site the references right now. What I remember is that adults favor earth tone colors whereas children favor circus colors. Also, too much beveling is distracting.

Re:Is this a good thing?

[ubernostrum]

Is it a good thing to have controls that deviate from the standard so much that they aren't even recognizable anyore, like the green/grey round toggle button that replaces the checkbox on the sample page? Why disguise standard controls so the user will have to spend some time trying to find out what the standard controls are "hidden as"?

In some cases, yes. For example if you're running a review system you could use stars (as in one of the examples on that site) and users would reasonably understand how it works. In fact, since using stars for reviews is a convention older in our society than the Web, this might improve usability.

OT: Try the 3/10 rating

[Furmy]

It returns 2/10.
I had fun clicking though.

and css

[eurostar]

If only I could style with CSS too..

Re: and css

[eurostar]

woops, the SELECT tag went somewhere else..

Please

[PunkOfLinux]

Please check the box if you care if you care what it looks like.

What about keyboard input

[Anonymous Coward]

I can't switch focus with this DHTML-Stuff.

Re:What about keyboard input

[stuffisgood]

Well I don't know what browser you are using coz I certainly can...suprised me too, wasn't expecting it to work after your comment

Re:What about keyboard input

[KillerDeathRobot]

Um, what? Did you rtfa? The point is that you can switch focus between the controls with tab and even activate them with space.

seen that before

[Anonymous Coward]

http://slayeroffice.com/code/custom_checkbox/

describes the same. and the author there even mentions that he took the idea off from aol webmail.

Damn you, Slashdot.

[bigtallmofo]

I just hope the marketing people that work in my company aren't reading Slashdot today.

Otherwise, I'll be making fancy checkboxes for the next 2 months.

Damn you, Slashdot.

Re:Damn you, Slashdot.

[TobascoKid]

At least your marketing people know to use javascript and html - ours "need" to use flash because they have no idea how to make a site using anything else.

Re:Damn you, Slashdot.

[xMilkmanDanx]

Nothing to worry about, most marketing people couldn't figure out why http:///..com wasn't working so they gave up.

PS. If your marketing people are actually looking at technical information, run. It'll end badly. Always does...

Are you joking?

[dave420]

This is what passes for a story on slashdot these days? This isn't new. People have been re-creating radio and check boxes using DHTML for YEARS. Shit, I remember first doing it 2 years ago, and I didn't think it was anything special when I did it.

Do editors not read articles any more? shit.

Re:Are you joking?

[ergo98]

This is what passes for a story on slashdot these days?

What they really needed was a groovy acronym, and then they could pretend they invented it.

SUDS - Stylistic User Design Standards

Does your website use SUDS? SUDS is all the rage these days.

Re:Are you joking?

[Neurotoxic666]

This is what passes for a comment on slashdot these days? This isn't new. People have been re-creating flame and rant comments using CTRL-C/CTRL-V for YEARS. Shit, I remember first doing it 2 years ago, and I didn't think it was anything special when I did it.

Re:Are you joking?

[dave420]

very drole ;) I think my comment stands. I was pissed off because it was akin to finding an article on slashdot entitled "Power button used for turning PCs on/off" or maybe "Stabbing stomach with scissors - uncomfortable". It's so blatantly obvious what that guy did, and it's not even a new technique. shit. ;)

Re:Are you joking?

[IpalindromeI]

The real question is why did it upset you? If you actually got "pissed off" because something that you find boring was presented as newsworthy, you may need to look into anger management.

I swear, Slashdot is full of people getting upset over things that don't make one lick of difference to them. If your intent was merely to point out that you disagree with the editors about what is newsworthy, the discussion comments are the wrong place to do it. The other users can't help you, you're just adding to the noise.

Re:Are you joking?

[jahknow]

I, for one, read Slashdot first and foremost for other readers' debates on a posting's newsworthiness or relevance. The Grammar Police are rather amusing as well.

Re:Are you joking?

[Anonymous Coward]

and yours work with js / css turned off? Kbd nav still works? Link please?

Re:Are you joking?

[Neurotoxic666]

very drole ;) I think my comment stands. I was pissed off because it was akin to finding an article on slashdot entitled "Power button used for turning PCs on/off"

Glad you didn't took it too personnal. I was just kidding ;)

Spiffy

[generic-man]

The examples look very nice. I still think the bigger problem is that web applications have absolutely no UI consistency between them, though. On one web site, select-boxes cause a form to be immediately submitted when a selection is made; on others, you have to click "Go." On one web site, check boxes look like boxes with check marks; on another they look like stars; on another they look like glowing orbs (not very colorblind-friendly).

This is the sort of thinking that leads to such UI atrocities as Winamp, iTunes for Windows, and Firefox for Mac OS X: all three of these ignore most of the native widget drawing capability in the name of creating a pointlessly slick, cross-OS-consistent experience.

I for one welcome the arrival of XAML and XUL: ways to describe forms that every OS will render using its own navigation and widget capabilities. It'll be as awesome as the time Java solved that problem for everyone everywhere.

Re:Spiffy

[m50d]

Just a minor complaint, I don't think the winamp thing is about slickness so much as space, and also themability. If you've tried to make a player with as small a footprint (which is important, because they want people having it open while they're using other programs) as winamp using native widgets, on any platform, you'll find it's impossible. And I've never seen anything as easily skinnable (there are web pages that will make a skin in one click given a picture) as winamp.

Re:Spiffy

[Anonymous Coward]

It'll be as awesome as the time Java solved that problem for everyone everywhere.

My sarcasm detector is broken here. I can't tell, are you being serious or not?

Re:Spiffy

[generic-man]

Ooh, sarcasm detector. That's a real useful invention! (boom)

I'm not being serious about the time Java solved the world's accessibility problems. Java applications still tend not to look or work like native apps: I can clearly tell when I'm in a Java app whereas I can't tell the difference as easily if a native Windows app was written in Delphi or MFC. Ideally the markup languages of the future will defer to the native OS for widget drawing while allowing for more capabilities (sliders, combo boxes, built-in validation) than HTML's set provides.

Re:Spiffy

[hazzey]

"...problem is that web applications have absolutely no UI consistency between them..."

"...ignore most of the native widget drawing capability in the name of creating a pointlessly slick, cross-OS-consistent experience."

Make up your mind. Is consistiency good or bad?

Re:Spiffy

[Anonymous Coward]

Really?

Though I love delphi, I can tell exactly when a program is delphi or not.

Thats probably because I spent so much time working with delphi. RAD was a joy back on windows... I wish C++ compiled even 10% as fast as delphi.

Re:Spiffy

[generic-man]

It's good.

When I'm on Windows, every application I use should look and act like a Windows application. Keyboard shortcuts should match up across Windows applications.

When I'm on Mac OS X, every application I use should look and act like a Mac OS X application. Keyboard shortcuts, VoiceOver for audio cueing, and other OS-native features should work in every Mac OS X application.

Even native applications aren't consistent. My point is that there is no way for a web page to be consistent with a native app: the W3C can tell you if your web page is valid XHTML, but that doesn't mean that people will be able to actually use it everywhere every which way.

Re:Spiffy

[hcdejong]

Make up your mind. Is consistiency good or bad?

Consistency with the client OS is good.

Cross-platform consistency unnecessarily complicates the user's interaction with the application. It's pointless for most applications and most of the user base.

Re:Spiffy

[rikkus-x]

http://www.foobar2000.org/

Re:Spiffy

[mike.newton]

They're fixing Firefox for Mac. And you forgot to mention Netscape 8 in your list. The horror...

Re:Spiffy

[X_Bones]

I still think the bigger problem is that web applications have absolutely no UI consistency between them, though. On one web site, select-boxes cause a form to be immediately submitted when a selection is made; on others, you have to click "Go." On one web site, check boxes look like boxes with check marks; on another they look like stars; on another they look like glowing orbs (not very colorblind-friendly).

I've never really understood this line of argument. So what if different Web sites put UI features in different colors, sizes, and areas? Does it matter that different retailers have their merchandise laid out differently and their signs in a different font and color? Is it a problem that you have to wait in line for a single register and pay only with cash at one retailer, but there's multiple registers accepting cash or plastic at another? As long as each application is internally consistent, that's as good as it can get (from a UI standpoint).

Consistency across an entire Web site (or, in the physical analogy, a chain of stores) is, obviously, very important; even better if the chosen design is attractive and intuitive. But there's no good reason to specify a common look'n'feel between seperate Web sites, and even if there was there's no easy way to determine it, and even if there was there's nobody to enforce it across every single CGI app on the Internet.

Re:Spiffy

[mrchaotica]

Firefox works out well for me on Mac OS X, once I got a good theme ("GrApple Classic") and replacement widgets (can't remember where I got mine, but here's a different good set).

Re:Spiffy

[DaveCar]

Of course, I'm sure that people are already using such techniques to make the opt out/in boxes for receiving marketing mailshots more obscure and convoluted than they already are :(

Re:Spiffy

[Anonymous Coward]

They're fixing Firefox for Mac.

That's nice. I've heard Longhorn is going to be a pretty cool OS too, and that Duke Nukem Forever is going to be a sweet game.

Re:Spiffy

[generic-man]

OK, so it looks nice now. It still doesn't behave like a Mac OS X application at all. If you're running Tiger, hit CMD+F5 to turn on VoiceOver and see how little of the interface is actually accessible to the operating system. None of the text works with services, TAB doesn't cycle through the UI elements like you'd expect it to, and so on.

Don't worry, though. I hear the next version is going to be great. Really.

Re:Spiffy

[generic-man]

Imagine if every store had a different way of opening the front door, or a different obtusely-shaped shopping cart that you couldn't easily remove items from, or a different style of shelf just because the folks in marketing thought it'd look cool. That's the real-world analog to this whole "let's make checkboxes look different" idea.

UI consistency doesn't have as much to do with colors and sizes as it does with basic interaction. After 20 years people still barely know how to use computers; now thanks to the web, interfaces are being torn down and rebuilt in the name of looking cool and different. It sucks, and nobody really cares to change it.

Re:Spiffy

[mrchaotica]

Yeah, yeah, I know. I wish Firefox supported Services and scripting (VoiceOver, AppleScript, and Automator) too. I still end up using it though, because I like how it can fit (many) more tabs in the bar without them overflowing than Safari can.

The original discussion was how the form widgets didn't look native, though, so discussion of Services and such is a bit offtopic, don't you think?

Re:Spiffy

[OmniVector]

that's because whoever wrote the java app didn't take the time to write a single fucking line of code that tells swing to use the native toolkit. java makes very nice looking (and rather native looking) mac, windows, and linux guis.

Re:Spiffy

[Anonymous Coward]

a player with as small a footprint

System requirements
Display: 800x600

Erm, something requiring 800x600 does not have a small footprint. I couldn't find any screenshots though, so I can't tell exactly how bad it is.

Now for Step 2

[LifesABeach]

What would be the next step so that in this would be used in CSS3?

are they really blinky for anyone else?

[pezpunk]

granted i'm not exactly running the latest hardware, but every click on a radio button seemed to illicit a lot of blinking and flashing on the part of the other buttons. maybe it's just javascript running slowly as the DIVs move around or something, but i prefer to think of it as simple jealous from the other buttons in that group. "click me instead!" "no me!"

in any case, i'm all for flashy design, but this seems to be more trouble and more cumbersome than it's worth, unless that javascript can be optimized to not be so slow.

Re:are they really blinky for anyone else?

[Anonymous Coward]

Not blinky for me, no. I looks and works as smooth as silk in ie6, but has no keyboard selection.

Re:are they really blinky for anyone else?

[henrywood]

I get the flashing whenever I move the mouse pointer over the icons. And I get a box drawn around the selected item - real ugly. This looks like the triumph of style (bad!) over content to me.

Thought the use of the words "flashing" and "flashy" in the parent were very descriptive - this reminds me of all those Flash pages that I hate so much. (OK, I'm old; I just want the information not some kid's version of "cool".)

Re:are they really blinky for anyone else?

[pezpunk]

it's a shame that in geek circles Macromedia has co-opted that word, and made it a dirty one to boot.

Re:are they really blinky for anyone else?

[Anonymous Coward]

Well, i'm using firefox on fairly old hardware (older than 3 years) right now and i'm able to tab through them just fine and then select them with the space bar.

Re:are they really blinky for anyone else?

[Anonymous Coward]

"but every click on a radio button seemed to illicit a lot of blinking and flashing"

It's "elicit," not "illicit."

Re:are they really blinky for anyone else?

[CDarklock]

In *real* geek circles, we know that "flash" is the crap overflow in the molding process that leaves little blobby tags of plastic and metal hanging off the sides of models, which must be carefully and completely trimmed away before trying to do anything meaningful.

So I think it's an EXCELLENT choice of terms.

Re:are they really blinky for anyone else?

[fnj]

but every click on a radio button seemed to illicit a lot of blinking and flashing

illicit - adj - not permitted, unlawful
elicit - verb - to draw forth or bring out

Re:are they really blinky for anyone else?

[PenguinRigger]

Yes, I had the same problem. Quite annoying if you ask me. Unfortunately these will probably be popping up all over the place. Forget the "blink" tag, now we have "randomly flicker".

Re:are they really blinky for anyone else?

[Anonymous Coward]

Ya you would, but flash stands alone in making nice neat, functional, eye pleasing apps that people usually DON'T have to install the plugin for...well unless you use some jackass OS that doesnt include it :)

Usuability standards

[AtariAmarok]

"The main focus however should be making sites that follow standards so they are viewable on every type of browser and platform."

Not just that; there are usability standards. Checkboxes and radio/option buttons are supposed to look and act a certain way. It makes using them that much easier. Disguising them as something that looks like Lucky Charms marshmallows really fudges matters. The sample even had checkboxes made to look like option buttons (round).

Re:Usuability standards

[I confirm I'm not a]

The sample even had checkboxes made to look like option buttons (round).

Aye, I spent a few seconds clicking various "radio buttons" and wondering why they weren't working properly before I realised they were 'sposed to be checkboxes. I don't know if it's because I'm used to the standard (I'm a web developer) or because I'm stupid... or both. Somehow I feel that making users feel stupid is the worst sin of all...

Re:Usuability standards

[mrchaotica]

Exactly! I mean, hasn't it occurred to anybody that maybe this is the reason why the W3C didn't make them stylable in the first place?! They could have, you know, but they chose not to.

I, for one, want my checkboxes (and buttons!) to look like the system buttons, not some fruity whim of the web "designer!"

Re:Usuability standards

[Intron]

That's why I do my whole site in 10-point courier in green on a black background. No images, javascript or CSS. It looks just the way it did on a CRT terminal in 1975, as God intended.

Re:Usuability standards

[mrchaotica]

The difference is that with text, you know that it's text and how to use (i.e., read) it no matter what font or color it is. With widgets, on the other hand, you don't necessarily realize it's a widget (or what kind of widget it is) unless it looks like the ones you're familiar with, which would be the system ones.

For example, a checkbox that's styled to be round makes people think it's supposed to be an option button. An option button without a circled dot (say it changes color instead) might be mistaken for a bullet. A button that looks like an image doesn't look clickable. Anyway, you get my point.

dontclick.it

[Anonymous Coward]

this is nice, but requires the mention of http://dontclick.it/

Re:dontclick.it

[Mostly a lurker]

this is nice, but requires the mention of http://dontclick.it/ [dontclick.it]

No ... off topic here. You need to bring it up when people are arguing about the merits of two button, three button and five button mice. Make the case for a zero button mouse then!

Accessible?

[Anonymous Coward]

Not to be an accessibility Nazi, but you can't tab through the form elements.

I would prefer to have normally and familiar elements that i can tab through than fancy graphics that don't work as expected.

Re:Accessible?

[senocular]

Firefox (Win) seems to have no trouble tabbing through them.

Re:Accessible?

[aug24]

Not to be a reading Nazi, but he says you can at the top of the page, and Firefox Just Works.

I'd ask you what browser you're using, but you're a useless AC so you'll prolly never read this.

J.

Re:Accessible?

[Freexe]

I'm the poster, and I'm using Opera. Plus it didn't work properly in IE either.

Looks like it works in Firefox but I dont count 1 out of 3 (not tested Safari) as great. Something should at least work in IE, Firefox and Safari for me to consider using it.

Re:Accessible?

[aug24]

Hallloooo! ;-)

Yeah, I wouldn't count it as finished without supporting at least IE and Moz. What I was getting at was, as he clearly intended it to work, it's a bug rather than a criticism of his project.

Cheers,
J.

Re:Accessible?

[Freexe]

Yeah, after looking at it in Firefox, I can see s/he had made an effort to get it to work.

I think it is a good step in controling the look and feel of a form, but to what end? Having a form that doesn;t look at all familiar could serve to confuse users if used badly, but I guess that is true of most things. Hopefully these things will be used to improve the user experience.

Re:Accessible?

[R4modulator]

Accessible doesn't just mean "keyboard accessible". It means
1) keyboard accessible in a way that users already know and understand, so that usability is not degraded, and
2) accessible with assistive technologies such as screen readers.

The page linked to has accessibility problems, not just for keyboard users, but especially for screen reader users. Fortunately a solution is on the way in the upcoming release of Firefox :)

I am working on a way to have accessible, styled/scripted form controls of all types. This includes menubars, tab panels, tree views and spreadsheets, not just simple widgets like checkboxes and radio buttons. IBM is contributing this work to Firefox as part of an open accessible DHTML standard.

The keyboard part of the solution involves the use of tabindex="-1" for elements that are focusable but not part of the tab order. This allows these elements to be in a container that the user arrows around, for example. This part is compatible with IE (see http://www.mozilla.org/access/keyboard/tabindex)

Then there is the compatibility with assistive technology. That is accomplished with new namespaced attributes. See http://www.mozilla.org/access/dhtml for an explanation and samples.

And you don't have to be a Nazi to care about accessibility. :)

Re:Accessible?

[poot_rootbeer]

he says you can [tab through elements] at the top of the page, and Firefox Just Works.

I'd ask you what browser you're using

IT DOESN'T MATTER WHAT BROWSER HE'S USING!

If there's ANY standards-compliant browser in which tabbing through elements doesn't Just Work, the solution is incomplete.

Re:Accessible?

[damiam]

From what I've read here, it works fine in standards-compliant browsers but not in Opera or IE.

Re:Accessible?

[aug24]

It does matter Mr Shouty, cos it might be NS4 or IE3. Does he say it's compliant?

Anyway, as I said to the op, that it doesn't work as he states it is supposed to is just a bug. We all write those and fix them when reported. If, on the other hand, he hadn't considered it at all, I'd be much more critical.

J.

Re:Accessible?

[aug24]

It's another step in making a browser into a platform, that's all. Sometimes people don't want the standard controls. Think of it as a dynamically downloadable widget?

I know web design/developers who would love this and make beautiful sites with it. I know others who will use it in entirely the wrong places and make sites that will show up on WorstOfTheWeb in a year's time ;-)

J.

Re:Accessible?

[Linus Torvaalds]

If there's ANY standards-compliant browser in which tabbing through elements doesn't Just Work, the solution is incomplete.

Don't worry, that won't be a problem. There are no standards-compliant browsers, so obviously there are no standards-compliant browsers in which tabbing through elements doesn't Just Work.

Very Nice

[A Dafa Disciple]

I teach an internet technology class that focuses on CSS and JavaScript and I will be sure to include this technique in our discussions before the end of the semester.

The article's author was a bit lazy, however; he should have made his images as .gif's with transparent backgrounds because they look like crap on my browser's settings. With .gif's and this technique, forms with revolutionary design are achievable.

I also recommend these techniques for new web designers (the source and authors of them will come as a huge "duh" to professionals, I'm sure).

Re:Very Nice

[A Dafa Disciple]

Sorry; I don't want to reply to myself but I wanted to share this inspiring and amazing CSS resource to those who don't know about it. Read the page to learn more.

Re:Very Nice

[Anonymous Coward]

Duh

Patent It!

[ryanjm]

The author should apply for a patent for this. I'm sure it'd be approved.

Re:Patent It!

[ArsenneLupin]

The author should apply for a patent for this. I'm sure it'd be approved.

Yes good idea, please do! At least if it's patented, the other webmasters won't be able to use that overly flashy bloatware on their sites!

On bells and whistles

[PIPBoy3000]

There are certainly some people out there who are impressed by cool graphic tricks.

After writing web applications for ten years, though, I find that more and more people simply want to get the job done. Perhaps it's that I work in Healthcare and my customers are busy people caring for patients.

The other thing that makes me nervous about bells and whistles is that they add complexity to things. Complicated things break. Browser makers have changed how they implement CSS and DHTML before and there's a good chance they'll change it in the future. Basic support for checkboxes will last another fifty years.

Re:On bells and whistles

[Anonymous Coward]

There are certainly some people out there who are impressed by cool graphic tricks.

For example, see my spouse's boss. Upon presenting the website that accomplishes all features required, plus some additional ones, two weeks ahead of schedule, the boss's only comment: "Huh. Lacks the 'wow' factor."

Personally I agree with you - if a text-only site 'gets the job done' that should be prized more than a Flash-site that is lacking, but looks pretty in its lacking.

EASIER

[Artfldgr]

its easier to create hidden variables in your form and then vary the same code that you would use for buttons to change the image while changing the value in the hidden fields. making it reverse compatible would be to put regular checks in a hidden div... so if there is javascript div is emptied.. if there is no javascript the contents of the div shows and the javascript doesnt run... cascading styles are optional...

Horrible and confusing

[baadger]

They look horrible and confusing to me, especially in the example the author has given. If i had come across that form on a page and it said "please select a rating" or the like I would be momentarily confused.

I think there is a good reason why radio buttons and check boxes haven't been styled too much - it's because they are perfect the way they are.

If you want to style a checkbox or radio button atleast make it look like one, get some inspiration from the likes of Opera skins.

Re:Horrible and confusing

[DevanJedi]

Just because the particluar examples are bad doesn't mean the entire concept is bunk. If correctly labelled and used when appropriate, this would make things much more aesthetically appealing. They don't have to look like Radio buttons in order to offer the same functionality. Netflix users are familiar with the star-ratings- if the usage is as intuitive as that, people will do it without second thought.

Re:Horrible and confusing

[booyabazooka]

The problem with his solution is that this particularly demonstration "fixed" the problem way beyond its original scope. The problem to overcome was that checkboxes don't accept css styling - And the solution was to turn them all into stars???

it's because they are perfect the way they are

Perhaps they don't deserve radical change as presented here, but existing checkboxes are far from perfect. Particularly, when working with a dark-colored page, you don't want a bright white checkbox to be the only thing a user notices. This solution IS capable of just changing the colors of the box and not the design- and I think that would solve most of what people are complaining about.

Re:Horrible and confusing

[baadger]

True but..

• There is little point in discussing the use of CSS generally to customise forms, that is only a tool. A tool which isn't even new to webdesign. Better is to the discuss the authors use of it and the way he promotes it's use.
• The author's examples and presentation of his method make his rating form look like a way of presenting a rating more than inputing one. If all inplementations end up this bad, and it does allow webdesigners to do so, it becomes difficult for a visitor to distinguish input from output and introduces confusion. My main point was he should have been promoting the use of customised radio and tickboxes not paving way for the introduction of, effectively, totally new unfamiliar form elements.
• Web standards are heavy on pushing the seperation of data, style and structure. Since a forms structure partially implies the data it houses doesn't that mean it's style should also? For example: a plain or stylish tick, no matter how you look at it, still implies a boolean/binary field.
• I don't see why a good webdesigner would want to introduce more presentation or user hand holding (Such as 'click to toggle' labels or legends) than necessary into a page just so the visitor can understand a pretty form, or how doing so makes the form more intuitive or enjoyeable to use
• The majority of web users, both online and offline, are familiar with the star rating but I don't think that clicking stars to rate something is intuitive at all.
• In the case of the example, and IMHO something much better, would be to have + and - buttons and a row of star graphics that appear and disappear as you use increase or decrease the rating. In my mind this seems more natural to me because you are mentally adding or subtracting from the score of whatever you are rating or reviewing.

Javascript != Solution

[Oz0ne]

I am very glad it degrades well, but javascript is never a solution. The goal of any web developer worth his salt is to make something universally compatible, intuitive, functional, AND good looking regardless of extensions or security settings.

It's a nice hack admittedly. Heck I may even use it on personal sites.

Re:Javascript != Solution

[t_allardyce]

Clients never ever want something that is universally compatible, intuitive, functional, AND good looking regardless of extensions or security settings.

Re:Javascript != Solution

[0BoDy]

I Develop Web Pages semi-professionally and I feel that using javascript to produce some basic functionality is the best way. As I see it the only alternative is flash, which I dislike becuase of the insecure way that it runs, and because I've always felt it was buggy and caused problems on the computer I use. I hate the installation process on linux, and javascript can completely replace it, SO I guess I just miss the point. The fact is, Javascript is as secure on firefox as flash or any other form of animation, so I think you're off base. ON the other Hand, Konqueror has really crummy support for it, so It's always good to make usre that basic functionality doesn't require the javascript, but so few developers realize they do the same thing when using flash.
Honestly how many people go without javascript on a regular basis? I'd be surprised to find out that anyone does, since almost every website in existence reguires it in some form or another, in order to function.

Re:Javascript != Solution

[Anonymous Coward]

I am very glad it degrades well, but javascript is never a solution.

JS is rarely a solution IMHO.

Just like Flash is 99% bad (there are times when you want a multimedia experience--mostly with animated web comics), JS is 90-95% bad.

Re:Javascript != Solution

[C. E. Sum]

The goal of any web developer worth his salt is to make something universally compatible, intuitive, functional, AND good looking regardless of extensions or security settings.

Funny, I always thought the goal of a (web) developer is to develop a project based on the requirements at hand. As a rule of thumb, the goals you state are good ideas. But saying the JS is never a solution is .. well .. stupid.

Would you also say that the goal of any Windows developer is to have their applications run on Windows 3.1? Requiring the client to use JS (or Flash or whatever) may be a bad idea, but never is a long time. There is a time and a place for even these technologies.

It seems expecially benign when (as in this case) the goal is to enhance the experience of users who happen to be running it, rather than requiring them to have it to access the site.

Heck, even The WASP has a JS include at the top of their landing page!

Re:Javascript != Solution

[C. E. Sum]

expecially -- I can't be bothered to check my spelling, apparently. :P

Re:Javascript != Solution

[Anonymous Coward]

I Develop Web Pages semi-professionally and I feel that using javascript to produce some basic functionality is the best way. As I see it the only alternative is flash

Er, there's HTML. That gives you basic functionality. If you are using Javascript for basic functionality (as opposed to optional enhancements), then you aren't doing it right.

ON the other Hand, Konqueror has really crummy support for it

Specifics, please. I find it to be better than Internet Explorer's support (which isn't a surprise, but still...).

Honestly how many people go without javascript on a regular basis? I'd be surprised to find out that anyone does, since almost every website in existence reguires it in some form or another, in order to function.

Huh? try switching off Javascript in your browser. You'll find that very few sites fail to function.

As for users without Javascript, the last stats I saw were about 10% about two years ago. There are lots of reasons. Search engine bots don't implement Javascript, but you still want them to see your content, don't you? Blind users usually prefer to switch it off. Corporate firewalls often filter it out. CERT recommends users switch it off.

Missing the point

[illtron]

A lot of people seem to be missing the bigger point here. It's not that he's replacing checkboxes with images, it's that he's managing to do it while keeping the page properly structured and accessible to all browsers. While the page isn't quite all the best HTML underneath (what's with the tables?), if you look at the forms, it's proper HTML and not some javascript hack that will break old browsers.

I think that's the point, anyway.

Re:Missing the point

[wodeh]

(what's with the tables?)

I'm lazy.

And, yes, that is half of the point. The other half is the global accesibility but some people are complaining it does not work quite as I expected- despite the fact I tested the script in recent versions of IE, Firefox, Opera, Camino, Safari and Netscape. Back to the tweaking board, I guess!

On a side and slightly off topic note- I don't think there is any point in complaining about the news-worthyness of Slashdot articles because they all inspire very interesting and entertaining conversions which are quite often read instead of the actual article. At least by myself, anyway.

Re:Missing the point

[Kozz]

Regarding the HTML underneath, I agree. However, I'm curious if you know of a good way to display his "Rating" boxes (1 - 10, poor, avg, good) without using tables.

I try to eschew tables whereever possible, but I don't think you can do this w/o tables unless you're using divs with absolute positioning -- am I right, or wrong?

Re:Missing the point

[illtron]

Unless it would be screwed up by the form somehow, which I don't think it would be, you could probably format them very nicely using a list. Oh the things they can do with lists these days!

Re:Missing the point

[Kozz]

side-by-side, equal-width boxes, using
<ul>
<li> item </li>
<li> item </li>
</ul>
?

Please do demonstrate. Sure, I can tweak the styles, but how do you get the LI element to not cause a line-break? If you give them "display: inline", then any use of "width" is ignored (In FF, anyhow, but not in IE).

I've been coding HTML by hand for a long time now, using CSS for far less time, but I'd love to see a demo or sample code. Here's mine, what am I missing?
http://kozz.dyndns.org:81/~kris/list.htm l

Re:Missing the point

[accessdeniednsp]

li.fw {
width: 150px;
margin: 2px;
float: left;
background: lightgrey;
list-style-type: none;
}

I added 'float:left' and that snapped it into shape. Since 'li' is a block-level tag (it forces a break like 'div', etc), then you can position it. In that case you can leave 'display' set to it's default value.

Hope that helps.

Re:Missing the point

[Anonymous Coward]

It's amazing how the rabid anti-table people will lie to push their agenda.

First off, you do a horrible thing in setting a size with pixels. How do you know how many pixels wide a certain bit of text is going to be? You don't. You should never do that. You should have never given that as an example. It will work when, for example, working with 150 pixel wide images, but it will never work for text.

Also, you are placing the items hard against the left margin. Most people want things like that centered. Since the W3C people hate people that actually do web pages for a living, they do not allow us to do "float: middle". Floats are useless unless you are jamming things against one side of the containing block, like for a menu on one side or the other or both. W3C shows their hatred again.

PS: I have students that could do what the original poster wanted to do with tables after only three weeks of class. Instead of just doing things the right way with a table, the W3C wants to ruin web pages.

Re:Missing the point

[lixlpixel]

CSS:

ul { display: table; }
ul li { display: table-row; }
ul li span { display: table-cell; }

HTML:

<ul>
<li><span>hello</span> <span>world</span></li>
<li><span>slash</span> <span>dot</span></li>
</ul>

this will do it, hope that helps...

Re:Missing the point

[Anonymous Coward]

It's amazing how the rabid anti-table people will lie to push their agenda.

Where did he lie?

First off, you do a horrible thing in setting a size with pixels.

So use percentages. It's not crucial to the technique to use pixels.

Also, you are placing the items hard against the left margin.

So use text-align: center. The alignment of the text isn't crucial to the technique.

Since the W3C people hate people that actually do web pages for a living

Cite please. Where did the W3C say that?

they do not allow us to do "float: middle".

You don't know what floating is. "float: middle" wouldn't centre the text. You have misunderstood the code. float: left is what arranges the li elements from left to right.

Floats are useless unless you are jamming things against one side of the containing block

Obviously not. This is one example of arranging things from left to right with floats.

W3C shows their hatred again.

Cite please.

I have students

Yeah, right.

that could do what the original poster wanted to do with tables after only three weeks of class.

ONLY THREE WEEKS? SURELY THAT CAN'T BE SO!

the W3C wants to ruin web pages.

Cite please.

PS: Is your name Alex or Andras? Your trolling style is very familiar.

note to author

[strider44]

Is it so hard to have those css and javascript scripts in the same html file so it's easy to just use "view source" as opposed to scrambling around to three different files?

Re:note to author

[0BoDy]

it's easier to use his code this way, I apreciate it. Also its good form to do it that way.

Accessible??

[dFaust]

I tried these in both Opera 8 and IE 6 and couldn't activate/de-activate any of the controls with the keyboard. Am I the only one having this problem??

Accessibility my arse.

Re:Accessible??

[AttilaSz]

My results:

IE6: space and enter can't push the button
Opera8 (my primary browser): tab can't select the button.

Sheesh...

Re:Accessible??

[Anonymous Coward]

I'm using Firefox/1.0.4/Linux and I don't get the same semantics when using Javascript or not. If I'm not using Javascript (no cute inputs) I can change the state using the space bar and I can submit using Enter. But, if using Javascript spacebar moves a page down changing the input state and enter just changes the state but doesn't submit the form.

Re:Accessible??

[Sentry21]

This fails also in Safari - the first tabbable element on the page is the button. Shift-tabbing up from that lands me in the tab (as in tabbed-browsing) area.

Ten points for style, but minus several million for accessibility.

Re:Accessible??

[Fulkkari]

What? Tabbed browsing works fine in Safari with tab + enter. Tab + space on other hand does not work. The only problem is that you can't see which element is selected. Personally though, I rarely use tabbed browsing and wouldn't even have checked it if it wouldn't have been mentioned here.

Works with space and tab?

[matth]

OR NOT.. using Mozilla... when I hit space it checks it and ALSO moves me to the next page!!! Not how it is suppose to work.

Re:Works with space and tab?

[oreaq]

It doesn't work in Safari either.

And they are an ergonomic nightmare. Principle of least astonishment: do not surprise your user. There are good reasons why GUI elements look they same in all applications, or at least they should.

Nothing new

[JPortal]

What he's doing is certainly useful, but not new. I could just as easily say that WebDDM is a solution to the age-old problem of styling menus... but people have been doing that for years. (Not that WebDDM isn't great :p)

Check Boxes and Radio Buttons Conquered by DHT

[damicha]

why is this limited to polish graphics artists? ;-}

Broken Standards

[Anonymous Coward]

This also breakes usage by embedded non-updateable systems like the Jornada line. These browsers were developed to work with STANDARDS because they are STANDARDS.. If you write your page in CSS - standards compliant browsers will not be capable of vieing it, will it? Will you bother to keep a seperate copy of the site to the standard or will you choose to not do business with them. If your planning on saying that the standard changes so buy a new system and get up to date.. Then the standard isn't much of a standard now is it. Perhaps we should start adding a date stamp so buys are aways that the HTTP that their system is design to work with now may not work at all a month from now becuase the standard changes.

doesn't work for me

[real_smiff]

Tab works, but Space does nothing (or in Firefox (Deer Park Alpha 1), it scrolls the page down as normal). IE6 has the same problem plus the icons flicker horribly when moused over. maybe i'm missing something?

Re:doesn't work for me

[Inda]

My first thoughts about the flicker was that the images aren't preloaded.

It's a common mistake. When you're working locally you don't notice. After uploading to the server you notice a slight glitch, but it never came back, so why worry...?

Nice idea. Nice attempt at a solution but it still needs a lot of work.

Re:doesn't work for me

[ubernostrum]

IE6 has the same problem plus the icons flicker horribly when moused over. maybe i'm missing something?

That's an IE bug the author apparently wasn't aware of; when you set certain properties with background images in CSS, IE will, for some reason, request a fresh copy of the image on every single mouseover event. There are a few ways to work around it.

Keyboard functionality is missing

[mdbelt]

This looks nice but, as many seem to forget about, the keyboard functionaility (eg: Tab then Spacebar to select) just isn't there. I have several users that still don't feel comfortable with a mouse.

Re:Keyboard functionality is missing

[tuffy]

This looks nice but, as many seem to forget about, the keyboard functionaility (eg: Tab then Spacebar to select) just isn't there.

Except that is is there. The checkboxes and radio buttons work with Tab and Spacebar/Enter to select. I just tried it with Firefox. TFA even says "Being an accessibility advocate and lover of CSS/XHTML design the solution had to be both accessible and fall back nicely to unstyled radio/check boxes where support is not available."

Re:Keyboard functionality is missing

[generic-man]

I'm using Mozilla 1.7 and spacebar acts as "page down" when I try using it to check the special boxes. The only time it actually checks/unchecks the box is when Mozilla can't page down any further.

Now I'm not about to upgrade to Mozilla 1.8.2.3.5-pr3 Alpha 7 Combo 65 (Marvellous!) just so I can play with fancy check boxes.

Re:Keyboard functionality is missing

[mdbelt]

It looks like keyboard support is flaky & browser version dependent. I'm using Firefox 1.0.4 on XP2 box with a standard english keyboard layout. Just like 'generic-man', my space bar is a "page down" when used with these customized controls. Thanks for the back-up 'generic-man'!

Seriously dude....

[Anonymous Coward]

WHO CARES??

DHTML is Dead Long Live CSS

[Anonymous Coward]

I'll bet he'll have an erection for a month. His mother must be so proud.

SVG based widgets?

[4of12]

After a couple of decades experience with developing windowing widget toolkits on multiple platforms, would it be possible for the W3C to come out with specifications for widgets, themes, etc. using SVG?

Re:SVG based widgets?

[kryptx]

It's really too bad that SVG hasn't been more widely accepted. It seems obvious that it should, given the popularity of such technologies as Javascript, XML, and CSS and in consideration of problems like the one described in TFA.

It seems like it should be relatively easy to add a graphical style property to CSS3 for certain elements that COULD point to an SVG file. This would also force the browsers to include some rendering capability to allow more websites to utilize this format. I for one am in favor of this idea.

Re:SVG based widgets?

[mlk]

It requires some good implementations first.

Re:SVG based widgets?

[kryptx]

Don't you think native recognition of this spec would be preferable to including third-party implementations? For the sake of consistency, at least?

Even if not, or if there's some common knowledge about SVG that I lack, what's wrong with Adobe's viewer?

Re:SVG based widgets?

[mlk]

Don't you think native recognition of this spec would be preferable to including third-party implementations?
Yes very much so, but browser-native implementations are still implementations. And look at the browser-native implementations, IE - none existent, Moz - early beta.

wrong with Adobe's viewer?

Partly what you have just mentioned, its not browser-native.
If you are an OSS Zelot, then well its not OSS.
Does not ingrate too well with Moz (for me, it open MSIE with an embeded Adobe SVG frame!)

Slow News Day

[adinu79]

Definetely a slow news day on Slashdot today. What will they report next? Seeing the back of your head finally possible thanks to an ingenious mirror system. Sheeesh.

Re:Slow News Day

[Glog]

WTF do you want as news? Another "Debian version 1.02103219032.213 has been released"?

JavaScript yes, Images no...

[Anonymous Coward]

This is not a degradeable, accessible solution. If I have JavaScript enabled and images switched off, what do I get? big empty spaces. Not really ideal.

[And it's the kind of thing that's been around for two or three years at least...]

Re:JavaScript yes, Images no...

[Krojack]

I agree.. This is cool however it needs to be 100% CSS only and no JavaScript code.

Re:JavaScript yes, Images no...

[Anonymous Coward]

plain text is much better, and usenet is more useful than all these funky buttons. Ask Linus, he knows for sure.

It's about time 1

[AtariAmarok]

"What will they report next? Seeing the back of your head finally possible thanks to an ingenious mirror system. Sheeesh."

It's about time! Once my son wrote "Insert Brain Here" on the back of my bald head. I was laying on the floor, spinning around for hours trying to read it before someone finally told me what it said.

Not quite done..

[Icephreak1]

That's fantastic. Now only if CSS could conquer my creditors, that would be peachy.

- IP

Wow!

[JCY2K]

Oooh! Pretty!

AWESOME!!!!!

[Ced_Ex]

Now I can make my circle checkboxes and my square radio buttons!

Konquerer...

[friedmud]

In Konquerer tabbing between the checkboxes works... but when you press space to check/uncheck them it tries to scroll down the page instead of checking the item....

That said... I'm sure it's a browser problem. This is some interesting work... and I just might put it to use.

Friedmud

Re:Konquerer...

[Anonymous Coward]

Try hitting 'enter' ;)

Re:Konquerer...

[spac3manspiff]

it works with pressing Enter and Space.

Re:Konquerer...

[ubernostrum]

That said... I'm sure it's a browser problem.

Probably it's caused by the fact that the form elements aren't actually form elements when JavaScript is enabled (they're programmatically replaced with the images), and so the usual form-element shortcut keys don't work on them.

YES

[Anonymous Coward]

SEPARATION IS THE FUTURE!!!

Not a solution

[Zebra_X]

Yes using images as form elements can work. Integrating them server side is difficult.

Though my real beef: every mouse over causes a *flicker* of the image.

End users don't like "wierd" behavior in user interfaces. There is no reason that the image should disappear and re-appear when the mouse goes over the image. This behavior gets worse as the connection speed of the user decreases.

This sort of behavior makes people who are not fully comfortable with the computer uncomfortable reducing their desire to interact with an application that behaves in this manner.

The flicker bahavior has also become rampant in drop down menu and site navigation everywhere. Back in the day we used to cache images but now we just accept sub-standard UI behavior because caching images "is a pain".

My 2 cents

Re:Not a solution

[Krojack]

What browser you using because i get no flicker at all using firefox 1.0.4 even with my PCI Matrox G450 video card.

Re:Not a solution

[Zebra_X]

I.E. 6 - Just after I submitted the post a thought occured to me: perhaps it's because i have all caching disabled i.e. this does seem to be the case lol. Firefox does not have an option for this, I'm not sure about safari.

Chalk one up for the bug list.

Re:Not a solution

[LesPaul75]

Agreed. The flicker is pretty annoying. It looks like it might be an IE-only problem, though.

Netflix ripoff

[Petronius]

Netflix's UI had that for ages. Yawwwwnnn.

Degradation?

[PeteDotNu]

Using the famous Web Developer toolbar (0.9.3) on Firefox, with JavaScript enabled and Images disabled, I see nothing at all.

Which is pretty much what I would have expected, but if people start using this method on websites then I'll get mighty annoyed.

amen, brother.

[Schwartzboy]

The number of marketroids I've met who actually know about Javascript is vanishingly small, like maybe two whole people. The rest of them simply break it down into its component parts to figure out what it means. Since the word is a combination of both "Java" and "script", it's obviously a set of pre-rehearsed lines that, when spoken, spur your marketroid intern to action so that he/she will bring you more coffee.

If you think that's bad, let me tell you about the months I spent trying to explain to a management-type that wanted us to do absolutely everything in XML. Lucky Charms form widgets? Sure! "Can you guys do them in XML? That's the language that we should be using for all of our projects now. Thanks!" Stupid buzzwords. *shudder*

Re:amen, brother.

[iamlucky13]

I had to dig back a bit through my Dilbert calendar:

PHB to Dilbert in his cubicle: I needed to make an engineering decision about your project this morning. You'll need to act like you agree with it so I don't look stupid (at the meeting).

Manager at meeting to Dilbert: Explain to us how fiber capacity can be increased by serial input at breakfast.

One more. The setting is in a meeting after the PHB just got restored to his managerial position after being temporarily demoted to engineer.

PHB: Let's ping the director of marketing and double-click on the budget. Then we can interface in batch mode and put a scope on his bandwidth

Alice: Please stop doing that!

PHB: Have I mentioned that I was an engineer for a week?

Re: Check Boxes and Radio Buttons Conquered by DH

[Tromeo]

It's nice to know that at least *someone* didn't forget Poland.

Javascript Image-Swaps are news?

[Mirkon]

Not to offend the guy, I mean it's nice to make something like this as a tutorial, but this technique has been implemented for many years. Saying that the lack of CSS coverage for radios and checks has been "conquered" by the Javascript image-swap is rather stretching it.

HORRIBLE idea

[Anonymous Coward]

My OS makes widgets look a certain way. Most software makers will either use the native widgets or try to mimic it.

STOP MAKING MY USAGE OF YOUR SOFTWARE INCONSISTENT W/ EVERYTHING ELSE!

Well, not quite perfect.

[demon]

Just tried it with Opera 8 on Linux - all the images get doubled up, and the bottom-most group of "radio buttons" only displays one (doubled) item instead of all 5. Guess it still needs some fine tuning.

Somebody please "conquer" the FILE input element!

[MaGnA_at_Slashdot]

File input elements are the most annoying when it comes to UI style inconsistencies.

I had a failed attempt at replacing a file input element with a text input + graphic button, due to the way the default "browser" button inconsistently works across browsers and for some obvious security reasons (like silently making the browser submit an arbitrary file from the local disk). This was a while ago and I don't know if it's still impossible. Has anyone succeeded in replacing file input items with custom visual elements?

gmail...

[Fusen]

isn't this the same as what gmail uses, and that's been out for quite awhile now.

Re:gmail...

[Random Web Developer]

technically gmail isn't out yet
as far as i can see the top left icon still reads "beta"

Re:gmail...

[Fusen]

well seeing as its public beta, and there are numerous sites that offer free invites such as the closed isnoop site which gave away more than a couple hundred thousand and now www.bytetest.com which has grown to 51,000 invites over a couple of days. Your comment doesn't really stand up just because google like to keep their products in beta for an unusually long period.

Accessibly

[Anonymous Coward]

As other people mentioned the tabbing is not performing properly but in addition people need to be careful about using color for meaning. If your user is color blind they might not be able to tell if a box is checked or not. Therefor, it is not accessible.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Somebody please "conquer" the FILE input elemen

[Krojack]

I feel your pain...

Box Button Bob Responds:

[the web]

"Even at this moment our buttons and boxes are crushing their .'s and #'s"

Kinda kludgey.

[Grendel Drago]

Shouldn't this be accomplished by styling form elements via some sort of CSS thingy? Isn't that why we have CSS?

--grendel drago

Re:Kinda kludgey.

[tuffy]

Shouldn't this be accomplished by styling form elements via some sort of CSS thingy? Isn't that why we have CSS?

It certainly should. Unfortunately, no browser I'm aware of supports applying CSS styles to radio buttons or checkboxes. Until one does, I'd rather do without than apply this sort of JavaScript hack to it.

File?

[somethinghollow]

We need support for input type="file"...

Re:File?

[ubernostrum]

We need support for input type="file"...

Try this.

Not Conquered!

[AutopsyReport]

Unfortunately for the author, this page renders terribly in Internet Explorer 6. Anytime I hover over the checkboxes or radio buttons, the graphics momentarily dissapear. I can even manage to get two checkboxes beside each other to dissapear by aligning the mouse in the middle. Not good.

However, it renders fine in Firefox. Nevertheless, when it's not compadible with Internet Explorer, I'd hardly call this issue conquered.

Re:Not Conquered!

[Laplace]

Did you consider that while you're loading a small image, the page itself is being slashdotted, so even small images will take a noticeable time to load?

Re:Not Conquered!

[AutopsyReport]

They appeared and dissapeared on hover, so that means they were loaded. Besides, I had the page up for over five minutes (loaded it and left to go do other things), came back, and that's when I noticed the problem.

Re:Not Conquered!

[ubernostrum]

The flickering is due to weird behavior in IE with some cache settings; when certain background properties are used, IE requests a new copy of the image on every mouseover event. This can be fixed by a couple of different workarounds on the server side, or by changing your IE cache settings.

Radios and Checkboxes aren't the problem...

[Anonymous Coward]

Dropdowns are.

Problems with them being OS-driven rather than application driven elements, problems with layering them (especially with Flash), inability to properly apply styles to them, different heights/widths in different browsers/OSes, the list goes on...

As far as I can tell here, he hasn't done anything new, just plonked some wrappers around elements. It's a nice trick, but certainly one that's been used before.

Flicker Problem

[milimetric]

There's a little flicker problem when you first use the page. I haven't debugged it or looked at it for more than a few minutes, but it's probably fixable by pre-loading the images so that when you first access them it doesn't have to get them from the server.

Labels

[sykjoke]

I suppose the real question is are they still accessable? can you use label and group tags like you can with normal input tags? BTW, you can style firefox form elements moderately well if you remove an !important that some idiot put in firefox's css for form elements,

Re:Somebody please "conquer" the FILE input elemen

[Anonymous Coward]

input type="file" is intentionally that way. Think about what someone malicious could do if they could implement their own file browser and have it run *on someone else's machine*.

Re:Slap the Stupid out of Everyone

[Anonymous Coward]

You, sir, are my new hero.
Congratulations.

Though, I may note that sysadmins have been using this philosophy for quite some time - in the form of LART.

Icky. Browser checks.

[BigZaphod]

It'd have been much more impressive if he had done this without any browser checks. It's hard, but frequently it can be done. I recently hacked together the Game of Life using Javascript and CSS and no browser detection tricks. It works on Mozilla, IE, Safari, and Opera (the latest versions, anyway). I just wish it wasn't so slow. Ah well. Ya win some, ya lose some...

Think Outside the Little Star

[Vagary]

The example the author uses is to replace the standard widgets with cutesy ones. This is probably a degenerate example.* What has really been implemented here is to add checkbox and radiobutton semantics to any element. Consider:

• Managing a shopping cart with thumbnails of the actual items rather than names
• Being able to control selection of paragraphs or words in an editing application (think Gmail spell checker?)
• Manipulating rich HTML elements like IFRAMEs for who-knows-what-killer-app

What I really like about the approach is that from a developer perspective (eg: PHP form parser), I can pretend that it's just a regular web form, while my user may perceive it as much friendlier and more fun.

* If you're going to be a degenerate, maybe you should just use Flash like the rest of your kind.

Re:Think Outside the Little Star

[Anonymous Coward]

What has really been implemented here is to add checkbox and radiobutton semantics to any element. Consider:

• Managing a shopping cart with thumbnails of the actual items rather than names
• Being able to control selection of paragraphs or words in an editing application (think Gmail spell checker?)
• Manipulating rich HTML elements like IFRAMEs for who-knows-what-killer-app

Er, what? None of those things are remotely connected to checkbox and radio button semantics. The first one would be fucking annoying. The second one is already possible. The third one is so vague it means nothing at all.

Re:Think Outside the Little Star

[Vagary]

I mean *applying* the semantics to those things. My point is that what pages need is a why to say "these things can be selected, but only one of them", and then leave the nature of the things and how selection is signified to the presentation layer. And you only think managing a shopping cart with thumbnails would suck because you're a technophile. My grandmother would dig it.

Re:Think Outside the Little Star

[Linus Torvaalds]

And you only think managing a shopping cart with thumbnails would suck because you're a technophile. My grandmother would dig it.

Classic usability mistake of assuming graphics makes things easier. This is only true some of the time, and replacing an actual product name with a little picture would be a disaster for grandmothers. I'm a technophile, I can figure out from going back and forth between the pages what's in my cart. Grannies would be stuck squinting at little icons trying to figure out the few pixel difference between different types of cardigan or whatever.

It's thinking like yours that has produced some of the biggest usability disasters of the web, things like "mystery meat navigation" etc. Bells and whistles are usually counterproductive to usability, they certainly are in the examples you gave.

Fucking graphic design majors

[Thaelon]

One of the most fundamental concepts of good UI/GUI design is that you DON'T INTRODUCE NEW THINGS.

Everytime you introduce something new the user has to learn how to use it or what the fuck it is. This is bad. Really bad. You just won't believe how vastly, staggeringly, jaw-droppingly bad it is.

It may seem incredibly anal, stale and anti-progressive but that's the whole point. There's no such thing as an innovative interface because innovation has connotations of something both new and better. In the realm of Human Computer Interaction (HCI) new and better are mutually exclusive. Good UIs are simple, intuitive and introduce absolutely nothing new. Ever.

There are only two truly intuitive interfaces in existance. The nipple and the vagina. The rest you have to learn how to use.

Save the styled checkboxes and radio buttons for other people in your yuppie coffee house. Your average user doesn't want them, won't understand them, won't appreciate them and doesn't care what they look like.

Re:Fucking graphic design majors

[Anonymous Coward]

Your wife called. She says she's leaving you for someone who realises there are no truly intuitive interfaces in existence, and you have to learn to use all of them.

Re:Fucking graphic design majors

[JChung2006]

There are only two truly intuitive interfaces in existance. The nipple and the vagina. The rest you have to learn how to use.

That explains a lot about your sex life (or lack thereof).

Re:Fucking graphic design majors

[Anonymous Coward]

Thaelon : Building a bridge to the earliest days of computing!

Mouse: Bad because you have to learn to use it
GUI: Bad because you have to learn to use it from the CLI

By your logic, the best home computer would be something on the lines of a Vic-20. Because God knows we don't want programmers to have to learn to program with more than 5k of RAM, and we don't want consumers to have to learn to use something as strange and complicated as a disk or a CD.

Grow up; not all progress is bad, and while I don't see this as a breakthrough new feature or item that will help revolutionize things, you need to realize that not all progress is negative.

Re:Fucking graphic design majors

[AutopsyReport]

There are only two truly intuitive interfaces in existance. The nipple and the vagina. The rest you have to learn how to use.

Spoken like a true virgin.

Re:Fucking graphic design majors

[diamondsw]

There are only two truly intuitive interfaces in existance. The nipple and the vagina. The rest you have to learn how to use.

Some slashdot readers may disagree.

Re:Fucking graphic design majors

[RosenSama]

I don't agree with this in two different ways.

#1 "new and better are mutually exclusive"
You are saying there is no way to improve UI. If new (change) is mutually exclusive with better than then only thing left is old (unchanged). Without change, there's no way to get better leaving a permanent status quo. By adhering to these arguments we'd still have rotary phones, analog clocks, and the command line.

#2 They didn't introduce a new UI element, they just learned how to make existing ones match the page.

Re:Fucking graphic design majors

[dr.badass]

Good UIs are simple, intuitive and introduce absolutely nothing new. Ever.

Care to give an example?

Everytime you introduce something new the user has to learn how to use it or what the fuck it is. This is bad.

It's only bad when it detracts from the task at hand, or takes up time without adding any new capability. If it takes 10 seconds for a user to learn what a new widget does, but it enables them to do do something they couldn't do before, then there is nothing wrong. If it takes 10 seconds to learn and doesn't make anything better, then it's staggeringly bad.

Re:Fucking graphic design majors

[Xepherys2]

Wow, I'm sorry, Windows 3.1 was newer AND better than DOS. Windows 95 was CERTAINLY newer and better than Windows 3.1. Holy crap, Windows 2000 was even BETTER STILL! What? Windows XP? OMFGWOWOWOWOMFG!

But seriously, how can you really believe this? it's not "anal, stale and anti-progressive", it's... well... ignorant. I'm not trying to troll, and to put that foot forward, I'll explain myself.

Interfaces are constantly changing. They have to. If the interface does not change, it means there are no new features. If there are no new features, it means that we are not getting something out of a product that we could. If you remember the "bag phone" from the 90's. The "portable" cellular phone in a bag for your vehicle. It was big, heavy, bulky and could call people and that's about it. Do you have a cellular phone now? Do you use text messaging? Do you use the web on it? I don't know, maybe you don't, but a LOT of people do!

What OS do you use? VAX? HP/UX? I'm sure you use something with a modern interface since you seem to like "simple GUIs" and those OSes are CLI. So then, what version do you use? Something old? MacOS 6.x? Windows 3.0/3.1?

There are infinite innovative interfaces. Also, humans THRIVE on learning new things. While many people are technophobes and/or have difficulty learning new things, learning and adapting keeps your brain strong. Innovation fuels innovation. Without it, the human intelligence average would slowly decline. Is that what you want? More ignorant people (more as a quantity AND a quality)?

*sigh*

Re:Fucking graphic design majors

[Stick_Fig]

I can't believe how fucking wrongheaded this statement is. It basically emphasizes that no growth should happen in user interface design.

By this logic, we should all still be writing on cave walls, walking around naked. I should still be designing newspapers on a linotype machine and have headlines going six layers deep.

I think what you MEANT to say was this: Don't sacrifice convention for the sake of art. That's entirely reasonable and does not take away from evolution in interface design.

The fundamental you speak of is just not very fundamental if all it does is force us into a black hole where there's no room for growth.

My god, you're fucking closed-minded and conservative to new ideas.

Re:Fucking graphic design majors

[slackwalker]

we do still have rotary phones, analog clocks, and the command line.

Re:Fucking graphic design majors

[Thaelon]

Interfaces are constantly changing. They have to. If the interface does not change, it means there are no new features. If there are no new features, it means that we are not getting something out of a product that we could. If you remember the "bag phone" from the 90's. The "portable" cellular phone in a bag for your vehicle. It was big, heavy, bulky and could call people and that's about it. Do you have a cellular phone now? Do you use text messaging? Do you use the web on it? I don't know, maybe you don't, but a LOT of people do!

Change, yes. Improvement yes, but totally new an incomprehensible things? NO

I'm not sure where you get the idea that if the interface doesn't change then there are no new features. You're still using a keyboard and mouse aren't you? Do you have things on your keyboard that aren't keys or buttons? The only new interace to the mouse in.....ever? is the wheel.. Additional buttons are not new features, just more buttons, optical tracking/laser tracking aren't new forms of interface, just better tracking. You still move the mouse around and click buttons. You still press keys on your keyboard with your fingers.

I never said interfaces can't be improved, just that newfangled interfaces do nothing but increase the learning curve.

What OS do I use? Funny you should ask. Funnier that you use VAX and HP/UX as examples. At home I use 2k/XP. At work I use OpenVMS, HP/UX, Concurrent OS, Solaris 8/9/10, Win2k3, XP, 2000. VAX isn't an OS it's a platform that runs OpenVMS.

Don't be so sure next time. I use modern interfaces as well as CLI. I actually prefer CLI for a lot of the things I do at work. As far as application development I think I like good old vi as much as I do Visual Basic .NET's IDE.

You talk alot about interfaces but only use operating systems as examples. Mice are interfaces, keyboard are interfaces, buttons are interfaces, radio buttons, check boxes, sliders, scroll bars, drop downs etc. What new interfaces have you seen since windows 3.1? As near as I can tell it's still radio buttons, buttons, scroll bars, text boxes, pulldowns, checkboxes, icons and windows.

Way to talk out your ass.

Re:Fucking graphic design majors

[Thaelon]

http://www.frankmahler.de/mshame/ShameRecent.htm

Re:Fucking graphic design majors

[Omega Blue]

#2 They didn't introduce a new UI element, they just learned how to make existing ones match the page.

It's nice and all... but how could a user tell wether a bunch of stars are just a bunch of stars or are actually checkboxes in disguise? Nielson is correct that Web surfing is a collective experience. Each individual website does not, and should not, standalone. Mucking with what users are accustomed to at your own peril.

Re:Fucking graphic design majors

[Xepherys2]

Hmmm, my ass appears to have no speech leaving it. Odd!

Yes, CLIs ARE better for some things. I completely agree. So where does an interface change step over the magic line from "improvement" to "newfangled"? And yes, your argument regarding keyboards and mice are true, but I'm not sure how CSS/js-based buttons that make things look nice and allow for customization of a webpage is a "totally new an [sic] incomprehensible thing". It's a button. You click it. Same as every other web button.

Also, I wasn't "so sure" this time. I asked a question. That denotes a lack of certainty.

Is Windows 3.1 and MacOS X the same interface? Actually, MacOS X IS a different interface than MacOS 6.x.x. The nice little bar at the bottom that allows you to rotate through running applications. That's an interface. That's also new.

Technically, by your view point, Windows is no different than DOS. Ever use a program called EDIT.EXE? It has scroll boxes and menus and though it does not, other DOS programs has buttons as well. Midnight Commander even had icons in DOS. So I guess there hasn't been a new interface since the dawn of computing. How strange.

"Way to talk out your ass." indeed!

Re:Fucking graphic design majors

[Thaelon]

but I'm not sure how CSS/js-based buttons that make things look nice and allow for customization of a webpage is a "totally new an [sic] incomprehensible thing". It's a button. You click it. Same as every other web button.

There were no pure buttons on TFA. There were radio buttons that looked like normal images as opposed to interfaces. There were checkboxes that also looked ilke normal images. If not for the article explaining what they were I would not have known. Good interfaces don't need to tell you how to use them, they're intuitive. In the world of HCI, having to spend 3 seconds learning how something works is considered a sub-par interface. It seems picky but that's how you separate the acceptable from the best. If you have to do ANY learning before you can begin USING the interface then there is room for improvement.

Technically, by your view point, Windows is no different than DOS.

I never said anything of the kind. I never even mentioned DOS and if you think that's my viewpoint then you've completely misunderstood it. Leave the slipperly slopes to the playgrounds please.

Is Windows 3.1 and MacOS X the same interface?

I don't know who you're arguing with here but I never said that. In fact I never mentioned MacOS. So you can go right ahead and argue with your invisible friend or whoever it is.

Also, I wasn't "so sure" this time. I asked a question. That denotes a lack of certainty.

Funny, you said this:

I'm sure you use something with a modern interface since you seem to like "simple GUIs" and those OSes are CLI.

Sounds awfully sure of yourself to me.

Your ass is still talking for you I'm afraid. Good day.

Re:Fucking graphic design majors

[Anonymous Coward]

Wow, I'm sorry, Windows 3.1 was newer AND better than DOS. Windows 95 was CERTAINLY newer and better than Windows 3.1. Holy crap, Windows 2000 was even BETTER STILL! What? Windows XP? OMFGWOWOWOWOMFG!

-1, Microsoft marketing employee.

The best feature of Windows 3.1 was Program Manager -> File -> Exit Windows. Windows 95 was at the time the worst piece of crap ever to come out of Microsoft (disclaimer: I never tried DOS 4.0), and stayed that way until Windows ME. Windows 2000 sucked, and while XP is better than 2000, it still sucks compared to Windows 98 SE.

I've seen the installer for every Windows version claiming that this version is better than the one before. That doesn't make it true. The same installer usually claims that this version is FASTER than the one before, while the system requirements just doubled.

Wrong

[Paradox]

You do not want to service people using the services you've described with a solution like this.

Moble devices have such a varied degree of fidelity to even the most basic HTML that all beautification is a waste of time (unless, of course, you have a specific device in mind). This also stands for Text-To-Speech. You're better off having plain HTML for these scenarios. Case in point, his solution doesn't render on my phone at all.

Why?

Because my phone gets really confused by CSS, except for a very small subset that the vendor chose to support so they could prettify their website.

If CSS delivers the style, and the HTML still delivers the content, then those will continue to work.

Web developers wish this was true, but the sad story is that it's not. There are lots of people with broken or partial implementations of CSS, to which approaches like this are actually more destructive.

Quite frankly, Javascript has better downgrade characteristics than CSS, which is sad because CSS is a wonderful standard. But people tend to feel gung ho about implementing parts of CSS, but back off from Javascript.

nice, but ultimatily can't really use this

[Anonymous Coward]

I've worked with the web html/scripting/javascript/dhml for years now; i'm by no means a standards nazi, but I do recognize the need for them; and as time goes on I go more in that direction. However, in spite of this I still get seduced by these types JavaScript dhtml 'pretty' applications. Even after all these years of spending so much time working on this sort of thing and then having to abandon it because
a.) it doesn't work cross browser platform;
b.) it confuses users who are ultimately more interested in function and not form. In fact this type of application actually creates more function problems in the sense that it takes away features that users like with form (tabbing though them for instance).

the best measure for this type of thing is really does the javascript/dhtml widget add functionally or take it away? (this is especially true for form elements) - if it improves appearance all the better. This example degrades usability.

Stop saying, "a javascript"!!!

[Anonymous Coward]

I just fucking hate it when you retards refer to a Javascript source file or code fragment as "a javascript". The word Javascript refers to a fucking programming language. Do you say, "I solved my physics problem with a FORTRAN," or, "Let's rig up a demo interface with a Visual BASIC?" No, you don't, unless you're an idiot. Well, then for fuck's sake stop saying, "a javascript!!!!"

It's been said many times already...

[Anonymous Coward]

But it can never be said enough.

If Javascript is part of the answer then keep looking for a real solution.

The use of Javascript is almost universally unacceptable as a solution. It is completely unacceptable for something like a form input. It is marginally acceptable only for purely frilly decorative purposes that have zero functional effect on a website.

Re:It's been said many times already...

[Anonymous Coward]

Well you're quite the idiot, aren't you?

I don't like this one bit...

[imputor]

I don't like this one bit.. form elements are part of the OS chrome, and shouldn't be messed with. Users grow accustomed to their native OS chrome, and as soon as you mess with that, you run into all sorts of UI problems.

Similar examples are IE's proprietary scroll bar stylings, and the fact that you can't style form elements in Safari. There's a reason why changing your scrollbar color or styling your submit buttons is bad.

As stupid as it may sound, things such as scrollbars, buttons, input boxes, etc, should remain the same across all appplications on the system. The checkboxes in my browser should be the same as the checkboxes in my spreadsheet editor.

"pretty forms"

[vigilology]

Doesn't look too pretty without that most basic of attributes - the background colour...

Amazon.com already does this

[DanCentury]

Amazon.com's developers must have read this post, stolen the idea, built a time machine, and went back in time and implemented it, becuase they've done the very same thing with the "Rate this" check boxes on their site. Whoa.

I hope Amazon hasn't patented time travel too.

Small Surfing

[Sir_Eptishous]

Your comments are good, but assuming no one browses from PDA's is like saying no one plays PS on a PSP... If anything, more people will be surfing from these type of devices, not less.

I've been using an HP iPAQ (yea I know they're out of style) with MS Pocket PC. It's a blast to surf on this thing.

Not only does the BBC and MSNBC support this format, they are many other sites as well.

Here is a good site:
PPCVidz

Fucking Luddite GUI design majors

[Anonymous Coward]

"One of the most fundamental concepts of good UI/GUI design is that you DON'T INTRODUCE NEW THINGS."

Damn! Well there goes my ZUI.

New ideas abound

[intangible]

There's a hidden check box in this post, solid white, when you click it, it turns solid white! If you get it, and you find the white button with white text, you win my money!

Seriously tho, I hope this doesn't become too widespread, I hate searching around websites for the options I need to select, I just want to click and go, not figure out what the designer was trying to accomplish.

We need more elements

[scarlac]

This is all fine, and it's no news, i thought of doing this some time ago, but didn't really want to spend any time doing it as it just causes more confusion and slower page-rendering with little or no better user-experience.

What we need is a better file-form element :/ it's a horrible element that is impossible to style since it's really 2 elements in 1 - a browse button and a text field with the path.
I am not familiar with any other way to make file-elements with a possible way of styling them. And it seems every browser renders the element quite different which is a pain.

You must be new here

[ShallowThroat]

pretty much every form element has been conquered by CSS so far, letting us create stylish, integrated forms to tie in closely with our site designs for that UI polish graphics artists love to have.

Ummm, hello, welcome to slashdot. graphics artists? no where to be found.

out of touch

[InternetVoting]

Oh /. my /.. How out of touch have you become? This is not new. People have been doing this or similar Javascript\checkbox hacks for some time.

This is good for one reason - sizing

[codesmithsf]

Standard checkboxes and radio buttons are generally fairly small - doing a lot of form input (ex. surveys) can be really aggravating. This is a good way to get larger sized inputs - especially for mouse challenged people.

not quite there

[hairyfarter]

I think he released a bit too soon. His technique doesn't respect disabled=true attribute.

Re:not quite there

[wodeh]

Aha, I never thought of that one! Should not be too difficult to implement though, if anyone adds a disabled form field I will just add some javascript to crash their browser with a billion popups. Well spotted!

Still holding out for Quantum Checkboxes

[SlightlyMadman]

I'm still holding out for Quantum Checkboxes. Let me know when somebody comes up with one that fully supports "maybe" and we'll talk.

Re:Still holding out for Quantum Checkboxes

[multipartmixed]

Mine do, but only when you're not looking at them.

Re:Still holding out for Quantum Checkboxes

[SlightlyMadman]

If they meow when you click on them, I'm sold!

What's new here?

[stonecypher]

This is hardly new. I first picked up the technique of plopping down two images and styling one of them to invisibility to simulate radio buttons and check boxes something like four years ago. When I had to make a DHTML application for work, I got them right on the first try.

If this is a big enough deal to hit the slashdot front page, perhaps someone could list the other things that are supposedly hard? This one took me ten minutes; maybe I can solve some others, and get some front page traffic of my own.

Re:What's new here?

[pooShooter]

uh, wow, u sound talented. Where do you work?

Stupid graphics!

[p3d0]

Graphics can be used to show pictures of a gentleman spreading his anus to an unnatural size. Ban all images on web sites!

Problem here

[christoofar]

Even though this is a nice solution, the problem is that most users have been used to the fugly styles of radio buttons and check boxes for so long, that most users won't know that these new styles are clickable (they will think they are just static images).

That differs from a standard windowing UI application where the user subconciously knows what is clickable and what isn't. With the browser we have become so ingrained to knowing that "such and such is a picture, it does nothing when you click on it" that I'm afriad it's too late to use this technique with any effect.

Custom Attributes

[scovetta]

I haven't seen this done anywhere, but you can add your own attributes to tags:

<input type="radio" subtype="skin1"/>

You access it by grabbing the element (via JavaScript/DOM):

x = (the element)
a = x.getAttribute("subtype");
if (a == 'skin1') {
(do something)
}

The syntax might be slightly off (getAttribute might return an object that you have to .getValue() of), but you get the point. I've used this to do some fancy schmancy validation by adding event handlers on the fly (that way your logic is bundled up in a .js file, and your html is clean(er)):

<input type="text" validate="integer"/>
<input type="text" validate="customer_id"/>

Re:Custom Attributes

[AKAImBatman]

I have actually tried that before, but I've found it to be a bit dangerous. Web Browsers often regenerate the HTML content based on their DOM tree. As a result, they often lose any tags or attributes that they don't recognize. It shouldn't be a problem in IE or Mozilla, but it's probably not the safest scheme. :-)

Problems with Firefox

[Anonymous Coward]

Neither the radio buttons or checkboxes rendered *at all* with Firefox-1.0.4 on Linux. I made sure JavaScript was enabled, and that I wasn't blocking images from other than the originating Web site (which I usually am). There are a few extensions installed: Flashblocker, Download Manager Tweak, etc. Probably, they would all be considered very mainstream by most Slashdot users.

So, yes, there can be rendering issues with Firefox as well.

Neilsen and Tufte are rolling over in their graves

[Pvt_Waldo]

Oh wait, Jakob Neilsen and Edward Tufte aren't dead, are they? They'll cough up a hairball if they see this though.

It is so sad to see this kind of diffusion of UI styles that this, and every program like Winamp etc. offers with new "skins". I want to just use my computer, not hunt for the UI elements. "Oh, the clown's nose is a checkbox, and his shoes are radio buttons! AWESOME USER INTERFACE DESIGN MAN! THIS IS SO INTUITIVE! I CAN'T WAIT FOR THE NEW GARDEN GNOME INTERFACE!"

Doesn't anyone remember back when the Mac and Windows came out, how it was fantastic that we had a CONSISTENT user interface? How we didn't need to learn yet another persons crazy GUI scheme? How developers didn't need to hack up custom UI designs using graphics primitives but instead could call simple SDK calls?

And think of HTML. Why in the WORLD would I want to install all that "stuff" when I can just say...

<input type=checkbox name=foo value=bar>CHECK ME

Re:Somebody please "conquer" the FILE input elemen

[Anonymous Coward]

There is a way to do this, although it's a bit of a hack. Basically you make a separate text element, and an image for a button. You make your actual file control invisible (using opacity of 0 in all its different variants, NOT using visibility or display) and position it using CSS so that the button is over the image (it helps to use a 50% opacity for this step). Then you put javascript in the onchange event of the file box that updates the other text field so the user can see that they've selected a file (although the other text field doesn't have to post back to the server).

I complained to a webmaster once

[Anonymous Coward]

Can't change font size (whaddya mean you can't see my 6 point fonts, what are you, blind?)

about his tiny, unchangable fonts. I was nice about it, too. His reply? "Get some glasses, grandpa!"

Fuck him AND his stupid shite site. The dumbass.

I'm tired of just ignoring and tolerating stupidity and ineptitude and excuses. It has to stop.

Then quit voting Republican!

Re:Neilsen and Tufte are rolling over in their gra

[Xepherys2]

Wow, I completely disagree. Allowing customization and personal details to be used on the internet is a step forward, not backward. If you want a consistant interface, use linux with lynx, and it'll always be 'x' pt. with tabbable links. It's not pretty but it's consistant. Oh wait, you WANT it to look nice... that's right, that's what GUIs are for. If you don't like the garden gnome interface, protest by NOT visiting that site. If you really like the site that much, you'll get over the interface issues. *shrug*

Damn Slashdot!

[colinrichardday]

Why is it that if I submit in Plain Old Text, the html tags still get interpreted?

I meant to ask if emphasis in TeX/LaTeX worked the same as in XHTML.

Re:Damn Slashdot!

[Mornelithe]

Emphasis in LaTeX would go something like:

\emph{This is emphasized text.}

Some things in LaTeX are a little less structured than XHTML, I suppose. For instance, you delineate paragraphs with \paragraph at the beginning, but there's no closing tag. It's more of a "new paragraph begins here" marker (like people used to use in the old days of HTML).

Of course, that's just the default way to do it. You can make macros in LaTeX that will let you structure things almost any way you want.

Re:Damn Slashdot!

[colinrichardday]

But is this structured or physical markup? \emph will italicize text, and unitalicize it if the surrounding text is italicized. In XHTML, the emphasis tag might default to italics, but allows the user to display it as bold. This is what the great-grandparent was trying to say in comparing emphasis to italics.

I would not say that the lack of an end tag for \paragraph shows a lack of structure (the need for end tags is a rule of XML, not structured markup as such).

Also, while LaTeX is structured in the sense of structured programming, is it structured in the sense that the great-grandparent meant by "semantic"? As the output of LaTeX is usually only printed, this may not seem like much of a distinction.

Rather, the main difference between the two is that TeX/LaTeX is compiled, whereas XHTML is interpreted. The former gives the author a lot of control, at the cost of leaving the reader with a finished product. The situation is reversed with XHTML, as the reader has some control over how the browser renders. If one could display the source files in such a way that the reader could apply his own macros, then that would be closer to XHTML.

Another difference is that TeX/LaTeX has only to be printed, whereas XHTML could be displayed on a screen, printed, or converted to speech.

Patent?

[thesoap]

Has anyone filed a patent for this new technology yet? How about the book and movie rights? Are they still available?

Other problems

[SideshowBob]

Other comments have pointed out that these 'styled' controls break consistency.

They have other problems:
- don't work with keyboard input
- accept clicks anywhere in their region rather than just the control itself
- a click-drag should leave the control in it's current state and perform no other action. On my browser (safari) a click-drag initiates an image drag
- don't work properly with the accessibility features of the OS (for vision impaired: voice over, sticky mouse, etc.)

Application developers - whether web or desktop - should always use native controls or you *will* be disrupting the user experience of at least some of your users (the accessibility problem is a biggy).

Re:Somebody please "conquer" the FILE input elemen

[Anonymous Coward]

Ew. You weren't kidding about it being a hack. It's a clever hack, but it's kind of scary. :P

users turning off javascript

[falconwolf]

His primary concern (and what he believes he's invented) is a method to be backward compatible with browers that have JavaScript turned off, and/or browsers that lack CSS support. (You actually want to support those guys?)

I certainly want to support those who have javascript turned off. If Mozilla were to allow me to turn off javascript for specific websites I'd do it in a heartbeat. Actually my firewall allows me to do this however for whatever reason it doesn't work with Netscape above 4.7 or with Mozilla derived browsers such as Firefox though it does with IE.

Falcon

christ...

[bored]

This is the reason I leave javascript off for most sites. The thing behaves better with it off.. The cute little stars for radio boxes are really really annoying.

Unobtrusive JavaScript

[kae_verens]

I've known about that style of widget replacement for a while (I've even written something similar myself (example)), and graphical widgets always impress the hell out of me, as I couldn't draw to save my life, but there are a few things that irk me about the example given.

• There are excessive elements! Ideally, the script should work with exactly what is given, and not require extra code to be added.
• There are onLoad JavaScript calls in the <body> tag. These should be added automatically by the external script.

The example is similar in philosophy to Unobtrusive JavaScript, where the point of the game is that the HTML should be written as if for a non-JavaScript browser, and all JavaScript effects should be added appropriately by an externally included file. That way, the page will have a very good chance of being accessible, as well as technically modern and something to be proud of.

accessibility

[falconwolf]

Web developers only need to cater to those devices in which they expect their content to be viewed. I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA.

You understand don't you that the web is supposed to be accessibly to all? It may be "fine" if a website is for the internal use of an organization that controls how those there accesses the site, but it definitely isn't good if the site is public to use nonstandards.

Falcon

Why Do Sites Often Require JavaScript On?

[Anonymous Coward]

Many websites require that users enable JavaScript to

• click on a link and navigate to the corresponding URL,
  
• submit a form,
  
• see the contents of a SELECT list,
  
• perform interframe operations, etc.
  

In all cases these can be done without requiring users to enable JavaScript. So why do site developers do this? Is it incompetence, laziness, a lack of knowledge or what?

Re:Not really new, but interesting-wrong

[Anonymous Coward]

This is my biggest problem with flash.

There is nothing more annoying than browsing to a site from a machine which doesn't have flash installed (don't want it) and realizing the site was written in such a way as to not be able to get past the into animation without flash.

People who make web-sites which can't be operated without flash need beatings.

As a flash developer who does exactly what you are complaining about I can honestly say that neither I, nor the clients I do the flash for are interested in serving people such as yourself who just don't want to upgrade because of some lame ass excuse....go away...find someone else still using outdated crap and go with them...we'll be fine thanks!!

I did this 4 months ago?!

[Anonymous Coward]

This is old news, I completed this about 4 months ago... an in a more accessible form as I use LABELs as the styling object, which means it degrades gracefully.

http://www.flog.co.nz/2005/04/27/arc-adams-radioch eckbox-customisation/

Not only that, at the same time I published my method somebody else posted almost the same thing on their blog.

You're behind the times slashdot.

Re:I did this 4 months ago?!

[wodeh]

Rather- all the other solutions were so buried in peoples silly blogs that I couldn't find a single one of them, re-invented the wheel, and claimed the "fame" by using my journalistic hyping talent to slide it by the Slashdot moderators.

You can climb on that mountain all you like, but if you don't take a flag nobody is going to know you've been there.

This is a hack

[Dracos]

And would be totally unnecessary if IE was capable of applying CSS to these inputs. Put a border on either, and you get an ugly square drawn around it. Styling inputs would also be infinitely easier if IE supported attribute selectors:

input[type=radio] {
height: 1em;
width: 1em;
background-image: url(gray_star.png);
border: 0;
}
input[type=radio][checked] {
height: 1em;
width: 1em;
background-image: url(yellow_star.png);
border: 0;
}

No javascript, no accessibility issues, just the user's annoyance at having to recognize these inputs.

Viva la browsers that don't suck!

HOW IS THIS NEW?!?!?!?

[popo]

You can also script "ipod style" rotating dials in javascript.
Scripting images to work like form elements is so not impressive by anyone's definition.

If only you could mod an entire article Retarded

Let me get this straight ...

[ravepunk]

We're all excited that someone has figured out how to "more easily" replicate a user interface element that has been a standard part of user interfaces since 1995? Replace "Internet" with "Mainframe" Replace "Browser" with "3270 Green Screen" Replace "HTML/DHTML/XHTML/CSS/etc..." with "Terminal emulation protocol" I'm currently typing this message into a box that covers about 1/10th of my total screen real estate and a scrollbar just appeared. I have to type 7 extra keystrokes to emphasize bold text. When are we going to grow up and stop reinventing complexity and start building systems for user interfaces that are truly useful?? I'm off to preview this post to make sure it looks right before I press the submit button. /blech Terry

Funnily enough it _is_ the law.

[Onan]

Standards compliance is a good guideline, but it is not law.

This may be the best embodiment of the concept "short-sighted" that I've ever seen.

Disregard for standards and a narrow focus on your current and intended audience got us Progidy and Compuserve. Focusing on standards, and leaving open the places and ways in which content are delivered got us the Internet and the Web.

Re:Funnily enough it _is_ the law.

[ubernostrum]

Actually, it's not law. Valid code is a WCAG Priority 2 checkpoint, and writing valid HTML will help you automatically pass some Priority 1 checkpoints (e.g., providing a text equivalent for images, since valid HTML must have the "alt" attribute on each img tag) but it is not required by any accessibility law of which I'm aware. And I'd agree 100% with parent on standards-compliance being a good guideline; when it comes to accessibility, validation is a means to an end and should not be confused with the end itself.

His view on "only cater to what you expect", however, belongs in the stone age.

Was this really a limitation?

[inkswamp]

I've encountered this limitation in my site designs, but there's more than one way to skin a cat. You don't always have to work within the limits of "official" methods. You can do lots of things with graphics and a more traditional approach to programming these elements yourself. Here's an example from a Pink Floyd webzine I help publish. Scroll to the bottom and play with the check box. It's just a graphic being swapped in and out and I keep track of its on/off value with a global variable in the Javascript. It's that easy. You just have to be willing to manage all aspects of the thing in your own code.

The indicator "lights" next to each question also probably looks like some kind of control to most users and it "lights up" when you answer correctly and turns red when it's wrong. Again, it's all managed in the code.

Re:Neilsen and Tufte are rolling over in their gra

[ubernostrum]

You know, if the styling used is such that it suits the task or is consistent with an existing convention (say, using stars as a quality rating in a review), it could actually enhance usability.

Re:Neilsen and Tufte are rolling over in their gra

[Pvt_Waldo]

I got a great idea, let's release a first person shooter game, and instead of WASD as the move keys, we're going to use FBLR! FBLR! Front, Back, Left, Right! It makes so much sense doesn't it? It's really intuitive isn't it?

So do stars for a rating, but unless you put a text message that says "Click the stars" nobody will click them - they will just assume they are images for decoration or existing rating.

Re:Toilet paper sig

[Anonymous Coward]

Any toilet paper with
"Now wipe your arse"
printed on it?

Re:Neilsen and Tufte are rolling over in their gra

[ubernostrum]

So do stars for a rating, but unless you put a text message that says "Click the stars" nobody will click them - they will just assume they are images for decoration or existing rating.

Actually, quite a few places use stars for ratings and it seems to work pretty well. Amazon does this particularly well on some of their product list pages, for example; hover over the stars and as you move the mouse it lets you know what each rating means. Click a star and it submits your rating.

So... want to pull any more wild assertions out of your ass?

Has anyone actually tried this? It doesn't work!

[Anonymous Coward]

The moment you add any text after the checkbox, boom. No longer works.

I'm not familiar (motivated) enough with javascript to fix it, but some basic experimentation shows these scripts to only work with unlabelled checkboxes or radio buttons.

Please test your code more thoroughly next time.

Your scripts don't actually work

[originalnih]

I'm noticing that in practice your script doesn't work outside of the example.

I got quite excited when I read your page and tried your code out immediately, but it appears that adding any sort of text after the checkbox or radio button breaks it. And you can't have checkboxes without some sort of label.

It was probably worth testing your scripts before releasing them to slashdot, but don't give up now. For my excitement's sake at least, please fix this and post an update on your page.

Re:Has anyone actually tried this? It doesn't work

[AKAImBatman]

The moment you add any text after the checkbox, boom. No longer works.

His scheme replaces the entire checkbox area. If you want to add text, it must be outside the SPAN area.

This version avoids the issue all together, but it isn't complete. You need to add a hidden field to store the value in.

For Pete's Sakes!

[Tablizer]

We still don't have semi-standard editable grid and collapsable tree/outline widgets, and you guys are fussing about pretty borders around checkboxes? Pardon me for my outburst, but you are a bunch of fucken girlie men!

Let's resolve the practical issues first, and THEN focus on pretty frilly borders.

Ouch

[Omega Blue]

I, as a user, expect the web apps I use to be usable from any web browser available to me, including cellphones and PDAs.

You really do that? Wow. My hat's off to you. Though personally I much rather do less painful things, such as piercing my tongue with hot nails.

Minor Bug

[serutan]

In Firefox if you hold down Ctrl while clicking these checkboxes, the article page is reopened in a new tab. This doesn't happen with a normal checkbox.

Bold Text Conquered By HTML

[jhamm]

"Now, there's an easy way to make text bold on a webpage. Just enclose it with ! It's also backwards-compatible, showing normal text on browsers (such as Lynx) that don't support bold text." Why is this a Slashdot article? Hasn't anyone heard of webfx.eae.net?

Web devellopement is DIFFERENT

[andr386]

IMHO web devellopement is a very specific kind of devellopement. And while respecting standard is important, pragmatism is far more important.

Choosing a target as specific as possible (e.g. Mozilla + IE) and define precise design practices is the only practical choice if you don't wanna end up in CHAOS.

You need to be very very pragmatic and do everything as simply as possible. Great revolutionnary designs, Design patterns for every problems, extreme modularity, and cutting the codes in many many very small practical functions may often end up being impractical with a web project and make it a hell of a job to be maintained.

And overall, in any languages, complexity is never welcome in the code source. All the job consist precisely in making a clever design allowing to make very complex stuffs in very simple and easy steps.

Of course it's only my sujective and personnal point of view. But having to maintain websites where the libraries implement or rename nearly every PHP functions, where it takes up to 2 hours to find the actual code that's causing an error. I'm sick of complexity. Especially when it's not needed.

Re:Web devellopement is DIFFERENT

[Shaper_pmp]

"IMHO web devellopement is a very specific kind of devellopement. And while respecting standard is important, pragmatism is far more important."

It depends - pragmatism in the sense of ignoring standards got us the fingernails-down-a-blackboard-experience that was web design for most of the late 90s/early 2000s, and often produces pages that look great on IE but don't work or look ugly on other browsers. Call this "code pragmatism".

Pragmatism in the sense of being prepared for your lovely graphical design to degrade right back to ASCII text (or using sematic markup so it can be mashed-up and re-presented by people or scripts) is pretty much what people mean by "standards-compliant coding". Call this "presentational pragmatism".

Generalising madly, the "non-standards" crowd mainly seem to be code pragmatics, whereas the "standards-are-all" crowd seem to be presentational pragmatists.

Being pragmatic doesn't mean anything in the context of the debate - it's what you're most pragmatic about that they disagree on.

"Choosing a target as specific as possible (e.g. Mozilla + IE) and define precise design practices is the only practical choice if you don't wanna end up in CHAOS."

Not even slightly. This sounds like another version of the "standards are bad because they restrict my design options" (which is false, if you know what you're doing) or "standards are bad because they're hard" arguments (which is false because many other people are fine, so it's clearly your failing not the standard's). You could say the same thing about compiling C++ code - you'd be much free-er to write complete gibberish if it didn't have to compile, but a C++ program that doesn't compile is useless.

Likewise (albeit to a lesser degree) non-standards-compliant code is less useful. It won't be semantic markup, so it isn't easy (sometimes even possible) to automatically aggregate it and customise how you access it. Presentation isn't separate from content or behaviour, so it's harder to manage sites or effect large-scale changes to a design. It's tightly tied to old, obsolete ways of doing things that don't degrade well, so when the technology changes (eg, if in five years' time mobile devices are the most popular way to access the web rather than PCs) you find you have to recode everything you've ever written or write it off and lose it forever.

"You need to be very very pragmatic..."

Which doesn't mean anything on its own, as I've demonstrated above.

"...and do everything as simply as possible."

Exactly - this I agree with wholeheartedly.

"Great revolutionnary designs, Design patterns for every problems, extreme modularity, and cutting the codes in many many very small practical functions may often end up being impractical with a web project and make it a hell of a job to be maintained."

Indeed, but those (with the exception of extreme modularity) are all more symptomatic of non-standards-compliant "tag-soup" code than clean, semantic markup, presentation mostly/entirely in CSS and well-coded javascript in a separate file.

Semantic markup is simpler to read than presentational markup - this is pretty much unarguable.

Extreme modularity is almost universally agreed to be a Good Thing - practically every advance or increase in power in computing seems to be a drive towards modularity - OOP, XML, Firefoxes "extensions" vs traditional plugins, DLLs vs duplicated code, interacting suites of tools vs bloated, monolithic applications, etc, etc, etc.

I'm not sure where you got the idea modularity's bad, but it's vastly simpler and vastly more powerful than spaghetti code, and I think you'll find it hard to find a single experienced programmer or developer who'd disagree. Bringing it back to web design, see the CSS Zen Garden for examples of the power of separating content from design.

"And overall, in any languages, co

Re:Toilet paper sig

[SComps]

Every fourth sheet. Followed immediately by "Grasp firmly here" (for the benefit of the next participant)

Now all we need

[iignotus]

is styled [Browse...] buttons, without the aid of JavaScript. They are not stylable and make any form that you put them in look out of place when the page is style with CSS.

FormStyle *** UPDATED ***

[wodeh]

FORMSTYLE UPDATED

I have updated the script based on some of your concerns, suggestions and whinings. Thanks for your input!

The new FormStyle is available for download here.

needs colors

[Anonymous Coward]

Don't use it! It is not accessible. The buttons do not appear in Mozilla 1.7.3 when colors are disabled. (And no, I won't enable colors in my browser.)