...as it was in Roe vs. Wade where a "right to privacy" which is ennumerated in no way, shape, or form in the constitution was found by the SCOTUS, and then used to imply further that under this right there was a right to abortion. If these invasions of privacy, erosions of private individual and group securit at the hands of the state continue without appropriate challenge, it will eventually come about through force of history and precedence that there is no right to privacy and with that goes any right to abortion.
"The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people."
As an analogy, which organization seems more dedicated to the ideals of Free Software: Debian or Red Hat?
Both distribute software licensed under the GNU General Public License and other Free licenses. Both abide by the terms of those licenses. Both remain involved in the development of the software they distribute, "giving back" to the software development communities who provide the software in the first place.
Perhaps you were trying to say that being a for-profit corporation is contrary to the ideals of Free Software, or that full dedication to those ideals requires one to forsake the idea of making money, but neither one of those is correct.
The sellout to Google is quite substantial. We all know about the prefetch for the Google search bar, and how you can disable this in about:config under network.prefetch-next if you don't like collecting cookies from places that you never visit.
Link prefetching has been in Mozilla for ages now, and anyone can write a web page to take advantage of it. How, then, would this qualify as "selling out to Google"?
Who cares? This is a CSS file with a wishlist of a single developer! Besides that, it has incorrect CSS in it. Somehow people have latched on to this thing.
No, it's a test designed by the members of the Web Standards Project, who are some of the world's foremost experts on the W3C specs. One of its stated purposes is to test CSS error-handling in browsers (since the CSS specification mandates certain behavior when invalid CSS is encountered, this is important). It does not test for 100% compliance with any particular specification (test suites exist for that purpose already), but does test the implementation of a specific set of useful features, in hopes of spurring browser vendors into improving support for those features.
(no, I'm not confusing Gecko and Firefox. You can bolt a kitchen sink on top of Firefox, so it's a browser + sink)
Whereas Opera now doesn't need any bolting on, because it picked up everything and the kitchen sink. I used Opera for several years because it was simply the best browser available for Linux, but at this point it's in need of a lot of streamlining and pruning if it wants to get back to where it was.
Yeah, about five years ago. Then this thing called "Firefox" came along, and somewhere in the last couple versions Opera decided that they were going to out-compete the old Mozilla suite on features and preferences.
If not (and I think if certainly should be "not"), then how do we go about supporting an ever widening gap in browser features?
A few simple guidelines can go a long way toward solving this problem:
Any JavaScript you use should be unobtrusive. The most important part of unobtrusive JavaScript is that the site should still be usable when scripting is disabled (this is often called "graceful degradation").
Any JavaScript you use should test for browser support by checking the availability of methods, not by testing browser user-agent strings which are apt to cause problems. For example, using something as simple as "if (document.getElementById) {...do stuff...}" can alleviate nearly all common "browser-sniffing" problems, because it only returns true when the feature is supported.
If you use advanced CSS that's not understood by Internet Explorer, make sure the page degrades gracefully or offer an alternative way of implementing it. For example, it's relatively easy to re-implement the CSS ':focus' pseudo-class for IE with a couple lines of scripting.
For more on the problem of how to offer new features to browsers that support them without "cutting off" IE and other deficient browsers, see Derek Featherston's "BrowserElitism" articles.
What evidence do you have of the memory usage being due to leaks? Firefox sits at around 120MB for me all the time, which says to me that it's not a leak, it's the app taking advantage of available memory. Which is what it ought to do.
The fact that even people who can't stand Dave Winer had serious issues with RSS 1.0, and put their efforts behind another project, might have some significance that you're overlooking.
RSS 1.0 is infinitely extensible because it can be combined with other RDF schemas. In order to extend RSS 9.x, the standard must be extended.
Ah, so you don't know anything about syndication formats, then?
This was an issue when syndication was starting out because people needed to be able to roll their own aggregators and debug summaries. Now that all that work is done, only computers ever read feeds, so it really doesn't matter what the syntax is.
Ah, so you don't know anything about syndication formats, then.
It's a pity that all the RSS folks couldn't simply hash together a common standard rather than wasting time on competing standards. Is 2.0 really that much simpler than 1.0? Is 1.0 really that much more capable than 2.0? Does Atom really add much to the mix? It seems that it ought to be possible to find a middle ground.
Without getting too much into the politics of the syndication world, the reason is that no-one wants to touch RSS 1.0 with a ten-foot pole (even without the bitterness and fallout from the name-grab fiasco, RDF-based syndication just never really caught on), and RSS 2.0 has been officially frozen. So the only way forward was to do something new.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
Slashdot Mirror
"The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people."
Both distribute software licensed under the GNU General Public License and other Free licenses. Both abide by the terms of those licenses. Both remain involved in the development of the software they distribute, "giving back" to the software development communities who provide the software in the first place.
Perhaps you were trying to say that being a for-profit corporation is contrary to the ideals of Free Software, or that full dedication to those ideals requires one to forsake the idea of making money, but neither one of those is correct.
Link prefetching has been in Mozilla for ages now, and anyone can write a web page to take advantage of it. How, then, would this qualify as "selling out to Google"?
No, it's a test designed by the members of the Web Standards Project, who are some of the world's foremost experts on the W3C specs. One of its stated purposes is to test CSS error-handling in browsers (since the CSS specification mandates certain behavior when invalid CSS is encountered, this is important). It does not test for 100% compliance with any particular specification (test suites exist for that purpose already), but does test the implementation of a specific set of useful features, in hopes of spurring browser vendors into improving support for those features.
Whereas Opera now doesn't need any bolting on, because it picked up everything and the kitchen sink. I used Opera for several years because it was simply the best browser available for Linux, but at this point it's in need of a lot of streamlining and pruning if it wants to get back to where it was.
Yeah, about five years ago. Then this thing called "Firefox" came along, and somewhere in the last couple versions Opera decided that they were going to out-compete the old Mozilla suite on features and preferences.
A few simple guidelines can go a long way toward solving this problem:
For more on the problem of how to offer new features to browsers that support them without "cutting off" IE and other deficient browsers, see Derek Featherston's "Browser Elitism" articles.
They both do it, just like all the other search engines. I've written a user stylesheet which hides them, if you're interested.
From whom and on what grounds?
What evidence do you have of the memory usage being due to leaks? Firefox sits at around 120MB for me all the time, which says to me that it's not a leak, it's the app taking advantage of available memory. Which is what it ought to do.
The fact that even people who can't stand Dave Winer had serious issues with RSS 1.0, and put their efforts behind another project, might have some significance that you're overlooking.
Ah, so you don't know anything about syndication formats, then?
Ah, so you don't know anything about syndication formats, then.
Without getting too much into the politics of the syndication world, the reason is that no-one wants to touch RSS 1.0 with a ten-foot pole (even without the bitterness and fallout from the name-grab fiasco, RDF-based syndication just never really caught on), and RSS 2.0 has been officially frozen. So the only way forward was to do something new.
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?
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?
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.
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.
Try this.
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.
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.
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.
Gmail doesn't degrade well at all, but it offers a non-JavaScript-dependent version.
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...
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.
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.
Too bad you're apparently not a real-world developer either. Or someone who understands the English language. Read on.
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.
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.