I was reading O'Reilly's Learning XML Book and read the following
HTML was in some ways a step backward.
To achieve the simplicity necessary to
be truly useful, some principles of
generic coding had to be sacrificed.
... To return to the ideals of
generic coding, some people tried to
adapt SGML for the web ... This proved
too difficult.
This reminded me of a StackOverflow Podcast where they discussed the poorly formed HTML that works on browsers.
My question is, would the Internet still be as successful if the standards were as strict as developers would want them to be now?
Lack of standard enforcement didn't hurt the adoption of the web in the slightest. If anything, it helped it. The web was originally designed for scientists (who generally have little patience for programming) to post research results. So liberal parsers allowed them to not care about the markup - good enough was good enough.
If it hadn't been successful with scientists, it never would have migrated to the rest of academia, nor from there to the wider world, and it would still today be an academic exercise.
But now that it's out in the wider world, should we clamp down? I see no incentive for anyone to do so. Browser makers want market share, and they don't get it by being pissy about which pages they display properly. Content sites want to reach people, and they don't do that by only appearing correctly in Opera. The developer lobby, such as it is, is not enough.
Besides, one of the reasons front-end developers can charge a lot of money (vs. visual designers) is because they know the ins and outs of the various browsers. If there's only one right way, then it can be done automatically, and there's no longer a need for those folks - well, not at programmer salaries, anyway.
Most of the ambiguity and inconsistency on the web today isn't from things like unclosed tags - it's from CSS semantics being inconsistent from one browser to the next. Even if all web pages were miraculously well-formed XML, it wouldn't help much.
The fact that html simply "marks up" text and is not a language with operators, loops, functions and other common programming language elements is what allows it to be loosely interpreted.
One could correlate this loose interpretation as making the markup language more accessible and easily used thus allowing more "uneducated" people access to the language.
My personal opinion is that this has little to do with the success of the Internet. Instead, it's the ability to communicate and share information that make the internet "successful."
It hurt the Internet big time.
I recall listening to a podcast interview with someone who worked on the HTML 2.0 spec and IIRC there was a big debate at the time surrounding the strictness of parsers adhering to the standard.
The winners of the argument used the "a well implemented system should be liberal in what it accepts and strict in what it outputs" approach which was popular at the time.
AFAICT many people now regard this approach as overly simplistic - it sounds good in principle, but actually rarely works in practice.
IMO, even if HTML was super strict from the outset, it would still have been simple enough for most people to grasp. Uptake might have been marginally slower at the outset, but a huge amount of time/money (billions of dollars) would have been saved in the medium-long term.
There is a principle that describes how HTML and web browsers are able to work and interoperate with any success at all:
Be liberal in what you accept, and conservative in what you output.
There needs to be some latitude between what is "correct" and "acceptable" HTML. Because HTML was designed to be "human +rw", we shouldn't be surprised that there are so many flavours of tag soup. Flexibility is HTML's strength wherever humans need to be involved.
However, that flexibility adds processing overhead which can be hard to justify when you need to create something for machine consumption. This is the reason for XHTML and XML: it takes away some of that flexibility in exchange for predictable input.
If HTML had been more strict, something easier would have generated the needed network effect for the internet to become mainstream.
Related
Does Google really care if I use an <h5> as a <b> tag?
What are some real-world, practical reasons I should care about semantic markup?
A few examples
Many visually impaired people rely on speech browsers to read pages back to them. These programs cannot interpret pages very well unless they are clearly explained. In other words semantic code aids accessibility
Search engines need to understand what your content is about in order to rank you properly on search engines.
Semantic code tends to improve your placement on search engines, as it is easier for the "search engine spiders" to understand.
However, semantic code has other benefits too:
As you can see from the example above, semantic code is shorter and so downloads faster.
Semantic code makes site updates easier because you can apply design style to headings across an entire site instead of on a per page basis.
Semantic code is easier for people to understand too so if a new web designer picks up the code they can learn it much faster.
Because semantic code does not contain design elements it is possible to change the look and feel of your site without recoding all of the HTML.
Once again, because design is held separately from your content, semantic code allows anybody to add or edit pages without having to have a good eye for design.
You simply describe the content and the cascading style sheet defines what that content looks like.
Source: boagworld
Semantics and the Web
Semantics are the implied meaning of a subject, like a word or sentence. It aids how humans (and these days, machines) interpret subject matter. On the web, HTML serves both humans and machines, suggesting the purpose of the content enclosed within an HTML tag. Since the dawn of HTML, elements have been revised and adapted based on actual usage on the web, ideally so that authors can navigate markup with ease and create carefully structured documents, and so that machines can infer the context of the wonderful collection of data we humans can read.
Until — and perhaps even after — machines can understand language and all its nuances at the same level as a human, we need HTML to help machines understand what we mean. A computer doesn’t care if you had pizza for dinner. It likely just wants to know what on earth it should do with that information.
HTML semantics are a nuanced subject, widely debated and easily open to interpretation. Not everyone agrees on the same thing right away, and this is where problems arise.
Allow me to paint a picture:
You are busy creating a website.
You have a thought, “Oh, now I have to add an element.”
Then another thought, “I feel so guilty adding a div. Div-itis is terrible, I hear.”
Then, “I should use something else. The aside element might be appropriate.”
Three searches and five articles later, you’re fairly confident that aside is not semantically correct.
You decide on article, because at least it’s not a div.
You’ve wasted 40 minutes, with no tangible benefit to show for it.
— Divya Manian
This generated a storm of responses, both positive and negative. In Pursuing Semantic Value By Jeremy Keith argued that being semantically correct is not fruitless, and he even gave an example of how <section> can be used to adjust a document’s outline. He concludes:
But if you can get past the blustery tone and get to the kernel of the article, it’s a fairly straightforward message: don’t get too hung up on semantics to the detriment of other important facets of web development.
— Jeremy Keith
Naming Things
Of all the possible new element names in HTML5, the spec is pretty set on things like <nav> and <footer>. If you’ve used either of those as a class or id in your own markup, it’s no coincidence. Studies of the web from the likes of Google and Opera (amongst others) looked at which names people were using to hint at the purpose of a part of their HTML documents. The authors of the HTML5 spec recognised that developers needed more semantic elements and looked at what classes and IDs were already being used to convey such meaning.
Of course, it isn’t possible to use all of the names researched, and of the millions of words in the English language that could have been used, it’s better to focus on a small subset that meets the demands of the web. Yet some people feel that the spec isn’t yet doing so.
Source: html5doctor (This goes on for quite a while so I've only put a few examples here.)
Hope this helps!
As far as I understand, the only real advantage of HTML5 semantic markup is for search engines and web crawlers to interpret the document better.
Since intranet applications have nothing to do with search engines or web crawlers, what are the advantages of using semantic markup in HTML5?
There is no straightforward example to point out, but the website (even intranet) can be consumed by different user agents (on different devices).
You are probably familiar with Skype (and the iOS Safari) making phone-number-like words clickable. In the future I can easily imagine mobile browsers being smarter to assist the user in completing tasks on the page, like importing a clearly indicated contact to the address book.
Screenreaders for blind people?
While there is not a whole lot of immediate benefit for non-disabled people, it is still good practice. Does your company not have any externally facing sites? If it does, do those people not look at internal page code? Good practices spread just like bad ones.
see also: http://en.wikipedia.org/wiki/Semantic_HTML
Simply said there the only rule you have to follow if you create your html documents is that it is valid html, otherwise you will have the problem that the browser would try to correct your broken syntax which may result in defects of the visual representation of your content.
In modern browsers you can use display to given any element - with some limitations e.g. with input element - the same visual look and behavior then any other element.
So if you ask what are the advantages of using semantic markup in HTML5 you should ask, why to use any of the semantic markup if it is possible to have the same result using css.
The short answer is, no one will stop you if it is your own project where you are responsible to - except the client that probably gives you requirements.
It is similar to asking: Language xyz provides comments and there is a syntax for doc-comments, but why should I use them?.
Using the semantics wisely increases the readability and thus maintainability. You are not required to use every possibility of semantics at all costs.
Using them will help you to get into the code again if you haven't looked at it for a longer time, e.g. to distinguish between the elements that encapsulate logical parts and elements that are used for styling. Especially if you use a template engine to create your code or to search for certain elements in multiple files.
Even if you are now the only one who works on the code it may happen that if the project grows that you need other people to work on the code. Or for the situation, you for some reason are not available, someone else needs to maintain your code, a good markup is essential.
Using the correct markup and additions like WAI-ARIA is not only essential for handicapped people, but also allows the browser to recognize the meaning of elements, allowing to e.g. improve the keyboard navigation. Especially in a productive environment where you need to type much, it is often faster to navigate with keyboard then using a trackpad or a mouse.
I read the following in HTML 5 tag reference at W3School
HTML5 improves interoperability and reduces development costs by
making precise rules on how to handle all HTML elements, and how to
recover from errors.
While I understand that there are some attributes like "pattern" and "required", are they talking about the same? Do they mean form validation when they mention "recovery from error"?
If not, what HTML 5 elements/tags are they referring to which helps "recovering from error"?
Thanks
From the source: http://dev.w3.org/html5/spec/Overview.html#an-introduction-to-error-handling-and-strange-cases-in-the-parser
HTML 5 defines a standard for the the handling of specific exceptional situations.
Why it's important
I have written a few HTML parsers for commercial use and--while no means an expert on the subject--I know firsthand how painful it can be to deal with malformed content. As hard as developers try (or fail to try), many major sites have poor, non-standard markup. Content management systems driven by non-technical users only increase the problem, as most WYSIWYG editors don't produce perfect markup.
So what do you do? you make assumptions and you relax the rules, rather than failing the whole process or rendering radically incorrect content when you know that was probably not the intention of the developer.
The HTML spec (versions 5 and previous) define rules for how user agents should handle the rendering of content. To my knowledge, the HTML 5 spec has the richest definition for how exceptional cases should be handled.
If all user agents (browsers) treat exceptional cases the same, you achieve consistency while still allowing for the inevitable human error. That said, I wish more people would take the warnings on validator.w3.org seriously (or at least read them!)
FWIW, most people on this site (myself included) don't trust w3schools as a reference.
I'm looking into HTML5 and I'm puzzled why it goes so easy on well-formedness.
<div id="main">
<DIV ID="main">
<DIV id=main>
are all valid and produce the same result. I thought with XHTML we moved to XML compliant code at no cost (I don't count closing tags as a cost!). Now the HTML5 spec looks to be written by lazy coders and/or anarchists. The result is that from the start of HTML5 we have two versions: HTML5 and the XML compliant XHTML5. Would you consider it an asset if C would suddenly allow you to write a for construct in the following ways?
for(i = 0; i < 10; i++) {
for(i = o; i < 1o; i++) { // you can use "o" instead of "0"
for(i = 0, i < 10, i++) { // commas instead of semicolons are alright!
Frankly, as an XHTML coder since many moons I feel a bit insulted by the HTML5 spec.
Wadya think?
Steven
edit:
Mind the "wadya": would you as a customer accept a letter with "wadya" written instead of "What do you"? :-)
HTML 5 is not an XML dialect like XHTML is.
What made HTML so popular was the fact that it tolerated mistakes, so just about anyone could write an HTML page.
XHTML made it much more difficult and it didn't get widely adopted. At the same time, further development of HTML/XHTML stagnated, so an industry group formed up, the WHATWG who started work on the next generation of HTML and decided to revert to a non XML standard for HTML 5.
Since XML is stricter than HTML, you can always write your HTML to be XML compliant. Make sure attributes are in lower case, use value delimiters, elements have closing tags and use correct XML escaping where needed.
HTML was never intended to convey media, and therefore never intended
for any kind of marketing or merchandising. HTML was only intended to
convey text and to provide some sort of descriptive structure upon the
text it was describing. The people originally using HTML professors and
scientists who needed the ability to describe their communications in
more depth and line breaks and quotes would allow. In other words HTML
was only intended to be a document storage mechanism. Keep in mind
there were no web browsers at this time.
HTML was first made popular with the release of the web browsers.
Initially web browsers were just text parsers that provided a handy GUI
for navigating the hyperlinking between documents, but this changed
almost immediately. At this time there was still no actual standard for
HTML. There was the list of tags and a description of mechanisms
initially created for HTML, which along with an understand of SGML, was
all that was required to create an HTML parser.
With web browsers came the immediate demand to extend HTML in ways HTML
never intended. It was at this point that the inventors and original
users completely lost control of the web. Tags were added, such as
center and font, and tables became the primary mechanism for laying
things out on a page instead of describing data. Web browsers supplied
a media demand completely orthogonal to the intentions of HTML.
Marketing people, being what they are, care very much for the appearance
and expressive nature of communications and don't give a crap for the
technology which makes such communication possible. As a result parsers
became more lax to accommodate the incompetent. You have to understand
that HTML was already lax because there were no standard parsing rules
and SGML, due to being so very obtuse, encourages a lax nature outside
of parsing instruction tags.
Its not that these early technology pioneers were stupid, although its
easy to argue the contrary, they simply had other priorities. When the
web went mainstream there was an immediate obsession to conquer specific
business niches in this new medium. All costs were driven towards
marketing, market share, traffic acquisition, and brand awareness. Many
web businesses operate today with similar agendas, but today's web is
not a fair comparison. In the 90s marketing was all that mattered and
technology costs were absolutely ignored. The problem was so widespread
and the surge of investment so grand that it completely defied all
rational rules of economics. This is why there was an implosion. The
only web businesses that survived this crash were those that confronted
their technology costs up front or those who channeled investment monies
into technology expenses opposed to additional marketing expense.
http://en.wikipedia.org/wiki/Dot-com_bubble
After the crash things changed. Consider the crash good timing, because
although it was entirely driven by bad business decisions, foolish
investments, and irrational economics there was positive technology
developments going on behind the scenes. The founders of the web were
completely aware that they had lost all control of their technology.
They sought to solve this problem and set things straight by creating
the World Wide Web Consortium (W3C). They invited experts and software
companies to participate. Although solving many of the technology
problems introduced to the web by marketing drivin motivations was a
lost cause many future problems could be avoided if the language were
implemented in accordance with an agreed upon standard. It was during
this time that HTML 2 (the first standard form of HTML), HTML 3, and
HTML 4 were written.
At the same time the W3C also began work on XML, which never intended to
be a HTML replacement. XML was created because SGML was too complex. A
simple syntax based upon similar rules was needed. XML was immediately
written off by marketing people and was immediately praised by data
evangalists at Microsoft and IBM. Because the holy wars around XML were
trivial, insignificant, and short lived compared to such problems
plaguing HTML XML's developement occurred at rocket speed. Almost
immediately after XML was formed the first version of XML Schema was
formed.
XML Schema was an extradinary work that most people either choose to
ignore or take for granted. An abstration model for accessing the
structure of HTML was also standardized based upon XML Schema, know as
the Document Object Model (DOM). It is important to note that the DOM
was initially developed by browser vendors to provide an API for
JavaScript to access HTML, but the standard DOM released by the W3C had
nothing to do with JavaScript directly.It quickly became obvious that
many of technology problems plaguing HTML could be solved by creating an
XML compliant form of HTML. This is called XHTML. Unfortunately, the
path of adoption from HTML to XHTML was introduced in a confused manner
that is still not widely understood years after clarification finally
occurred.
So, there was a crash and leading up to this period of economic collapse
there were some fantastic technology developments. The ultimate source
of technology corruption, the web browsers, were finally just starting
to innovate around adoption of the many fantastic technology solutions
dreamed up at the W3C, but with the crash came an almost complete loss
of development motivation from the browser vendors. At this time there
was only really Netscape, IE, and Opera. Opera was not free software,
so it was never widely adopted, and Netscape went under. This
essentially left only IE and Microsoft pulled all their developers off
IE. Years later development on IE would be revived when competition
arose from Firefox and when Opera adopted free licensing.
About the same time that browsers were coming back to life the W3C was
moving forward with development of XHTML2. XHTML2 was an ambitious
project and was not related to XHTML1, which created much confusion.
The W3C was attempting to solve technology problems associated with HTML
that had been allowed to fester for long and their intentions were valid
and solid. Unfortunately, there was some contention in the XHTML2
working group. The combination of failed communication on how and why
to transition from HTML to XHTML in combination with the unrelated
nature of XHTML2 and its infighting made people worry.
The marketing interference that allowed the web to crash regressed with
the web crash, but it did not die. It was reviving during this period
as well. Let's not forget that marketing motivations give dick about
technology concerns. Marketing motivations are about instant
gratification. All flavors of XHTML, especially XHTML2, were an
abomination to instant gratification. XHTML2 would eventually be killed
for a single draft was published. This fear and disgust lead to the
establishment of separate standards body whose interests were aligned
with moving HTML forward in the nature of instant gratification
silliness. This new group would call itself WHATWG and would carry the
marketing torch forward.
The WHATWG was united, because their motivations were simple even if
their visions of the technology were ambitious, essentially to make it
easier for developers to make things pretty, interactive, and reduce
complexity around media integration. The WHATWG was also successful,
because the web began to contract since the crash. There were fewer
major players around and each had a specific set of priorities that were
more and more inalignment.
The web is a media channel and its primary business is advertising.
Web businesses that make money from advertising tend to be significantly
larger than web businesses that make money from goods or services. As a
result the priorties of the web would eventually become the priorities
of media and advertising distribution. For instance why did JavaScript
become much faster in the browser? The answer is because Google, an
advertising company, made it a priority to release a web browser that
was significantly faster at processing JavaScript. To compete other
browsers would need to become 20 to 30 times faster to keep up. This is
important because JavaScript is the primary means by which advertisement
metrics are measured, which is the basis of Google's revenue.
Since HTML5 is a marketing friendly specification it allows a lax
syntax. Browser vendors are economically justified to spend more money
writing more complex parsing mechanisms against sloppy markup, because
it allows more rapid developement by which media is published so as to
allow deeper penetration of advertising. This is economically qualified
because all of the 5 major web browsers available now are primarily
funded from advertising revenue. Unfortunately, this is nothing but
cost for anybody else that want's to write a parser and is limiting or
harmful to any later interpretation of structured data. The result is
a lack of regard for the technology and the rise of hidden costs with
limits upon technology innovation within the given medium.
This is why HTML syntax continues to be shit. The only solution is to
propose an alternate and technologically superior communication medium
that technologically emphasizes a decentralization of contracting market
concerns.
For natural parsing the quotes aren't necessary in the first place.
Regarding case, HTML elements are reserved regardless of case; for example, you can't define your own DiV or Div.
HTML is a markup language where speed and simplicity is a greater priority than consistency.
While arguable, this matters greatly to search engines; documents with quoted attributes and any kind of error are very expensive to process. It's funny -- the quoted example in HTML docs has 'be evil' in quotes; as to say that, not using quotes is not being evil.
Better that the spec allows it then it forbids it, everyone does it anyway, and browsers have to error correct.
XHTML never really took off, not least because MSIE never supported it (pretending it is HTML by sending a text/html content type not withstanding).
Honestly, your question answers itself. "We have two different specs." Each spec addresses a different level of conformance, and they do so for a reason. As much as we might loathe the notion of "backwards compatibility," it's a burden we have to bear, and HTML5 is far better at maintaining it than XHTML5 will ever be.
I'm building a site right now, so far I've painfully forced everything to be compliant and it looks pretty much the same across browsers. However, I'm starting to implement some third party/free javascripts which do things like add attributes (eg. order=2). I could work around this but it's a pain, and I'm starting to lose my principals of making sure everything is valid. Really, is there any point to working around something like this? I got the HTMLValidator plugin for firefox, and looking at most major sites (including this one, google, etc.), they aren't valid XHTML or HTML.
The validation is useful to determine when things are failing to meet standards you presumably agree with. If you are purposefully using a tool that specifically adds something not in the validation standards, obviously that does not break your personal standards agreement.
This discussion gets much more difficult if you have a boss or a client who believes everything should return the green light, as you'll have to explain the above to them and convince them it's not simply you being lazy.
That said, be sure it's not simply be a case of you being lazy. While the validators may annoyingly constantly bring up every instance of the third party attribute, that doesn't invalidate (ha) the other validation errors they're mentioning. It's often worth scanning through as a means of double-checking your work.
Standards compliance is about increasing the chance that your page will work in the browsers you don't test against. This includes screen readers, and the next update of the browsers you do test against, and browsers which you do test against but which have been configured in unexpected ways by the user.
Validating doesn't guarantee you anything, since it's possible for your page to validate but still be sufficiently ambiguous that it won't behave the way you want it to on some browser some day.
However, if your page does validate, you at least have the force of the XHTML spec saying how it should behave. If it doesn't validate, all you have is a bunch of informal conventions between browser writers.
It's probably better to write valid HTML 3 than invalid XHTML, if there's something you want to do which is allowed in one but not the other.
If you're planning on taking advantage of XHTML as XML, then it's worth it to make your pages valid and well formed. Otherwise, plain old semantic HTML is probably want you want. Either way, the needs of your audience outweigh the needs of a validator.
I have yet to experience an instance where the addition of a non-standard attribute has caused a rendering issue in any browser.
Don't try to work around those non-standard attributes. Validators are handy as tools to double check your code for unintentional mistakes, but as we all know, even fully valid xhtml will not always render consistently across browsers. There are many times when design decisions require us to use browser specific (and non-standard) hacks to achieve an effect. This is the life of a web developer as evidenced by the number of technology driving sites (google, yahoo, etc.) that do not validate.
Just keep in mind that the XHTML tag renders differently in most browsers than not having it. The DOCTYPE attribute determines what mode the browser renders in and dictates what is and isn't allowed. If you stray from the XHTML compliance just be sure to retest in all browsers.
Personally I stick with the latest standards whenever possible, but you have to weigh time/money against compliance for sure and it comes down to personal preference for most.
As far as browsers are concerned, XHTML compliance is pointless in that:
Browsers don't have XHTML parsers. They have non-version-specific, web-compatible HTML parsers that build a DOM around the http://www.w3.org/1999/xhtml namespace.
Some browsers that have XML parsers can treat XHTML markup served as application/xhtml+xml as XML. This will take the XML and give default HTML style and behavior to elements in the http://www.w3.org/1999/xhtml namespace. But, as far as parsing goes, it has nothing to do with XHTML. XML parsing rules are followed, not some XHTML DTD's rules.
So, when you use XHTML markup, you're giving something alien to browsers and seeing if it comes out as you intend. The thing is, you can do this with any markup. If it renders as intended and produces the correct DOM, you're doing pretty good. You just have to make sure to keep DOCTYPE switching in mind and make sure you're not relying on a browser bug (so things don't fall apart in browsers that don't have the bug).
What XHTML compliance is good for is syntax checking (by validating) to see if the markup is well formed. This helps avoid parsing bugs. Of course, this can be done with HTML also, so there's nothing special about XHTML in this case. Either way, you still have to test in browsers and hope browser vendors make awesome HTML parsers that can accept all kinds of crap.
What's not pointless is trying to conform to what browsers expect. HTML5 helps with this big time. And, speaking of HTML5, you can define custom attributes all you want. Just prefix them with data-, as in <p data-order="This is a valid, custom attribute.">test</p>.
Being HTML Valid is usually a help for both of you and the browser rendering engine. The less quirks the browsers have to deal with, the more they can focus on adding new features. The more strict you are, the less time you'll spend time wondering why this f##cking proprietary tag does not work in the other browsers.
On the other hand, XHTML is, IMHO, more pointless, except if you plan to integrate it within some XML document. As IE still does not recognize it, it's pretty useless to stay stick with.
I think writing "valid code" is important, simply because you're setting an example by following the rules. If every developer had written code for Fx, Safari and Opera, I think IE had to "start following the rules" sooner than with version 8.
I try write compliant code most of the time weighing the time/cost vs the needs of the audience in all cases but one. Where you code needs to be 503 compliant, it is in your best interest and the interest of your audience to write compliant code. I've come across a bunch of screen readers that blow up when the code is even slightly off.
Like the majority of posters said, it's really all about what your audience needs.
It's not pointless by any means, but there is plenty of justification for breaking it. During the initial stages of CSS development it's very useful for diagnosing browser issues if your markup is valid. Beyond that, if you want to do something and you feel the most appropriate method is to break the validation, that's usually ok.
An alternative to using custom attributes is to make use of the 'rel' attribute, for an example see Litebox (and its kin).
Sure, you could always just go ahead and write it in the way you want, making sure that at minimum it works. Of course, we've already suffered this mentality and have witnessed its output, Internet Explorer 6.
I am a big fan of the Mike Davidson approach to standards-oriented development.
Just because you can validate your code doesn’t mean you are better than anybody else. Heck, it doesn’t even necessarily mean you write better code than anybody else. Someone who can write a banking application entirely in Flash is a better coder than you. Someone who can integrate third-party code into a complicated publishing environment is a better coder than you. Think of validation as using picture perfect grammar; it helps you get your ideas across and is a sign of a good education, but it isn’t nearly as important as the ideas and concepts you think of and subsequently communicate. The most charismatic and possibly smartest person I’ve ever worked for was from the South and used the word “ain’t” quite regularly. It didn’t make him any less smart, and, in fact, it made him more memorable. So all I’m saying is there are plenty of things to judge someone on… validation is one of them, but certainly not the most important.
A lot of people misunderstand this post to mean that we shouldn't code to standards. We should, obviously, but it's not something that should even really be thought about. The validation army will always decry those that do not validate, but validation means so much more than valid code.
So, don't lose your principles, but remember that if you follow the standards you're a lot less likely to end up in the deep-end of issues in the future. The content you're trying to provide is far more important than how it is displayed.