Slashdot Mirror

Makes perfect sense. Sounds alot like PICS actually. I actually rate with SafeSurf.

The problem I see with doing rating this way in meatspace is this: how does the movie theater (or whoever) know what rating level the kid may see? With a web browser surfing cyberspace, the parent sets the levels that may be viewed, and it's automatically regulated. How do you do that IRL? Tattoo the kid's forehead "cannot view sexual content more explicit than innuendo"?

In the ideal world, the parent would accompany the kid to the movies. In the real world, the kid is going to have lots of time not under the direct supervision of the parents. That's the whole reason for ratings in the first place. You can't always monitor what your kids surf. You can't always take off from work when the kids go to the movies after school.

This, I'm pretty sure, is the rationale for the current age-based rating scheme. Parents feelings for what a kid of a certain age may see follows a standard distribution. Stuff that most parents feel a sub-13-yo should not view gets rated PG-13. Etc. It's easy to check someone's age. And if I feel my 10-yo is as mature as a typical 13-yo, I'll OK him to see a PG-13 flick.

Personally, I think we should come up with a GeekCode-like PICS rating system for the web. How nerdy is your site? Do you provide Unix man pages or sendmail docs online? Are you Rob Malda or Illiad? High score for you! I actually have seen a PICS scheme for something other than "nastiness" - VWP rated "Canadianness" I think.

When it comes to bargaining, whoever says a number first loses.

In retail, you always lose. (have you ever been haggled UP in price at walmart?)

Many companies that are Quasi-retail (like these guys) try to hold the price close, so they can make as much as they can.

This is not surprising, really. With this type of product you can't pop into "the other guy's" store to see what he charges, so you have to be careful trying to sense what the market will bear.

I am sure that they feel that the business that they lose (yours) is outweighed by what they would lose (in prices and business) if they did "up front pricing." (with apologies to GM Service Plus.)

-Peter



Slashdot cries out for open standards, then breaks them.

Office2K will already save docs in a kind of bastardized HTML++ format which truly sucks because it is neither rules-following HTML nor well-formed XML

You can use HTML Tidy to correct the HTML output by Word.

That is very interesting. At first glance I tended to agree.

First, I think that it is obvious that I was using a touch of hyperbole.

For the third time (just for clarity) I wouldn't change the "content" just the medium.

I don't think that a large print COPY of the Bible is blasphemous.

Or even an English version ;-)

I don't even think that there is anything wrong with someone making a change, or even making a change and redistributing (with the kind permission of the author.) As long as they don't try to pass it off as the real thing.

Say some slashdot troll gets his kicks from putting a copy of the Guide on his site, but replaces references to tea with hot grits (again, with the authors permission to modify and redistribute) I don't see any harm.

This seems equivalent to having wallpaper of the Mona Lisa with a shirt that says "Shit Happens" courtesy of the GIMP.

To put it another way. If I scanned in my copy of Mostly Harmless and converted it, say, to PDF would a copy of that file be more valuable than mona_s_happens.bmp?

Again, we have crossed the divide between atoms and bits. The Mona Lisa is valuable because it is "the one true" Mona Lisa (in atom form)

Adams himself converted the Guide to digital form and resold it (for an early "digital book") Did some "creative control" he exerted maintain its "value" (your word) or is it just as good in pixels as it is in ink?



Slashdot cries out for open standards, then breaks them.

Well, my friend, you could not be more wrong. On every count no less!

1. I am neither clueless, nor a zealot. I offer no evidence, but neither did you.

2. I happen to own at least one copy of each of Mr. Adams works, with the exception of that hippy book, "The Meaning of Lif," and the Infocom Hitchhikers game (which I wish I had.) (yes, I do have Bureaucracy.) I do not begrudge Mr. Adams one cent of his royalty for any of these items.

3. I would sooner paint a mustache on the Mona Lisa, or something vulgar on the Sistine Chapel than alter one of Mr. Adams masterpieces.

