Comments on: Input Elements: disabled vs. readOnly http://rediscoverer.net/archives/32 ... since almost everything is already out there. Sun, 10 Jan 2010 02:20:22 +0000 hourly 1 http://wordpress.org/?v=3.0 By: OldSchoolBBSer http://rediscoverer.net/archives/32/comment-page-1#comment-10603 OldSchoolBBSer Sun, 10 Jan 2010 02:20:22 +0000 http://rediscoverer.net/archives/32#comment-10603 well crap... looks like it yanked my examples since they were html code. sorry bout that. well crap… looks like it yanked my examples since they were html code. sorry bout that.

]]> By: OldSchoolBBSer http://rediscoverer.net/archives/32/comment-page-1#comment-10602 OldSchoolBBSer Sun, 10 Jan 2010 02:18:04 +0000 http://rediscoverer.net/archives/32#comment-10602 Lol. Working with it right now. I ran across an article that had some cryptic/technical arguments from someone with the W3C as to why. They were decent, but that's about it. I understand that they are looking at things from a more wide reaching technical point of view, but they seem to forget the sayings, "You can't please everyone." and "What works, and what's logical are two different beasts." "Read-Only", the coder gets the data easily in one line without a hidden field, but the user gets confused and rightly so. "Disabled", the user gets every time and understands with little thought, but the coder gets jack returned if they need it for some reason without extra coding for a hidden field and extra code to check. Holding state data is already a bit bloated, be it via Javascript or PHP. How it alluded them to state that they look identical and have the only difference aware to only programmer I'll never understand since surely upwards of 90% of the time that would be the needed and expected action in the "real world"... In both cases the user can't change the data, so they may as well be the same look to them. The coder needs an option there data-wise in several scenarios, so it makes sense to have them. Then if you wanted it to look like the current "Read-Only" box then that should have been in CSS. Ex of my opine: -- Normal w/ passed value. -- Greyed nothing passed. -- Greyed w/ passed value. -- Same as above with the box looking different from CSS (like perhaps the way it looks now... :P lol.) Well, that's my two scents. Haven't seen a scenario yet that that would have definitely conflicted with. Lol. Working with it right now. I ran across an article that had some cryptic/technical arguments from someone with the W3C as to why. They were decent, but that’s about it. I understand that they are looking at things from a more wide reaching technical point of view, but they seem to forget the sayings, “You can’t please everyone.” and “What works, and what’s logical are two different beasts.”

“Read-Only”, the coder gets the data easily in one line without a hidden field, but the user gets confused and rightly so.

“Disabled”, the user gets every time and understands with little thought, but the coder gets jack returned if they need it for some reason without extra coding for a hidden field and extra code to check. Holding state data is already a bit bloated, be it via Javascript or PHP.

How it alluded them to state that they look identical and have the only difference aware to only programmer I’ll never understand since surely upwards of 90% of the time that would be the needed and expected action in the “real world”… In both cases the user can’t change the data, so they may as well be the same look to them. The coder needs an option there data-wise in several scenarios, so it makes sense to have them. Then if you wanted it to look like the current “Read-Only” box then that should have been in CSS.

Ex of my opine:
— Normal w/ passed value.
— Greyed nothing passed.
— Greyed w/ passed value.
— Same as above with the box looking different from CSS (like perhaps the way it looks now… :P lol.)

Well, that’s my two scents. Haven’t seen a scenario yet that that would have definitely conflicted with.

]]>