Why validate?

[Ganesh J Acharya]

Wanted to discuss this one for a very long time.

Why validate when most browsers ignore errors in an HTML, XHTML
documents?

[idle]

On Wed, 7 Dec 2011 11:21:13 -0800 (PST), Ganesh J Acharya wrote in
comp.infosystems.www.authoring.stylesheets,alt.html,alt.html.critique,comp.infosystems.www.authoring.html:

> Wanted to discuss this one for a very long time.
>
> Why validate when most browsers ignore errors in an HTML, XHTML
> documents?

It's a good basis for finding things that break things ;)
In a nutshell.
http://validator.w3.org/docs/why.html

--
idle
http://www.youtube.com/watch?v=VWvLF4z_W8M

[Jonathan N. Little]

Browsers don't *ignore* errors, they *try* to "correct" the errors by
guessing what you meant with your poor markup...however each browser's
"guesses" may come to different conclusions.

Strange that some web designer feel that do not need to know their
craft? You would you feel about your doctor if he had that attitude? Or
carpenter, plumber, or <substitute any professional>?

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Beauregard T. Shagnasty]

Ganesh J Acharya massively cross-posted:

> Wanted to discuss this one for a very long time.
>
> Why validate when most browsers ignore errors in an HTML, XHTML
> documents?

Have you no pride in your work? Would you build a car with no piston in
the number-three hole? A square wheel instead of a round one?

(XHTML is a dead-end. Either use HTML 4.01 Strict, or move along to
HTML5 .)

--
-bts
-This space for rent, but the price is high

[SAZ]

In article <784c5497-d11b-43d3-9b1f-381df9b39799
@q16g2000yqn.googlegroups.com>, ganeshj...@gmail.com says...

>
> Wanted to discuss this one for a very long time.
>
> Why validate when most browsers ignore errors in an HTML, XHTML
> documents?

Very simple answers:

1) Validation shows you are a professional that cares about his/her work
2) The website may work in *most* browsers today, but it might not work
tomorrow

[Ben C]

They don't. They ignore some and "fix" others (guessing often wrong and
differently in different browsers what you meant). If you validate
against the standard DTDs it's true you will have to fix a bunch of
things that don't really matter, practically speaking, for most
purposes, but it may also catch things that would otherwise have taken
you much longer to track down. So overall it usually saves you time.

[tlvp]

Why brush your teeth, when most communication is via email?
Why spell-check, when most correspondents can't spell anyway?
Why distinguish between milligrams and micrograms, when both
are abbreviated mg anyway?
Why check for oncoming traffic when you cross the street, if
drivers must give you the right of way in any event?

Or perhaps when I order ham and eggs in my thick German accent,
I should gratefully accept the letters M and X placed before me
by my puzzled waitress?

Perhaps if browsers truly *did* ignore errors in HTML the world
would be better off -- web designers would have to get their HTML
right in order to see anything. Older versions of NN had that gift:
leave off the final </body> and they wouldn't know which lines of
HTML to be trying to render, hence would render precisely nothing.

These days browsers are designed so as to seem to be making intelligent
guesses at just what valid HTML a given piece of invalid HTML might be
trying to convey -- but they can be wrong in a remarkable variety of
ways, not all of them ways that you might approve of.

Alas, none of us is really playing a good Krishna to your Arjuna
in this web page chariot pulled into the HTML fray. If we were,
you wouldn't need to ask, but would see it's simply your duty to
be sure your HTML is both valid and fit for the purpose intended.

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[Denis McMahon]

On Wed, 07 Dec 2011 11:21:13 -0800, Ganesh J Acharya wrote:

> Why validate when most browsers ignore errors in an HTML, XHTML
> documents?

Browsers don't all ignore errors.

Some, perhaps even most browsers try and guess what you meant. Sometimes
this works, sometimes it doesn't.

An occasional poster here had a problem. His document repeated the same
markup errors many times. The browsers tried to guess what he meant, and
generally got it right until his incorrect markup caused so much invalid
nesting of elements that the browsers were overwhelmed and failed to
display the pages the way he wanted.

A browser author would be within their rights to just ignore any invalid
markup, discarding attributes and even elements which were incorrect.
Validation gives a reasonable degree of confidence that most browsers
will probably display your page more or less as you intended, rather than
by using the individual rendering engines' authors' guesses about what to
do with various errors.

Rgds

Denis McMahon

[David E. Ross]

In your prior thread in this newsgroup, I suggested that you read my
<http://www.rossde.com/internet/Webdevelopers.html>. Did you? Did you
pay attention in the sections titled "Why Validate Web Pages?" and
"Standards: Why and How".

Did you get the point of the Bizarro cartoon on that page? As I state
to the left of that cartoon:
> A browser can only do what we tell it to do. What a Web developer
> wants must be expressed according to the standards. Only then will
> "tell" = "want" without regard for what brand of browser is used.
> Otherwise, there may be significant differences between how the
> developer wants a Web page to appear and what his page tells my
> browser to display.


Whether you have followed the standards is best determined by validating
the HTML file.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., the government)
snooping into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>

[Ganesh J Acharya]

On Dec 8, 6:19 am, "David E. Ross" <nob...@nowhere.invalid> wrote:
> On 12/7/11 11:21 AM, Ganesh J Acharya wrote:
>
> > Wanted to discuss this one for a very long time.
>
> > Why validate when most browsers ignore errors in an HTML, XHTML
> > documents?
>
> In your prior thread in this newsgroup, I suggested that you read my
> <http://www.rossde.com/internet/Webdevelopers.html>.  Did you?  Did you
> pay attention in the sections titled "Why Validate Web Pages?" and
> "Standards: Why and How".
>
> Did you get the point of the Bizarro cartoon on that page?  As I state
> to the left of that cartoon:
>

Is there a resource that discuss the practical accessibility issues?

E.g.
What would happen when using a non standard approach with each error
raised...

I had big argument with someone before, the person had asked me the
following

"what is the point spending huge amount of money when it does not
matter in terms of most users?"
Most browsers comply the non standard approach.

