Slashdot Mirror

We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

Perhaps not. I believe the point of this newly crafted subset of CSS2 is to provide a stable reference for useful functions that ought to be in mobile devices (meaning ultra-portable devices with limited display capabilities, and not meaning laptops which might have better display capabilities than many quite old desktop computer layouts with small VGA monitors which are still in use throughout the world).

This area is of keen interest to me, and after the long agony with simple HTML 3.2/4.0[1]+ and with CSS1 through the still not-quite-totally-there CSS2, any way to avoid any more standards wrangling will come as a great relief to those of us who have to actually do this stuff for a living. I'd imagine that XSLT 1.0+ engines will do much of the actual work, and it really helps to be able to more or less reuse all that existing work with a near-exact subset of CSS2.

Anyways, I'm back (in a few minutes, after a little more procrastination) to figuring out how to most efficiently split up parts of (simple for now) XML documents for later Java/Python XML/XSLT processing, while allowing simpler, more immediate PHP 4.0+ XML processing. Argh ....

We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

Perhaps not. I believe the point of this newly crafted subset of CSS2 is to provide a stable reference for useful functions that ought to be in mobile devices (meaning ultra-portable devices with limited display capabilities, and not meaning laptops which might have better display capabilities than many quite old desktop computer layouts with small VGA monitors which are still in use throughout the world).

This area is of keen interest to me, and after the long agony with simple HTML 3.2/4.0[1]+ and with CSS1 through the still not-quite-totally-there CSS2, any way to avoid any more standards wrangling will come as a great relief to those of us who have to actually do this stuff for a living. I'd imagine that XSLT 1.0+ engines will do much of the actual work, and it really helps to be able to more or less reuse all that existing work with a near-exact subset of CSS2.

Anyways, I'm back (in a few minutes, after a little more procrastination) to figuring out how to most efficiently split up parts of (simple for now) XML documents for later Java/Python XML/XSLT processing, while allowing simpler, more immediate PHP 4.0+ XML processing. Argh ....

We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

Perhaps not. I believe the point of this newly crafted subset of CSS2 is to provide a stable reference for useful functions that ought to be in mobile devices (meaning ultra-portable devices with limited display capabilities, and not meaning laptops which might have better display capabilities than many quite old desktop computer layouts with small VGA monitors which are still in use throughout the world).

This area is of keen interest to me, and after the long agony with simple HTML 3.2/4.0[1]+ and with CSS1 through the still not-quite-totally-there CSS2, any way to avoid any more standards wrangling will come as a great relief to those of us who have to actually do this stuff for a living. I'd imagine that XSLT 1.0+ engines will do much of the actual work, and it really helps to be able to more or less reuse all that existing work with a near-exact subset of CSS2.

Anyways, I'm back (in a few minutes, after a little more procrastination) to figuring out how to most efficiently split up parts of (simple for now) XML documents for later Java/Python XML/XSLT processing, while allowing simpler, more immediate PHP 4.0+ XML processing. Argh ....

We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

Perhaps not. I believe the point of this newly crafted subset of CSS2 is to provide a stable reference for useful functions that ought to be in mobile devices (meaning ultra-portable devices with limited display capabilities, and not meaning laptops which might have better display capabilities than many quite old desktop computer layouts with small VGA monitors which are still in use throughout the world).

This area is of keen interest to me, and after the long agony with simple HTML 3.2/4.0[1]+ and with CSS1 through the still not-quite-totally-there CSS2, any way to avoid any more standards wrangling will come as a great relief to those of us who have to actually do this stuff for a living. I'd imagine that XSLT 1.0+ engines will do much of the actual work, and it really helps to be able to more or less reuse all that existing work with a near-exact subset of CSS2.

Anyways, I'm back (in a few minutes, after a little more procrastination) to figuring out how to most efficiently split up parts of (simple for now) XML documents for later Java/Python XML/XSLT processing, while allowing simpler, more immediate PHP 4.0+ XML processing. Argh ....

