Slashdot Mirror

and you're too cowardly to even allow the validator access
Sincerely,
phroggy.com webmaster

you are a failure of a webmaster

Sincerely,
Slashdot Eds

I agree about the originality of Apache and snort (sodi-mumbo-jumbo-podi I am not familiar with).

Oo - perhaps if it was different people would complain. But also:
a) if it was different and better, people wouldn't complain (I never hear people complain about Apache, although it's different from IIS, or Firefox)

b) if it is indeed the same, then it's a clone (and bad at that, since it's not better)

Most OSS aren't clones (on the other hand, one possible reason is that Microsoft and Apple were never that focused on office or creative desktop software), but many apps are clones, and bad clones at that.

It's same like with commercial software - some of it is good, some of it is shite.

The DOM is a _STANDARD_. When someone "forks" the DOM, it's _NOT_ the DOM anymore. It's proprietary extensions.

So if people have a reference of the DOM handy, things should be no problem. Just emulate (or elliminate) the features that aren't cross-browser, and you're done.

I've learned most of the javascript tricks by reading the DOM levels (NOT versions) 1,2,3 specifications, the DOM events, the DOM stylesheets specs, etc etc. As a web developer, I keep the DOM Specs in my harddrive as a fulltime reference. And of course there are some non-DOM extensions that are really useful, like the world-famous offsetWidth and such. But the rest is DOM.

My javascript automatic validation routines use DOM in a _HEAVY_ way (assigning events, altering nodes, reading nodes' attributes and so on). But I only call ONE function to enable validation on my forms, and voila! And yes, they work on both Moz and IE.

There are only TWO THINGS i haven't been able to do with Mozilla that work on IE.

a) overflow-x (or y), (and that's CSS, not DOM)
and b) Microsoft extensions to the XSLT spec. (Like the eval xslt function).

But I could redesign the page, and use Mozilla's Transformiix implementation of XSLT.
There ya go. All thru the standards.

By the way, if the guys making the original Mosaic had listened to the standards before launching it, we would have CSS1 fully working, 10 years ago. The FONT tag wouldn't have even existed.

But bad web designers don't download the Official DOM Specs. (Just press CTRL-F, search "DOM" 2 or 3 times, and you're done). Instead, they just buy (or download) cheap javascript tutorials or some Microsoft-only ASP for "real dummies" book.

So, whenever someone uses "document.all" instead of using the DOM Standard getElementById, he shouldn't complain that he's using ASP, or that the DOM implementations differ. He's just being lazy (and probably a n00b). Period.

Such features you advise against using were added to HTML/XHTML for a good reason - they allow better (more efficient) learning and task completion through greater human computer interaction

Except when implemented by bozos who don't understand how people use computers. Which I think is Jacob's point rather than the inherent evil of any particular technology.

Fair comment, however looking at his heuristics for the web - he has been against valid technology without any reason (or any reason that still holds true today - hence my ramble about slow connections/computers). The people who do have a clue about usability shouldn't need to listen to Nielson - ever. Yes, the bozos should. But for the rest of us with half an idea, usability decisions come down to common sense. These may or may not conflict with Nielson's ideas.

If we limit our UI designs based upon the guidance of one man, it's unwise. Just like it's unwise to put much faith in just one company (M$ for example).

What usability guidelines do you adhere to?

Web Content Accessibility Guidelines in 100% valid W3C XHTML and CSS :-)

--BladeMelbourne

Such features you advise against using were added to HTML/XHTML for a good reason - they allow better (more efficient) learning and task completion through greater human computer interaction

Except when implemented by bozos who don't understand how people use computers. Which I think is Jacob's point rather than the inherent evil of any particular technology.

Fair comment, however looking at his heuristics for the web - he has been against valid technology without any reason (or any reason that still holds true today - hence my ramble about slow connections/computers). The people who do have a clue about usability shouldn't need to listen to Nielson - ever. Yes, the bozos should. But for the rest of us with half an idea, usability decisions come down to common sense. These may or may not conflict with Nielson's ideas.