In business world people count everything in terms of investments. And
a website in the end is a business investment :(

[Beauregard T. Shagnasty]

Ganesh J Acharya wrote:

> Is there a resource that discuss the practical accessibility issues?

You're using Google... what did it say? Here's one of the first hits
using your sentence above:

http://websitetips.com/accessibility/tutorials/

> E.g.
> What would happen when using a non standard approach with each error
> raised...

I'd say that depends upon the authors of each browser.

> I had big argument with someone before, the person had asked me the
> following
>
> "what is the point spending huge amount of money when it does not matter
> in terms of most users?"
> Most browsers comply the non standard approach.

No, they don't follow "non-standards." They follow *standards* and then
attempt to *error-correct* for non-valid code. Note that all browsers
follow the standards, but each are free to interpret errors however they
see fit.

> In business world people count everything in terms of investments. And a
> website in the end is a business investment :(

..and therefore, it seems, should be done correctly.

In the time you've spent here arguing against following standards, you
could have fixed a dozen web sites.

[Ganesh J Acharya]

On Dec 8, 8:00 am, "Beauregard T. Shagnasty"

<a.nony.m...@example.invalid> wrote:
> Ganesh J Acharya wrote:
> > Is there a resource that discuss the practical accessibility issues?
>
> You're using Google... what did it say?  Here's one of the first hits
> using your sentence above:
>
> http://websitetips.com/accessibility/tutorials/
>
> > E.g.
> > What would happen when using a non standard approach with each error
> > raised...
>
> I'd say that depends upon the authors of each browser.

Is there a study already done, and is someone here aware about it?

[Ganesh J Acharya]

On Dec 8, 8:00 am, "Beauregard T. Shagnasty"
<a.nony.m...@example.invalid> wrote:

I need these arguments to get those dozen websites at first :-)

[Beauregard T. Shagnasty]

Google consists of more than the Google Groups interface you're using
instead of a real newsreader. Try entering this in the search engine part
of Google:

list of standards compliant browsers

It will turn up enough information to keep you busy until the next lunar
eclipse.

[Beauregard T. Shagnasty]

Ganesh J Acharya wrote:

> "Beauregard T. Shagnasty" wrote:
>> In the time you've spent here arguing against following standards, you
>> could have fixed a dozen web sites.
>
> I need these arguments to get those dozen websites at first :-)

If you would just write valid code to begin with, there isn't anything
further you need to do. (loosely speaking, of course)

[tlvp]

On Wed, 7 Dec 2011 18:41:45 -0800 (PST), Ganesh J Acharya wrote:

> What would happen when using a non standard approach with each error
> raised...

Why would you want to waste time and money developing non standard
approaches for each error raised, when it is so much easier and
practical and economical simply to root out errors at the outset?

> I had big argument with someone before, the person had asked me the
> following
>
> "what is the point spending huge amount of money when it does not
> matter in terms of most users?"

Because it really *does* matter to most users, hence it's far *less*
costly than the alternative :-) .

> Most browsers comply the non standard approach.

I cannot validate the grammar of this seeming sentence. Is "comply"
spelled correctly? Does it stand for the familiar intransitive verb
with that spelling? Are you aware you are using it as if it were a
*transitive* verb? What exactly have you in mind by the phrase
"the non standard approach", and what have you in mind when you say
most browsers *comply* it?

I can try to guess, and answer accordingly, but I'd almost surely be
guessing wrong, as English grammar renders the sentence devoid of meaning.

> In business world people count everything in terms of investments. And
> a website in the end is a business investment :(

A call center too is a business investment. In hopes of reducing their
call center expenditures, many North American businesses have chosen to
outsource their call centers to other countries, where wages are lower.
First they went to England and Ireland, then to India, later to the
Phillipines, and more recently even to lands of the former Soviet Union.

The call center investment gradually became smaller and smaller ... and,
as customers grew more and more frustrated at being unable to get any
satisfaction from these foreign staffed call centers, whose operatives
no longer even shared the linguistic habit of articles in daily speech,
these customers fell away from the companies whose short-sighted call
center strategies led to such foolish call center investments.

A number of North American companies have now learned that what they
saved on call center staffing costs they lost hundreds of times over
in lost clientele ... and they are now hard at work restoring domestic
call centers, at far greater cost than simply retaining them here in
the first place would have demanded, for now they have *no* experienced
old-timers in place, and must once again build up a critical mass of
experienced call center workers.

So: let not your treating a website as an investment cause you to believe
that the less spent on a website the better :-) . After all, the easiest
way to minimise what you spend on a website is to spend nothing at all,
by renouncing all desire for a website in the first place :-) .

But if you *do* want to do battle on the field of HTML, do it with
conviction, do it with enthusiasm, do it boldly, engage in it with
all your chakras, do it as if it were your duty to do it well, for
it *is* your duty to do it well. And validation is just the tip of
the "do it well" iceberg :-) .

HTH. Cheers, -- tlvp

[tlvp]

On Thu, 8 Dec 2011 03:00:43 +0000 (UTC), Beauregard T. Shagnasty wrote:

> ... You're using Google... what did it say? Here's one of the first hits

> using your sentence above:
>
> http://websitetips.com/accessibility/tutorials/

Alas, Beau, the first item here I tried the link to, that page's
suggestion of a site giving Canadian accessibilty requirements, viz.

http://evolt.org/node/28074 ,

gives me a 'site not found' error just at this moment. And

http://www.downforeveryoneorjustme.com/http://evolt.org/node/28074

agrees with me :-{ . (Sigh!) Oh well, cheers, -- tlvp

[Ganesh J Acharya]

On Dec 8, 8:40 am, "Beauregard T. Shagnasty"

Which is why I reached here, I certainly do not want to spend time

until the next lunar eclipse.

:-)

[dorayme]

In article <jbpbiv$q9m$4...@dont-email.me>,

"Beauregard T. Shagnasty" <a.non...@example.invalid> wrote:

> Ganesh J Acharya wrote:
>
> > "Beauregard T. Shagnasty" wrote:
> >> In the time you've spent here arguing against following standards, you
> >> could have fixed a dozen web sites.
> >
> > I need these arguments to get those dozen websites at first :-)
>
> If you would just write valid code to begin with, there isn't anything
> further you need to do. (loosely speaking, of course)

