Domain: w3.org
Stories and comments across the archive that link to w3.org.
Comments · 6,785
-
Re:Okay. Here's *MY* blog entry, Senator
Furthermore, McCain's website is showing a major 103 errors to Obama's 8, which are fairly minor. -
Re:Okay. Here's *MY* blog entry, Senator
Furthermore, McCain's website is showing a major 103 errors to Obama's 8, which are fairly minor. -
Re:*sigh*
Not to ruin the joke, but BODY isn't optional: try the following in the W3C validator:
<html>
<head><title>Not Valid</title></head>
<!-- <body><p>Uncomment this line to make it valid.</p></body> -->
</html> -
Re:*sigh*
Not to ruin the joke, but BODY isn't optional: try the following in the W3C validator:
<html>
<head><title>Not Valid</title></head>
<!-- <body><p>Uncomment this line to make it valid.</p></body> -->
</html> -
Re:What about Opera?
But is the only one that follow a standard (Widget 1.0 Compliance - http://www.w3.org/TR/widgets/), if you consider this draft a standard.
-
IE standards compliant that is ..
That is of course standards-compliant to the current version of Internet Explorer and not a Browser by any other name
.. :)
"Microsoft is .. letting Web site developers signal to IE how standards-compliant it ought to be with their pages"
How about writing web pages to a generic standard, something like W3C -
Re:Incredibly Inflated Sense of Self Worth
I very much doubt anyone on Slashdot is stupid enough to click on tinyurl links. Perhaps you should consider learning how to make links.
-
Re:solution in search of a problem
What's the purpose of Privacy Policy then?
I certainly hope you're not talking about P3P because that extra header means nothing in the real world. As for the typical "Read our privacy policy" links which almost always lead to legalese, there have been enough sites changing privacy policy as they see fit without even bothering about notifying their users.
Privacy policies are the saddest joke on the internet at the expense of anyone who's naive enough to believe them. Only a few high profile sites will bother obeying them out of fear for litigation, and I wouldn't be surprised if your precious personal data gets stolen by an employee looking for a quick buck.
As for its purpose: it reassures users that their personal data is safe with the company, while they carefully enter their personal information which is then usually POST'ed over plain old HTTP.
-
Re:Umm, noYour web client sucks then. Get one that understands persistent HTTP connections. If you actually look at a network sniffer while any modern browser accesses a webpage you should see them all use the same socket. So, your web client is able to ask for the JavaScript before it's loaded the page, huh? Otherwise your response is just moronic.
I'm sure this is over your webmonkey head anyway, but not all of us are using fiber lines to connect to the web. Some of us are still stuck on, gasp, dial-up. And loading an external JavaScript file is STILL far slower than inlining it.
See, here's how it works:
1. Send request for the page.
2. Read the page, sees it needs a JavaScript file.
3. Sends request for the JavaScript file.
4. Read the JavaScript file.
5. Finally finish loading the page and let people interact with it.
If you'd just inlined the script, you'd remove step 3 completely. And it matters on dial-up.
As it turns out, web browsers can't preemptively request resources they don't know they need, and a request takes time EVEN IF YOU ALREADY ESTABLISHED THE CONNECTION.
Inlining will ALWAYS be faster. -
Re:Umm, noSecond, I've always had this complaint with the whole external javascript files. When you're already downloading a 50K html page, another 10K of javascript code in the same file inline downloads at full-speed. The external file requires yet another hit to the server, and everything involved therein. It almost never makes any sense. Even as a locally cached file, on a broadband connection, downloading the extra 10K is typically faster than opening and reading the locally cached file!
That's not the reason that I generally use external JavaScript files. The reason is code reuse, pure and simple. Generally speaking it's far easier to just link to the file (especially for static HTML pages) than it is to try and inline it. That way when you fix a bug that effects Internet Explorer 6.0.5201 on Windows XP SP1.5 or whatever you don't have to copy it to all your static files as the code is in a single location.
Sure, you could use server-side includes, but then you need to make sure that your JavaScript code doesn't include "</script>" anywhere. The requirements are even more strict for (true) XHTML.
It's also code separation. It separates the JavaScript code from the display, which generally makes it far easier to work with, especially with syntax-highlighting editors that get retarded when they see JavaScript in HTML.
But anyway:
The external file requires yet another hit to the server, and everything involved therein.Your web client sucks then. Get one that understands persistent HTTP connections. If you actually look at a network sniffer while any modern browser accesses a webpage you should see them all use the same socket.
The other option is that the web server sucks or is configured not to use persistent HTTP connections. In any case, this shouldn't be a real problem.
-
Re:A lot can be seen from their choice of advisor.
Before this gets too out of hand, let's make sure that we're all dealing with the facts. A quick Google search shows that Daniel Weitzner is also a lawyer.
"Mr. Weitzner has a degree in law from Buffalo Law School, and a B.A. in Philosophy from Swarthmore College."
Granted, I'd still rather have him advising the president than a former media executive, but he's not exactly Robert Morris. -
Re:What is it with UbuntuAgreed. The Ubuntu website is the amateurish one that breaks the rules. For example, it is fixed width and doesn't flow to fit the screen, and it fails validation (Debian's site passes validation and flows). I also feel it just isn't as functional as the simpler, cleaner Debian site.
Like most people, you're confusing two different concepts here: skillful vs. professional. Debian's site is clearly more skillfully done, and wins on technical merit. Ubuntu's site is clearly more professional; people are more likely to pay for a site like that. Debian's site is both technically superior and more amateurish. The very qualities you mention as signs Ubuntu's site is "more amateurish" are common and even to some degree desired in many professional web designs (fixed-width, for example, is required to accurately control precise layout, a common client requirement). If the Debian developers were trying to sell the site design, it'd look more like Ubuntu's, which is to say, more professional, albeit not as good in many ways.
Never confuse "professional" with "better" or "amateur" with "worse". The first terms relate to the compensation for the activity, the second refer to subjective criteria which are usually utterly unrelated to that.
-
Re:What is it with UbuntuAgreed. The Ubuntu website is the amateurish one that breaks the rules. For example, it is fixed width and doesn't flow to fit the screen, and it fails validation (Debian's site passes validation and flows). I also feel it just isn't as functional as the simpler, cleaner Debian site.
Like most people, you're confusing two different concepts here: skillful vs. professional. Debian's site is clearly more skillfully done, and wins on technical merit. Ubuntu's site is clearly more professional; people are more likely to pay for a site like that. Debian's site is both technically superior and more amateurish. The very qualities you mention as signs Ubuntu's site is "more amateurish" are common and even to some degree desired in many professional web designs (fixed-width, for example, is required to accurately control precise layout, a common client requirement). If the Debian developers were trying to sell the site design, it'd look more like Ubuntu's, which is to say, more professional, albeit not as good in many ways.
Never confuse "professional" with "better" or "amateur" with "worse". The first terms relate to the compensation for the activity, the second refer to subjective criteria which are usually utterly unrelated to that.
-
Re:What is it with Ubuntu
Agreed. The Ubuntu website is the amateurish one that breaks the rules. For example, it is fixed width and doesn't flow to fit the screen, and it fails validation (Debian's site passes validation and flows). I also feel it just isn't as functional as the simpler, cleaner Debian site.
However, I am a bit of a minimalist (use IceWM, Emacs (small by today's computing resources), play nethack, etc.), making me less likely to be interested in Ubuntu anyway (besides some other reasons).
-
Re:What is it with Ubuntu
Agreed. The Ubuntu website is the amateurish one that breaks the rules. For example, it is fixed width and doesn't flow to fit the screen, and it fails validation (Debian's site passes validation and flows). I also feel it just isn't as functional as the simpler, cleaner Debian site.
However, I am a bit of a minimalist (use IceWM, Emacs (small by today's computing resources), play nethack, etc.), making me less likely to be interested in Ubuntu anyway (besides some other reasons).
-
Re:Blacklist gmail
How about 10 errors?
http://validator.w3.org/check?verbose=1&uri=http://www.taylorbyrnes.org/ -
Re:Blacklist gmail
Sorry, that's wrong: http://www.w3.org/TR/xhtml-media-types/#summary
The only time you should serve XHTML as text/html is when it's XHTML 1.0, with special care taken to keep backward compatibility in mind.
And as for 88 errors, well, if you're not going to be valid, why declare a document type? This isn't difficult stuff. That's 88 more errors than there should be.
-
Re:I hope that this set precedent...
It passes now. Thanks.
-
Re:I hope that this set precedent...
what a great site! they give a nice warning message about non-standards compliant browsers (ie7 here), but they fail validation!
-
Re:More details
I agree, they've done some other good things recently:
collaborating with mozilla in the tamarin project
open sourcing the flex libraries and compiler, which by the way is in fact an actionscript compiler, meaning you can develop any actionscript application with it, not just flex
Yep, i looks like they're moving in the right direction, i think they are aware of SVG and SMIL, and they realize that eventually they'll have to open source the player too if they don't want the flash platform to disappear. -
Re:More details
I agree, they've done some other good things recently:
collaborating with mozilla in the tamarin project
open sourcing the flex libraries and compiler, which by the way is in fact an actionscript compiler, meaning you can develop any actionscript application with it, not just flex
Yep, i looks like they're moving in the right direction, i think they are aware of SVG and SMIL, and they realize that eventually they'll have to open source the player too if they don't want the flash platform to disappear. -
Re:W3C
Only insofar as the className in JS is nothing more than a string.
It really shouldn't be. The HTML content model is a space-separated series of values, so it's the DOM at fault for not providing it in array form, and I'm pretty sure all the major JavaScript libraries offer a better interface.
Turning that string into something remotely useful (e.g. an key-value array) requires you to roll your own parser, which opens up room for truckloads of bugs
I've personally done just this, it was quite a while ago, but I don't remember any difficulties at all. You urlencode the values and split on whitespace. It's almost a one-liner, it even automatically handles quotes, spaces in values, unicode characters, etc if I remember correctly. I agree that having to parse it yourself is sub-optimal, but it's not as difficult or fragile as it first seems.
In any case, this objection is going away as HTML 5 will probably include this facility. On its face, it seems useful, but I have to say, when I want to embed data in an HTML document, there's usually a perfectly appropriate element type or attribute ready and waiting, and I can't think of a time when I'd have actually used this.
-
Re:Valid Markup != Good Code
We'll disagree about the definition of apathy. You are referring to things done "for no good reason" when in fact they have a good reason (in their opinion).
Regarding Google... OK, I'll bite. Looking at Google's deviations from spec, I note mostly deliberate omissions: no DOCTYPE declaration; style and script tags don't include TYPE attributes; most tag attributes do not have quotes around them (e.g. bgcolor=#ffffff and width=25% and onclick=gbar.qs(this)) which, in turn, causes a lot of additional errors in the validator (since # and % are not valid except when quoted); and ampersands in linked URLs are flagged as errors.
So, since it is so easy to change this to spec, I copied the home page source, corrected the errors, and ran it back through the validator. That resulted in 9 errors (down from 63), and almost all of them involve nonstandard attributes used by old nonstandard browsers -- so, in theory, we might forgive their presence for the sake of backward compatability. In any case, the home page footprint increased by 466 bytes (6990 bytes before, versus 7456 bytes after). I can't immediately find hard numbers about how many visitors Google gets, but I'll make a guesstimate at 200 million per day, which would translate to a savings of roughly 90gb of data a day.***
Is that worth it? I don't know. If saving bandwidth and improving data transmission efficiency are your top priorities, then yes, it's worth it. Perhaps Google thinks those are more important than meeting formal HTML specifications.
*** My back-of-the-napkin math may be totally flawed. Feel free to correct it.
-
Re:W3C
Citation, please?
If you want the authoritative source, you'll have to buy the ISO 8879:1986 standard, it costs around EUR140. Aren't "open standards" like HTML great?
I've read the HTML spec and see nothing of the sort.
The HTML specification defines the content model, not how the syntax should be parsed. It gives a brief overview in the introductory material for people unfamiliar with SGML, but it's incomplete and refers readers to the SGML standard I just mentioned. It does, however briefly mention the shorthand syntax in the appendix, which is probably why you missed it.
The purpose for checking attributes is to avoid running into conflicts with future attributes that might be declared as part of the standard.
No, that might be your reason to use a validator, but it's not the validator's purpose in checking them. The validator's purpose in checking them is because it is a syntax checker, and the syntax defines which attributes are acceptable. To complain that a syntax checker is pointing out syntax errors is ludicrous. If you don't want to know about syntax errors, don't use a syntax checker.
strict attribute checking is a waste of time and effort
This has nothing to do with strict attribute checking. The validator doesn't reject XHTML-style empty elements because it thinks the slash is an attribute it doesn't recognise, it rejects it because the element is opened and the greater-than sign becomes character data. This gives rise to problems such as having character data within the <head> element where it isn't permissible, which is a problem quite different to an incorrect attribute.
the HTML standard is fundamentally flawed in that it did not provide a clean, standard way of providing arbitrary tagging of elements with additional information except through attributes, and a strict attribute check makes that impossible.
Look up the class attribute. That's exactly what it's for.
I don't know any definition of pedantic that strict attribute validation doesn't meet
But of course the validator is being pedantic! That's the entire purpose of its existence! What good would it be if it didn't pedantically go through your markup, looking for all the errors it could find?
I'm not disagreeing about the validator being called pedantic, I'm pointing out that complaining about it is like complaining water is wet. It's part of its fundamental nature.
If you want some kind of checker that doesn't check validity, but uses heuristics to point out potential problems, then you want a linter, not a validator.
I find it very obnoxious that the W3C validator doesn't allow you to disable that check
I haven't looked at the source in quite a while, but last time I checked it would be pretty difficult to do so, because the SGML feature that allows those shortcuts is also the SGML feature that allows minimised attributes.
But the validator is open-source, so if you think it's easy, download it and do it yourself. It's pretty obnoxious to use their free service all the time when you could be running it locally anyway.
-
Re:W3C
That reasoning would work if the people behind XML had chosen any other character to indicate empty elements. But unfortunately, they chose the slash. Not many people realise because browser support is rare, but a slash inside an opening tag means that it is the end of the tag and the contents follow
Citation, please? I've read the HTML spec and see nothing of the sort. According to the spec, the tag ends when a > is encountered, period.
What on earth do you think a validator is for, if not to point out syntax errors? Do you complain that your spelling checker is being pedantic when it tells you that you have misspelt something?
The purpose for checking attributes is to avoid running into conflicts with future attributes that might be declared as part of the standard. Otherwise, browsers are expected to ignore any unknown attributes for compatibility with future versions of the standard. Since the user of attributes for formatting, etc. is pretty much obsoleted by CSS and adding new attributes is so strongly discouraged, coming up with tags that conflict with a future version of the standard is basically a non-issue, so strict attribute checking is a waste of time and effort.
More to the point, the HTML standard is fundamentally flawed in that it did not provide a clean, standard way of providing arbitrary tagging of elements with additional information except through attributes, and a strict attribute check makes that impossible. In fact, the HTML spec (http://www.w3.org/MarkUp/html-spec/html-spec_4.html) explicitly says:
"To facilitate experimentation and interoperability between implementations of various versions of HTML, the installed base of HTML user agents supports a superset of the HTML 2.0 language by reducing it to HTML 2.0: markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization. Undeclared attributes are treated similarly. The entire attribute specification of an unknown attribute (i.e., the unknown attribute and its value, if any) should be ignored."
Emphasis mine. Now admittedly, it goes on to say that this is non-binding, but in practice, any browser that doesn't ignore unknown attributes will fail to successfully display the vast majority of web pages, including the HTML 4.0 specification page that I linked to in the previous paragraph.
I don't know any definition of pedantic that strict attribute validation doesn't meet, and I find it very obnoxious that the W3C validator doesn't allow you to disable that check, as it really doesn't contribute anything useful except in cases where an attribute's usage is known to conflict with a later version of the specification.
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:Valid Markup != Good Code
they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time.
So... you've just insulted all the web programmers at Google, Yahoo, Apple, YouTube, Windows Live, EBay, Amazon, etc.?
Well, at least MSN passes the validator. They must have competent programmers!
-
Re:W3C
Per the specification, omitted end tags are valid.
No, omitted end tags are valid only for some element types, as the section you link to clearly says. The HTML specification lists exactly which element types it is permissible to omit end tags for. The NYTimes are omitting end tags for <div> elements, which are required.
-
Re:W3C
Per the specification, omitted end tags are valid.
No, omitted end tags are valid only for some element types, as the section you link to clearly says. The HTML specification lists exactly which element types it is permissible to omit end tags for. The NYTimes are omitting end tags for <div> elements, which are required.
-
Re:Valid Markup != Good Code
It would be impossible to make a working website by being totally loyal to the markup rules.
This is quite wrong. You absolutely can make a site that validates, and (what's more important, in fact) is actually semantically correct HTML, yet displays properly in all the major browsers out there. A good example is the Opera website (validates as XHTML 1.0 Strict). Also, if you have a browser that has such feature, try disabling CSS and JavaScript entirely, and see how it looks then - I was pretty surprised to find out that drop-down menus are actually defined as a hierarchy of nested unordered lists, which is why it is fully navigable in Lynx and similarly restricted browsers. -
Re:W3C
Forgotten end tags
They are using HTML, not XHTML. Per the specification, omitted end tags are valid. The if an end tag is missing the element is closed at the end of the parent element or the start of the next block level element.
-
Re:W3C
"The alt attribute must be specified for the IMG and AREA elements. It is optional for the INPUT and APPLET elements." http://www.w3.org/TR/html401/struct/objects.html#h-13.8
-
That's not fair
That's not fair. I didn't get any errors at all on my page. And after all that work hand coding the HTML and the CSS inside PHP.
-
Re:Valid Markup != Good Code
An & sign in a link to a URL isn't a syntax error
Yes, it is. Don't just take my word for it, take a look at what the HTML specification has to say on the matter.
treating it as such would nullify all GET parameters after the first one.
You are confusing a URI with the representation of that URI within an HTML document. Just because it appears as & in the document, it doesn't mean that's what you end up with after it has been parsed.
-
Re:W3C
...and yet they get 455(!) errors. That's not very good. http://validator.w3.org/check?uri=http%3A%2F%2Fnytimes.com%2F&charset=%28detect+automatically%29&doctype=Inline&group=0. They are up to 471 errors now. I think you should bring it to their attention before it gets out of hand. ;-) -
Re:W3CForgetting required attributes like alt What is the correct value of the alt attribute for the CAPTCHA image in a "free registration required" form?
-
W3C
...and yet they get 455(!) errors. That's not very good. http://validator.w3.org/check?uri=http%3A%2F%2Fnytimes.com%2F&charset=%28detect+automatically%29&doctype=Inline&group=0.
-
Re:While we're at it...
Um, that's in the spec already. Both the "height" and "width" attributes for the IMG tag can be defined as percentages.
"Um,"
grow up! -
Re:alt="" or alt=missingSection 508 only applies to government websites. Those and the web site of any company that supplies goods or services to the government. Outside the United States, accessibility laws may be even more comprehensive. Not every image should have an alt tag anyway. Or do you think "upper right rounded corner grey on black" is something a blind person would be interested in. You're right that decorative images should have alt="". But I see plenty of images on web sites that are not decorative yet still have alt="" or no alt attribute at all. For example, how is alt="Security Code" accessible to somebody who uses a screen reader?
-
Re:While we're at it...
Or HTML spec is upgraded so that we can specify image size in % as well as pixels similar to a table.
Um, that's in the spec already. Both the "height" and "width" attributes for the IMG tag can be defined as percentages.
-
Re:$100/user is still pretty high for small biz
This is just an anecdote, but...
I work in a large semiconductor corporation, where everyone uses Outlook, Powerpoint, etc...
Today I attended a presentation explaining the consequences of the switch of a compiler backend to GNU binutils, and the presentation was done using HTML Slidy.
Oh, and we're finally switching away from Clearcase to SVN.
Only now do I realize how far pervasive open-source has become in the corporate market. Of course, it doesn't appear on the balance sheets :\ -
Re:HTML5 needs a lot more work
Last I checked, HTML 5's working doc says that forms aren't going to change over html4.
They are going to change. It's not yet decided exactly how they will change – the HTML WG has Web Forms 2 (an extension of HTML4's forms), and the Forms WG is working on some rough ideas for trying to fit XForms into HTML5, and there is a joint Task Force that is meant to be working things out between the groups but hasn't actually managed to achieve anything yet. (None of the major browser developers has indicated much interest in implementing XForms, whereas Opera has already released an implementation of WF2 and there is some ongoing work to implement parts in Firefox and Safari, so the momentum is currently in that direction.)
allow forms to validate without having to have [div]s that do nothing but hold hidden fields because [input] is a presentation tag and therefore must be within a text-carrying tag
Web Forms 2 says "input elements of type hidden may be placed anywhere (both in inline contexts and block contexts)", which sounds like it satisfies your concern (and has the advantage of working in all existing web browsers, unlike a new <state> element).
can we PLEASE have them back so that we can use them for tabular data (like item names, prices, descriptions, etc)?
<table> has never been deprecated, and HTML5 still permits it. (Tables used for layout are not allowed, although that's impossible for an automatic validator to detect). There are already CSS properties that can replace cellpadding ('padding') and cellspacing ('border-spacing').
would it really kill the documentation writers to say what something has been deprecated BY?
It seems spec writers usually think that kind of thing should be described in tutorials or other documents, not in the specification. The HTML5 spec is far harder to read than HTML4 (because it's far more detailed, to fix the differences between implementations caused by HTML4's vagueness), so it really needs that kind of user-oriented documentation. The differences document gives a brief mention of what should be used instead of some obsolete features, but it would be nice to have more detail and examples for people who want to move to HTML5.
-
Re:HTML
Check this out: http://validator.w3.org/check?uri=http://www.google.com
Google managed to fit 62 errors in their 4-line half-page home page.
On another note, 90% of all pages that claim to be conformant, with the "Valid (X)HMTL Strict/Transitional" button at the bottom of the page, are not conformant. This statistic gathered from personal observation. -
Re:HTML
Speaking of HTML, it's amazing how many high-profile sites fail validation. For example, I just ran http://www.nytimes.com/ through http://validator.w3.org/ with a result of "Failed validation, 454 Errors." "Something like HTML that browsers can more-or-less read" is not actual HTML. When I redid a local newspaper's site, I did it by hand (in nicely formatted, human-readable HTML) and made sure that every page passed validation before it went live.