All CSSMP does is say that there is now a mobil-phone media type, and that these rules are used for it. In a way, it's a completely different spec, but you'd need it to be separate. Lumping voice browsers, TV browsers, and console-browsers into one standard would get... messy. CSSMP just gives another set of rules for rendering HTML content.

BTW, how do you expect ISP's to rewrite Amazon.com's main page to work on a cellphone? It's kinda graphically intensive... How about Slashdot? For simple pages, it'd be easy, but for complex pages like Slashdot it would be all but impossible. (Especially pages that are designed to look a certain way, which cellphones, and lynx, usually choke on. Try nVidia's webpage under Lynx some time - it's all graphics without ALT tags.)

Actually, as it turns out, CSSMP might be exactly what you want - since a page designed with a CSS2 style sheet can have multiple media types, the cellphone section would describe how to render the page on a cellphone, while the browser sections would identify how to display it under a browser. A properly designed page would work both under a CSS2 compliant browser (there aren't any!) and under a CSS2 compliant cellphone (and... there aren't any of those, either). But it would be the same HTML document, just different styling rules for different ways of displaying the same content.

And while you're giving the W3C credit for being forward looking, realize that there is no (finished, I think Mozilla trys to) browser that currently implements CSS2 - and the W3C is currently working on CSS3 .

I'm not sure about bloat, but Mozilla/Netscape 6 beats IE or Netscape 4.7 hands down on standards compliance.

I fed my personal home page throught w3.org's validator pages for xhtml 1.0 and css. (validator.w3.org and jigsaw.w3.org/css-validator, respectively). After everything passed validation, only Mozilla/NS6 rendered the page correctly in all aspects.

I'm not sure about bloat, but Mozilla/Netscape 6 beats IE or Netscape 4.7 hands down on standards compliance.

I fed my personal home page throught w3.org's validator pages for xhtml 1.0 and css. (validator.w3.org and jigsaw.w3.org/css-validator, respectively). After everything passed validation, only Mozilla/NS6 rendered the page correctly in all aspects.

Look, SOAP is a protocol. I read the other day that IBM has a Lixux beta of SOAP-based web services available. Try reading the w3.org SOAP proposed spec. Microsoft is just one member of this spec. So is IBM and lotus.

to quote: "SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules."

Yes, but isn't that P3P?

Well, from their description of it -

What is it

SVG is a language for describing two-dimensional graphics in XML.

For one, it's missing a dimension somewhere.

Why not have a go with SVG? It's XML based and it works just fine.

Actually, accessibility when advanced features are disabled is addressed in item 6 of the W3C Accessibility Guidelines, so it's not just for the disabled.

The other thing to consider is this, since your question concerns sites for paying clients: People who turn Java and/or JavaScript and/or cookies off are probably more tech savvy on average than people who don't. So it's entirely possible that people who turn Java and/or JavaScript and/or cookies off would have higher average incomes than people who don't. It would be interesting to see someone do a survey of this; if an income difference were shown to be true, such a result might lessen the enthusiasm of clients for creating sites which require these technologies in order to even work.

Actually, accessibility when advanced features are disabled is addressed in item 6 of the W3C Accessibility Guidelines, so it's not just for the disabled.

The other thing to consider is this, since your question concerns sites for paying clients: People who turn Java and/or JavaScript and/or cookies off are probably more tech savvy on average than people who don't. So it's entirely possible that people who turn Java and/or JavaScript and/or cookies off would have higher average incomes than people who don't. It would be interesting to see someone do a survey of this; if an income difference were shown to be true, such a result might lessen the enthusiasm of clients for creating sites which require these technologies in order to even work.

It's worth noting that PNG, the format used natively by Macromedia Fireworks, and PNG, the Portable Network Graphics format, aren't exactly the same. Macromedia embeds all kinds of wacky vector, layer, and texture information inside the PNG file (PNG is a raster format), which in other respects conforms to the standard.