How loose?

--
dorayme

[Denis McMahon]

On Wed, 07 Dec 2011 18:41:45 -0800, Ganesh J Acharya wrote:

> I had big argument with someone before, the person had asked me the
> following
>
> "what is the point spending huge amount of money when it does not matter
> in terms of most users?"
> Most browsers comply the non standard approach.
>
> In business world people count everything in terms of investments. And a
> website in the end is a business investment :(

This one is easy. If your potential customers include people whose
browsers don't handle your errors gracefully, then you will lose sales to
competitors, because those potential customers will go to other websites
that they can actually use.

Rgds

Denis McMahon

[Denis McMahon]

It is not simply each error, but it is also the cumulative effect of the
specific sequence of errors concerned, and the effect that it has in each
of how ever many browsers you want to test in.

In other words, the only way to determine the effect of your broken html
on various browsers is to do your own study with every browser that might
be used to view it.

And then repeat the study for every update to any of those browsers, or
any new browsers that might get released.

Rgds

Denis McMahon

[Ganesh J Acharya]

Why was
"/>" instead of ">".

introduced?

[MG]

"Ganesh J Acharya" <ganeshj...@gmail.com> wrote in message
news:0e2ff83f-571c-4ce1...@v31g2000prg.googlegroups.com...

One is xhtml (for a limited number of elements).

The other is html

--
MG

[Ganesh J Acharya]

On Dec 8, 12:21 am, Ganesh J Acharya <ganeshjacha...@gmail.com> wrote:

Why "/>" instead of ">".

for tags like

<br> and <img>

was introduced?

[Ganesh J Acharya]

On Dec 8, 2:37 pm, "MG" <nos...@nospam.com> wrote:
> "Ganesh J Acharya" <ganeshjacha...@gmail.com> wrote in messagenews:0e2ff83f-571c-4ce1...@v31g2000prg.googlegroups.com...

> On Dec 8, 12:21 am, Ganesh J Acharya <ganeshjacha...@gmail.com> wrote:
>
> >> Wanted to discuss this one for a very long time.
>
> >> Why validate when most browsers ignore errors in an HTML, XHTML
> >> documents?
> > Why was
> > "/>" instead of ">".
>
> > introduced?
>
> One is xhtml (for a limited number of elements).
>
> The other is html

This reference says

http://www.personal.psu.edu/v23/presentations/accessibility/20errors/standards_errors.html#error8
"HTML 4.01 and XHTML require that all tags have end tags, including
tags like <br> (which would be <br /> - starting and closing in the
same tag)."

[Beauregard T. Shagnasty]

Ganesh J Acharya wrote:

> "Beauregard T. Shagnasty" wrote:

>> Google consists of more than the Google Groups interface you're using
>> instead of a real newsreader. Try entering this in the search engine
>> part of Google:
>>
>>    list of standards compliant browsers
>>
>> It will turn up enough information to keep you busy until the next
>> lunar eclipse.
>
> Which is why I reached here, I certainly do not want to spend time

So it would seem.

> until the next lunar eclipse.
>
> :-)

<http://en.wikipedia.org/wiki/December_2011_lunar_eclipse>

That is two days from now, and is why I chose to say that. If you can't
give a mere two days into learning how to write good web pages, there's
no hope for you.

[Beauregard T. Shagnasty]

Ganesh J Acharya wrote:

> Why "/>" instead of ">".
>
> for tags like
>
> <br> and <img>
>
> was introduced?

"/>" == XHTML

">" == HTML

You need to find a Basic Tutorial. Google can probably help you with that.

[Beauregard T. Shagnasty]

tlvp wrote:

> and more recently even to lands of the former Soviet Union.

You've talked to Peggy!! <lol>

[Ganesh J Acharya]

I have already given years into understanding all this, its not about
spending two days.
If I can reach my required solution in a couple of hours or sooner,
wouldn't spending 2 days be unwise?

[Ganesh J Acharya]

On Dec 8, 3:15 pm, "Beauregard T. Shagnasty"

<a.nony.m...@example.invalid> wrote:
> Ganesh J Acharya wrote:
> > Why  "/>" instead of ">".
>
> > for tags like
>
> > <br> and <img>
>
> > was introduced?
>
> "/>"  ==  XHTML
>
> ">"   ==  HTML
>
> You need to find a Basic Tutorial. Google can probably help you with that.

I already post the reason for my confusion

This reference says
http://www.personal.psu.edu/v23/presentations/accessibility/20errors/...

[Beauregard T. Shagnasty]

Ganesh J Acharya wrote:

> Beauregard T. Shagnasty wrote:

>> Ganesh J Acharya wrote:
>>> until the next lunar eclipse.
>>

>> <http://en.wikipedia.org/wiki/December_2011_lunar_eclipse>
>>
>> That is two days from now, and is why I chose to say that. If you can't
>> give a mere two days into learning how to write good web pages, there's
>> no hope for you.
>
> I have already given years into understanding all this,

Really? Somehow I had the idea you were a beginner.

> its not about spending two days.
> If I can reach my required solution in a couple of hours or sooner,
> wouldn't spending 2 days be unwise?

If you can't give two days towards learning your craft - possibly your
main source of income - then there is no hope.

It is like learning to drive. You can't become an expert in two hours; it
will take months/years until you can do it well.

[Ganesh J Acharya]

On Dec 8, 3:26 pm, "Beauregard T. Shagnasty"

<a.nony.m...@example.invalid> wrote:
> > its not about spending two days.
> > If I can reach my required solution in a couple of hours or sooner,
> > wouldn't spending 2 days be unwise?
>
> If you can't give two days towards learning your craft - possibly your
> main source of income - then there is no hope.
>
> It is like learning to drive. You can't become an expert in two hours; it
> will take months/years until you can do it well.

I certainly cannot become an expert in two days as well. But, I need
to reach a **ready research** first if that is available. As it will
save me from investing time discussing each and every aspect of the
errors those got raised.

I am doing all this since I know what further excuses will be given
when I will recommend corrections to the code.