Perhaps open was a poor choice of (buzz)words, what I really meant was "will you waive your copyrights on fans producing copies, translations and "ports" to other media types." But in the end these ARE changes, aren't they? So maybe open is what I meant after all.

What I would like is:

1. To be able to reformat his works to other media (as in the CD reference.)

2. and to hear his reaction (as a writer) to the question.

-Peter



Slashdot cries out for open standards, then breaks them.

XHTML is (mostly?) backwards compatible because it's basically just well-formed HTML. If you're already using CSS then writing XHTML rather than HTML won't do much to cramp your style. If you're not: you should be! Using XHTML is like tabbing your code -- there's no reason not to and it might help you later on. Download HTML tidy to help you along the way.

I must say I feel the same way about XML. I've written DTDs and linked CSSs such that it displays nicely in IE5, but I'm not sure where this is leading. What we need is a database of DTDs so that instead of writing my own I'll try and make something that is compatible with someone else's. Obviously for a major project I can consistantly use a DTD interally, but for just random web docs there should be an Open Content repository.

And yes, I know about XML.ORG's list, but they're hardly RFCs.

Yes, there could be a truly interoperable "rich text format" used by every word processor and based upon XML.

It hasn't been done for a variety of reasons:

• developing it would be a non-trivial exercise.
• most people in the "XML world" are more interested in generic markup than in WYSIWYG word processor formats. This means that the presentation is dicatated by a complex stylesheet which adds a level of complexity. This makes the problem even harder to solve (we've been working on it for more than ten years!) Some people would actively oppose a common word processing format based on the principle of direct WYSIWYG application of style.
• HTML+CSS is "good enough" for some subset of people which takes away some of the impetus.
• Microsoft would probably not go along. This means that 90% of the world's word processor users would still be left behind.
• The competing word processor vendors are so small and weak that the development would actually incur a sizeable cost.
• Word processors internally have very different ways of thinking about the organization of text and formatting. A common data format might inadvertantly lead to a common "look and feel" which would hurt vendors who charge extra for their extra features.
• The feature set of word processors is not entirely congruent so you get into a typical "Lowest Common Denominator" versus "Extensible Pseudo-Standard" situation.
• There are ostensibly already a few (failed) international standards in this area like ODA.

Of course people in the opens source software world are motivated differently than those in the software sales business so if a standard was to arise it would probably arise out of cooperation among those groups. Still, it would take a lot of hard work and cooperation.

I once proposed that the existing XSL Formatting Objects could be leveraged in this way once, but was shouted down by those who felt that any move away from generic markup is inherently a step backwards.

Am I missing something here?

In a word, yes.

Right beneath the normal save option is a nice looking "save as webpage" button. Use it...

...Won't be of much help tough because as other people have pointed out already, this feature actually produces an (MS)HTML document with XMLized OLE related info.

Note that if you have a relatively complex document, Office2K will create a directoy with the same name as the file in which it puts various other stuff.

I just went to the trouble of running a small "saved as webpage"-word2000 doc trough the W3C validation service. Result:

Sorry, this document does not validate as HTML 4.0 Transitional.

But it is quite a nifty feature if you're running an all Microsoft shop (which I have the displeasure of doing), since it allows people to post stuff on the local intranet without any additional work... I guess Microsoft is quite pleased with this feature :)

Presumably you could handle most of the document formatting via vanilla XHTML and CSS.

However, one problem is that there currently isn't a sufficient standard to support printed output, along with things like margins, page numbering, headers/footers, foot/end notes, and so on.

An alert slashdotter pointed this out to me just the other day - the proposed CSS3 Page Media Properties spec addresses most of these issues. However, it's not done yet, and has not been implemented anywhere that I know of. So, it might be a year or more before we have a truly open format that could be used for word processing programs.
--

That has been documented as a typo. I can't remember where I read that though. Maybe his biography (who's name escapes me, perhaps I left it on a bus.)

-Peter