If we limit our UI designs based upon the guidance of one man, it's unwise. Just like it's unwise to put much faith in just one company (M$ for example).

What usability guidelines do you adhere to?

Web Content Accessibility Guidelines in 100% valid W3C XHTML and CSS :-)

--BladeMelbourne

XML has its problems, the main one being the characterset representation which makes it so verbose. There is a variant called WBXML, which was designed for WAP based mobile phones (i.e., limited bandwidth). With this form you can considerably reduce the size of the XML and also ease the parsing process.

http://www-gap.dcs.st-and.ac.uk/~history/HistTopic s/Zero.html

http://www.w3.org/TR/html4/struct/links.html#h-12. 2

CSS columns will be great for documents printed from html source, but I dread seeing webpages formatted for the screen using columns (all of which are about 100 pixels taller than the browser window, of course).

If you want to know more, you might read
draft of css standard for multicolumn layout
Mozilla bug for this enhancement

1. It's got an XML declaration and an XHTML doctype, but it's served as text/html
2. It most assuredly does not validate as XHTML, containing more errors than content!
3. It has two <head> elements , one embedded in the body.

invalid html

a browser shouldn't be subjected to such torture. Not Firefox's problem.

I hate sites that don't conform to html standards.

FOAF Whitelists

Been there, seen this.

A URL is a type of URI as defined by the W3C. URLs specifically reference an object via a means of accessing it. URNs are the other half of the namespace where you specify a sort of unique name for an object, regardless of how you might go about getting access to it.

This distinction is fuzzy though (for example, no one really knows why mailto: is considered a URL scheme other than the fact that the RFCs call it that), and the important thing to remember is that if you're speaking generically of anything that starts with a " protocol:", you say "URI", and if you're speaking of something more specific that really is a URL, like an http link, then you call it a "URL". When you want to sound nerdy you say "URN" ;-)

As for "internet" vs "Internet", somebody should ask its inventor, Al Gore.

That's not all. Other J2SE apps that I personally use are...

• IsaViz is great for visualizing and validating RDF
• ArgoUML is a pretty decent UML editor
• FreeMind is a great Mind Mapping tool.
• Gantt Project beats MS-Project if all you need is Gantt charts.
• Protege is very impressive for editing OWL files.

OUCH!

PNG is lossless.

Actually many of the GIFs were actually replaced with PNGs