[tlvp]

On Thu, 8 Dec 2011 02:18:16 -0800 (PST), Ganesh J Acharya wrote:

> ... If I can reach my required solution in a couple of hours or sooner,
> wouldn't spending 2 days be unwise? ...

You shoud rephrase that: "To the extent that I can reach my required
solution in a couple of hours, spending two days at it would be unwise."

But to what extent do you now believe you *can* reach that solution
in just a couple of hours? You've already spent days on it here ... :-) .

So I'd estimate the extent to which "spending two days at it would
be unwise" is vanishingly small :-) .

Cheers, -- tlvp

[tlvp]

On Thu, 8 Dec 2011 10:16:02 +0000 (UTC), Beauregard T. Shagnasty wrote:

> tlvp wrote:
>
>> and more recently even to lands of the former Soviet Union.
>
> You've talked to Peggy!! <lol>

Peggy? No: she was from Capetown. And a pleasure to listen to,
though she had trouble understanding me and my Yankee twang :-) .

It was *Maggy* who was from Uzbekistan, I believe, or Tadjikistan perhaps.

[tlvp]

Oversimplified. Anyway, not a definitive reference -- just an
interesting Pennsylvania State University internal publication,
with problems of its own, e.g., the erratum in the phrase
"... keep browsers from incorrectcly parsing ...".

Anyway: in HTML 4.01 the correct form is <br> while in
XHTML it is <br /> -- clearly you have to decide once and
for all, for one document, whether you propose to write it
to HTML or to XHTML standards, and declare it (in the
!DOCTYPE declaration) accordingly :-) .

HTH. Cheers, -- tlvp

[PS: Forgive me my typos, as I (try to)
forgive those who typo against me :-) .]

[Beauregard T. Shagnasty]

tlvp wrote:

> Beauregard T. Shagnasty wrote:
>> tlvp wrote:
>>> and more recently even to lands of the former Soviet Union.
>>
>> You've talked to Peggy!! <lol>
>
> Peggy? No: she was from Capetown. And a pleasure to listen to, though
> she had trouble understanding me and my Yankee twang :-) .
>
> It was *Maggy* who was from Uzbekistan, I believe, or Tadjikistan
> perhaps.

Nah. You probably don't watch television.

http://www.youtube.com/watch?v=GRLwKw9up3s
http://www.youtube.com/watch?v=lDgjOtcIkBM
http://www.youtube.com/watch?v=pV5-LcEmXls
and many more.

[tlvp]

On Thu, 8 Dec 2011 16:28:14 +0000 (UTC), Beauregard T. Shagnasty wrote:

> ...

> Nah. You probably don't watch television.

Right you are, Beau. And you won't get me started, no matter *how* much
I respect your HTML/CSS skills :-) .

>
> http://www.youtube.com/watch?v=GRLwKw9up3s
> http://www.youtube.com/watch?v=lDgjOtcIkBM
> http://www.youtube.com/watch?v=pV5-LcEmXls
> and many more.

[Jonathan N. Little]

And you have been informed as reason: It is not a good reference.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Chris F.A. Johnson]

That is incorrect. In XHTML, all tags must have end tags (or be
self-closing with />).

In HTML many elements do not need closing tags. Even some of the
opening tags are optional (HTML, HEAD, BODY).

--
Chris F.A. Johnson
<http://torontowebdesign.cfaj.ca/>

[David E. Ross]

That reference is NOT as authoritative as the W3C specification.
> The World Wide Web Consortium (W3C) is an international community
> where Member organizations, a full-time staff, and the public work
> together to develop Web standards.
"Member organizations" includes Microsoft, Mozilla, Google, Apple,
Chinese Academy of Sciences, Cisco, etc. (For the full list, see
<http://www.w3.org/Consortium/Member/List>.) W3C is the organization
that is generally recognized as the authority on HTML, XHTML, and CSS.

The W3C specification for HTML 4.01 says that end-tags are often not
required. At <http://www.w3.org/TR/REC-html40/index/elements.html>, the
chart clearly indicates an end-tag is forbidden for <hr> and <img> in
HTML 4.01. The complete HTML 4.01 specification begins with
<http://www.w3.org/TR/REC-html40/>; it is the ONLY HTML 4.01 reference I
use and should be your only one, too (even if you rely on tutorials
elsewhere).

As for XHTML, implementation was not successful in all current browsers.
The general suggestion has been to avoid it.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., the government)
snooping into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>

[Ganesh J Acharya]

On Dec 8, 2:37 pm, "MG" <nos...@nospam.com> wrote:

> "Ganesh J Acharya" <ganeshjacha...@gmail.com> wrote in messagenews:0e2ff83f-571c-4ce1...@v31g2000prg.googlegroups.com...

> On Dec 8, 12:21 am, Ganesh J Acharya <ganeshjacha...@gmail.com> wrote:
>
> >> Wanted to discuss this one for a very long time.
>
> >> Why validate when most browsers ignore errors in an HTML, XHTML
> >> documents?
> > Why was
> > "/>" instead of ">".

Again, why XHTML considered "/>" instead of ">"?

[tlvp]

In my limited understanding, it's not a blanket XHTML decision to
use "/>" instead of ">" -- it's only using <tag-name /> instead of
<tag-name></tag-name> for tags not enclosing any content
(like br or img or hr or META).

If I've got any of that wrong, of course, I sure hope someone
better-informed than me steps up and sets us *both* straight :-) .

[Adrienne Boswell]

tlvp <mPiOsUcB...@att.net> wrote

XHTML is an application of XML, so it has to obey the rules of XML, which
means that all tags must be closed, and all tags and attributes must be
in lowercase.

HTML has elements whose tags must not be closed, eg: img, br, hr, meta,
link. In addition, there are elements that do not have to be closed,
such as p, td and others.

So the XHTML solution is for those elements which must not be closed to
have the slash at the end of the opening tag, thereby closing the
element.


--
Adrienne Boswell
Arbpen Web Site Design Services - http://www.cavalcade-of-coding.info/
The Good Plate - Fresh Gourmet Recipes - http://the-good-plate.com/
Please respond to the group so others can share