Slashdot cries out for open standards, then breaks them.

Mr. Adams,

I know that "creating content" (buzz word alert) is your livelihood, but how would you feel about "opening" that content at some point?

Do you think, at some point, you may "retire" and make a "gift" of your work to your fans? This becomes more meaningful as books become more of a digital medium. I would love to hand a disc with all of your books on it to a friend.

What I would like to know most of all, is how do you react to this question. Does it seem like a ridiculous question? Does it immediately strike you as something you would not even consider? Is it something you had already considered?

Did you consider piracy when the digital version (I can't remember the name of that computer book doohickey that it was on.) of the Hitchhikers Guide was released? Did the manufacturer convince you that it would not be prevalent, or did you not care?

Is there anything that convinces you that you are outside outside the asylum more than Slashdot?

-Peter



Slashdot cries out for open standards, then breaks them.

Just tried them both in today's CVS snapshot - it can deal with dynamicdrive.com perfectly,

netmeister.org doesn't work (black page), but a quick check at validator. w3.org shows why...

Please try making the pages more standards-compliant.

Has anyone tested how extensive the CSS/CSS2 support in Konqueror is? All of the other main browsers (yes, even Mozilla) support CSS in a very patchy 'mine field' sort of way.

Care to share where some of the worst bombs are? :-) Seriously, I've noticed that the latest version of Explorer on the Mac and Mozilla on, well, anything, do an almost perfect job at CSS1, at least according to the w3.org test suite

I'm getting really tired of writing CSS that works in only one version of one platform. What's up with that?

That's the sound of the market not insisting on standards compliance. But note that things are really beginning to catch up now. Within a year, I susptect sites that don't effectively use CSS (including slashdot) are going to look increasingly dorky.

How hard could it possibly be to support CSS in an even way, across *all* platforms??

Really, really hard I think. Seriously, once you start getting to support CSS at the level of units in ems, exes picas, mm and pixels when your output is some random CRT, I think it would make the strong weep.

What about CSS3? Anyone heard what the browsers are doing about this?

CSS3 is, alas, way out there; there's not even a unified proposal yet

I suspect that the first universal thing we'll see out of CSS3 is the paged media stuff, which is already sort of available in Explorer.

Doing style right is hard, and I think everybody can see now that it's worth doing right. At least, I hope that's the case...

Has anyone tested how extensive the CSS/CSS2 support in Konqueror is? All of the other main browsers (yes, even Mozilla) support CSS in a very patchy 'mine field' sort of way.

Care to share where some of the worst bombs are? :-) Seriously, I've noticed that the latest version of Explorer on the Mac and Mozilla on, well, anything, do an almost perfect job at CSS1, at least according to the w3.org test suite

I'm getting really tired of writing CSS that works in only one version of one platform. What's up with that?

That's the sound of the market not insisting on standards compliance. But note that things are really beginning to catch up now. Within a year, I susptect sites that don't effectively use CSS (including slashdot) are going to look increasingly dorky.

How hard could it possibly be to support CSS in an even way, across *all* platforms??

Really, really hard I think. Seriously, once you start getting to support CSS at the level of units in ems, exes picas, mm and pixels when your output is some random CRT, I think it would make the strong weep.

What about CSS3? Anyone heard what the browsers are doing about this?

CSS3 is, alas, way out there; there's not even a unified proposal yet

I suspect that the first universal thing we'll see out of CSS3 is the paged media stuff, which is already sort of available in Explorer.

Doing style right is hard, and I think everybody can see now that it's worth doing right. At least, I hope that's the case...

Has anyone tested how extensive the CSS/CSS2 support in Konqueror is? All of the other main browsers (yes, even Mozilla) support CSS in a very patchy 'mine field' sort of way.

I'm getting really tired of writing CSS that works in only one version of one platform. What's up with that?

How hard could it possibly be to support CSS in an even way, across *all* platforms??

CSS Level 1

CSS Level 2

Two last notes:

IE5 *on the MACINTOSH* has the most extensive CSS1 coverage BEFORE IT WAS EVEN A COMPLETE RECOMMENDATION. Almost perfect (still problems with embedded fonts and some other stuff).

What about CSS3? Anyone heard what the browsers are doing about this? IE3 supported some minimal CSS1 back in the day, why aren't browsers not only keeping up, but staying ahead of the curve?

Rami James
Pixel Pusher
ALST R&D Center, IL
--

Has anyone tested how extensive the CSS/CSS2 support in Konqueror is? All of the other main browsers (yes, even Mozilla) support CSS in a very patchy 'mine field' sort of way.

I'm getting really tired of writing CSS that works in only one version of one platform. What's up with that?

How hard could it possibly be to support CSS in an even way, across *all* platforms??

CSS Level 1

CSS Level 2

Two last notes:

IE5 *on the MACINTOSH* has the most extensive CSS1 coverage BEFORE IT WAS EVEN A COMPLETE RECOMMENDATION. Almost perfect (still problems with embedded fonts and some other stuff).

What about CSS3? Anyone heard what the browsers are doing about this? IE3 supported some minimal CSS1 back in the day, why aren't browsers not only keeping up, but staying ahead of the curve?

Rami James
Pixel Pusher
ALST R&D Center, IL
--

I just did a search on my own name, and found out that I'm an aviator, author, and humorist. That page, as well as several others with additional evidence, showed up in both AltaVista and Google, so it must be true! Amnesia is the only possible explanation for my unawareness of this obvious fact.

Seriously, though, this just shows that it's fairly easy to get bogus information when trying to pull it together from several sources. Lack of privacy is bad enough, but the possibility of having one's reputation warped by a false positive identification may be even worse. Remember the Harry Buttle / Harry Tuttle mixup in "Brazil"?

BTW, I also found a bunch of old emails I'd sent to the www-style@w3.org mailing list as archived on the W3C's site.

However, if you preview, it replaces the &HTML escapes -- bug in slashdot. So after preview, instead of hitting submit, use your browsers back function, and then hit submit. This bug has been known for more than six months.

I don't know a lot about the topic, but I used to work for a radio guy (in the Army) and from what I gathered in that time, antennae work -specifically- by NOT being grounded. I imagine that this would not add, and might even reduce, EMI.

That is one hell of a sentence.


Slashdot cries out for open standards, then breaks them.

It would be interesting if it only blew up in IE.(further proof of MS not adhering to standards.)

Actually, it would be much more interesting if you went and learned XML, rather than spout off half-baked Microsoft conspiracy theories. :) I suggest the nice recommendation spec over at www.w3.org.

Your link is spitting out bad XML, most likely due to Slashdot using tools which don't grok UTF-8 encoding. If they want to use ASCII characters in the 128-255 range, like the "á" that IE's parser flags as an error, and don't have any tools which will output UTF-8 characters, then they should be using the appropriate entity in their text instead, i.e. á. Failing that, a less effective solution would be for them to specify a character encoding for their xml file, like ISO-8859-1, since their document doesn't match the default UTF-8.

Oh yeah, and if Netscape 6 allowed that xml to go through without reporting an error, then it has a broken parser.

Now see, learning isn't so hard, is it? And besides, it's so much more original around here than senseless Microsoft-bashing.

Cheers,
ZicoKnows@hotmail.com

