Slashdot Mirror

I won't clutter this with too many "I was there" stories nor add my view of the value of PDF to prepress operations. But ever since Sun rolled over on its support from its own Display PostScript-based Network extensible Window System (NeWS) in the face of the tide of X, I have been intrigued by how Adobe has managed to become so important to the Web without ever really getting it.

At its heart, Adobe never quite manages to shake its cultural foundation in the (permanent) placement of dots on paper and take on the very different challenge of realising the potential of interactive displays and ever "under construction" documents. (Nor does much of the printing industry but that is another story.)

Having been seduced by PostScript from the start, how do we now deal with the enigmatic prospect that Adobe also appears to be the driving force behind the great white hope of Scalable Vector Graphics (SVG)?

It has not been proposed because HTML is not a page description language. It's a document structuring language, even if a lot of people do not understand the difference. Its is simply the wrong tool. HTML displays a document using information about its structure (title, paragraphs), to an arbitrary media. A page description language is about describing precisely the graphical structure (x,y position of all elements).

Take a arbitrary page layout (say a magazine - a paper one), and ask yourself, can I describe this with HTML? The answer is no. HTML and PDF have different goals. Trying to use one for the other is not a good idea. Use the right tool.

A much better candidate would be the SVG format, which is based on XML, open and has all the needed features. It is a true vector graphic file format. The only problem is, it is not widely supported (and maybe the font embedding mechanism is not as good).

Then again, PDF does the job nicely -- and is widely supported. While you can embed proprietary features in PDF, so can you with an HTML file (simply by including a GIF file). In fact if you take the current HTML technology, as far as I know, the font embedding mechanism used for HTML is completly proprietary.
Maybe this issue is more complicated than Adobe = BAD Open Source = GOOD

As to why PDF has better compression that an compressed html page. The difference is that the compression is done inside the file, so each type of data is compressed with a different compression algorithm. Also PDF has a feature that is called object reuse, the basic idea is that if an element is present multiple time in a document, it will only be stored once (perfect compression if you want). If you design your html document carefully, you can get this, but more often, machine generated html is very redundant.

As a matter of fact there has been on-going efforts in this arena. There are also some published documents on the issue.

For more information you can also check here.

As a matter of fact there has been on-going efforts in this arena. There are also some published documents on the issue.

For more information you can also check here.

That isn't true anymore. Try searching for "to be or not to be". Google used to require you to put +'s on the stop words, but they stopped requiring that in phrases a while ago.

BTW, You might notice that some pages don't actually have the phrase you were looking for. That generally means that there's are links pointing to that page with that phrase in them. For example, if you search for "html 4 spec" you get this page. That page doesn't contain the phrase "html 4 spec", but there are lots of links pointing at it that contain that phrase, so it's probably the page you want if that's your query.

Interesting/amusing query: "click here"

I Know that there is one XML standard for drawing programs (or at least a draft proposal..) but I can't . It seems like they need to simplify where to find these thing to get usage up.

• You can edit it with a plain editor, or with a pretty one like amaya, or of course emacs HTML mode...
• You can print it nicely with html2ps or in some cases with whatever browser you think doesn't do too horrible of a job.
• converting to HTML is a no-op
• if you keep it in CVS you can use easy hacks to cvsweb to make the revision history and current and past versions browsable on the web.

A few notes from my experience:

HTML: easy to write, easy to format. HTML TIDY will make everything beautiful for you. HTML actually prints very nicely. I believe most browsers will let you turn off the default page header/footers. I can see, however, that page breaks might be an issue. You'll probably want to use style sheets anyway, and there's a feature in CSS2 that allows for defining page breaks (Paged Media documentation). Also see Converting HTML to other formats.

LaTeX: Personally, I'm a big fan of LaTeX. Never tried pure TeX. However, once (if!) I master the CSS2 paged media commands, I'll probably abandon LaTeX. I don't know that one's really any easier than the other; it's just comes down to the simple fact that I know HTML better.

LyX: I found this very non-intuitive and gave up on it quickly. As I recall, the tab key did not work as I expected it, and various things just weren't what I expected them to be.