[tlvp]

On Sun, 11 Dec 2011 18:44:07 +0000 (UTC), Adrienne Boswell wrote:

> tlvp <mPiOsUcB...@att.net> wrote
>
>> On Sun, 11 Dec 2011 01:43:31 -0800 (PST), Ganesh J Acharya wrote:
>>

Thanks, Adrienne. Clear, comprehensible, and well-motivated.

Though, frankly, I myself, unlike our Ganesh, have always just been ready
simply to accept it as "one of those rules you gotta live with" :-) .

[Thomas 'PointedEars' Lahn]

Adrienne Boswell wrote:

[Fixed quotation]

> tlvp wrote:
>> Ganesh J Acharya wrote:

>>> Again, why XHTML considered "/>" instead of ">"?
>>
>> In my limited understanding, it's not a blanket XHTML decision to
>> use "/>" instead of ">" -- it's only using <tag-name /> instead of
>> <tag-name></tag-name> for tags not enclosing any content
>> (like br or img or hr or META).
>>
>> If I've got any of that wrong, of course, I sure hope someone
>> better-informed than me steps up and sets us *both* straight :-) .
>

> XHTML is an application of XML, so it has to obey the rules of XML, which
> means that all tags must be closed, and all tags and attributes must be
> in lowercase.

You should watch your terminology, as it reveals whether you know what you
are talking about. (It is surprising that you would reply in such a way
even about 4 hours after my very detailed posting on the matter. I was
under the impression that you were reading my postings, and receiving them
much faster. Is your newsfeed really that slow lately?)

That all *tags* must be *closed* follows from the SGML declarations of HTML
4 and XML [1, 2]. Because *closing* a *tag* means to use the TAGC (tag
close) delimiter. In HTML and XML that is declared (implicitly) to be `>'.
It corresponds with the STAGO (start tag open) delimiter, `<', and the ETAGO
(end tag open) delimiter, `</'.

What you *mean* instead is that _all XHTML/XML elements must have a start
tag and an end tag_ (unless the start tag indicates with `/>' that there is
no end tag, but see my other followup for details), and that _all element
type names_ are _case-sensitive_. By "coincidence", all element type names
are declared lowercase _in the XHTML DTDs_, *therefore* you must write
*those* lowercase in XHTML documents [3].

> HTML has elements whose tags must not be closed, eg: img, br, hr, meta,
> link. In addition, there are elements that do not have to be closed,
> such as p, td and others.

That would be "element types that have the content model EMPTY",
respectively. The proper element type names are IMG, BR, HR, META, LINK, P,
and TD, as you are discussion HTML 4 [4]. Where IMG, BR, HR, META and LINK
have the content model EMPTY (ibid.), *and* have their end-tag flag set to
`O'(mit), which means "forbidden" [5]. By contrast, the P and TD element
types have their end-tag flag set to `O', and they do not have the content
model EMPTY, which means that the end tag is optional and that they can have
content (ibid.). Other element types, like `A', do not have their end-tag
flag set (`-') and their content model is not EMPTY, so the end tag is
required for the corresponding elements (ibid.).

> So the XHTML solution is for those elements which must not be closed to

Elements which _have no content_

> have the slash at the end of the opening tag,

_start_ tag

> thereby closing the element.

_ending_ the element.


PointedEars
___________
[1] <http://www.w3.org/TR/html4/sgml/sgmldecl.html>
[2] <http://www.w3.org/TR/xhtml1/DTD/xhtml1.dcl>
[3] <http://www.w3.org/TR/xhtml1/#h-A1>
[4] <http://www.w3.org/TR/html401/sgml/dtd.html>
[5] <http://www.w3.org/TR/html401/intro/sgmltut.html>
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

Tim Streater wrote:

> XHTML is dead, I don't know why anyone is bothering discussing it.

Because it is _not_ dead.


F'up2 comp.infosystems.www.authoring.html

PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)

[Thomas 'PointedEars' Lahn]

Tim Streater wrote:

> XHTML is dead, I don't know why anyone is bothering discussing it.

Because it is _not_ dead.

<http://try.powermapper.com/demo/statsversions.aspx>

[dorayme]

In article
<timstreater-57D5...@news.individual.net>,

Tim Streater <timst...@greenbee.net> wrote:

> XHTML is dead, I don't know why anyone is bothering discussing it.

Hitler is dead but people will never stop discussing him.

--
dorayme

[Ganesh J Acharya]

On Dec 12, 2:54 am, tlvp <mPiOsUcB.EtLlL...@att.net> wrote:
> On Sun, 11 Dec 2011 18:44:07 +0000 (UTC), Adrienne Boswell wrote:

> > tlvp <mPiOsUcB.EtLlL...@att.net> wrote

I certainly need reasons, as decision making is more logical and
rational

[tlvp]

On Sun, 11 Dec 2011 22:43:57 -0800 (PST), Ganesh J Acharya wrote:

> On Dec 12, 2:54 am, tlvp <mPiOsUcB.EtLlL...@att.net> wrote:
>>

>> ... frankly, I myself, unlike our Ganesh, have always just been ready

>> simply to accept it as "one of those rules you gotta live with" :-) .
>
> I certainly need reasons, as decision making is more logical and
> rational

:-) You want "reasons" for every design decision in the development of
HTML or of XHTML before you'll consent to write valid HTML or XHTML code?

Do you want "reasons" for the choice of speed on each speed limit sign you
encounter on a highway before you consent to drive at that speed or slower?

(Sigh!) Cheers, -- tlvp

[Scott Bryce]

On 12/12/2011 3:16 PM, tlvp wrote:
> On Sun, 11 Dec 2011 22:43:57 -0800 (PST), Ganesh J Acharya wrote:
>> I certainly need reasons, as decision making is more logical and
>> rational
>
> :-) You want "reasons" for every design decision in the development
> of HTML or of XHTML before you'll consent to write valid HTML or
> XHTML code?

If I am reading his comments correctly, Ganesh is looking for arguments
he can give to potential clients to allow him to bill for the extra time
it will take him to write valid HTML. He wants to write valid HTML. His
clients don't want him to, because they expect it to cost them more, and
they don't see a good reason why they should pay extra for valid HTML.

