Slashdot Mirror

All you have to do is save the /. HTML from the front page, go to the valitador, and choose the upload service.

Quick hint, more HTML errors than can be easily counted.

All you have to do is save the /. HTML from the front page, go to the valitador, and choose the upload service.

Quick hint, more HTML errors than can be easily counted.

http://validator.w3.org/check?uri=http%3A%2F%2Fgoo gle.com&charset=%28detect+automatically%29&doctype =HTML+4.01+Transitional google has the similar problems if you look at it the same way...

Even better is how Slashdot isnt allowing their bot access to do the check on slashdot.org.
HTML 4.01 Transitional

I finally found something more overwhelming than HTML 4.01 (transitional) validation of Microsoft's website.

I was refering to the scripting and/or other methods of embeding fonts. Not using CSS to tell the browser what fonts to use.

This demonstrates a fundamental misunderstanding of font embedding technologies. The WEFT and TrueDoc specifications do not require client scripting to be implemented. Embedding retrieves needed fonts via simple linking so it is in no way different in practical implementation than CSS, images or other auxiliary web data. In fact CSS2 was built with the explicit inclusion of font embedding (search the page for "download"). My personal resume is an example of a script-free web standards compliant site which implements both WEFT and TrueDoc, and is 100% disabled-accessible. I highly encourage you to read up on web font embedding, and hopefully revise some egregious misconceptions.

I don't see how you can fault IE for not having a complete P3P implementation, when P3P itself is not complete. You can fault Microsoft for insisting that IE be integrated with everything. A bad idea for a bunch of reasons, not the least of which is that it makes holes like this inevitable.

Unfortunately, Microsoft's superintegration approach is being too-thoroughly imitated by the very projects that are supposed to give us an alternative: Mozilla, KDE, and Gnome.

Gladly.

But just in case nobody gets it (and since the original post is still scored at 1, I assume that most don't), here's the W3C's SOAP Messaging Framework spec.

Maybe someone can cook up a version of lint that can be used with SOAP!

Pfft, the least secure PHP application on earth (and one of the worst written), and another app based on the least secure and worst written PHP app? No thanks :)

Personally I've found that pretty much all systems like this turn out to be messy, badly written, poorly designed, and have URI's that would make TBL gag.

Case in point: phpNuke, long, long history of major security holes, with a hugely speghettified codebase.

Scoop, with embedded Perl and HTML thrown about everywhere in the database.

Drupal, with raw HTML everywhere in the PHP.

This pattern repeats just about everywhere. The closest I've found to an open source web application which doesn't make me want to hit something is ezPublish, which at least makes an effort to have reasonable URI's, and has a decent attempt at making itself OO (although sadly at a significant cost of performance).

Developers: mod_rewrite is your friend. Go read Cool URI's Don't Change, and maybe TBL's other Hypertext Style Guide stuff, it'll be good for you even if you don't agree with all of it.

Pfft, the least secure PHP application on earth (and one of the worst written), and another app based on the least secure and worst written PHP app? No thanks :)

Personally I've found that pretty much all systems like this turn out to be messy, badly written, poorly designed, and have URI's that would make TBL gag.

Case in point: phpNuke, long, long history of major security holes, with a hugely speghettified codebase.

Scoop, with embedded Perl and HTML thrown about everywhere in the database.

Drupal, with raw HTML everywhere in the PHP.

This pattern repeats just about everywhere. The closest I've found to an open source web application which doesn't make me want to hit something is ezPublish, which at least makes an effort to have reasonable URI's, and has a decent attempt at making itself OO (although sadly at a significant cost of performance).

Developers: mod_rewrite is your friend. Go read Cool URI's Don't Change, and maybe TBL's other Hypertext Style Guide stuff, it'll be good for you even if you don't agree with all of it.

Yes, they've spent the last 18 months rewriting the engine rather than hacking DOM support into the old engine, rather like what Mozilla's spent the last 4 years or so doing for NS4.