Word: I know you, the poster, don't want to use Word, so this is for others who must use it. I dislike MS as much as the next /., but I must say that Word is actually a very good product. There are things that annoy me (especially placement of pictures), and there's the macro virus issue, but you probably don't need macros in documentation anyway. As someone else pointed out, there are versioning features in Word. In addition, there are collaboration features that let you track, accept, and reject changes. The style sheets are pretty powerful (most people never use them), and allow you to quickly and easily create tables of contents. And of course, if you're in Windows and have Word already, and assuming it does not constantly crash, it's really the easiest thing to use. Just don't try exporting your document to HTML!

A few notes from my experience:

HTML: easy to write, easy to format. HTML TIDY will make everything beautiful for you. HTML actually prints very nicely. I believe most browsers will let you turn off the default page header/footers. I can see, however, that page breaks might be an issue. You'll probably want to use style sheets anyway, and there's a feature in CSS2 that allows for defining page breaks (Paged Media documentation). Also see Converting HTML to other formats.

LaTeX: Personally, I'm a big fan of LaTeX. Never tried pure TeX. However, once (if!) I master the CSS2 paged media commands, I'll probably abandon LaTeX. I don't know that one's really any easier than the other; it's just comes down to the simple fact that I know HTML better.

LyX: I found this very non-intuitive and gave up on it quickly. As I recall, the tab key did not work as I expected it, and various things just weren't what I expected them to be.

Word: I know you, the poster, don't want to use Word, so this is for others who must use it. I dislike MS as much as the next /., but I must say that Word is actually a very good product. There are things that annoy me (especially placement of pictures), and there's the macro virus issue, but you probably don't need macros in documentation anyway. As someone else pointed out, there are versioning features in Word. In addition, there are collaboration features that let you track, accept, and reject changes. The style sheets are pretty powerful (most people never use them), and allow you to quickly and easily create tables of contents. And of course, if you're in Windows and have Word already, and assuming it does not constantly crash, it's really the easiest thing to use. Just don't try exporting your document to HTML!

A few notes from my experience:

HTML: easy to write, easy to format. HTML TIDY will make everything beautiful for you. HTML actually prints very nicely. I believe most browsers will let you turn off the default page header/footers. I can see, however, that page breaks might be an issue. You'll probably want to use style sheets anyway, and there's a feature in CSS2 that allows for defining page breaks (Paged Media documentation). Also see Converting HTML to other formats.

LaTeX: Personally, I'm a big fan of LaTeX. Never tried pure TeX. However, once (if!) I master the CSS2 paged media commands, I'll probably abandon LaTeX. I don't know that one's really any easier than the other; it's just comes down to the simple fact that I know HTML better.

LyX: I found this very non-intuitive and gave up on it quickly. As I recall, the tab key did not work as I expected it, and various things just weren't what I expected them to be.

Word: I know you, the poster, don't want to use Word, so this is for others who must use it. I dislike MS as much as the next /., but I must say that Word is actually a very good product. There are things that annoy me (especially placement of pictures), and there's the macro virus issue, but you probably don't need macros in documentation anyway. As someone else pointed out, there are versioning features in Word. In addition, there are collaboration features that let you track, accept, and reject changes. The style sheets are pretty powerful (most people never use them), and allow you to quickly and easily create tables of contents. And of course, if you're in Windows and have Word already, and assuming it does not constantly crash, it's really the easiest thing to use. Just don't try exporting your document to HTML!

Much more information can be found at W3C's Semantic Web page.

> Secure login - we're thinking about that. Expect to see it sooner or later.

It can never be too early.

> Browser sniffing - not likely.

Then at least modify the scripts to out put pucca HTML that validates on the W3C validator. Also, what are the chances of
phasing out tables in favour of CSS? At least as a user preference?

Thanks for the update.

Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft).

SOAP is the standard protocol accepted INDUSTRY WIDE for web services. This is not just across companies from Microsoft to Sun to Oracle, etc. but across programming languages from C# to Java to Perl.

The cost of using soap means the XML has to use DOM and it has to validate the required nodes.

One does not need a DOM to validate an XML document. There are many validating SAX readers and in fact there also validating Pull-based XML APIs like Microsoft's XmlValidatingReader or XPP.

It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and .NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press .NET has generated for XML services will help create the critical mass needed to get semantic web [w3.org] moving.

