Slashdot Mirror

Topic usually doesn't change within a sentence, so I like to add a 'text button' at the end that augments the topic-info with the resource-type. [examples] [robotwisdom.com]

Topic usually doesn't change within a sentence, so I like to add a 'text button' at the end that augments the topic-info with the resource-type. [examples] [robotwisdom.com]

Bobby is the least useful accessibility report tool in town.

I agree - Bobby really is quite useless. It gets confused easily and spews out incorrect messages left and right. It's probably the worst validation tool I've ever used.

get the checklist instead of the W3C novella format

The checklist really is the best way to go.

I've been hearing about accessibility and other potentially imposing guidelines for quite some time, and I've always been curious: is there any plan to try to enforce the guidelines?

There are many countries in which accessibility is a legal requirement for lots of organisations. For more information on these, please see WAI Policy.

But speaking of the private individual, should you and I also be subject to enforcement of web guidelines even in our personal, private web space?

I believe the most common point of view is that people who must cater to the needs of disabled people in the physical world must also do so on the WWW.

For instance, McDonald's are legally obliged to provide bathrooms that are specially equipped for people with mobility problems, at least in the UK. However private homes aren't required to provide them. It seems reasonable to draw the line at the same place on the web - so individuals would not be required to follow WCAG (or similar), yet service providers would.

The W3C is a consortium that includes the makers of IE, Netscape, Opera, and Safari. Check their About page and the member list.