Do I have that right?

[tlvp]

On Mon, 12 Dec 2011 15:33:12 -0700, Scott Bryce wrote:

> ...

> If I am reading his comments correctly, Ganesh is looking for arguments
> he can give to potential clients to allow him to bill for the extra time
> it will take him to write valid HTML. He wants to write valid HTML. His
> clients don't want him to, because they expect it to cost them more, and
> they don't see a good reason why they should pay extra for valid HTML.

If that's the situation, I've misread poor Ganesh rather badly,
treated him even worse, owe him my abject apologies on both counts,
and will now refrain from butting in any further.

> Do I have that right?

Probably so. Thanks for making me aware of it. And cheers, -- tlvp

[Jonathan N. Little]

Hmmm, you know the saying "You get what you paid for"?

#############################################
# Deziners-R-Us 'Half-ass coding, CHEAP!' #
#############################################

Now there's a banner to stand under ;-)

[Ganesh J Acharya]

On Dec 13, 3:33 am, Scott Bryce <sbr...@scottbryce.com> wrote:
> On 12/12/2011 3:16 PM, tlvp wrote:
>
> > On Sun, 11 Dec 2011 22:43:57 -0800 (PST), Ganesh J Acharya wrote:
> >> I certainly need reasons, as decision making is more logical and
> >> rational
>
> > :-) You want "reasons" for every design decision in the development
> > of HTML or of XHTML before you'll consent to write valid HTML or
> > XHTML code?
>

"before you'll consent"
I understand that's not necessary.

But, is knowing the answer to the problem not better than not knowing
it?

> If I am reading his comments correctly, Ganesh is looking for arguments
> he can give to potential clients to allow him to bill for the extra time
> it will take him to write valid HTML. He wants to write valid HTML. His
> clients don't want him to, because they expect it to cost them more, and
> they don't see a good reason why they should pay extra for valid HTML.
>

My client has already asked me the following
"Why should I spend more of validating my HTML code, I see no good
reason when my code works?" etc

Knowing perfect answer is easier to convince them to validate.

[tlvp]

On Mon, 12 Dec 2011 19:42:38 -0800 (PST), Ganesh J Acharya wrote:

> On Dec 13, 3:33 am, Scott Bryce <sbr...@scottbryce.com> wrote:
>> On 12/12/2011 3:16 PM, tlvp wrote:
>>
>>> On Sun, 11 Dec 2011 22:43:57 -0800 (PST), Ganesh J Acharya wrote:
>>>> I certainly need reasons, as decision making is more logical and
>>>> rational
>>
>>> :-) You want "reasons" for every design decision in the development
>>> of HTML or of XHTML before you'll consent to write valid HTML or
>>> XHTML code?
>>
>
> "before you'll consent"
> I understand that's not necessary.
>
> But, is knowing the answer to the problem not better than not knowing
> it?

Only if it's a true problem :-) .

>> If I am reading his comments correctly, Ganesh is looking for arguments
>> he can give to potential clients to allow him to bill for the extra time
>> it will take him to write valid HTML. He wants to write valid HTML. His
>> clients don't want him to, because they expect it to cost them more, and
>> they don't see a good reason why they should pay extra for valid HTML.
>>
>
> My client has already asked me the following
> "Why should I spend more of validating my HTML code, I see no good
> reason when my code works?" etc

You need to make your client aware that what seems to work in one browser
on one computer at one resolution has less of a guarantee to work equally
well in another browser, on another computer, or at different resolution,
if it's *not* valid code than if it *is*. But perhaps your client is the
sort of person who is content to let a contract be drawn up and then to
sign it without having a lawyer on his side proof it for details. In that
event, your client is irremediable :-) .

> Knowing perfect answer is easier to convince them to validate.

Well, you must have enough ammunition from the good folks here by now :-) .

[Ed Mullen]

Ganesh J Acharya wrote:
> On Dec 8, 6:19 am, "David E. Ross"<nob...@nowhere.invalid> wrote:

>> On 12/7/11 11:21 AM, Ganesh J Acharya wrote:
>>
>>> Wanted to discuss this one for a very long time.
>>
>>> Why validate when most browsers ignore errors in an HTML, XHTML
>>> documents?
>>