Now it is clear you have no idea what you are talking about. The push for the semantic web is a push for a richer web experience by adding more meta data to the content of the web.

SOAP is a distributed computing protocol similar to predefined protocol the Internet Inter-ORB Protocol (IIOP) for CORBA, the Object Remote Procedure Call (ORPC) for DCOM, and the Java Remote Method Protocol (JRMP) for Java/RMI but defined in XML instead of a binary format.

Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft).

SOAP is the standard protocol accepted INDUSTRY WIDE for web services. This is not just across companies from Microsoft to Sun to Oracle, etc. but across programming languages from C# to Java to Perl.

The cost of using soap means the XML has to use DOM and it has to validate the required nodes.

One does not need a DOM to validate an XML document. There are many validating SAX readers and in fact there also validating Pull-based XML APIs like Microsoft's XmlValidatingReader or XPP.

It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and .NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press .NET has generated for XML services will help create the critical mass needed to get semantic web [w3.org] moving.

Now it is clear you have no idea what you are talking about. The push for the semantic web is a push for a richer web experience by adding more meta data to the content of the web.

SOAP is a distributed computing protocol similar to predefined protocol the Internet Inter-ORB Protocol (IIOP) for CORBA, the Object Remote Procedure Call (ORPC) for DCOM, and the Java Remote Method Protocol (JRMP) for Java/RMI but defined in XML instead of a binary format.

I don't remember all the differences between C# and Java, but it does make it more appealing. Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft). The cost of using soap means the XML has to use DOM and it has to validate the required nodes. From W3C spec on SOAP, it states:

• A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP Header, and a mandatory SOAP Body.

Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures. For a simple document like SOAP, it's not bad until you realize it is intended for business to business processes, which could mean millions a day. The argument that SOAP is "as simple as it can/should be" ignores the fact that systems that would benefit from SOAP or other XML RPC (remote procedure calling) the most have complex distributed processes. Most of the .NET whitepapers I've read so far recycle ideas others developed. Microsoft's innovation was repackaging it as a platform.

It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and .NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press .NET has generated for XML services will help create the critical mass needed to get semantic web moving.

I don't remember all the differences between C# and Java, but it does make it more appealing. Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft). The cost of using soap means the XML has to use DOM and it has to validate the required nodes. From W3C spec on SOAP, it states:

• A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP Header, and a mandatory SOAP Body.

Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures. For a simple document like SOAP, it's not bad until you realize it is intended for business to business processes, which could mean millions a day. The argument that SOAP is "as simple as it can/should be" ignores the fact that systems that would benefit from SOAP or other XML RPC (remote procedure calling) the most have complex distributed processes. Most of the .NET whitepapers I've read so far recycle ideas others developed. Microsoft's innovation was repackaging it as a platform.

It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and .NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press .NET has generated for XML services will help create the critical mass needed to get semantic web moving.

There was a thread on RDF on 02-15-01 with more info.

The Patent was awarded November 1997, but was filed in Dec 1994.

Scanning through the patent, the patent seems to be filed on a mathematical system. of course I may have this wrong, but the language of the patent is filled with it.

It is like trying to patent arithmetic, but making it so complex that it is not obvious to most people looking at it.

This is from the RDF specifications available from W3C:

The Resource Description Framework (RDF) integrates a variety of applications from library catalogs and world-wide directories to syndication and aggregation of news, software, and content to personal collections of music, photos, and events using XML as an interchange syntax.

Ignore the fact that they catalyzed the web market (either as Netscape or as their preceding life as the Mosaic free university-ware browser) by making it easy to view pictures and text on the same page, as opposed to the previous ftp-like interfaces. And those Bad Bad Netscape Monopolists destroyed the chances for REAL HYPERTEXT which the Xanadu project was planning to ship Real Soon (after a mere 25 years of development :-).

Also, people *do* make superior browsers. The World Wide Web Consortium W3.org has done a variety of browsers that are cleaner, smaller, and more correct than the big MS and NetscapeZilla product suites. Opera has been lured away into bloatware by the evils of flashiness and feature creep, so they're no longer the lean, mean, fits-on-a-floppy browser that their wonderful early versions were, but they're still a lot smaller than their major competitors. And there are bunches of EMACS-based browser hacks, which were the original integrated browser/mailtool/newsreader/wordprocessor suite. (It's no longer "Eight Megabytes", but it's still "And Continually Swapping". :-)