GIFs and PNGs support transparency (something JPEGs can't do)

In any case many of had followed history and not only changed our GIFs, but also our JPEGs to PNG. PNG is a powerful open standard for image compression that is supported by our internet overlords.

Since we like to talk about standards compliance here, shouldn't we be following all the standards?

Using the World Wide Web Consortium's (W3C) name to generate traffic?
Official sites:
http://w3c.org
http://w3.org

Copies:
http://www.w3c.com/ (WWW Communications Ltd: a revolution in internet access to Delhi)
http://wc3.org (airCloud Communications
http://www.wc3.org/home/ (Walnet Creek Church of Christ

Actually the ancestor (can't be bothered to count) was talking about the future spec (actually 1.1 not 2.0 at the moment), where the requirements doc (http://www.w3.org/TR/2004/NOTE-xforms-11-req-2004 0611/) says:

1. Client/Server Interaction

1.1 SOAP Integration

Requirement: Support SOAP as a new method of submission.

I, for one, am in favour, since adding a presentation layer to SOAP-based web services is currently a real pain.

As on your point that XForms will replace Java Applets in the near future, I'm not so sure about this. Applets are (next to Flash and the like) a way of putting some brain at the client side. It is commonly used to set up communication between the client and a server that is not a simple GET or POST request. (I fear a bit that Flash is pushing Java Applets aside.)

While I was being a bit reactionary (to the anti-Microsoft message in the article) and don't think all of the roles of Java Applets would be subsumed either (JGraph being a good example in that case), I am serious that XForms intend to do a serious amount of the stuff that we're both talking about.

Check out Section I of the 1.1 Requirements (http://www.w3.org/TR/2004/NOTE-xforms-11-req-2004 0611/) and the associated discussions...

Do you know the relevant history behind the development of the WWW? Do you know why web browsers show a little hand with a finger pointing out when you hover over a link even today? It's because of the software the web was modelled after. Hugely influential and revolutionary software by Bill Atkison. Software for creating little 'page' (card) based 'applications'. That was where the initial inspiration came from.

I never used Hypercard, but I don't doubt it was influential. However, according to the original proposal for the WWW, TBL was more inspired by his earlier work with Enquire in 1980. This was seven years prior to the first release of Hypercard and the hypertalk programming language. I think that JavaScript and the DOM event model have more in common with hypertalk than the original vision for the WWW. And what about the contributions of Ted Nelson and Doug Engelbart. Surely they were more influential!

...and they missed the boat on having a half decent scripting language so Netscape assumed dominance with the god awful JavaScript to fill a niche...

Well, I really disagree! JavaScript is a wonderful programming language. Little things like dynamic typing, Self-like prototypes, and object/dictionary equivalence makes it easy to do really powerful things. I find it a real pleasure to work with.

The WWW is not about simply 'sharing documents' (do not listen to your inner hobgoblin who tells you otherwise), it's about sharing information - the exchange of information - and that's a two way process, and for that, you need an interface that facilitates that.

You're describing the Internet as a whole. The WWW is mainly about document-like information; that's what most of it is! Web apps are a relatively small part. (Note that there are hybrids, like /. and similar forums.)

As the bunny icon used to say "Subvert the dominant paradigm!"

Isn't that how the W3C works? Companies submit their "paradigm" to the consortium. The W3C works on a compromise. Companies implement the compromise along with their "paradigm". And due to a recent (long overdue) change in their policy: when there are at least two implementations, the compromised paradigm becomes a ratified specification. I still don'w understand: what's your beef?

No, use CSS whenever you need (or want) to say how something's displayed. Use Javascript whenever you need (or want) a page to be dynamic (but don't use it for things that you can accomplish with CSS/HTML!). And yes, as you say, HTML 4 still works. Just make sure your html is semantic.

True, but I was pointing out alternatives. Perhaps I wasn't clear.

It was originally designed that way, but now it is quite useful for documents, small programs (like rot13ing text, or something on a similar scale) and web applications (where a user interacts with a program that is actually on the server by means of a web browser and an html interface)

I've always considered web apps to be a big hack. Hence XAML, XUL, and other program-oriented GUI languages. I'm not saying that they aren't useful; I use them every day! I just think that they aren't ideal. Of couse, some things could be done any other way. However, the trade-off are still kinda annoying.

P.S. Not to be pedantic, but I will. :-) Did you know that the blockquote tag requires a block-level element inside of it? Simple text content does not conform with XHTML doctype or the HTML 4 doctype.

"You should be able to align anything by top left, top right, bottom left and bottom right of an object (such as a div) both as an absolute and a percentage."

Your example here isn't too clear; you don't specify if you want the element you are aligning to be inside or outside of the other element, but both are easily possible with margins and/or relative positioning.

"You should also be able to specify on what layer within that said container the object you are positioning should be drawn."
The property is called z-index.

And all these techniques work in Mozilla, Konqueror, Safari, and IE 6. I use them all the time.

It seems to me that the main problem with modern (semantic HTML/XHTML & CSS) web design is that people bash it without knowing what they're talking about.

Warning: also a long rant.

Certainly, in 1995 it was a lot easier to learn how create a web page. You can still use the same HTML of course, but few places teach that - they all want to try and teach new users about CSS, XHTML, DHTML, JavaScript and other buzzwords which only serve to overwhelm people.

Um, the only thing that seems correct is that it used to be a lot easier to become a professional web page author (IMHO). In my experience, most (educational) places want to teach 1995 era web development ... things like massively nested frames, tables, and photoshopped images. Design is an afterthought.

Furthermore, those "buzzwords" aren't really that hard learn at all! XHTML is just a simpler HTML; CSS makes design so much easier; and a little JavaScript is easy as pie (a lot - like any programming language - takes skill). DHTML usually represents methods using JavaScript to change the existing CSS and markup; easy for little cutting-and-pasting. It just seems complicated many developers feel the need to use everything including the kitchen sink. Don't use CSS if you can use templates with PHP or ASP. Don't use JavaScript unless you really need it. HTML 4 still works. Moderation! Moderation! Moderation!

The hard parts about web development are design and consistency. Web browsers in 1995 were not more compliant than now; however, designs were so much simpler that it didn't matter. As I said before, developers nowadays want everything including the kitchen sink. Complex designs take more skill to develop and more testing to work around browser differences. Good design makes it easier to learn to code web sites, but learning to design well is really hard.

A very easy to use but powerful scripting language (something not unlike HyperTalk itself springs to mind), the ability to easily use other native interface widgets - like tabs and menus -, as well as some basic drawing tools (line, rectangle, circle and a basic fill tool spring to mind) together with an easy publishing system should have been the goals for HTML & HTTP IMO.

You're describing the design goals for Java or the X Window System. However, that's not for what hypertext was meant. The World Wide Web is about transferring documents - not programs. Writing documents with (X)HTML, and CSS is easy. On the other hand, writing complex programs with markup and scrips is hard.

IMO we should have a system where - say you are browsing your web site and you spot a spelling mistake on it at http://www.i-like-kibble.org/about.html you should just be able to click an edit button in your browser, be asked to supply a username and password and then have it open webdav://www.i-like-kibble.org/about.html either in a built in editor or it should ask you to select an editor (such as notepad, gedit or even MS Word). When the page is 'saved' in the editor, the changes should be uploaded to the site automatically by the browser. If they had been even remotely competant and argued for this from day one (and hacked up a couple of functional implimentations) we could all have that functionality today.

TBL did have that functionality in mind while writing the original web browser: WorldWideWeb. The W3C's proof-of-concept web browser was designed with exactly that feature built-in. WikiWikiWeb is the popular server version of your vision. The W3C's founders envisioned your suggestion; however, most users simply didn't need or want that functionality. That's one reason why Mosaic and Netscape Navigator were successful despite not having automatic editing capabilities.

And what really annoys me? CSS wasn't even that well designed. It's got huge gaping holes in functionality. You sh

Warning: also a long rant.

Certainly, in 1995 it was a lot easier to learn how create a web page. You can still use the same HTML of course, but few places teach that - they all want to try and teach new users about CSS, XHTML, DHTML, JavaScript and other buzzwords which only serve to overwhelm people.

Um, the only thing that seems correct is that it used to be a lot easier to become a professional web page author (IMHO). In my experience, most (educational) places want to teach 1995 era web development ... things like massively nested frames, tables, and photoshopped images. Design is an afterthought.

Furthermore, those "buzzwords" aren't really that hard learn at all! XHTML is just a simpler HTML; CSS makes design so much easier; and a little JavaScript is easy as pie (a lot - like any programming language - takes skill). DHTML usually represents methods using JavaScript to change the existing CSS and markup; easy for little cutting-and-pasting. It just seems complicated many developers feel the need to use everything including the kitchen sink. Don't use CSS if you can use templates with PHP or ASP. Don't use JavaScript unless you really need it. HTML 4 still works. Moderation! Moderation! Moderation!

The hard parts about web development are design and consistency. Web browsers in 1995 were not more compliant than now; however, designs were so much simpler that it didn't matter. As I said before, developers nowadays want everything including the kitchen sink. Complex designs take more skill to develop and more testing to work around browser differences. Good design makes it easier to learn to code web sites, but learning to design well is really hard.

A very easy to use but powerful scripting language (something not unlike HyperTalk itself springs to mind), the ability to easily use other native interface widgets - like tabs and menus -, as well as some basic drawing tools (line, rectangle, circle and a basic fill tool spring to mind) together with an easy publishing system should have been the goals for HTML & HTTP IMO.

You're describing the design goals for Java or the X Window System. However, that's not for what hypertext was meant. The World Wide Web is about transferring documents - not programs. Writing documents with (X)HTML, and CSS is easy. On the other hand, writing complex programs with markup and scrips is hard.

IMO we should have a system where - say you are browsing your web site and you spot a spelling mistake on it at http://www.i-like-kibble.org/about.html you should just be able to click an edit button in your browser, be asked to supply a username and password and then have it open webdav://www.i-like-kibble.org/about.html either in a built in editor or it should ask you to select an editor (such as notepad, gedit or even MS Word). When the page is 'saved' in the editor, the changes should be uploaded to the site automatically by the browser. If they had been even remotely competant and argued for this from day one (and hacked up a couple of functional implimentations) we could all have that functionality today.

TBL did have that functionality in mind while writing the original web browser: WorldWideWeb. The W3C's proof-of-concept web browser was designed with exactly that feature built-in. WikiWikiWeb is the popular server version of your vision. The W3C's founders envisioned your suggestion; however, most users simply didn't need or want that functionality. That's one reason why Mosaic and Netscape Navigator were successful despite not having automatic editing capabilities.

And what really annoys me? CSS wasn't even that well designed. It's got huge gaping holes in functionality. You sh

And notice that he doesn't say to not use XHTML in that document, he does say that, in his opinion a) it's not worth the trouble at the moment because of the bad support for it in browsers b) don't do it unless you're going to do it correctly (and it's not as easy as many people think it is).

But how do we ever expect to get the browser makers on board if we don't use it? I'm currently using apache's content negotiation to serve out strict XHTML1 as text/html (for IE) or application/xhtml+xml (for non-IE) as described here, and it works nicely on both gecko based browsers as well as IE6.

A deprecated element or attribute is one that has been outdated by newer constructs. Deprecated elements are defined in the reference manual in appropriate locations, but are clearly marked as deprecated. Deprecated elements may become obsolete in future versions of HTML.

User agents should continue to support deprecated elements for reasons of backward compatibility.

Definitions of elements and attributes clearly indicate which are deprecated.

This specification includes examples that illustrate how to avoid using deprecated elements. In most cases these depend on user agent support for style sheets. In general, authors should use style sheets to achieve stylistic and formatting effects rather than HTML presentational attributes. HTML presentational attributes have been deprecated when style sheet alternatives exist (see, for example, [CSS1]).

It's been quite a while since I made my site LinuxReviews IPv6 Ready. This has made me look at the IPv6-ready Web Server list from time to time and sadly there is very few sites out there that are IPv6 capable.

It is nice to know Tor supports standard protocols like http://. But do you really believe those "Tor Ready!" websites will start popping up any time soon? I don't think so. The majority of todays websites do not validate, doesn't support IPv6 and many don't even render correctly in the majority of web browsers. Will Tor-Ready be prioritized higher by the average webmaster than these and other more serious issues?

I am also very skeptical to the bandwidth requirements and the latency. My Ipv6 connection gives me full bandwidth, but I do notice that connections going through the tunnel are, in fact, much more latent than normal native Ipv4 connections. So why would I prefer to visit some website using Tor when the real difference is a longer loading period? Yes, what the author says about low latency may be true. It may have less latency than alternatives, but do not try to tell me I won't notice significantly higher latency if I try to IRC through a TOR connection.

People are talking about Ipv6 becoming standard in 5-6 years, I will be amazed if tor still exists at that point in time and even more amazed if it's actually implemented on more than 0.0001% of the Internet's services.

No it doesn't have any problems displaying open/close form tags. If IE is not displaying the extra new lines then it's actually doing it wrong. Form tags, as specified in the w3 standard are block-level elements.

Block-level elements are those elements of the document language that, by default, are formatted visually as blocks (e.g., paragraphs). Inline elements are those elements of the document language that do not cause paragraph breaks (e.g., pieces of text, inline images, etc.).

That is why you get the extra space around the element. This is the intended behavior of form elements. If you want to get rid of the space, as mentioned, use a style sheet of margin:0; or display: inline;

No it doesn't have any problems displaying open/close form tags. If IE is not displaying the extra new lines then it's actually doing it wrong. Form tags, as specified in the w3 standard are block-level elements.

Block-level elements are those elements of the document language that, by default, are formatted visually as blocks (e.g., paragraphs). Inline elements are those elements of the document language that do not cause paragraph breaks (e.g., pieces of text, inline images, etc.).

That is why you get the extra space around the element. This is the intended behavior of form elements. If you want to get rid of the space, as mentioned, use a style sheet of margin:0; or display: inline;

No it doesn't have any problems displaying open/close form tags. If IE is not displaying the extra new lines then it's actually doing it wrong. Form tags, as specified in the w3 standard are block-level elements.

Block-level elements are those elements of the document language that, by default, are formatted visually as blocks (e.g., paragraphs). Inline elements are those elements of the document language that do not cause paragraph breaks (e.g., pieces of text, inline images, etc.).

That is why you get the extra space around the element. This is the intended behavior of form elements. If you want to get rid of the space, as mentioned, use a style sheet of margin:0; or display: inline;

Looks like these guys need to go back to school themselves so they can figure out how to write proper HTML.

FYI, Bibster uses Semantic Web technology and standards, actually. Data is stored in RDF, and peers retrieve data using the SeRQL
RDF query language.

They need more HTTPanties

Such as "403 : Forbidden" or "400 : Bad Request", although I'm curious as to what would happen with "405 : Method Not Allowed", "411 : Length Required" and "305 : Use Proxy"

HTTP/1.1 : Status Code Definitions

Within ten years the DNS will have migrated to an XML format.

I've heard some RETARDED statements on /. before, but this near takes the cake. DNS using XML?

Whatever you are smoking, I want some - 'cause it's clearly some REALLY GOOD SHIAT!

Given that:

1) DNS is a protocol, not a data format, and