While we're talking about HTTPD's written in various languages, the W3 Consortium has written a free (as in speech) HTTPD entirely in Java for maximal portability: Jigsaw (see also the Jigsaw test site — that is, let's see how Jigsaw reacts to being slashdotted:-).

As you can guess, Jigsaw is fully HTTP/1.1 compliant (last time I checked, Apache still had some problems with that). While it's certainly much less efficient than Apache, it's probably also more flexible, modular and reusable. Personaly I haven't given it more than a cursory glance: I wonder if some people have tried it more thoroughly and would care to review its pros and cons?

While we're talking about HTTPD's written in various languages, the W3 Consortium has written a free (as in speech) HTTPD entirely in Java for maximal portability: Jigsaw (see also the Jigsaw test site — that is, let's see how Jigsaw reacts to being slashdotted:-).

As you can guess, Jigsaw is fully HTTP/1.1 compliant (last time I checked, Apache still had some problems with that). While it's certainly much less efficient than Apache, it's probably also more flexible, modular and reusable. Personaly I haven't given it more than a cursory glance: I wonder if some people have tried it more thoroughly and would care to review its pros and cons?

While we're talking about HTTPD's written in various languages, the W3 Consortium has written a free (as in speech) HTTPD entirely in Java for maximal portability: Jigsaw (see also the Jigsaw test site — that is, let's see how Jigsaw reacts to being slashdotted:-).

As you can guess, Jigsaw is fully HTTP/1.1 compliant (last time I checked, Apache still had some problems with that). While it's certainly much less efficient than Apache, it's probably also more flexible, modular and reusable. Personaly I haven't given it more than a cursory glance: I wonder if some people have tried it more thoroughly and would care to review its pros and cons?

"Why use HTML when javascript, cascading style sheets, java, cookies, imagemaps, and shockwave will do?"

The problem isn't the new technologies, it's people who use those technologies without following the standards. If you read and follow the standards put out by the W3C, you'll find that the standards are very much geared towards the creation of webpages that are accessible to all clients, whether they be text only or graphical.

Putting something in print that was submitted anonymously is just flat out irresponsible.

You had me, right up until this statement.

In the middle of an insightful, well-reasoned post, this is just rubbish.

If you submit something to Slashdot anonymously, you're not sending it to small, secret group of people; you're sending it directly to several tens of thousands of people worldwide, and you're listing it on search engines where it'll show up to anybody typing a keyword or two.

What would be irresponsible would be backtracking the Anonymous postings to identify their poster, so he could be credited; that would completely undermine people's confidence in the anonymity of their postings, and have a chilling effect on a tool that's getting a lot of important messages moved from inside people's brains (where they often aren't accomplishing much) and out into the wide world, where they sometimes are accomplishing useful things.

Slashdot isn't a private messagebase on a BBS somewhere, it's a public forum.

It's a bit like a big reader-edited newspaper, which doesn't really have parallels in the non-virtual world because it's not feasible without Tim Berners-Lee's amazing invention.

I assure you, when we collectively interview somebody, he doesn't assume he's speaking to use in our living rooms privately; he assumes he's being published.

If you post something to Slashdot anonymously, the very act of making it anonymous removes any right you have to hope it remains unpublished, because you've made it unattributable.

How about security?

If you program in Perl, do you know what -T means?

If you program in C, have you carefully considered buffer overflows?

etc?

Regards,
Ben

According to Ian Hickson, image alt text is supposed to be displayed as normal text, with nothing distinguishing it from page text, unless the page specifies how broken images are supposed to be displayed.

Umm, I don't know who the hell Ian Hickson is, but according to the W3C IMG definition, alt text is "rendered when the image cannot be displayed." That definately doesn't sound like it should be displayed all the time, which is just silly.

. Very few webpages with broken or slashdotted images look good in mozilla as a result, and layout is completely messed up even when width= and height= are specified

This isn't because Gecko is off spec, it's because we're used to programming for browsers that don't conform to spec. Gecko passes (with flying colors) ALL of the tests the W3C setup to test browser compliance. If an HTML document is compliant, then Gecko/Mozilla will display it according to spec. If you don't believe me, then read the spec yourself.

According to Ian Hickson, image alt text is supposed to be displayed as normal text, with nothing distinguishing it from page text, unless the page specifies how broken images are supposed to be displayed.

Umm, I don't know who the hell Ian Hickson is, but according to the W3C IMG definition, alt text is "rendered when the image cannot be displayed." That definately doesn't sound like it should be displayed all the time, which is just silly.

. Very few webpages with broken or slashdotted images look good in mozilla as a result, and layout is completely messed up even when width= and height= are specified

This isn't because Gecko is off spec, it's because we're used to programming for browsers that don't conform to spec. Gecko passes (with flying colors) ALL of the tests the W3C setup to test browser compliance. If an HTML document is compliant, then Gecko/Mozilla will display it according to spec. If you don't believe me, then read the spec yourself.

The other option is to change from HTML Formatted to extrans or plain text.

(For more information about HTML entities, visit W3C and look up the HTML spec. &, <, and &>gt; are by far the most useful entities...)

stuff accesses just as easy to the web surfer, no matter where it's located.

Not 100% accurate. The user might only see com instead of co.uk (or even better to), but ping times to faraway sites are bound to be lower because, for example, light moves only 299.8 km per millisecond. Latency produces slow loading sites, which turn off users who browse linearly and don't use Open Link in New Window aggressively.

Another non-Netscape Mozilla development... this is looking into the use of W3C RDF for logic/inference applications (eg. client-side decision support tools). See the Mozilla Enabling Inference pages for details, and Geoff Chappell's Mozillation announcement on the RDF Interest Group.

DARPA's RDF-related Agent language might also be of interest to /. conspiracy theorists... ;-)

Another non-Netscape Mozilla development... this is looking into the use of W3C RDF for logic/inference applications (eg. client-side decision support tools). See the Mozilla Enabling Inference pages for details, and Geoff Chappell's Mozillation announcement on the RDF Interest Group.

DARPA's RDF-related Agent language might also be of interest to /. conspiracy theorists... ;-)

Another non-Netscape Mozilla development... this is looking into the use of W3C RDF for logic/inference applications (eg. client-side decision support tools). See the Mozilla Enabling Inference pages for details, and Geoff Chappell's Mozillation announcement on the RDF Interest Group.

DARPA's RDF-related Agent language might also be of interest to /. conspiracy theorists... ;-)

That seems similar to PICS (not that I know so much about PICS).

But you would be blocking entire sites that use dynamic links like Slashdot.
Slashdot can contain censurable comments everywhere and they can have lots of URLs, because they embed parameters into the URL.

As Tim Berners-Lee says somewhere in W3C, URLs should not be stuffed with representation stuff, that should be negotiated.
__

--

The only problem is that this stuff is pretty new and no one's written editing software to take advantage of it yet. Stay tuned to the w3.org site and I highly recommend reading Tim Berners-Lee's Weaving The Web.

The only problem is that this stuff is pretty new and no one's written editing software to take advantage of it yet. Stay tuned to the w3.org site and I highly recommend reading Tim Berners-Lee's Weaving The Web.

Colour choice: go for contrast any time. I prefer dark backgrounds with light text, too, and find (for example) standard M$loth-produced black-on-bright-white painful to think about.

Widths: no-one in their right minds browses at 800x600 "full-screen" whatever that might mean; and to press the point I *like* something that resembles an A4 page in aspect ratio, with minimum usable browser-"isms" at the top.
So any page that pushes its content off the right and gives me a horizontal scroll-bar is out of the question. (It boils down to using "width=90*" in your tables, for example. Or better yet, not using tables at all.)

Front pages: the "click here to enter this site" stuff is abhorrent. I entered the URL, so give me the content. I do not want a "web-surfing experience", surprisingly enough.

Javascript: don't bother, it's disabled. I find too many sites out there abuse it with gratuitous pop-ups and stuff (even whole new browser windows) to bother with it.

Images: ALT attribute or forget it.

Broken mime-types: do NOT do what themes.org do and make everything a CGI-link to the file with a perverse mime-type. If it's closest to "octet-stream", send it that way and I'll handle it - that's my problem. If you give me the filename I'll be able to download it in bulk mode later, or use shift+click to force a download. Honestly, people who expect left-click to do everything for them... *sigh*!

Let's remember that the Web is a document-dissemination medium and how it looks is determined by the browser, NOT the other way round. If you write valid HTML then there's no excuse for folks not to be able to read it - after all the rule for browsers is, "if you don't know the tag, ignore it and don't lose content", which allows a site designer to adopt the approach of "valid HTML+CSS" instead of "works OK on all but 20% of browsers".

Roll on the W3C and DOM, any day!
~Tim
--
.|` Clouds cross the black moonlight,

Colour choice: go for contrast any time. I prefer dark backgrounds with light text, too, and find (for example) standard M$loth-produced black-on-bright-white painful to think about.

Widths: no-one in their right minds browses at 800x600 "full-screen" whatever that might mean; and to press the point I *like* something that resembles an A4 page in aspect ratio, with minimum usable browser-"isms" at the top.
So any page that pushes its content off the right and gives me a horizontal scroll-bar is out of the question. (It boils down to using "width=90*" in your tables, for example. Or better yet, not using tables at all.)

Front pages: the "click here to enter this site" stuff is abhorrent. I entered the URL, so give me the content. I do not want a "web-surfing experience", surprisingly enough.

Javascript: don't bother, it's disabled. I find too many sites out there abuse it with gratuitous pop-ups and stuff (even whole new browser windows) to bother with it.

Images: ALT attribute or forget it.

Broken mime-types: do NOT do what themes.org do and make everything a CGI-link to the file with a perverse mime-type. If it's closest to "octet-stream", send it that way and I'll handle it - that's my problem. If you give me the filename I'll be able to download it in bulk mode later, or use shift+click to force a download. Honestly, people who expect left-click to do everything for them... *sigh*!

Let's remember that the Web is a document-dissemination medium and how it looks is determined by the browser, NOT the other way round. If you write valid HTML then there's no excuse for folks not to be able to read it - after all the rule for browsers is, "if you don't know the tag, ignore it and don't lose content", which allows a site designer to adopt the approach of "valid HTML+CSS" instead of "works OK on all but 20% of browsers".

Roll on the W3C and DOM, any day!
~Tim
--
.|` Clouds cross the black moonlight,

And btw, some of the quotes are excellent.

And btw, some of the quotes are excellent.

The current version is HTML 4.01
Or you can glance at the previous version, HTML 4.0

Not quite. The current W3C recommendation is XHTML 1.0, which is very similar.

You guessed right. See the w3c for all your HTML specification needs. Personally, it's the only place I go for answers on HTML questions. If it's not in the spec, it's not worth my time.

The current version is HTML 4.01
Or you can glance at the previous version, HTML 4.0

You guessed right. See the w3c for all your HTML specification needs. Personally, it's the only place I go for answers on HTML questions. If it's not in the spec, it's not worth my time.

The current version is HTML 4.01
Or you can glance at the previous version, HTML 4.0

Well, you have the wrong link, for starters.

Try this one (Lynda with a 'Y').

And yeah, it still doesn't validate, but the W3C Validator is strict, and pretty crappy too. And the CSS validates just fine. Pretty good, for a (probably hacked) "Adobe GoLive 4" generated page.

And remember: Valid HTML might be syntactically correct, but that doesn't make it Good.
---
pb Reply or e-mail; don't vaguely moderate.

I agree that XHTML is probably a good starting point for unified Linux documentation.

FWIW, XHTML is not the same as XML. XHTML is "a reformulation of HTMLÊ4 as an XML 1.0 application" (to quote the W3C's take on it ... and they should know. XHTML can be displayed by ordinary HTML browsers like the one you're using now, but it can also be parsed by an XML parser. It's basically a transitional form ... getting people used to writing formally correct XMLish markup while there aren't yet enough XML tools out there.

(In other words, XML is not a markup language; it is a markup metalanguage. XML applications, of which XHTML is one, are markup languages.)

XHTML, because it is HTML, is the Wrong Thing for documentation, because HTML has insufficient structure, and the wrong sorts of what it's got. DocBook may or may not be the Right Thing for manpages, but the Linux Documentation Project folks seem to get along with it for HOWTOs, and they seem to be okay at rendering it into text or HTML or various other formats. DocBook is an SGML system and not XML, but that will be changing with the next major revision, and presumably LDP will be keeping up.

I agree that XHTML is probably a good starting point for unified Linux documentation.

FWIW, XHTML is not the same as XML. XHTML is "a reformulation of HTMLÊ4 as an XML 1.0 application" (to quote the W3C's take on it ... and they should know. XHTML can be displayed by ordinary HTML browsers like the one you're using now, but it can also be parsed by an XML parser. It's basically a transitional form ... getting people used to writing formally correct XMLish markup while there aren't yet enough XML tools out there.

(In other words, XML is not a markup language; it is a markup metalanguage. XML applications, of which XHTML is one, are markup languages.)

XHTML, because it is HTML, is the Wrong Thing for documentation, because HTML has insufficient structure, and the wrong sorts of what it's got. DocBook may or may not be the Right Thing for manpages, but the Linux Documentation Project folks seem to get along with it for HOWTOs, and they seem to be okay at rendering it into text or HTML or various other formats. DocBook is an SGML system and not XML, but that will be changing with the next major revision, and presumably LDP will be keeping up.

--

but why isn't offsite cookie rejection built into all browsers?

Microsoft is blackmailing DoubleClick. :-)

There's a thread on the www-talk list about this at the moment. Though it's easy to remove cookies from <img>-derived HTTP requests, other features such as frames are not as easy. For example, a banner ad frame at the top of the page is likely, and could easily be passed URI information from the frameset. Disallowing cookies on subframes, however, would break sites running under the likes of AskJeeves, where the 'real' site is viewed as part of a frameset.

I don't know if IDcide prevents cookies being passed to sites in subframes, or just images. Probably the latter since it's the most common case at the moment. But frame, layer, object, embed and applet have the same problems.

Given that we were discussing embedded-object-cookie-rejection on www-talk as an obvious way to circumvent cookie abuse, it's somewhat worrying that IDcide Inc. might have a patent on it:

IDcide's patent-pending technology allows cookies to be blocked according to the site you're visiting, not according to where the cookies came from!

(From the FAQ.)

but why isn't offsite cookie rejection built into all browsers?

Alternative answer: because IDcide have patented it?

I can't see anything on www.patents.ibm.com yet, so it's unclear whether IDcide have indeed applied for a patent on cookie rejection, or whether it's some technical implementation detail.

Before I begin: My original post contained the word official formatted like this: `official' meaning that not everybody recognizes this as the best way things should be done. It is a `standard' (note the quotes) that is designed to unify (sp?) the way document rendering is performed. (ie, not everybody agrees with it)

There are four bugs with a summary description containing TBODY, so those bugs are known and being worked on. (Mozilla will continue to run Milestones long after NS6 is released. Don't confuse Netscape and Mozilla.)

Blink has been around so long, but I too wish it would be removed... (It can have uses though.) Some things are no longer being supported, such as the NS4.x ILAYER and LAYER stuff.

17 .7 The TEXTAREA element doesn't contain any mention of an "onscroll" event, and I haven't seen it anywhere else in the docs (Nor in DOM 1 or 2). Try talking to the W3 people, it isn't Mozilla's fault it isn't implemented.

TBODY align support isn't in the spec either: 11.2.3 Row groups: the THEAD, TFOOT, and TBODY elements Sorry, gotta talk to the W3 about this too.

The TBODY is a row grouping element, from the spec:

Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.

Of course, there is no mention of how to indicate that the tbody should be scrolled or printed on each page because you are supposed to use style sheets for that. (same with all rendering details)

Remember, Mozilla didn't write the spec, they just want to implement the spec. There are places (too many) that are ambiguous and must be interpreted according to the letter and intent of the writers.