Actually, Konqueror has a great deal more DOM support than Mozilla does. Most of the current bugs in Konqueror are in kjs, not in it's DOM support, which is indeed, one of the best.

Check out w3's browser listing:
http://www.w3.org/Style/CSS/

and Konqueror's own support table:
http://www.konqueror.org/content/khtml_css2.html"

You are, however, right that Konqueror handles broken pages less than Mozilla does. That is certainly true. But the thing is that Konqueror tries to be as standards compliant as possible, so it does not implement things like the (broken, nonstandard) nobr tag while mozilla does.

maybe you should look up the object tag for using gifs when the user agent doesn't support PNG.
oh, hangon, IE is notorious for bad OBJECT handling.

nevermind.

Why don't you try catching up with the late 20th century by using an anchor tag for your link?

Unlike your pointless pedantry over GMT vs. UTC, the lack of an anchor tag poses a significant inconvenience to people actually interested in following the link in your post.

I'd commend a read of the cited QinetiQ Report cited as background to the current consultation. In fact, I'm quite shocked at how well considered it is; I'm sure it will help readers seeking to convince their management to consider the adoption of OSS.

Its more than easy to diss Govtalk for its many failings - such as the failure to embrace text and RTF when it has the opportunity; hotchingly bad HTML on the website, &c.

But there's a great deal of good going on, too; not least the RFC process of which this consultation is a part; and the strong support for XML in the eGovernment Interoperability framework (itself a coherent position statement).

As food for further debate, here are the main recommendations under which the current consultation was predicated:

1. OSS is indeed the start of a fundamental change in the software infrastructure marketplace, and is not a hype bubble that will burst.
2. Within five years, 50% of the volume of the software infrastructure market could be taken by OSS.
3. OSS's position in large servers (e.g. those managing massive multi-user databases), such as those that underpin many large Government procurements, will grow from its current position of near zero penetration, to a position where OSS is a viable option, within 2 - 3 years.
4. Within the developed world, we as yet see no sign that OSS will become a viable alternative to Microsoft Windows, for user's (general purpose) desktop machines in the corporate or home PC markets. However, OSS on the desktop may soon become a significant player in the developing world. For these reasons we recommend against any preference for OSS on the desktop, but also recommend that this issue be reassessed by the end of 2002, by which time early trials of the use of OSS desktops may have generated sufficient evidence to warrant a reassessment.
5. We see no benefit that the Government would gain from expressing a general preference for OSS within server infrastructures.
6. The Government could clarify its position as to whether there are circumstances in which Microsoft products are to be preferred.
7. The Government could consider publishing policy as to how the risk of lock-in to proprietary protocols is to be managed.
8. As yet it is not possible to predict that OSS will make a major contribution to the software applications market.
9. Many of the Government's risks that arise from over-dependence on proprietary protocols and data formats for interoperability can be controlled by the selective use of open data standards.
10. The existence of an OSS reference implementation of a data standard has often accelerated the adoption of such standards, and we recommend that the Government consider selective sponsorship of OSS reference implementations.
11. The rise of OSS, offers the possibility that non-US players will find it easier to influence the future direction of IT infrastructure technology.
12. The Government should consider using OSS as the default exploitation route for UK Government funded software.
13. The differences between OSS and proprietary software are not a major factor in either improving or degrading the vulnerability of a nation's IT infrastructure.
14. We recommend that the Government obtain full rights to bespoke software that it procures - this includes any customisation of off-the-shelf software packages.
15. The Open Source model offers a new paradigm for funding software in communities-of-interest (e.g. Health and Education). The Government could consider running pilot projects to test the viability of the OSS approach to such software.
16. We recommend that the Medical Records data standard be examined by appropriate domain experts for possible inclusion in the e-GIF.

Reverse engineering any closed-source format will take time, though, and I was only mentioning the recent changes. For the PDF files out there as "one of the world's most widely used formats" open source software is more than capable of reading it.

It has nothing in particular to do with open source. A closed source reverse engineering of a format is in the same position. This is the problem with closed formats.