You can export plain vanilla PNG files from Fireworks, though. It's really a pretty nifty program.

Whatever format is used, it should

1. Provide URLs for locating software and facilitating auto-updates
2. Provide for digital signatures
3. Provide obvious stuff, such as version, name, authors, and descriptions
4. Provide some mechanism for describing dependancies. This is a tough one; even RPM doesn't do a very good job of resolving dependancies, which I believe is due in part to its format for describing them.
5. Be XML based for machine readability, human-editable, and platform independant.

Unfortunately, there is still no coherent architecture for mirroring and for mirror sites to register their collections with the sites which they mirror. In fact, we lack even a common (de facto) standard for recording this replication information in a machine readable for-mat. Some progress was made on this a few years ago by the Internet Engineering Task Force s [1] working group on Internet Anonymous FTP Archives, with the creation of the so-called IAFA Templates [2]. These provided a simple machine readable format for recording per-resource or collection metadata, which could easily be created by hand or programatically. Although support for IAFA templates was integrated into some software packages, e.g. the ALIWEB search engine [3] and the ROADS resource discovery sys-tem [4] , this approach never became successful on a large scale. The World Wide Web Consortium s Resource Description Format (RDF) [5] and the Dublin Core metadata effort [6] may eventually provide a viable machine readable interchange format.

Currently, the database underlying the freshmeat.net weblog [7] is perhaps the closest thing we have to a genuine mirror registry - though it focuses almost exclusively on soft-ware packages and operating system distributions, and only offers limited mirror informa-tion. RDF is also being used in this capacity as part of rpmfind.net [8], although mirror information is very limited in this case too. The Internet Engineering Task Force s Uni-form Resource Names effort [9] is also relevant here, since it would be very useful if there were persistent and location independent names for these collections of replicated resources.

[1] http://www.ietf.org/ Internet Engineering Task Force website
[2] http://info.webcrawler.com/mak/projects/iafa/ IAFA Working Group & IAFA Templates homepage
[3] http://aliweb.emnet.co.uk/ ALIWEB website
[4] http://roads.opensource.ac.uk/ ROADS website
[5] http://www.w3.org/RDF/ World Wide Web Consortium Resource Description Format (RDF) homepage
[6] http://purl.org/dc/ Dublin Core website
[7] http://freshmeat.net/ freshmeat.net website P. Lenz & Andover Advanced Technologies, Inc.
[8] http://rpmfind.net/ rpmfind.net website
[9] RFC 1737, Functional Requirements for Uniform Resource Names K. Sollins & L. Masinter December 1994

And at the end somewhat less relevant to the topic.

This kind of metadata should be extremely valuable for implementation of the URIs and particularly for the I2C(s) (URI tp URC). Quote from the RFC 2483:

"Uniform Resource Characteristics are descriptions of resources. This request allows the client to obtain a description of the resource identified by a URI, as opposed to the resource itself or simply the resource's URLs. The description might be a bibliographic citation, a digital signature, or a revision history. This memo does not specify the content of any response to a URC request. That content is expected to vary from one server to another."

I believe this is what you want: Open Software Description Format (OSD) from w3.org.

Abstract: This document provides an initial proposal for the Open Software Description (OSD) format. OSD, an application of the eXtensible Markup Language (XML), is a vocabulary used for describing software packages and their dependencies for heterogeneous clients. We expect OSD to be useful in automated software distribution environments.

The most notable places where RDF is presently used for real things (as opposed to "we'd like it to be used here vaporware") include:

• In the dmoz.org Open Directory RDF Dump
• The encoding of rpm2html used at rpmfind.net

The latter is exceedingly relevant, as it represents an encoding of metadata about Linux software packages in RDF form.

I would also like to point out RDF as an existing use of XML for something very similar to what you're asking for. It can be extended with more tags if you need them. Right now it's targeted more towards web content, but I think it will give you some good ideas.