2) XML is a data format, not a protocol, and

3) DNS is incredibly light and efficient, and

4) DNS has already proven that it scales well to just about any size, and

5) XML offers no particular advantage, since you could serve DVD ISOs over the DNS, and

6) moving to an "XML PROTOCOL" format would require the update of every single DNS server on the face of the earth, many of which are still running Bind 8.x, and some are still running BIND 4.X for god's sake,

I consider this to be HIGHLY UNLIKELY(tm) !!!!!

I recently started playing around with Jena, a Java API for writing Semantic Web applications. W3C's Resource Desciption Framework (RDF) page has RDF specs, a means for storing semantic information.

Incidentally, Paul Ford is a regular writer on these sorts of topics. He has a collection of writings on the web and semantics.

Tim

I was actually a bit disappointed by the article. First of all: it is very hard to search in distributed knowledge networks, if not impossible. Some structures, which are a necessity to make explainable in an onthology are possible to describe, but not possible to make deductions on (some of the queries cannot be proved to finish at all). An example are meta-classes (a Chardonai wine can be an instance of the class Wines, in which case a specific bottle of wine can be an instance of Chardonai as well as a normal wine).

Second of all, the article fails to mention anything about the Ontology Web Language (OWL, see this site on W3), which has become an official specificion of W3C since May this year. This language, based on RDF is much more expressive than RDF is, it also contains several 'language levels' based on the amount of complexity and decidability involved.