The open format that is becoming more popular (Abiword can save it, for example) is the W3Cs XSL:FO -- an XML PDF replacement. As with most new formats there isn't nearly the same ammount of software - but time will tell.

ps. It wasn't really meant as a "knock". It was meant as a statement of fact.

I foresee an XML programming language.

Use HTML Tidy.

I don't want to block anyone from access because they're not using MegaloBrowser 4.999.999.999.today's build. :-)

Certainly, I agree completely. But I still think that CSS is your friend, you just need to be careful, and BGCOLOR is Evil[tm]. In this particular example, using BODY {background : #fff} in a stylesheet will have no negative effect on any browsers (but you should define a foreground color too). BGCOLOR, OTOH, has a negative effect, because AFAIK, I know of no browser where you can turn it off.

All this boils down to whether best graceful transformation is offered by the Bad[tm] features of HTML or by careful use of (a small subset of) CSS. I have been through many such discussions, but they have usually concluded that careful use of CSS is the best for graceful transformation, and thus is the best you can do to make your pages accessible to any browser.

I mean, what we really, really want, is to get rid of the BGCOLOR, FONT and all that stuff, remove it from HTML alltogether, right...?

I think there was a pretty exhaustive discussion about it on the WAI interest group mailing list, but I can't find it in the archives and this was also the main reason why BGCOLOR was marked as deprecated.

I also think it was the main reason why it took so long to get XHTML out. A lot of people thought that the Transitional DTD never should have made it to XHTML, because it represent a sort of tag soup that should be dead. But the W3C membership wanted the Transitional in XHTML.

> Again: where is europe years behind?

Europe is years behind when it comes to recognize, adopt and market competive innovation. Europe stands for MiniTel and Bildschirmtext versus The Web

The only difference between my pages in 1997 and today is that I use a BGCOLOR="#FFFFFF" tag now. :-)

But why? I mean, when I design new pages now, I remove the BGCOLOR attribute. BGCOLOR is clearly marked as deprecated in the specs, and should only be used in a transitional period, and I think the tranaitional period has lasted more than long enough. From now on, I think one should use the Strict DTD, either 4.01 or XHTML 1. There is no use for BGCOLOR anymore (eh, actually, I think there never was.... :-) ). Instead, use an (external) stylesheet. It's easy to turn off for the users, and it'll be easier for users to make your pages suit their taste.

Other than that, I agree with your philosophy. The pages I write now are XHTML 1 (it should be completely backwards compatible) and comply with at least two levels of Web Content Accessibility Guidelines 1.0. I think that if everybody did that, the web would be a lot more usuable for everyone (it was a huge blunder by the W3C to market the Accessibility Guidelines as being something only for people with disabilities).

The only difference between my pages in 1997 and today is that I use a BGCOLOR="#FFFFFF" tag now. :-)

But why? I mean, when I design new pages now, I remove the BGCOLOR attribute. BGCOLOR is clearly marked as deprecated in the specs, and should only be used in a transitional period, and I think the tranaitional period has lasted more than long enough. From now on, I think one should use the Strict DTD, either 4.01 or XHTML 1. There is no use for BGCOLOR anymore (eh, actually, I think there never was.... :-) ). Instead, use an (external) stylesheet. It's easy to turn off for the users, and it'll be easier for users to make your pages suit their taste.

Other than that, I agree with your philosophy. The pages I write now are XHTML 1 (it should be completely backwards compatible) and comply with at least two levels of Web Content Accessibility Guidelines 1.0. I think that if everybody did that, the web would be a lot more usuable for everyone (it was a huge blunder by the W3C to market the Accessibility Guidelines as being something only for people with disabilities).

When will they learn that if someone is linking to their site, they can determine that through the HTTP Referer header and stick in some logic to do some of their own redirection or change the dynamic content. They can surely make the link as ineffective as if the original page had made an error in the link and put in the wrong domain. Or are corporate suits just too dumb to realize they can control something like their own web site?