(I know, I've been trolled, but some might find the clarification useful.)

The W3C is a consortium that includes the makers of IE, Netscape, Opera, and Safari. Check their About page and the member list.

(I know, I've been trolled, but some might find the clarification useful.)

(see also: SVG)

Way back in 2000 I had a hard look at how you'd deliver an XForms form to a legacy device, and concluded that it was in the general case virtually impossible using standard tools. So I said so. As far as I know, there's still no way, and no one has produced any sensible response to this problem.

AFAIK no web (WWW) standards are 20 years old yet; 1991 is the earliest year for an HTTP specification.

And Perl works just fine, thank you, with any of the newer standards, so the term "standards based technology" is gratuitous at best.

Perl development is so much quicker than JSP servlet development partially because there are so many well-written and thoroughly debugged CPAN modules written for Perl (and partially because Perl is simply so much quicker for development!-P)

See the following bugzilla item for XForms support in Mozilla: http://bugzilla.mozilla.org/show_bug.cgi?id=97806. There are also plugins available for some present browsers. See the implementations section of http://www.w3.org/MarkUp/Forms/ for more info.

Just take a look at the W3C validation results.

Now it's also "the next generation of web forms". Gag me with a buzzword.

It's not as if the original XForms were unknown, either -- it comes up second in a Google search for "Xforms". These jokers should have known better.

Feh.

Talk about making a mountain out of a molehill... either you don't read much online, or you felt extraordinarily picky over this article. With all due respect, most articles online aren't Grade-A English essays. Most articles may not even pass the Word 97 grammar checker.

I read a lot online, and you're right, much of it is poorly copy-edited. It nearly always annoys me, and I guess I was just in the mood to complain about it this time.

By the way, I don't know about the Word 97 grammar checker in particular, but every grammar checker I've ever used has been so horrendous I turned it off. Not only do they flag things that are correct (albeit perhaps not considered "best practices"), they miss completely blatant errors. I think one time I deliberately entered a random sequence of words and whatever grammar checker I was testing at the time saw nothing wrong with it.

She said "I am in no way saying that by playing video games will make you smarter". She's trying to avoid people going up to her and saying "You said playing Halo would raise my IQ" or "I played Counterstrike all night and didn't pass my exam, you said-" etc. Rather she clarifies her position and says the studies would help people remember certain things (whether they are remembering gaming tips or integration techniques).

I think you're reading that rather charitably, and even so, I see little more justification for it than for the belief that playing violent video games causes real-life violence. I.e., it might be "common sense", but there doesn't seem to be any actual support for it.

Forgive my poor html, it is the best I can do.

Of course, but if you want your posts to look more like mine, try the <blockquote> tag.

Anyhow... I don't even see why you had to pull this sentence out of the article to complain about. Many sentences can be reworded different to carry the same message. She wanted to write like that. Perhaps she wished to use the "conquer" word and make it more game related. Simply put: she wanted it worded like that to convey a certain message.

If you honestly think that she was being that wordy to try to achieve a particular effect, then I can see why you wouldn't object to her writing style. She can certainly use the word "conquer" if she wants to, but what does "It is a well-known fact that" add to her sentence? As far as I can see, it just increases her word count and makes her article more annoying to read.

I just think you're picking at such minute details that reading your post is more annoying then reading the errors in her work.

Well, it should have been pretty easy to tell that my post was a grammar / style flame relatively early on. You could have just skipped over it if you didn't want to read it. On the other hand, then I would have missed out on the chance to see my post criticized on its own terms, so I'm glad that you didn't.

Perhaps you should apply for an editor position at that web page instead and spare us her grammatical inaccuracies beforehand.

Touche. (Slashdot doesn't appear to give me any way of getting an e with an acute accent. I find that irritating.)

Why bother with a lie that's so easily disproved?

A user agent that wishes to authenticate itself with a server -- usually, but not necessarily, after receiving a 401 response--does so by including an Authorization request-header field with the request.
RFC 2616, HTTP 1.1

It is really simple: When a user wants to see something, he issues a GET. This is idempotent and doesn't carry any kind of state except what the client explicitly provides, like the URI, the preferred format and language, and his credentials. If he wants to perfom some destructive operation, he uses POST, PUT or DELETE. Again, all that's neccessary for the server to know is in the headers and the payload, where applicable.

Listen, web developers: Using HTTP the way it was meant to actually works. You don't need kludges like cookies or GET with lots of parameters where what you do has nothing to do with GETting a resource. It even makes lots of nasty problems go away, like the back-button breaking your app. Try reading and understanding the actual specs, or the diss of the guy who wrote (some of) them.

Does anyone know what kind of heuristics MSIE used to determine which cookies are good and which are bad?

Internet Explorer 6 uses the Compact Privacy policy as specified in the W3C P3P spec. It uses this to determine whether a cookie is unsatsifactory (different rules based on whether it is a third party cookie or not). MSDN has documentation covering Internet Explorer's decision matrix (unfortunately framed).

I believe the project you're talking about is now a recommendation from the W3C called P3P (Platform for Privacy Preferences), which IIRC, has a detailed section relating to the use of cookies. Microsoft implemented this recommendation partially in MSIE 6 before it became a standard.

I believe the project you're talking about is now a recommendation from the W3C called P3P (Platform for Privacy Preferences), which IIRC, has a detailed section relating to the use of cookies. Microsoft implemented this recommendation partially in MSIE 6 before it became a standard.

an SVG graphic on a webpage I was asked to download a viewer, and 30 seconds later I saw the image. That's not a real inconvenience.

You weren't browsing the web via a braille-interface.

Nothing like making the world block, more-entirely, ones already blocked by circumstance from participating...

exclusive, rather than inclusive, humanity...

sometimes it's necessary, but...
sometimes it isn't.

why not an alt-version, using -pre- tags, and text-graphs, for display of information?

... if eyeball-blind people are worth enough to include?

Try some of these:
The WWW Consortium's accessibility checklist, and Jakob Nielsen's bi-veekly Alertbox: current issues in Web Usability.

Don't forget the W3C, which has its main office at MIT's Laboratory for Computer Science!

validate slashdot, if you can. A great solution to the problem; screw making your code valid; just block requests from the validator in robots.txt!

sorry.. better urls.. no idea where those spaces came from :S...

http://validator.w3.org/check?uri=http%3A%2F%2Fmic rosoft.com%2F&charset=iso-8859-1+%28Western+Europe %29&doctype=HTML+4.01+Transitional

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .oogle.com%2F&charset=iso-8859-1+%28Western+Europe %29&doctype=HTML+4.01+Transitional

Reece,

sorry.. better urls.. no idea where those spaces came from :S...

http://validator.w3.org/check?uri=http%3A%2F%2Fmic rosoft.com%2F&charset=iso-8859-1+%28Western+Europe %29&doctype=HTML+4.01+Transitional

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .oogle.com%2F&charset=iso-8859-1+%28Western+Europe %29&doctype=HTML+4.01+Transitional

Reece,

Heh heh sounds like a respectable guy but...

By "enterprise application", I take it this is an application with a large number of users (10,00+), but still internal to your company.

I'd agree with the above post for an external website. About the only two plug-ins that you can reasonably count on people having are Flash and Acrobat Reader. And IE 5+ would limit you to about 90% of the browsing public - you don't want to turn away 10% of your potential customer base.

However, if the application is internal to your company, requiring a plug-in is very reasonable. You do need to make sure you have an easy way to distribute the plug-in and that you have your support people ready when you implement your app. In fact, part of your app should be detecting if someone has the plugin then directing them to the correct page to install it. A plug-in based system linke SVG or Flash is a little easier to install than a Java Runtime Environment. However if you plan on creating more web applications, you may find yourself needing a standard JRE eventually.

I wouldn't limit myself to IE - a better standard would be the W3C's recommendations or you could check out the Web Standards Project. If you must use IE, I strongly recommend IE 6. Again, you may need to upgrade some people's browsers; you just need to include that in your implementation.

I think that if a site requires the referring page to come from one its own domain and you spoof that somehow to make a deep link

That makes no sense. The Referer header is under the control of the user, not the website with the originating link on. A person who deep-links to another site can't make his visitors send "fraudulent" requests in this way.

If a site requires it and you use a proxy that strips it off, then you will simply be denied access. That's the proxie's fault for purposefully thwarting the HTTP standard, so I have no sympathy for them.

There is no requirement in the HTTP RFC that clients must provide that header, in fact it explicitly states that it should be easily disabled by end-users. See section 15 of RFC 2616 for details:

We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information.

The Adobe SVG Viewer has supported a variation on the SMIL audio element since version 1.0 (released in 2000).

The SVG 1.2 draft specification incorporates support for the SMIL audio and video elements.

Adobe just released a developer preview release of Adobe SVG Viewer 6.0 which includes support for both of the SVG 1.2 specification versions of the audio and video elements.

The SVG 1.0 specification includes support for SMIL animation and interactivity which means that you can have declarative animation and interactivity that doesn't require JavaScript. The Adobe SVG Viewer has supported this since version 1.0. And SVG and ASV also support full JavaScript control of the SVG DOM, of course.

The Adobe SVG Viewer has supported a variation on the SMIL audio element since version 1.0 (released in 2000).

The SVG 1.2 draft specification incorporates support for the SMIL audio and video elements.

Adobe just released a developer preview release of Adobe SVG Viewer 6.0 which includes support for both of the SVG 1.2 specification versions of the audio and video elements.

The SVG 1.0 specification includes support for SMIL animation and interactivity which means that you can have declarative animation and interactivity that doesn't require JavaScript. The Adobe SVG Viewer has supported this since version 1.0. And SVG and ASV also support full JavaScript control of the SVG DOM, of course.

The Adobe SVG Viewer has supported a variation on the SMIL audio element since version 1.0 (released in 2000).

The SVG 1.2 draft specification incorporates support for the SMIL audio and video elements.

Adobe just released a developer preview release of Adobe SVG Viewer 6.0 which includes support for both of the SVG 1.2 specification versions of the audio and video elements.

The SVG 1.0 specification includes support for SMIL animation and interactivity which means that you can have declarative animation and interactivity that doesn't require JavaScript. The Adobe SVG Viewer has supported this since version 1.0. And SVG and ASV also support full JavaScript control of the SVG DOM, of course.

Ok SVG is trying to be like Flash in scope, but i don't see anything besides animation. I see nothing about syncing with audio or adding interactive elements.

Here is info on synching with audio. And on synching with video and there are hundreds of examples of interactivity. Most SVG's on the Web are interactive. For instance: asteroids in SVG. A bunch of demos including a paint program written in SVG.

Ok SVG is trying to be like Flash in scope, but i don't see anything besides animation. I see nothing about syncing with audio or adding interactive elements.

Here is info on synching with audio. And on synching with video and there are hundreds of examples of interactivity. Most SVG's on the Web are interactive. For instance: asteroids in SVG. A bunch of demos including a paint program written in SVG.

A new SVG 1.2 draft specification was just published last Tuesday. It describes two things that may help provide the user interface elements you need.

First, the SVG Working Group is looking at supporting XForms in SVG.

Second, there is new feature for rendering custom content ("RCC") which would allow people to create sharable SVG components (kind of like Java Beans).

A new SVG 1.2 draft specification was just published last Tuesday. It describes two things that may help provide the user interface elements you need.

First, the SVG Working Group is looking at supporting XForms in SVG.

Second, there is new feature for rendering custom content ("RCC") which would allow people to create sharable SVG components (kind of like Java Beans).

A new SVG 1.2 draft specification was just published last Tuesday. It describes two things that may help provide the user interface elements you need.

First, the SVG Working Group is looking at supporting XForms in SVG.

Second, there is new feature for rendering custom content ("RCC") which would allow people to create sharable SVG components (kind of like Java Beans).

I don't know why everybody has latched onto SVG == open Flash. SVG is just vector graphics. SMIL [w3.org] is closer to Flash in terms of functionality.

SVG includes SMIL! You are quite wrong that SVG is "just" a vector graphics format. SVG Tiny is just a vector graphics format, but full SVG has animation and scripting, just like Flash.

The funny thing in this whole Flash vs SVG debate is that no one apparently has read the authors list of which Macromedia is there. Not to mention the other big names. As far as SWF, it's free as in beer, not speech.

You may be thinking of SMIL. SMIL Working Draft is already supported by IE it seems.

The testsuite is a good list of what SMIL can support and more details can be found from the full spec.

You may be thinking of SMIL. SMIL Working Draft is already supported by IE it seems.

The testsuite is a good list of what SMIL can support and more details can be found from the full spec.

You may be thinking of SMIL. SMIL Working Draft is already supported by IE it seems.

The testsuite is a good list of what SMIL can support and more details can be found from the full spec.

This is the example I always use to impress people of SVG's capabilities (like convincing my boss of using it instead of Flash) :-)
http://www.karto.ethz.ch/neumann/cartography/vienn a
A lot of useful information here: http://www.w3.org/Graphics/SVG/Overview.htm8

Ok SVG is trying to be like Flash in scope, but i don't see anything besides animation. I see nothing about syncing with audio or adding interactive elements.

I don't know why everybody has latched onto SVG == open Flash. SVG is just vector graphics. SMIL is closer to Flash in terms of functionality.

You are wrong, scripting is just one possibility. You can also write animations purely declaratively using elements like <animate> or <animateMotion>, see the animation chapter in the SVG spec. Another possibility is SMIL.

Read this: The Document Object Model (DOM) for SVG, which includes the full XML DOM, allows for straightforward and efficient vector graphics animation via scripting.

That's like saying you can make animations with HTML just because you can access HTML tags through the DOM and script them.

First off, let me say that I have toyed around with the Corel SmartGraphics Studio, and I think that it's a very good first pass at simplifying the process of creating SVG for a lot of users. As a big fan of SVG, I appreciate all the effort that Corel has put forth.

That being said, I think that the Open Source community should know that dSVG is only one of three UI-defining proposals that the SVG Working Group is considering for SVG 1.2. One of the other two, currently known as RCC, proposes the ability to create a kind of template with a separation of style and functionality, but defined in the document rather than being built in the plug-in. Ultimately, I think that this is a better way to go, since it is far more adaptable. It uses scripting and an XSLT-like syntax to transform semantic content into graphical elements (like form controls, scrollbars, etc.). The last proposal, Live Templates, seems like a generalized case of RCC, and I suspect they could be married together.

Adobe has released a tech preview of ASV6, the next version of their plugin (Windows only for now). It implements an early version of RCC (as well as some other cool features like text wrapping, audio, video, and external resources), and looks very promising. At SVG-Open, I saw an RCC forms widget toolkit for SVG, which worked well and weighed in at all of 6KB. I also saw ASV6pr working on a Linux box, and with the latest build of Mozilla. It's still buggy, but it's more conformant to the Spec than ever.

May the best spec proposal win!

In other news, the excellent Batik (an OSS SVG toolkit) also released a stable 1.5 last week.

Basically, SVG is getting really exciting.

SVG itself is a W3C Recommendation, not an IETF RFC.

You may be surprised, if you look around... SVG is already pretty widely used. Examples: it's used for theming in the metacity window manager and in nautilus; for support in graphics editors, if dia and sodipodi don't ring a bell maybe you've come across Adobe Illustrator, or Microsoft Office 11's Visio.

I do agree that Mozilla has a long way to go. But it's worth it. SVG can be manipulated with XSLT and XML Query, can be generated with open source tools, stored in XML databases, is often massively smaller than Flash files, and can be made accessible. Depending on how much you script, it could also be indexed by google and other search engines.

You can see the W3C SVG page for more information.

Disclaimer: I work for the W3C, although I am not directly involved in SVG.

(No, I didn't forget PNG. It has some technical and ideological advantages, but browser support is still, well, incomplete.)

So what's wrong with SVG plugins? They don't exploit the full power of SVG. It's not just a graphics format, it's an XML application. In other words, it's a markup language, just like HTML. A good XML-aware browser (something both IE and Mozilla pretend to be) shouldn't isolate SVG from the rest of the document.

Consider the gif-filled Slashdot page you're looking at right now. They have gotten rid of a lot of bitmaps (though the left hand clickbar looks slightly less cool as a result). But they still use some weird little bitmaps, plus a lot of weird tables and font kludges that are hard to maintain and tend to be browser dependent.

There's a simple fix: put SVG support in the browser (it is a W3C invention after all) and allow indiscriminate embedding of XHTML and SVG in each other. (Not to mention any other XML applications the browser happens to support.) The Mozilla people know this, but still consider SVG support experimental and non-standard. This has been the status quo for quite some time, and given AOL's abandonment of Gecko, is not likely to change.

Maybe if Mozilla had concentrated on basic technological improvements like this and less on eye-candy and silly features... well, AOL, would probably still have screwed them over. But I might feel bad about it.

KHTML looks to be the new leader in open-source web browsers. And their does seem to be a lot of interest in using the engine to render SVG. Alas, the KDE people still think of SVG as something you embed in something else.

Are you a programmer? Simple HTTP isn't that hard. Anyway, just about every language has some sort of HTTP library. I believe both Python and Perl's standard distribution comes with one. There is one for C at w3.org. I serously doubt even Microsoft wouldn't include some sort of library to facilitate downloading with HTTP--they merged an entire web browser into their operating system after all.

It is official; TrollKore confirms: GNAA is dying One more crippling bombshell hit the already beleaguered GNAA community when IDC confirmed that GNAA market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent TrollKore survey which plainly states that GNAA has lost more market share, this news serves to reinforce what we've known all along. GNAA is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be a Sexual Asspussy to predict GNAA's future. The hand writing is on the wall: GNAA faces a bleak future. In fact there won't be any future at all for GNAA because GNAA is dying. Things are looking very bad for GNAA. As many of us are already aware, GNAA continues to lose market share. Red ink flows like a river of blood.

Homosexual Rights is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time Homosexual Rights developers Slashdot Editors only serve to underscore the point more clearly. There can no longer be any doubt: Homosexual Rights is dying.

Let's keep to the facts and look at the numbers.

Free Love leader Theo De Raadt states that there are 7000 users of Free Love. How many users of Gay Pride are there? Let's see. The number of Free Love versus Gay Pride posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 Gay Pride users. First Posting posts on Usenet are about half of the volume of Gay Pride posts. Therefore there are about 700 users of First Posting. A recent article put Homosexual Rights at about 80 percent of the GNAA market. Therefore there are (7000+1400+700)*4 = 36400 Homosexual Rights users. This is consistent with the number of Homosexual Rights Usenet posts.

Due to the troubles of GNAA Illuminati, abysmal sales and so on, Homosexual Rights went out of business and was taken over by Worthless Scumbags who sell another troubled OS. Now Worthless Scumbags is also dead, its corpse turned over to yet another charnel house.

All major surveys show that GNAA has steadily declined in market share. GNAA is very sick and its long term survival prospects are very dim. If GNAA is to survive at all it will be among OS dilettante dabblers. GNAA continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, GNAA is dead.

Fact: GNAA is dying

It is official; TrollKore confirms: GNAA is dying One more crippling bombshell hit the already beleaguered GNAA community when IDC confirmed that GNAA market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent TrollKore survey which plainly states that GNAA has lost more market share, this news serves to reinforce what we've known all along. GNAA is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be a Sexual Asspussy to predict GNAA's future. The hand writing is on the wall: GNAA faces a bleak future. In fact there won't be any future at all for GNAA because GNAA is dying. Things are looking very bad for GNAA. As many of us are already aware, GNAA continues to lose market share. Red ink flows like a river of blood.

Homosexual Rights is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time Homosexual Rights developers Slashdot Editors only serve to underscore the point more clearly. There can no longer be any doubt: Homosexual Rights is dying.

Let's keep to the facts and look at the numbers.

Free Love leader Theo De Raadt states that there are 7000 users of Free Love. How many users of Gay Pride are there? Let's see. The number of Free Love versus Gay Pride posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 Gay Pride users. First Posting posts on Usenet are about half of the volume of Gay Pride posts. Therefore there are about 700 users of First Posting. A recent article put Homosexual Rights at about 80 percent of the GNAA market. Therefore there are (7000+1400+700)*4 = 36400 Homosexual Rights users. This is consistent with the number of Homosexual Rights Usenet posts.

Due to the troubles of GNAA Illuminati, abysmal sales and so on, Homosexual Rights went out of business and was taken over by Worthless Scumbags who sell another troubled OS. Now Worthless Scumbags is also dead, its corpse turned over to yet another charnel house.

All major surveys show that GNAA has steadily declined in market share. GNAA is very sick and its long term survival prospects are very dim. If GNAA is to survive at all it will be among OS dilettante dabblers. GNAA continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, GNAA is dead.

Fact: GNAA is dying

• It boggles my mind that Slashchick managed to become a "web developer" without discovering how the default character set is specified in IE. (View/Encoding).
• sC seems to think that IE is doing something non-compliant when it assumes a character set. I dont see anything like that in the html spec. It simply says that every document should have a character set specified somehow. But what is a browser supposed to do when it's not?
• UTF-8 and 8859-1 (aka ISO Latin1) are not the same thing. They both use ASCII for the first 127 characters, but after that, forget it. 8859-1 is fixed-width, UTF-8 is variable-width. If Slashdot is sending out UTF-8, then the headers it is using are incorrect.