Last, but not least: the article is still very vague on privacy and thrustworthyness. I would think that public-private key cryptography would not do in these areas: far too many single points of failures when, for example registering. Only one user with a hacked account can derail the whole system!

I'm really interested, by the way, to speak with some people who are deep (at least above their knees) in OWL and RDF. Planning on making a study at intelligent databases and datamining.

While well written, the author of the linked page completely failed to mention the /real/ date standard, ISO 8601. It is the most logical (descending order) and least confusing.

Just wanted to point out that the w3C recently published their intention to have a finger in this pie. With this, they hope to be able to support graphic formats that are representable in XML - notably SVG.

> That hasn't been a correct HTTP request since HTTP 0.9.

Which all newer HTTP specifications require backwards compatibility with.

That's definitely untrue. The spec writers deliberately state that they won't address backwards compatibility.

> Try actually reading the protocol specification. It uses HTTP.

Try actually using the servents. The document does not reflect how the GnutellaNet operates.

Okay, I just fired up gtk-gnutella, opened a connection and issued an HTTP request by hand. It responded with a correct HTTP response conforming to RFC 2616. The software and the specifications appear to agree with me, not you.

Which browser have you used that provides separate buttons specially for use of this tag, be it in a separate toolbar or what? I don't see any such controls in Firefox, Konqueror, or Mozilla, which is all that I have installed on my system.