I don't really know why you want Gecko so much. KHTML is just as fast, if not faster, than Gecko. For a comparison, try loading this page (which is just straight CSS, no images, so it's a good rendering test) in the latest Konqueror (2.2.2x) and the latest Mozilla/Galeon. You'll notice that it renders much faster in KHTML. Now, I'm not saying this would be true of every page (although it may be!), but I think it goes to show that KHTML can stnd on its own, and there is really no need to use Gecko in Konqueror.

Maybe they changed their website to a more slashdotting compatabile design. They are also dealing with alot of different browsers hitting their site. Hey its simple, fast, and IMHO suited very well for its purpose. Hell I bet its valid html code. If you want bloat, fancy graphics, and bandwidth hogging webpages please go here.

certainly not mine.

The W3C has already has a recommendation for an Extensible Stylesheet Language (XSL) for use with XML. The specification is here.

Yup, XML describes the data, but I would have a look at http://www.w3.org/Style/XSL/. xsl:fo can do a lot of magic ;-)

/AC

• DOM Inspector
  
• JavaScript console
  
• JavaScript debugger
  

• DOM Inspector
  
• JavaScript console
  
• JavaScript debugger
  

In response to public comments and the reaction of various member organizations, the W3C invited Bruce Perens and Eben Moglen to join the Patent Policy Working Group. They also plan a new draft of the Patent Policy document. This was widely reported, so I'm surprised you haven't heard about it. See this announcement.

The W3C does not call itself a standards body. It issues "recommendations".

and he's certainly not afraid to speak his mind.

He certainly isn't afraid to write long-winded anesthesia documents, which makes him eminantly qualified to be a government regulator.

The only question I have is "How does it feel to be the beurocratic hack that every member of the smear campaign against Microsoft was hoping for?"

Of course, somehow I don't expect he'll be answering that question.

HTML links which use the A element are unidirectional primarily because they are embedded in the source document (the webpage at the start of the link).

There is a branch of hypermedia research which deals with what is known as Open Hypermedia, in which links are objects which exist independantly of the documents that they link. This allows more complex link types, such as bidirectional or n-ary (many-ended) links, and promotes a degree of flexibility in the hypertext because links may be applied to many different documents (simplifying link maintenance).

Because the links are stored separately from documents, the resolution of links can be performed both forwards (when following a link in the normal manner) and backwards (when asking "what links point at this page?") with equal ease. The relative paucity of the Web with respect to this type of links has historically been an issue in the hypermedia research community, and it is due to this that the W3C has taken steps to rectify the situation by introducing the XLink recommendation, which allows the creation of open hypertext links.

..bwahahahah.

Check out the results of the w3c validator

(Yeah, slashdot doesn't have to be consistent, they don't have to obey the open standards they promote, but you'd think at least the OSDN navbar would be correct.)

yeesh.

I use HTML for my presentations. Really.

Next thing: Powerpoint leaves no traces. You can't take it with you unless the presenter prints it out, which is an insult to the information carrying ability of paper. You can't refer to something that used to be projected up on a wall but now isn't. Often, the presentation itself is of little use if the presenter isn't speaking any more.

I use OperaShow for this very reason. Problem solved. Like you said, content is everything. Include more content, combine it with content transformation, and voilà! One version for the demo, one version for later reference, and only one document.

We cannot regard anyone as having the "right not to be referred to" without completely pulling the rug out from under free speech.

Frankly, if KPMG doesn't want to be linked to, they should not be on the web.

I got the following unexpected response when trying to retrieve http://www.kpmg.com:

302 Object moved

Please make sure you have entered the URI correctly.

Running their page through the w3c's HTML validator return the following reponse...

I got the following unexpected response when trying to retrieve http://www.kpmg.com/index.html: 302 Object moved

Please make sure you have entered the URI correctly.

[Valid HTML 4.01!] Gerald Oskoboiny
Last modified: Date: 2001/09/14 04:13:13

Don't forget about the W3C's Web Content Accessibility Guidlines -- version 1.0, version 2.0 draft.

Don't forget about the W3C's Web Content Accessibility Guidlines -- version 1.0, version 2.0 draft.

When I first saw the title I immediately thought it was another thing by the same name: Ruby Annotation. (31 May 2001, Marcin Sawicki, Michel Suignard, Masayasu Ishikawa, Martin Dürst, Tex Texin)

The sort of Ruby I had in mind was a type of markup used to add pronunciation alongside text.