The CSS support is largely on par with Mozilla, and in some places better (ever notice the CSS3 WD's work better in Opera?).

Clearly slashdot has dropped gif's for jpegs.

Not to be a stickler, but the freely usable (and W3C-recommended) replacement for GIF is PNG. Like GIF, PNG is non-lossy compression. JPEG is lossy.

I'll be quiet now.

But NN4.* doesn't even support CSS1

One could argue for programs in HTML, with the code bracketed in XML so that the compiler could find it.

Yes, and as i recently posted, i've found that it does in fact further program understanding to be able to embed xml tags of various types into the code and the surrounding documentation, if one can make use of it. Example benefits, achievable in code and non-code sections using the Amaya editor:

* Formatting, as you point out. XHTML, CSS works.
* Hyperlinking to other files, sections, and urls.
* SVG for drawing. (limited capability at present)
* Automatic (re)creation of hierachical table of contents based on <h> tags (Amaya shows this nicely in a separate window, and allows drill-down from it into the document). Here's your outline.

I implemented this as a tiny PHP/XSLT program.

Since the above mentioned post, in addition to getting its two qn's answered, I added code to use as the target filename the <title> element of the source document (sudo'ing to root when necessary (which it wouldn't be for Windows)).

The code sections are id'ed by being in a a named ("code") style, which simultaneously formats them.

Using Amaya's also nice because it allows editing of html content in the same window in which the html is interpreted (and without any of the flood of non-standard tags MSWord uses).

I plan on creating a Sourceforge project based on this w/in a week. No name yet but it should be findable via search on ANDed terms: php, xslt, literate programming.

One could argue for programs in HTML, with the code bracketed in XML so that the compiler could find it.

Yes, and as i recently posted, i've found that it does in fact further program understanding to be able to embed xml tags of various types into the code and the surrounding documentation, if one can make use of it. Example benefits, achievable in code and non-code sections using the Amaya editor:

* Formatting, as you point out. XHTML, CSS works.
* Hyperlinking to other files, sections, and urls.
* SVG for drawing. (limited capability at present)
* Automatic (re)creation of hierachical table of contents based on <h> tags (Amaya shows this nicely in a separate window, and allows drill-down from it into the document). Here's your outline.

I implemented this as a tiny PHP/XSLT program.

Since the above mentioned post, in addition to getting its two qn's answered, I added code to use as the target filename the <title> element of the source document (sudo'ing to root when necessary (which it wouldn't be for Windows)).

The code sections are id'ed by being in a a named ("code") style, which simultaneously formats them.

Using Amaya's also nice because it allows editing of html content in the same window in which the html is interpreted (and without any of the flood of non-standard tags MSWord uses).

I plan on creating a Sourceforge project based on this w/in a week. No name yet but it should be findable via search on ANDed terms: php, xslt, literate programming.

So why did they sue an ISP, rather then say, W3C?

[Mozilla rendering the MARQUEE element], IMHO, is one instance of Mozilla playing a bad game of catchup to IE. Fortunately this hasn't happened too often, but everytime it does, it's a blow to W3 Standards, and an acknowledgement of Microsoft's market share.

Correct me if I'm wrong, but W3C offers recommendations, not standards. Sure, documents containing MARQUEE elements will not validate against the W3C [X]HTML DTDs, but does that invalidate the choice of a browser builder to support use of an element not in any W3C Recommendation?

The W3C certainly has nothing to say about this w/r/t the HTML 4.01 Recommendation:

"This specification does not define how conforming user agents handle general error conditions, including how user agents behave when they encounter elements, attributes, attribute values, or entities not specified in this document."

The W3C notes concerning invalid documents suggest that when "a user agent encounters an element it does not recognize, it should try to render the element's content." Seems to me that it might be in the best interests *to* recognize the "market leader" and render the content of a MARQUEE element (even in "strict mode"). That Mozilla would render the content as does MSIE, rather than as a static string of text, just means that certain Mozillains are making the most of a bad situation.

That situation being the simple existence of MARQUEE at all, not the ruination of some imagined, inflexible W3C Standard. Read the published recommendations a bit more closely, and you'll find that there is a surprising amount of leeway.

[Mozilla rendering the MARQUEE element], IMHO, is one instance of Mozilla playing a bad game of catchup to IE. Fortunately this hasn't happened too often, but everytime it does, it's a blow to W3 Standards, and an acknowledgement of Microsoft's market share.

Correct me if I'm wrong, but W3C offers recommendations, not standards. Sure, documents containing MARQUEE elements will not validate against the W3C [X]HTML DTDs, but does that invalidate the choice of a browser builder to support use of an element not in any W3C Recommendation?

The W3C certainly has nothing to say about this w/r/t the HTML 4.01 Recommendation:

"This specification does not define how conforming user agents handle general error conditions, including how user agents behave when they encounter elements, attributes, attribute values, or entities not specified in this document."

The W3C notes concerning invalid documents suggest that when "a user agent encounters an element it does not recognize, it should try to render the element's content." Seems to me that it might be in the best interests *to* recognize the "market leader" and render the content of a MARQUEE element (even in "strict mode"). That Mozilla would render the content as does MSIE, rather than as a static string of text, just means that certain Mozillains are making the most of a bad situation.

That situation being the simple existence of MARQUEE at all, not the ruination of some imagined, inflexible W3C Standard. Read the published recommendations a bit more closely, and you'll find that there is a surprising amount of leeway.

Hmmm, I didn't notice your name signed at the bottom of the original FAQ document like you've done in your post.

If you don't want to be linked to, don't put your stuff on the web.
And use open standards, too, dammit!
The web was built for the free sharing of information for the good of all. If you're to damn greedy to share, get the fuck out.

Stupid motherfuckers don't understand that's what the web's all about.

The site and all of its user selectable themes have been Tested in Netscape, Mozilla, Opera, Konquerer and IE. What browser are you using?

Remember: don't just check with favorite browsers. You also need to validate to standards.

SVG, anyone?

Relying on specific fonts for pages to render correctly is just asking for breakage -- and the FONT tag is deprecated, anyhow.

You say this as if modern web specs don't offer a way to control fonts. The fact of the matter is that HTML is (and has been) moving from controling the look-and-feel in HTML to controling the look-and-feel in CSS. And of course setting the font is supported in CSS: fonts and more fonts.

CSS font support is much better than HTML, and this is certainly the reason the font tag has been deprecated.

Relying on specific fonts for pages to render correctly is just asking for breakage -- and the FONT tag is deprecated, anyhow.

You say this as if modern web specs don't offer a way to control fonts. The fact of the matter is that HTML is (and has been) moving from controling the look-and-feel in HTML to controling the look-and-feel in CSS. And of course setting the font is supported in CSS: fonts and more fonts.

CSS font support is much better than HTML, and this is certainly the reason the font tag has been deprecated.

Guess what? If the standard is ignored, it doesn't reflect reality. Your point is circular. You've made no argument for ignoring standards; you've simply argued that certain companies ignore them now. And they shouldn't. It may be a sneaky way to short-term control of a market, but in the longer term it promotes chaos, which does not help anyone.

Don't act like the W3C is some sort of fascist or socialist bureaucracy. Membership is open to anyone who wants in. The agenda of the w3c is created by its members. If you have a problem with the standards, join the organization and participate in the democratic process. Standards are not being defended by anyone here as an a priori good; the point is that an external standards organization is an excellent means to a specific end -- cross platform interoperability -- in such a way that various agenda might be represented, rather than simply the agenda of MSFT shareholders.

Well, why don't you read up on the World Wide Web Consortium's (W3C) Web Accessibility Initiative? That should answer your questions.

Since I'm not a real life web developer, I'm curious - is a reasonable course of action to push candidate fodder web pages through something like the W3 validator and have things work more of the time?

I'd really like to know, cause I'm a happy Mozilla user in a rising sea of IE 6 users. Hence, I'm advocating W3 standards rather than standards defined as "whatever the dominant application does".

But it would be some encouragement if compliance to the W3 standards (say HTML 4.01) would be sufficient to have web pages render properly in a maximal subset of browsers.

There's a bit of JS you can link to which makes it work.

Alternatively you can use absolute positioning and hide the fixed from IE using one of the many tricks/selectors it doesn't support (assuming this is compatible with your use of fixed).

Or you can do what the W3C do and ignore it. Nice how IE6 SP1 *still* doesn't fix this.

Ok - I use "position: fixed" (EG), that does not work. What next?

I don't know *what* you meant by that, replying to somebody talking about the W3C specs. position: fixed is part of the spec. When you say does not work, do you mean doesn't validate, or doesn't render? Netscape does seem to have trouble with it though, so try "position: absolute" as well (just chuck both of em in, its what the W3C does.)

That's true - the current browsers won't render it. And they can barely render various other simple features, blah blah blah. However, this sets the stage for several years from now - when browsers will render it. I'd figure four years.

For example, just now, it's becoming possible to design web pages with CSS and relatively plain HTML markup. CSS having been established in late 1996, according to this. So, figure four or five years from now we may start designing web pages in XHTML 2.0, and Dreamweaver version 53 or whatever might actually spit out pages in XHTML 1.0.

I know it's annoying that progress is so slow, but that's how it goes.

Can You please insert some more links into your article. on slashdot?

I don't think I can possibly do all the background research myself.

Plus since the latest Gecko engine has adopted many of the IE conventions (IFRAMES etc...)

The IFRAME element is a part of the W3C HTML 4.0.1 spec.

"There is no doubt, mass copying off the Internet is illegal and deserves to be a high priority for the Department of Justice," said RIAA Chairman Hilary Rosen in a statement.

I believe the grandparent was referring to the Internet (capital 'I') as opposed to the web which can be thought along the lines of a metaphor: the web:internet::mind:brain :)
So, yes, this website says TB Lee "invented" the WWW. Says it right there on the web page that makes it sound as if he single-handedly crafted the web out of clay, so it must be true ;-)
The Web, as in the application-level invention HTTP and the family of "languages" in exchanges, are a technology that run on the internet which was pioneered by the United States DoD used to link universities, research centers, and gov't institutions, hence ARPANET. When it had later become too cumbersome to be entirely administrated/supported by the DoD it was taken over by a new 'backbone' built by the Nat'l Science Foundation (NSFNET) tailored to large-scale networking and evolved to what you use today.
However, pioneering initial research and implementation of a global switched net and SW protocols was done by DARPA and the NSF.

What an idiot. Firstly, there's the false impliction that since a guy at CERN wrote the first specs for the WWW that this means the internet was made by Europeans. (First off, it was the university of illinois that was communicating with CERN that worked on actually making mosaic and httpd to implement the spec, and secondly there's the fact that "the internet" != "the WWW".)