Writing style sheets
Web Design Group's CSS Guide
ZDNet's CSS primer
W3C's CSS Guide
A full list of CSS properties (cheat sheet!)

The cool thing about CSS is it lets the author specify fancy layouts, colours etc, but older browsers etc do not rely on them at all - the heirarchical nature of the document remains intact.

Freenet is good, it came up with some pretty neat ideas, but it would be better if it had been developped and thought out in advance in the context of an IETF working group, if the specifications had been released as a Request For Comments, and, in other words, if it had paid a little more attention to existing Internet standards instead of being Yet Another anti-censorship system.

For example, why did Freenet have to come up with their own key scheme instead of using the official standard of Uniform Resource Names (URNs) defined by RFC2141 (the previous link was an example of a URN)?

I have this dream of a true world-wide distributed database founded on recognized Internet standards. It would use URNs as keys. (In particular, it would allow arbitrary Unicode character data.) It would use the ubiquitous RDF format as "semantic sugar" (pardon the expression) of its communications. It would borrow ideas from HTTP (the best Internet communications protocol we have so far) for the protocol, and Usenet and Freenet for the distribution mechanisms, as well as the public key distribution system and trust web, and the everything system. It would use public-key cryptography as the basis for its trust graph, so as to make data authentification possible and tampering impossible. Certificates and signatures would be distributed along the network itself. It would employ secret sharing mechanisms to split the risks of carrying certain data. It would be impossible to tamper with, impossible to censor, and extremely difficult to break. It would replace the lousy and obsolete DNS system (and also alleviate somewhat the power of "root registrars" in the DNS), and possibly The Web itself. And, to make my dream even more of a dream, it would be simple to implement.

Hmmm.... Nice project, for the year 2100 or so. Anyone care to start an IETF working group?

Me too, but the point is that I don't want my mobile phone to be any bigger than it currently is (I've got a Nokia 3210), in fact, I would like it to shrink even further, but I still like it to be able to read web pages, and the fact is that HTML is suited for the purpose. It's called graceful degradation, and it is all very nicely put in the Web Content Accessibility Guidelines. When you can have both, why settle for less?

Um... Wasn't the first web client and server -- built with NEXTSTEP at CERN by Tim Berners-Lee ? Without this 'not so great... desktop... Unix... that sucked", this page would not be here.

However, I recognize the need for some automated rating criteria, and that is not just about pr0n, but all kinds of information. I think that rating technologies are not inherently good or bad. Take RDF for example. It can be used to check out enormous amounts of information for you, and you may decide whether or not you want to see it. Since you have a finite life, you can't wade through all the information, so you'll be happy that somebody or something has done a lot of things for you. So the opposition to RDF or (even) PICS is a bit wrong, I feel.

Now, the same technology can be used to vlock sites for kids. Well, that could be good or bad, I would for example have no objections to let kids explore AllAboutSex without me hanging over them, but there are certain sites I would want to guide them through... So, you need rating schemes that are able to make a clear distinction somewhere here, that's the important thing. Opposition to any technology that can do this is counterproductive.

What one should oppose in this case is not the technology, but rather any laws that makes any rating scheme or technology mandatory. That's the scary thing, if any of this is mandatory, that's wrong, as long as it is voluntary, it's OK.

Another compelling (and often-quoted) section of The Cathedral and the Bazaar is the discussion about debugging. Raymond says: "Given enough eyeballs, all bugs are shallow" and "Debugging is parallelizable." These assertions simply are not true and are distortions of how the development of fetchmail proceeded. It is true that many people, in parallel, looked for bugs and proposed fixes. But only one person (Raymond) actually made fixes, by incorporating the proposed changes into the official code base. Debugging (the process of fixing the program) was performed by one person, from suggestions made by many people. If Raymond had blindly applied all proposed code changes, without reading them and thinking about them, the result would have been chaos. A rare bug can be fixed completely in isolation, with no effect on the rest of the program.