It's an element type, not a tag. Mozilla calls it the "site navigation toolbar", and you can switch it on in the View menu. I think Firefox only supports it when you install the extension. Opera calls it the "navigation bar" and you can also switch it on in the View menu. I don't think Konqueror supports it.

But you stated "this is currently provided in browsers by overloading existing controls" - which browsers do this?

The issues you state are privacy issues, and deliberately chosen.

Oh, I know that. But they are solved in a very simplistic manner that causes lots of problems and isn't very robust. For instance, you state that one domain can't retrieve cookies that another domain set for privacy reasons. Of course, I understand that. But why can't a website supply a list of domains that are permitted to do so? The current types of workarounds employed by the likes of Passport are numerous, very fragile, and should not be necessary.

The other issue, that cookies may not be available, falls into the same category. I used to deny cookies and whitelist particular sites, because I did not like the privacy implications (a webmaster has no need to see me as anything other than a series of requests -- he can tack a CGI argument representing my ID onto the end of an URL, if he feels it necessary to maintain server-side state, like a shopping cart).

This kind of hack is exactly why current cookies are a problem.

For instance, what happens when you click a link that takes you to an external website? That ID shows up in their logs. You want to restrict it to a certain IP address? Sorry, clients and IPs don't have a one-to-one relationship, that doesn't work.