>> In your prior thread in this newsgroup, I suggested that you read my
>> <http://www.rossde.com/internet/Webdevelopers.html>. Did you? Did you
>> pay attention in the sections titled "Why Validate Web Pages?" and
>> "Standards: Why and How".
>>
>> Did you get the point of the Bizarro cartoon on that page? As I state
>> to the left of that cartoon:
>>
>
> Is there a resource that discuss the practical accessibility issues?
>
> E.g.
> What would happen when using a non standard approach with each error
> raised...
>
> I had big argument with someone before, the person had asked me the
> following
>
> "what is the point spending huge amount of money when it does not
> matter in terms of most users?"
> Most browsers comply the non standard approach.
>
> In business world people count everything in terms of investments. And
> a website in the end is a business investment :(

Why is this a question for your clients?

It should simply be your practice to make compliant product and for it
to be transparent to your clients. The cost, if any, will be
transparent to them. No discussion, no extra charge for validation.
Just do it right as a matter of course.

I suppose you could specify in your quotes that your product will
validate and is compliant. And then offer to discount your work by
dropping that guarantee. Yeah, now there's a great marketing strategy.

"Okay, I'll give you 20% off if you don't want it to work."

--
Ed Mullen
http://edmullen.net/
Hard work pays off in the future. Laziness pays off now.

[Ganesh J Acharya]

On Dec 8, 12:21 am, Ganesh J Acharya <ganeshjacha...@gmail.com> wrote:
> Wanted to discuss this one for a very long time.
>
> Why validate when most browsers ignore errors in an HTML, XHTML
> documents?

Also it says here
"reduced legal risk"
http://www.w3.org/WAI/bcase/

Why is there a legal risk involved? What if the website is
inaccessible?

[Adrienne Boswell]

Ganesh J Acharya <ganeshj...@gmail.com> wrote

Well, gee, let's see...

2000 Olympics Website in 2000
Target settled in 2008
Jet Blue Airways in 2010
Disney in 2011

You see Ganesh, making a web site validate and making it accessible are
really not the hard. Just stick to a strict doctype, use semantic
markup, presentation via external CSS, and you should be fine.

Your most important visitor is blind and deaf, with no sense of humor,
but has millions of friends all over the world. If that visitor isn't
choking on invalid markup, and can full access your site, then that
visitor will broadcast that site all over the Internet. Do you know who
your most important visitor is yet?

[Ganesh J Acharya]

Agree about it. That is a great reason.

[Ben Bacarisse]

Adrienne Boswell <arb...@yahoo.com> writes:
<snip>

> Your most important visitor is blind and deaf, with no sense of humor,
> but has millions of friends all over the world. If that visitor isn't
> choking on invalid markup, and can full access your site, then that
> visitor will broadcast that site all over the Internet. Do you know who
> your most important visitor is yet?

I am not saying you are wrong, but there is lots of evidence that sites
with appalling presentational markup and hundreds of validation errors
do perfectly well. I keep seeing them right up there at the top of my
search results! [Quick check: last search I did, none of the top 10
results validated. The best was a Wikipedia page with only 3 errors.]

Are these sites "beating the odds" and getting good placement despite
validation errors, or are web crawlers, like browsers, forced to do
their best with junk markup in order to satisfy *their* customers?

--
Ben.

[Beauregard T. Shagnasty]

Ben Bacarisse wrote:

> Adrienne Boswell writes: <snip>

Well, I would venture that web crawlers (search engines) don't read
markup at all. They read the *content* of pages and don't care a whit
about valid or invalid HTML tags or CSS errors.

Only the search engine visitors (us humans) need deal with the markup,
once they choose to visit a presented result. If one's bad markup
prevents a human from access, then the problem surfaces.

--
-bts
-This space for rent, but the price is high

[Ganesh J Acharya]

On Dec 13, 6:47 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Adrienne Boswell <arb...@yahoo.com> writes:
>
> <snip>
>
> > Your most important visitor is blind and deaf, with no sense of humor,
> > but has millions of friends all over the world.  If that visitor isn't
> > choking on invalid markup, and can full access your site, then that
> > visitor will broadcast that site all over the Internet.  Do you know who
> > your most important visitor is yet?
>
> I am not saying you are wrong, but there is lots of evidence that sites
> with appalling presentational markup and hundreds of validation errors
> do perfectly well.

I agree, but aren't W3C recommendations standard guidelines those are
readily available which ever browser try to meet? Non standard methods
will always need extra hours of research to ensure problems are
tackled.

[Jonathan N. Little]

Ganesh J Acharya wrote:

> My client has already asked me the following
> "Why should I spend more of validating my HTML code, I see no good
> reason when my code works?" etc

Well if he wants a pure economic reason; if you spend the time now to
create a site with valid HTML markup it will lessen the chance he will
have to spend more in the future for a complete redo when the
browser-du-jour and its quirks falls out of fashion and the site breaks.
Ask anyone whose business site was "Designed for MSIE 4.0"

[Ben Bacarisse]

Ganesh J Acharya <ganeshj...@gmail.com> writes:

> On Dec 13, 6:47 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Adrienne Boswell <arb...@yahoo.com> writes:
>>
>> <snip>
>>
>> > Your most important visitor is blind and deaf, with no sense of humor,
>> > but has millions of friends all over the world.  If that visitor isn't
>> > choking on invalid markup, and can full access your site, then that
>> > visitor will broadcast that site all over the Internet.  Do you know who
>> > your most important visitor is yet?
>>
>> I am not saying you are wrong, but there is lots of evidence that sites
>> with appalling presentational markup and hundreds of validation errors
>> do perfectly well.
>
> I agree, but aren't W3C recommendations standard guidelines those are
> readily available which ever browser try to meet?

I don't think every browser tries to meet W3C recommendations. They try
to parse what's out there on the web. They both fail to handle some
standard markup and, at the same time, try hard to understand all sorts
of junk markup that comes along. Take this valid HTML 4.01 Strict
document:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title>HTML</title>
<p>
X<b/Y/Z<br>
X<b>Y</>Z<br/
X<b>Y</b>Z

Almost every browser in widespread use will fail to handle this as the
specification requires. That's probably a good thing. Understanding
the various tag minimisation options would probably interfere with the
more pressing issue of making sense of the web pages that are out there.

> Non standard methods
> will always need extra hours of research to ensure problems are
> tackled.

In general, yes, but there is a sort of "kitchen sink" HTML that a lot
of people write (probably through cut and paste, bad tutorials, and so
on) that so may browsers have had to deal with that, from an entirely
practical point of view, may be almost and even as portable as valid
HTML. This is partly what drives the "why should my code validate"
crowd.

I validate frequently as I work, mainly to help me. I don't have to
remember quite so much, or be quite so vigilant, if there is tool that
can that check my work. My feeling is that, by such tools, I can write
valid HTML faster than I can write invalid, but "mostly working" HTML.
I.e. for new pages there is a negative cost to writing valid HTML.

The case is much more murky for correcting existing invalid pages. I'd
consider every situation separately.

--
Ben.

[Scott Bryce]

On 12/13/2011 7:29 AM, Ganesh J Acharya wrote:

> Non standard methods will always need extra hours of research to
> ensure problems are tackled.

It looks to me like you already know what to tell your clients.

[tlvp]

Something else to think about: valid or not, for the sighted
visitor, legibility counts.

Here is an email I felt compelled to send to British Airways recently
because their HTML-formatted customer contact emails were so hard to read:

| The Executive Club / Avios emails you send are beautifully designed
| from an aesthetic perspective, but rather poor so far as legibility
| is concerned, since the choice of a pale grey font on a paler white
| background means contrast is so reduced as to make your text
| very difficult to read.
|
| But I presume your reasons for sending those emails are to convey
| to your recipients the content of that text, or?
|
| Please be advised hereby, and urge your HTML email designers to
| adjust accordingly the contrast between the text they use and the
| background that text resides upon.

Details: text-color was something like HTML silver, background-color
probably white, or something vaguely off-white. Bed-sheets and table
linens do well in such white-on-white, but *not* text. (You'd think
BA would know that, eh?)

FWIW. Cheers, -- tlvp

[dorayme]

In article <jc7nfa$oit$1...@dont-email.me>,

"Beauregard T. Shagnasty" <a.non...@example.invalid> wrote:

> If one's bad markup
> prevents a human from access, then the problem surfaces.

Not much of a one for commercial bottom-line enterprises, it
would take a critical mass of you form them to see it as a
problem.

--
dorayme

[Ben C]

Browsers these days are designed to render anything that's possible in
CSS, which is a much larger superset of valid HTML plus default
stylesheet.

For example, HTML says you can't put blocks inside inlines. But in CSS
you can.

For example:

<div style="display: inline">
<span style="display: block">foo</span>
</div>

is valid HTML and perfectly good CSS and browsers can render it
according to well-defined CSS rules.

A lot of HTML validity was about supposedly making rendering easier for
early pre-CSS browsers. A lot of it nowadays is just history. This is
invalid, believe it or not:

<blockquote>
Twas brillig and the slithy cove...
</blockquote>

It's supposed to be something like:

<blockquote>
<p>
Twas brillig and the slithy cove...
</p>
</blockquote>

But it's pretty obvious how to render the former, and any browser that
supports CSS would be unlikely to have any serious limitation preventing
it from doing the obvious thing.

This is why a great deal of HTML invalidity doesn't really matter much
and you get away with it (which is partly why a lot of people don't
bother). But some errors do matter a lot because they cause the browser
to construct a document tree very different from the one you were
expecting.

The time spent fixing things that will be harmless in practice is less
than the time saved by catching the occasional thing that really does
matter, so you should still validate.

[Ganesh J Acharya]

Figured that out during these discussions. The idea struck!

[Scott Bryce]

Back in the days when I took clients, I figured that if I made a
mistake, I owed the client a fix. If the client made the mistake, by not
being clear on the spec, they paid for the fix.

If they don't want valid HTML, then decide later that they need the HTML
to render correctly in XYZ browser, that is a change in the spec, and
they should pay you for the extra time.

Getting valid HTML to render correctly in IE may take extra time, and
should be worked into the original bid.

[David Stone]

In article <jcaieh$fe7$1...@dont-email.me>,

Wouldn't that last comment depend somewhat on which version(s) of IE
you were supporting? I only code fairly simple pages, but I can't think
of anything that's really "broken" my layouts except the IE 6 "white
space" bug with list items, and that is a fairly trivial fix which
doesn't require elaborate CSS hacks.

Valid html 4.01 and css 2.1 seem to give me excellent agreement
between IE7+, Firefox 3+, and Safari 3+ (as well as various
versions of Opera and Chrome when I've actually checked those too).

[Ganesh J Acharya]

On Dec 14, 9:21 pm, Scott Bryce <sbr...@scottbryce.com> wrote:
> On 12/14/2011 5:11 AM, Ganesh J Acharya wrote:
>
> > On Dec 13, 10:52 pm, Scott Bryce<sbr...@scottbryce.com>  wrote:
> >> On 12/13/2011 7:29 AM, Ganesh J Acharya wrote:
>
> >>> Non standard methods will always need extra hours of research to
> >>> ensure problems are tackled.
>
> >> It looks to me like you already know what to tell your clients.
>
> > Figured that out during these discussions. The idea struck!
>
> Back in the days when I took clients, I figured that if I made a
> mistake, I owed the client a fix.

As you improved in your learning curve did you not find you made a
mistake or your work was flawed all the while? So, did you keep
providing fixes all the time?

[Scott Bryce]

On 12/15/2011 2:04 AM, Ganesh J Acharya wrote:
> As you improved in your learning curve did you not find you made a
> mistake or your work was flawed all the while? So, did you keep
> providing fixes all the time?

I don't consider improving my skills to be a mistake. I don't owe a
client a free re-work just because I would do the job differently now.

Creating a HTML that does not render correctly because it does not
validate is a mistake on my part.

[Lambda]

Ganesh J Acharya <ganeshj...@gmail.com> writes:

Decision making is more logical and rational than what? Seems like you
apply the same mentality to both your English sentences and your HTML
code. In both cases you say something illogical and count on the
recipient to correct your logic mistakes.

As for why following the relevant standards is better, here are 2
reasons: support for minor (i.e. lesser used) browsers and
maintainability.

If the proper functioning of your website depends on random non-standard
quirks of major browsers then there is a good chance that your site will
not work on some minor browsers as supporting the documented standards is
much easier than supporting random undocumented quirks that the browsers
which you tested on happened to have. This means you are likely
to lose out on customers that use minor browsers if your code is broken.

Also, random non-stadard quirks tend to be transient and they thus often
disappear in browser updates. If your site depends on those quirks
then your site is much more likely to malfunction in newer versions of
browsers than it would if it followed proper standards. This means that
you will more often have to go back to your site to repair it.

And to make that worse, if you are sloppy enough to release broken code
then you probably will also be sloppy with organising your code. So when
one of the non-standard quirks that you depend on happens to be removed
from a browser that you want to support you will likely have a nightmare
sifting through your spagetti code and maye you will even wish that you
had to foresight to properly organise your code and to actually make it
correct.

Another disadvantage, one that is somewhat deeper, is that you cannot
care about your work if you write sloppy code. Illogical incorrect code
is ugly, and no one, not even who made it, can appreciate it. True
beautiful websites come exclusively from people who respect and love the
craft, and thus people always endeavor to write correct and organised
code. You clearly do not love your craft, you want your code to be
incorrect and ugly because you think that makes business sense. But the
irony is that people may notice that you are a sloppy worker. They may
notice your lack of knowledge (if you do not care enough to write
correct code then you certainly do not care enough to keep informed and
skilled in your craft of writing code). As long as you keep your current
mentality you will always be, at best, a mediocre worker with mediocre
results. The kind of worker you could replace with a college kid.
Learn to love your work or do something else that you can love!