Slashdot Mirror

OK, I did some searching for the Neowin article on this, and can just as well post it here too.
It's a bunch of fun historical documents. ;-)

- Screenshot of Tim-Berner Lee's web browser/editor gizmo (apparently two apps in one suite, kinda like Mozilla?)
- Web page (from 1992) describing a very early version of HTML
- Description of the web (from 1992)*
- The original WWW proposal from 1989**
- History of the web

* = It tells you why the WWW was made... "Tim decided that high energy physics needed a networked hypertext system and CERN was an ideal site for the development of wide-area hypertext ideas"

** = excerpt: "Note that the only name I had for it at this time was "Mesh" -- I decided on "World Wide Web" when writing the code in 1990."

OK, I did some searching for the Neowin article on this, and can just as well post it here too.
It's a bunch of fun historical documents. ;-)

- Screenshot of Tim-Berner Lee's web browser/editor gizmo (apparently two apps in one suite, kinda like Mozilla?)
- Web page (from 1992) describing a very early version of HTML
- Description of the web (from 1992)*
- The original WWW proposal from 1989**
- History of the web

* = It tells you why the WWW was made... "Tim decided that high energy physics needed a networked hypertext system and CERN was an ideal site for the development of wide-area hypertext ideas"

** = excerpt: "Note that the only name I had for it at this time was "Mesh" -- I decided on "World Wide Web" when writing the code in 1990."

Internet explorer will still display the alt

unless they fixed that in modern versions

Internet explorer will still display the alt

unless they fixed that in modern versions

I guess it's just easier to block the W3C validator instead.

With...

color: blue {a.blue, span.blue, div#back}

You got it backwards.

a.blue,span.blue,div#back { color:blue }

Also, you can specify classes more than once in a stylesheet. I use this to separate my stylesheets in two: Operational (margins, positioning width, etc), and Presentational (color, border styles).

For example:

STYLESHEET A

#whatever, #somethingelse { border:1px solid; width:35%; }

STYLESHEET B

#whatever { border-color:#f00;border-style:ridge; }

#somethingelse { border-color:#0f0;border-style:outset; background-color:#fff; }

Just link both stylesheets in your html header section. Perhaps if you read the CSS specs at the w3c you might find some pleasant surprises :)

Actually for the experienced person I would recommend learning from the actual "Standard" of CSS at W3C.

CSS 2.1 Specification

If you want to see the upcoming CSS 3 standard, or learn more about CSS, you can go here:

http://www.w3.org/Style/CSS/

Actually for the experienced person I would recommend learning from the actual "Standard" of CSS at W3C.

CSS 2.1 Specification

If you want to see the upcoming CSS 3 standard, or learn more about CSS, you can go here:

http://www.w3.org/Style/CSS/

If you're an XML parser, you should have done so on the very first byte.

That said, it's too bad that Half-Life 2 can't be run on software unlike the original should the need/desire arise. I don't think the engine really matters, so much as the scalability of said engine. Half-Life 2's Source is about as scalable as...well, not much (requires DirectX, and at least version 6). Whatever HL's engine was, and however bad it looks now compared to HL2, it could still run on LOTS more PCs--OpenGL, DX and (again) plain old software. That helped its popularity.