I'm not saying you should give up your privacy, just that if they are disabled, there should be a real way of finding that out, instead of the *nasty* kludges currently in use.

Furthermore, what difference does it make to you whether your session is being tracked by in-URL ID or in-cookie ID? Your session is still being tracked, either way.

No, /. certainily doesn't, if you don't believe me look here:
http://validator.w3.org/check?uri=http%3A%2F%2Fsla shdot.org%2F

This site is really good for learning tricks. HTML Help also has some good stuff. W3C is useful if you're stuck on something, but it's awful technical.

There are some good message boards where you can ask for help too.

In CSS1 it does not have this limitation.

Yes it does.

Applies to: block-level and replaced elements

All the text renders a bit off in FireFox...Wow, I never would have thought Microsoft would stoop so low to make other browsers view their page incorrectly! Not...


And guess what, it's not even properly coded!
Take a look!

Don't validate as HTML 4.01 Transitional in many cases
Doing a quick check I cant find even one of your many cases ...
Aren't accessible to blind or colorblind readers
Why not? The page renders very well even in lynx ...
Are changing font sizes with hard-size values, making the page unreadible for sight-disabled visitors
Where?
False elitism. [...] Please, to all the Gentoo folks still learning HTML in their second-level grade school class, learn to do things right.
You are getting a bit into flame-mode here, arent you? BTW its been taken care of.
These pages aren't generated by an XSLT transformation from XML to HTML (and if they were, they certainly wouldn't be using a .xml handler in the doctype or URI handling).
And gentoo uses GuideXML for most of its Docs ... and even with the glitches described by you thats still far better than for example /. ...

400 Bad Request

Bad Request. Bad! Go sit in the corner. Go on. Corner! Sit!

("400" errors are invalid request errors. See RFC2616)br>
409 Conflicting Request

An attack is a form of conflict...

412 Precondition Failed

There are conditions of use for Google. One says something to the effect of:

"You can't use automated request things which make an excessive number of requests."

A precondition of using this service is YOU ARE NOT A WORM.

There could, however, be a new one... br>
411 Problem exists between keyboard and chair

Catch all for human caused errors.

Ok... so it's not exactly accurate use for these codes, but close enough?

They could assign a new error code, but according to the HTTP RFC, server errors are always the 5xx branch.

So maybe 569?