The above quote from the article suggests that "debugging" consists essentially of making the code changes themselves. - WRONG!

The most excrutiatingly painful part of the "debugging" process is to actually find the bug, not necessarily and exclusively fixing it which I consider more like the fun part of the challenge. Well that can be inverted in some cases too ...

Anyway, the Open Source model, with "many eyeballs" looking at the code, helps you FIND a lot more bugs than one person would, and identify the weaker areas of the code and architecture. Of course the code doesn't fix itself because a bunch of geeks looked at it, and the OpenSource concept never ever claimed to allow that, but it does allow a more thorough debugging process which will eventually make for stronger code.

One of my favorite Open Source projects is the Xalan XSL processor, which I believe is another marvelous example of the success of the Open Source concept. I have tested its compliance against W3C Standards by using a good 99% of XSL-T and XPath's features in some complex XSL-based applications I'm working on, and I can tell you this thing is rock-solid, which I find even more laudable as language processors are some of the more complex applications one can develop.

Switch to an open source browser! Volunteer developers have no interest in building a browser that's going to spy on it's users...

Unless, of course, they're an Evil Genius.

The problem with the available open-source browsers is that they don't have IE's functionality. As lame as IE is, it has better standards support (And I don't mean the M$-defined standards, either) and more functionality (And here I am talking about Micro$haft-specific stuff, like activeX and client-side VBscript.) They also support CSS more fully than any other browser, and last I checked, that included arena, the W3C's (now yggdrasil's)standards-flagship buggy-as-all-hell featureless browser.

Of course, Arena is basically now all but dead. The only sign of life that I could see is that it still has a webpage. It's been replaced in the W3C with Amaya, which claims it "supports HTML 4.0, XHTML 1.0, HTTP 1.1, MathML 2.0, and many CSS 2 features". Amaya has an ungodly slow display engine.

By contrast, in a quote from the W3C website (C&P'd from Amaya, BTW) we see the following: "000327 Microsoft shipped Internet Explorer 5 for the Macintosh. It apparently supports full CSS1, the first browser to do so." IE5.5/windows still doesn't do this, reportedly. I don't have a test suite handy, so I can't verify any of this one way or another.

Mozilla is tres crashy. Netscape is agonizingly slow. Arena is slow and painful, ditto for Amaya. Opera finally has Java working properly, or so I hear (haven't run it recently) so I guess you can take it seriously, but the default layout made me shudder. It's also not as easy to customize (Or at least, to understand what you're doing) as I had thought it would naturally be. I guess the Mac users have a couple of other options, but they're missing major functionality, too, right?

So what's left? If you discount IE for privacy reasons - nothing. Though I do use Mozilla for Mail, and occasionally K-Meleon to check out a small webpage quickly, or to load something that IE has network problems with. And Netscape and Mozilla both have dramatically faster implementations of Javascript and GIF89a animation.

I'm not sure if there are any guidelines in the ADA, but w3c has guidelines:
http://www.w3.org/TR/WAI-WEBCONTENT/

In fact, JPEG relies on perceptual coding, so that the perceived effect of the lossy algorithm is minimized.

The exceptions to the rule are SGI machines (which were designed with ray-tracing in mind, so they assume physical coding in the frame buffer and use gamma correction to convert to perceptual coding) and Macs (which have a gamma correction intended to mimic the dot gain of the original Laser Writer.)

For more than you ever wanted to know about gamma, see Charles Poynton's Gamma FAQ and the sRGB proposal.

--

Recently I posted this comment mentioning the fact that there's really no reason why a domain such as www..com (you should see two Chinese ideograms meaning "China" between the "www." and the ".com" parts; further, if you click on this link, your browser should open a window telling you that the domain "www..com" does not exist, with the same two Chinese ideograms) doesn't exist.

Let us recall: first, as specified by the HTML specification, every HTML document, no matter what character set it is "encoded" as, is written in the all-englobing Unicode character set. So when you write something like "中国" in HTML, it refers to the Unicode characters (decimal) 20013 and 22269, no matter what the current character encoding and font are. So that's how you write the link text. Second, as for the URL itself, well, although it is not (as far as I know) formally recommended by an Internet standard, it is widely recognized that URLs are written in the UTF-8 encoding format (which is afterward %-encoded into ASCII).

The whole process is described in this Internet Draft ("Internationalized Uniform Resource Identifiers"; WORK IN PROGRESS!) by Larry Masinter and Martin Duerst where the relationship between URIs and IURIs (Internationalized URIs) is discussed in detail.

The DNS is the toughest part of all. The DNS specification (RFC1034) states (section 3.1) that DNS data is to be taken as binary for possible upward compatibility (this was wonderful foresight on Mockapetris' part!). Consequently, there is nothing as per standards wrong with using (UTF-8 encoded Unicode) 8-bit data in DNS labels. Except, of course, that many "buggy" implementations will have to be corrected for broken assumptions, *sigh*. The IDNS working group suggests using a UTF-5 encoding to avoid going beyond the current domain name limits: I think this is not a good thing and we should stick to UTF-8 and repair broken software.

Oh, and incidentally, see this page too know how broken your browser's Unicode support is.

Recently I posted this comment mentioning the fact that there's really no reason why a domain such as www..com (you should see two Chinese ideograms meaning "China" between the "www." and the ".com" parts; further, if you click on this link, your browser should open a window telling you that the domain "www..com" does not exist, with the same two Chinese ideograms) doesn't exist.

Let us recall: first, as specified by the HTML specification, every HTML document, no matter what character set it is "encoded" as, is written in the all-englobing Unicode character set. So when you write something like "中国" in HTML, it refers to the Unicode characters (decimal) 20013 and 22269, no matter what the current character encoding and font are. So that's how you write the link text. Second, as for the URL itself, well, although it is not (as far as I know) formally recommended by an Internet standard, it is widely recognized that URLs are written in the UTF-8 encoding format (which is afterward %-encoded into ASCII).

The whole process is described in this Internet Draft ("Internationalized Uniform Resource Identifiers"; WORK IN PROGRESS!) by Larry Masinter and Martin Duerst where the relationship between URIs and IURIs (Internationalized URIs) is discussed in detail.

The DNS is the toughest part of all. The DNS specification (RFC1034) states (section 3.1) that DNS data is to be taken as binary for possible upward compatibility (this was wonderful foresight on Mockapetris' part!). Consequently, there is nothing as per standards wrong with using (UTF-8 encoded Unicode) 8-bit data in DNS labels. Except, of course, that many "buggy" implementations will have to be corrected for broken assumptions, *sigh*. The IDNS working group suggests using a UTF-5 encoding to avoid going beyond the current domain name limits: I think this is not a good thing and we should stick to UTF-8 and repair broken software.

Oh, and incidentally, see this page too know how broken your browser's Unicode support is.

______

If it can be changed later without the customer's knowledge, what good is it?

P3P recognises this, and has mechanisms to support it. You're allowed to make a new policy whenever you wish, but the original one must be preserved, must remain accessible, and must be distinguishable from the new one. There are solid business reasons why you might want to (or be forced to) change it. A generous interpretation of Amazon.com's changes are that they're clarifying their position after the ToySmart privacy issue.

I think it is worthwhile to check out W3C'S Micropayments Overview. They have recently issued a working draft on Common Markup for Micropayment per-fee-links for last call review.

At least this would increase the Chaos.

Does anyone remember DeCSS, I mean, the program that removes Cascading Style Sheet statements from HTML source? It is mentioned on W3C's CSS-page. A university student even got his account terminated for mirroring that DeCSS!

Whatever, I'm actually just posting to include yet another link to DeCSS on Slashdot.

--

HTML 4.1, the most recent standard, makes the ALT tag a requirement. The HTML validators at W3C won't let you get away with not using ALT tags. They do validate their HTML, right?

HTML 4.1, the most recent standard, makes the ALT tag a requirement. The HTML validators at W3C won't let you get away with not using ALT tags. They do validate their HTML, right?

HTML 4.1, the most recent standard, makes the ALT tag a requirement. The HTML validators at W3C won't let you get away with not using ALT tags. They do validate their HTML, right?

While there is a lot more to accessibility than a simple ALT-attribute, the ALT-attribute is required by HTML4, and if you hire someone and they give you code that doesn't validate, then I think you are in your full right to say that "the product you delivered doesn't work, fix it".

While there is a lot more to accessibility than a simple ALT-attribute, the ALT-attribute is required by HTML4, and if you hire someone and they give you code that doesn't validate, then I think you are in your full right to say that "the product you delivered doesn't work, fix it".

This is the exact same situation, not only is the ALT tag reccomended by the standard,

<!-- To avoid problems with text-only UAs as well as to make image content understandable and navigable to users of non-visual UAs, you need to provide a description with ALT, and avoid server-side image maps -->
<!ELEMENT IMG - O EMPTY -- Embedded image -->
<!ATTLIST IMG
%attrs; -- %coreattrs, %i18n, %events --
src %URI; #REQUIRED -- URI of image to embed --
alt %Text; #REQUIRED -- short description --

.. etc ..

After some investigation, I find you're correct - I was misinformed. In fact, AOL has apparently already been the subject of a class-action lawsuit under the ADA for failing to support access by the blind.

For more information: this page from the W3C has links to laws about web accessibility from several countries.

And yes, I realize US law doesn't apply in Australia. But the post I was responding to raised the issue of US law as an expansion of the topic.

If the customer had been smarter, they would have specified HTML 4.01 compliance as a condition of acceptance of the deliverable. The use of the alt attribute for the img element is required by the HTML 4.01 Recommendation

The problem with your CSS is the "#664433". Get rid of those quotes and it renders fine for me in Mozilla.

Always a good idea to check your pages for standards compliance.

Not sure why the JavaScript doesn't work (although DOM layer support is rather dicey and browser specific).

The problem with your CSS is the "#664433". Get rid of those quotes and it renders fine for me in Mozilla.

Always a good idea to check your pages for standards compliance.

Not sure why the JavaScript doesn't work (although DOM layer support is rather dicey and browser specific).

"it doesn't work with lynx!"
BOO HOO.

You know something? I can't find any music on 8 track, and it's amost impossible to find a convenience store that sells leaded gas.

In short, AOL's webmaster info page doesn't seem standard's compliant.

• I tried to view the AOL "help" page from Opera 4.02, and the navigation frame on the left didn't show up. Funny, I can view the source.
• So I tried IE 5.5, figuring that AOL would support at least that browser (after all, they ship it as part of the package), and the frame's Javascript magically worked.
• Then I tried Navigator 4.74, and the Javascript worked again. Magic.
• I was then truly intrigued, so I put the page in Amaya (W3C's standard's demonstrating browser/authoring tool), and the page didn't load at all. None of the frames showed up, but I could look at the source if I wanted to.
• And I couldn't get Mozilla 17 to load the navigation frame at all, then the reload put the main frame in the navigation frame. (BTW, a connection was refused when attempting to contact webmaster.info.aol.com.) Persistent reloading got the main frame back into the right spot, but I still can't see the Javascript navigation frame on the left, though I can see the source.
• K-Meleon also gives me the connection error, but I can't get anything to show up on the screen.

In short, AOL's webmaster info page doesn't seem standard's compliant. Oh, and this is all from Win98, on a T1.

After this, I don't want to read about how to make my pages work with their software. If I can't even see their webpage with my browser, how can I trust them when they tell me what will work with theirs? Their suggestions would probably break Opera or Mozilla.

. . .

"Where do you want to go ...

I hope these will enlighten:

• W3C's PICS page (How To Do It)
• Censorware.Ørg (critical site, as usual)