Read this if you want to know about binary XML (http://www.w3.org/TR/wbxml/).

The XOP proposal is a mechanism to represent and refer to binary data in an XML document.

XOP is not a proposal to compress XML documents.

You might say, oh, I can use CDATA, right.

Unfortunately, no. CDATA cannot be reliably used because the character range for CDATA is loosely 0x9, 0xA, 0xD, and anything above 0x20. (http://www.w3.org/TR/REC-xml/#NT-Char)

That's why tty and screen both come under the visual group.

That's why tty and screen both come under the visual group.

(Black and White War Propaganda Film)

It is one's dutey
to test one's governmental site
for good and proper accessibilitey

So therefore I assembled ELinks
And thus perused the site in question
When it came on offering one's humble generositey
One was instead sadley denied - the transaction.

Blimey Guv'nor, you do push your luck don't ya?

Quite so.

This might be what you're looking for:

http://www.w3.org/MarkUp/Test/

These specs (XOP and MTOM) were created becase Web Services people wanted to be able to add binary attachments to XML messages (in SOAP). Initially the attachment technologies (like SOAP with Attachments) worked by just slapping the binary data alongside the XML message, without a clearly defined processing model for the receiver. Now with XOP attachments are logically in the XML document, but physically transported outside without the bloat of base64 or other XML-safe encodings. It's important to notice that XOP is just an optimization of the situation where binary data is put inside an XML document.

XML has become at least two things since its evolution:

1. an abstract structure consisting of (possibly-nested) elements and their corresponding attributes.
2. a human-readable representation of that structure

The interesting part of the story is that #2 came first. Since then, the W3C has recommended the Infoset abstract concept.

For the developers out there, think of how often you parse the "angle brackets" yourself. Most everyone these days (yes, I know there are exceptions) uses an API which presents elements and attributes in a wire-format-agnostic way.

As a developer, I would love to have the option to flip a switch in my code to permit Binary XML. If I can read and use the Infoset in exactly the same way, why would I object to the wire format being binary instead of text? My API is the same, but the transport is more compact and efficient.

Human-readable wire formats are great for debugging during development, but provide no real advantage in production systems (provided there are utilities available to produce human-readable XML from the binary wire format.)

I thought this was going to be about a standardization of compressing XML files that got rid of the excess bloat in the markup.

these testimonials are so much like the TWO THUMBS UP !! type things you see for movies like this one

People in glass houses shouldn't throw stones.

Due to the title of this article, I just noticed that Firefox doesn't translate SGML character references (ex. © = ©) in RSS feed bookmarks. That may be an issue with the Windows GUI, though. There's bound to be someone around here looking at this from Firefox under *nix - does it appeart to be universally broken, or is it just a windows thing?

IE fudges sites and this hides errors, I want to see errors in pages I develop, then I can fix them.

All browsers fudge sites to some extent, otherwise only fully compliant pages would display (I'm assuming by fudging you mean 'fixing' the HTML so that it'll display). Just take a look at Slashdot's many unclosed P elements; if it weren't fudged you probably wouldn't see much. If you really want to see errors I recommend W3's Validator. And if you're writing a web page, please use it. Writing validating web pages to begin with isn't hard. It's a lot harder to fix existing non-validating pages.

It also chokes on my company's online timecard page, and looking at the page code I don't see anything particularly unusual or esoteric.

Did you actually validate the code of your company website? There's probably just a small error in the HTML, often that's why stuff renders in a strange way.

run it through http://validator.w3.org/

It looks like you and I do the same thing to build standard code, but as for your specific question, there's no real automated way that I know of, though it'd be a cool service to automate.

All you can do is validate your code and then load the site in different browsers to see how it looks.

Here's what I do:

I use the validators on the W3C site to determine if my pages are coded correctly, and furthermore I have placed the buttons for checking this directly on the site. This lets visitors check for themselves if they're so inclined, rather than taking my word for it, and it also lets visitors know that such things as standards-validators exist.

The W3C Markup Validation Service is the main page; you can see an example of the output by looking at the review of the site I built at Validation Results. It will also check your CSS, which you can do at The W3C CSS Validation Service (demo output, validation of my pages, at this location).

This also allows me to dodge complaints that the site doesn't look good in browser (x) -- though I tested it in a variety of them and it looked fine, although I don't guarantee that Navigator 4 will work though not through much trying on my part to get it to be at least passable. If I get complaints I point to the verification icons and explain how browser standards work (thus, since the page is validated to be correctly built, I can't control what the user's browser is doing) and let 'em know that they might get better results if they try a different browser. Fortunately, I haven't gotten any complaints in recent memory.

For browsers I don't have (Opera, for example) I contact friends who do have those browsers, and ask them to take screenshots and send me the screenshot. A longtime friend of mine uses Opera nearly constantly, so it wasn't a problem for him to supply a bit of help. I did the same for Omniweb, etc.

My idea for an automated service: send the server the URL of a page you want to check, and it will load the requested site into a variety of different browsers and take screenshots of the browser windows and let you login later to view the results or email you the images. This would let developers check how their pages look in browsers they don't normally have access to.

Would save you and I (and others!) a lot of trouble!

It looks like you and I do the same thing to build standard code, but as for your specific question, there's no real automated way that I know of, though it'd be a cool service to automate.

All you can do is validate your code and then load the site in different browsers to see how it looks.

Here's what I do:

I use the validators on the W3C site to determine if my pages are coded correctly, and furthermore I have placed the buttons for checking this directly on the site. This lets visitors check for themselves if they're so inclined, rather than taking my word for it, and it also lets visitors know that such things as standards-validators exist.

The W3C Markup Validation Service is the main page; you can see an example of the output by looking at the review of the site I built at Validation Results. It will also check your CSS, which you can do at The W3C CSS Validation Service (demo output, validation of my pages, at this location).

This also allows me to dodge complaints that the site doesn't look good in browser (x) -- though I tested it in a variety of them and it looked fine, although I don't guarantee that Navigator 4 will work though not through much trying on my part to get it to be at least passable. If I get complaints I point to the verification icons and explain how browser standards work (thus, since the page is validated to be correctly built, I can't control what the user's browser is doing) and let 'em know that they might get better results if they try a different browser. Fortunately, I haven't gotten any complaints in recent memory.

For browsers I don't have (Opera, for example) I contact friends who do have those browsers, and ask them to take screenshots and send me the screenshot. A longtime friend of mine uses Opera nearly constantly, so it wasn't a problem for him to supply a bit of help. I did the same for Omniweb, etc.

My idea for an automated service: send the server the URL of a page you want to check, and it will load the requested site into a variety of different browsers and take screenshots of the browser windows and let you login later to view the results or email you the images. This would let developers check how their pages look in browsers they don't normally have access to.

Would save you and I (and others!) a lot of trouble!

It looks like you and I do the same thing to build standard code, but as for your specific question, there's no real automated way that I know of, though it'd be a cool service to automate.

All you can do is validate your code and then load the site in different browsers to see how it looks.

Here's what I do:

I use the validators on the W3C site to determine if my pages are coded correctly, and furthermore I have placed the buttons for checking this directly on the site. This lets visitors check for themselves if they're so inclined, rather than taking my word for it, and it also lets visitors know that such things as standards-validators exist.

The W3C Markup Validation Service is the main page; you can see an example of the output by looking at the review of the site I built at Validation Results. It will also check your CSS, which you can do at The W3C CSS Validation Service (demo output, validation of my pages, at this location).

This also allows me to dodge complaints that the site doesn't look good in browser (x) -- though I tested it in a variety of them and it looked fine, although I don't guarantee that Navigator 4 will work though not through much trying on my part to get it to be at least passable. If I get complaints I point to the verification icons and explain how browser standards work (thus, since the page is validated to be correctly built, I can't control what the user's browser is doing) and let 'em know that they might get better results if they try a different browser. Fortunately, I haven't gotten any complaints in recent memory.

For browsers I don't have (Opera, for example) I contact friends who do have those browsers, and ask them to take screenshots and send me the screenshot. A longtime friend of mine uses Opera nearly constantly, so it wasn't a problem for him to supply a bit of help. I did the same for Omniweb, etc.

My idea for an automated service: send the server the URL of a page you want to check, and it will load the requested site into a variety of different browsers and take screenshots of the browser windows and let you login later to view the results or email you the images. This would let developers check how their pages look in browsers they don't normally have access to.

Would save you and I (and others!) a lot of trouble!

It looks like you and I do the same thing to build standard code, but as for your specific question, there's no real automated way that I know of, though it'd be a cool service to automate.

All you can do is validate your code and then load the site in different browsers to see how it looks.

Here's what I do:

I use the validators on the W3C site to determine if my pages are coded correctly, and furthermore I have placed the buttons for checking this directly on the site. This lets visitors check for themselves if they're so inclined, rather than taking my word for it, and it also lets visitors know that such things as standards-validators exist.

The W3C Markup Validation Service is the main page; you can see an example of the output by looking at the review of the site I built at Validation Results. It will also check your CSS, which you can do at The W3C CSS Validation Service (demo output, validation of my pages, at this location).

This also allows me to dodge complaints that the site doesn't look good in browser (x) -- though I tested it in a variety of them and it looked fine, although I don't guarantee that Navigator 4 will work though not through much trying on my part to get it to be at least passable. If I get complaints I point to the verification icons and explain how browser standards work (thus, since the page is validated to be correctly built, I can't control what the user's browser is doing) and let 'em know that they might get better results if they try a different browser. Fortunately, I haven't gotten any complaints in recent memory.

For browsers I don't have (Opera, for example) I contact friends who do have those browsers, and ask them to take screenshots and send me the screenshot. A longtime friend of mine uses Opera nearly constantly, so it wasn't a problem for him to supply a bit of help. I did the same for Omniweb, etc.

My idea for an automated service: send the server the URL of a page you want to check, and it will load the requested site into a variety of different browsers and take screenshots of the browser windows and let you login later to view the results or email you the images. This would let developers check how their pages look in browsers they don't normally have access to.

Would save you and I (and others!) a lot of trouble!

It's true, overuse of ALT attributes can just add noise to a page.

For a good overview of Web accessibility, check out the World Wide Web Consortium's Web Content Accessbility Guidelines.

Well I'm sure it doesn't help that Slashdot's HTML isn't valid HTML 3.2... or even HTML 2.0.

Well I'm sure it doesn't help that Slashdot's HTML isn't valid HTML 3.2... or even HTML 2.0.

I suppose that's while they don't have a link to w3c's html validator in the footer, like some other sites do. checking out the Validator does wonders for your mark-up, but its hell on your ego.

I agree with most of what you said, but keep in mind that Google doesn't care about standards compliance per se.

Why take the time and effort to make a site standard compliant when in the end it would probabaly use more bandwidth for google

You're talking a handful of bytes, at most. Things like making sure your 'id' tags conform with proper naming conventions (e.g., starting with a letter, rather than a number), and wrapping quotes around attributes' values, don't (or, shouldn't) break browsers, don't incur overhead, and are (gasp) standards compliant.

I'll point out that only on the 'Web is this type of sloppiness anticipated and handled gracefully; try the same level of lack of attention to syntactic detail in, say, Java, Perl, C/C++, etc., and you'd be in for a rude awakening.

What makes W3C standards anyway?

Are you serious? Ever here of Tim Berners-Lee, the inventor of this here world wide web?

Remember, the 'web isn't just MSIE and Firefox; my cellphone has to render Google these days, as does my PDA, as does . . . When sites are coded to standards, it makes it very easy for programmers to accomodate those sites. When sites disregard the standards, browsers have to become exponentially larger and more complicated, to address the myriad ways in which code is non-standardized. Standards adherence streamlines things for *everyone*; lack of standards compliance may work today but may break nastily tomorrow.

Having a standard document from which both parties are working (browesr builder and site programmer) means both are on the same page, literally. It's not "one way to make the internet more uniform," it's the only way in which the Internet will work the way it's designed to. If everyone didn't accomodate at least HTTP/0.9, you wouldn't be web surfing today; if every modern browser didn't support HTTP/1.1 no one could get cheap shared-server web hosting (and/or we'd have a serious shortage of IP addresses) . . . You use standards every day. Bringing HTML into compliance with basic standards is a no-brainer, and it's inexcusable (IMHO) for a company as large and prominent as Google to ignore them.

So this means the Google will get the features it wants and to hell with everyone else, including standards compliance which seems to be taken a back seat these days.

I've never done so before, but this comment prompted me to run the basic main Google page through the w3c validator; the results were suprising. It's such a simple page; why not take the (minimal!) time necessary to code proper HTML?! Yikes. I didn't expect that level of sloppiness.

(Yes, my personal page validates just fine, thanks (though some subpages may not, given the age of a lot of the code, and the multiple generations of sites the content pages have churned through... After I graduate and pass the Bar, maybe I'll have time to go back and fix them...)

So this means the Google will get the features it wants and to hell with everyone else, including standards compliance which seems to be taken a back seat these days.

I've never done so before, but this comment prompted me to run the basic main Google page through the w3c validator; the results were suprising. It's such a simple page; why not take the (minimal!) time necessary to code proper HTML?! Yikes. I didn't expect that level of sloppiness.

(Yes, my personal page validates just fine, thanks (though some subpages may not, given the age of a lot of the code, and the multiple generations of sites the content pages have churned through... After I graduate and pass the Bar, maybe I'll have time to go back and fix them...)

XML is a way of repreenting data.

JSON is an RPC API for javascript, that is implemented by a simple on-wire data represenation.

The W3C XML encryption standards notwithstanding, security is clearly a concern outside the scope of simple data respresentation. However, this is NOT the case for a RPC system.

After spending a few minutes futzing around with this, clearly this is pretty interesting stuff. However what is missing is a sense of what best practices for security are in a JSON application. Is security supposed to be handled by the remote objects? By the application container? By the transport layer?

A quick look at the JSONRPCServlet code makes it look like no thought has been given to security at all. It merely checks for a session and creates one if it doesn't exist. So, if you are simply mapping /JSON-RPC to com.metaparadigm.jsonrpc.JSONRPCServlet, you get no security whatsoever. Once an attacker figures out the URL patterns of your system (which would be very easy, especially if he can sniff packets on your network), your objects are basically wide open.

Experience has shown that not thinking about security in a network.

My guess it that best practices for security in a JSON applicaiton would include a combination of TLS for on-wire security and AOP to your remote callable objects. You could put an adapter around com.metaparadigm.jsonrpc.JSONRPCServlet to perform some kind of security check on requests, maybe checking authentication credentials against a set of configuration files. This would in effect be a kind of aspect oriented programming wrapped around your remoteable objects, without any special AOP magic.

My sense is that this would have the potential to be reasonably secure, while remainign orthagonal to the overall model and so maintain the original simplicity. These JSON folks should consider making this mandatory -- to have a role/method security registry that would cause an error to be thrown if somebody exceeded their rights. The servlet could then be configured in one of two differnt modes: allow-if-not-forbiiden, or forbid-if-not-allowed. The allow-if-not-forbidden mode of the servlet would work just as it does now in the absence of any security configuration information.

Because XML requires a parser, and this JSON thing looks like it could be evaled into a jscript array,

Which magical browser do you use that doesn't need to parse the code that it eval()s?

which is a *much* quicker operation

I think that you have forgotten that eval() needs to parse too, I'm not convinced that it is much quicker. Even if it was, it doesn't follow the Principle of Least Power. XML doesn't execute. Javascript does. There's a reason why JSSS was rejected by the W3C and CSS wasn't. Using a fully-fledged scripting language to represent data is insane, especially when you are working with untrusted data off the web.

and requries no external libraries to operate.

An XML parser is built into every web browser that JSON targets.

Hopefully this will provide some added incentive for browser makers to support DOM Level 3 Load and Save...

Here's an example of what I mean...

Section 5.3.3 of the W3 spec for CSS1 includes:

BODY { background-image: url(marble.gif) }

I use this CSS item in the stylesheet for my own site. When I view this in IE I get a background image, when I view it in FireFox I don't. One small item, but it makes a big difference to the look of the site.

By the time the average user can run a XAML app, hopefully XUL will have been accepted as an ISO standard. Development in XUL has been rather slow so far, but hopefully it will pick up in the n+2 years before Longhorn ships. I've seen some XAML code, and it's got the expected ass-backwards MS feel.

I agree about SVG (it would be huge right now if MS hadn't yanked it out of IE6 at the last minute), and that rowser support for XSL/namespaces/etc is rather poor right now. The rest of this paragraph belongs to the domain of plugins and or bloatware.

Standards are great. I'm not saying get rid of the html 4.0 standard. I'm saying we need to create a 5.0, 6.0, etc that are much better. Standing still will cost you a lot.

Sorry, but there won't be any more versions of HTML... the W3C replaced HTML 4 in January 2000. Seems you've been standing still for 5 years.

If you want "more powerful html standards", take a look at DOM, XPATH, and XForms2.

<clue-by-4 action="hit">
The web was not designed to drive upgrade cycles and corporate profits, it was designed to freely exchange information. If Tim Berner-Lee was a greedy bastard and wanted to get rich off of the WWW, he would have patented it and held out his hand for royalty payments.
</clue-by-4>

To handle transformations (as a separate issue from styling) the new XQuery language has some advantages over XSLT. The syntax is a lot more readable and more concise, and it's actually a reasonable programming language. It's a superset of XPath, which may people (including XSLT users) are familiar with. On the other hand, it doesn't have XSLT's "template processing" model, which simplifies writing transformations, and it's not a finished standard yet (though it's close). My article discusses and illustrates using XQuery to transform XML for presentations. It's about generating web pages, while the parent is about generating PDF, but it does suggest it might be worth trying XQuery for generating XSL-FO (or even XHTML+CSS).

CSS is incredibly well documented, both officially and by its users.

Dealing with browser quirks takes nothing more than time and a little pit of patience. You have to set your goals of which browsers with which features, plan for graceful fallback, and test test test. Just like any trade with numerous and subtle exceptions, if you do it long enough it all becomes second nature and you find yourself writing CSS that not only validates, but looks right on every browser you desire.

CSS would be nowhere today if it had been an XML-based language. The spec is pretty well written and (numerous gotchas excepted) pretty well supprted, even by Microsoft.

CSS is incredibly well documented, both officially and by its users.

Dealing with browser quirks takes nothing more than time and a little pit of patience. You have to set your goals of which browsers with which features, plan for graceful fallback, and test test test. Just like any trade with numerous and subtle exceptions, if you do it long enough it all becomes second nature and you find yourself writing CSS that not only validates, but looks right on every browser you desire.

CSS would be nowhere today if it had been an XML-based language. The spec is pretty well written and (numerous gotchas excepted) pretty well supprted, even by Microsoft.

It's enough to create TOC, list of figuires, footnotes, what have you. Enjoy: CSS3.

I think parent was not talking about frontpage, but making a joke about how Internet Explorer is not Standards Complient.

a[href$=".pdf"]:after { content: " [PDF]" }

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

I think this last paragraph is important. "nofollow" is not on the official list of link-types. If blog authors wish to use this attribute in anchor elements, they need to define it properly (or at least properly reference a definition).

Remember back in the 90's when Netscape and MS were breaking standards right and left so that their browsers would have an edge on the competition? That was the wrong way to do it, and it created the mess we're in now with sloppy HTML spewed all over the web and designers unable to use compliant designs because the most popular browser doesn't even try to support standards (an example here). Google is doing this the right way. They went back and read the HTML specification to see if it was already capable of doing what they needed. It does? Great! Let's utilize the standard!

Granted, HTML these days has a much better design than it did in the pre-4.0 specifications. Back when Netscape and MS were at each other's throats the document format was actually incapable of doing a lot of things that designers wanted to do on the web. But HTML is a very mature format these days.

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

I think this last paragraph is important. "nofollow" is not on the official list of link-types. If blog authors wish to use this attribute in anchor elements, they need to define it properly (or at least properly reference a definition).

Remember back in the 90's when Netscape and MS were breaking standards right and left so that their browsers would have an edge on the competition? That was the wrong way to do it, and it created the mess we're in now with sloppy HTML spewed all over the web and designers unable to use compliant designs because the most popular browser doesn't even try to support standards (an example here). Google is doing this the right way. They went back and read the HTML specification to see if it was already capable of doing what they needed. It does? Great! Let's utilize the standard!

Granted, HTML these days has a much better design than it did in the pre-4.0 specifications. Back when Netscape and MS were at each other's throats the document format was actually incapable of doing a lot of things that designers wanted to do on the web. But HTML is a very mature format these days.

Yes and yes.

rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

Authors may use the following recognized link types, listed here with their conventional interpretations. In the DTD, %LinkTypes refers to a space-separated list of link types. White space characters are not permitted within link types.

These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate".

User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.

...

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

Yes and yes.

rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

Authors may use the following recognized link types, listed here with their conventional interpretations. In the DTD, %LinkTypes refers to a space-separated list of link types. White space characters are not permitted within link types.

These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate".

User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.

...

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

The list of valid link types does not include "Nofollow", but "Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types."