Yeah, yeah, we know. Just because the original graphical web client was written at CERN (in Switzerland, not the United States) by Tim Berners Lee (an Englishman, not an American), and the original HTTPD was written at CERN, isn't important because it's the first American implementation that goes in the history books. The American history books can comfortably ignore the fact that the University of Manchester (that's Manchester, England) had a programmable computer before anywhere in the United States, because, hey, England's a long long way away and probably doesn't really exist anyway. I could go on.

Bill Thompsons article is over the top and fundamentally wrong headed, but this is exactly the sort of blind, ignorant, narrow, uneducated US arrogance which makes you so disliked in the rest of the world, and which irritates people like Bill enough to make them go over the top.

For the record: no, you didn't invent the Internet. You didn't invent packet switched networking. You did build ARPAnet, at about the same time as the UK built JANET (and other European countries developed similar initiatives); and later, ARPAnet, JANET and several other networks were linked together to form the Internet. For the record, my first email address was @uk.ac.lancs.csvax, because the UK equivalent of DNS ordered name segments from the most general to the most particular.

I can't believe this was modded up to +3.

"Apache and Perl was the way to go in 1996, but times have changed." What?! This is the same type of fallacious argument that Microsoft uses against UNIX; "it's 30 years old, it can't be any good!"

Of course, generally, the entire reason one uses a high-level language (like Perl, or Python, or PHP, or whatever...) is because quickly putting something together is more important than lightning-fast speed. It's safe to say that web development is one of those tasks which generally benefits more from the former than the latter. With this in mind, your (unsupported claims) of Perl CGI's "efficiency" problems are irrelevant. Could we see something like benchmarks, or any kind of evidence?

Your comment about "serious" webmasters "doing it" in "Java or C" for "serious speed" strikes me as being particularly odd. Your use of the word "serious" seems quite silly; there are plenty of serious 'webmasters' using Perl. As for the languages you mention, almost no one uses C; that defeats the entire purpose of general web development methodology. Again, your claims are completely unsupported by any further evidence.

Personally, if I need to do any web scripting, I have my own language of choice.

Um, is nothing new; it was in HTML 4 and looks much the same.

It's effectively an img/embed tag which can be nested to allow the UA to fall back if it doesn't support something.

The draft's example includes showing the use of embedding an applet - so what? If the UA wants to execute it outside a sandbox, that's no the W3C's problem, just like Java or ActiveX security or Flash's security isn't their problem. If Python applets were ever to appear I'm sure they'd be secured similarly.

Seems like if they're going to make it backwards incompatible,

For example, are nested tables really the best way to lay out a page?

How about the script and noscript tags?

Any chance we can stop having to put comments around the script code?

How about separating the 2 distinct uses of anchor tags?

Seems like if they're going to make it backwards incompatible,

For example, are nested tables really the best way to lay out a page?

How about the script and noscript tags?

Any chance we can stop having to put comments around the script code?

How about separating the 2 distinct uses of anchor tags?

no XLink in this draft, despite it being a recommendation.

People wanting to know why might find "What is the scope of using XLink?" interesting.

Frames replaced by XFrames (nothing public yet).

An XFrames Working Draft has been released. See http://www.w3.org/TR/xframes/. XML Events look really fun, too.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.