I have a web site that, due to maintenance by several people, some of whom are
fairly clueless about HTML and CSS, etc. (notably me), has gotten to the point
where I'm pretty sure it's suffering from bit rot. Though the pages seem to
display okay under IE and FF, I really think it's time for an under-the-hood
cleaning. I recently received a copy of Molly Holzschlag's "Spring Into HTML
and CSS," and in the first chapter, she makes a big deal of producing pages
that validate cleanly. However, she doesn't explain why this is important,
e.g., doesn't say what the consequences of validation failure are.
I went to http://validator.w3.org/ and was unsurprised to see my home page
fail to validate. But then I got to playing around, and I found that the home
pages for none of the following validate, either: yahoo, ebay, google, artima,
and cnn. This makes me wonder whether validation is really something I need
to worry about. Morally, I'm all for standards, and given a choice between
pages that validate and those that do not, I'd choose validation, but I'm
going to have to find somebody else to do the work for me (somebody who DOES
know about HTML and CSS, etc.), and I'm worried that finding somebody who is
familiar with validation is going to be a lot harder and/or more expensive
than finding somebody who is not.
Can somebody please explain to me what the practical advantages of having
pages validate are? Also, I'm open to suggestions on who to consider hiring
to do the work at my site (which happens to be aristeia.com).
Thanks,
Scott 67  5219 
Gazing into my crystal ball I observed Scott Meyers <Us****@aristeia.com>
writing in news:MP************************@news.hevanet.com: Can somebody please explain to me what the practical advantages of
having pages validate are?
In the old days, before browsers did so much error correction, writing
valid code was important, because browsers would not render invalid
markup. For example, a missing </td> would make Netscape give a blank
page.
Now browsers do a lot of error correction, especially IE. Maybe one of
the reasons IE is so behind all the others is because there was so much
put in to do error correction. However, some browsers, if served
application text/xhtml+xml and the markup is not well formed, will
partially display with an error message.
For me it is a tool to discover why something is not rendering the way I
think it should. It is also a matter of pride, everything I produce is
valid. That might be because on new documents, I start with a strict
DOCType, and no presentational markup.
With that said, I have found that using valid, sematically correct,
presentationalless markup has made me and my clients get very good SERPs,
without resorting to any trickery.... <Mafia music>and now that I have
told you my secret, I'm going to have to kill you. ;-)</music>
--
Adrienne Boswell http://www.cavalcade-of-coding.info
Please respond to the group so others can share
Scott Meyers wrote: I recently received a copy of Molly Holzschlag's "Spring Into HTML
and CSS," and in the first chapter, she makes a big deal of producing
pages that validate cleanly. However, she doesn't explain why this
is important, e.g., doesn't say what the consequences of validation
failure are.
Error correction. If your documents validate, the onus is on the browser
to do the right thing. If they don't, then they'll guess at what you
meant. How well they'll guess is, erm, anyone's guess. :-D (Apologies
for the corny joke.)
then I got to playing around, and I found that the home pages for
none of the following validate, either: yahoo, ebay, google, artima,
and cnn.
Most pages don't. In the case of Yahoo, CNN, et. al., they likely have
substantial budgets for coders and testing. Do you?
This makes me wonder whether validation is really something I need to
worry about.
It is if you want durable www documents.
Morally, I'm all for standards,
Morals have nothing to do with it. Practically, validation is a useful tool.
http://www.cs.tut.fi/~jkorpela/html/validation.html
Can somebody please explain to me what the practical advantages of
having pages validate are?
I already did. Perhaps I could encourage you to consider the advantages
of googling the group archives? ;-)
--
Brian
On Sat, 13 Aug 2005 11:59:44 -0700, Scott Meyers <Us****@aristeia.com> wrote: I recently received a copy of Molly Holzschlag's "Spring Into HTML
and CSS," and in the first chapter, she makes a big deal of producing pages
that validate cleanly. However, she doesn't explain why this is important,
e.g., doesn't say what the consequences of validation failure are.
I went to http://validator.w3.org/ and was unsurprised to see my home page
fail to validate.
<http://aristeia.com/>
Can somebody please explain to me what the practical advantages of having
pages validate are?
Practical advantages of creating valid pages are, to me:
- all those who work on the pages work with the same standards and can take over
from each other with ease (assuming they are up to working with standards, that
is :-) );
- one knows for sure it is not an error in the code that is the cause of that
unwanted <*$+@@ &££@!!> rendering effect :-) ;
- years from now you as the author will still understand what you did when you
read back the code;
- I'm pretty sure valid code is a better garantee of getting your content across
the world wide web with its wide variaty of browsers (like text- and aural
browsers or screen readers, besides the more usual graphical ones), then is
invalid code, although to be really sure, one should also provide valid code
that is logical, has some semantics to it;
- I expect that valid code will not only work in the browsers of the present,
but will still work fine in browsers to come.
--
,-- --<--@ -- PretLetters: 'woest wyf', met vele interesses: ----------.
| weblog | http://home.wanadoo.nl/b.de.zoete/_private/weblog.html |
| webontwerp | http://home.wanadoo.nl/b.de.zoete/html/webontwerp.html |
|zweefvliegen | http://home.wanadoo.nl/b.de.zoete/html/vliegen.html |
`-------------------------------------------------- --<--@ ------------'
On Sat, 13 Aug 2005 20:02:22 GMT, Adrienne <ar********@sbcglobal.net> wrote: With that said, I have found that using valid, sematically correct,
presentationalless markup has made me and my clients get very good SERPs,
without resorting to any trickery....
Ah, yes. That too of course.
<Mafia music>and now that I have
told you my secret, I'm going to have to kill you. ;-)</music>
lol
--
,-- --<--@ -- PretLetters: 'woest wyf', met vele interesses: ----------.
| weblog | http://home.wanadoo.nl/b.de.zoete/_private/weblog.html |
| webontwerp | http://home.wanadoo.nl/b.de.zoete/html/webontwerp.html |
|zweefvliegen | http://home.wanadoo.nl/b.de.zoete/html/vliegen.html |
`-------------------------------------------------- --<--@ ------------'
Scott Meyers <Us****@aristeia.com> wrote: Can somebody please explain to me what the practical advantages of having
pages validate are?
How long is a bit of string?
aristeia.com
It's funny that you are a C++ specialist, normally programmers are
sticklers for correct syntax.
There are more pressing issues than validation that should be solved
first, such as:
1) If you specify one colour you need to specify them all. Currently my
default link colour is used, but legibility is very poor against the
green of the navigation section of your site.
2) Your frames cause problems, users cannot bookmark specific views,
search engine indexing is poor, orphaned pages (pages without a nav
section) to name a few.
3) Your documents contain very little if any structure, you should use
headings.
4) Some of your links attempt to open a new window/tab, this is really
bad form since it forces your preferences onto people who do *not* want
new windows/tabs to be opened.
--
Spartanicus
On Sat, 13 Aug 2005 20:02:22 GMT, Adrienne <ar********@sbcglobal.net>
wrote:
[...] In the old days, before browsers did so much error correction, writing
valid code was important, because browsers would not render invalid
markup. For example, a missing </td> would make Netscape give a blank
page.
Validation wouldn't have helped in that case anyway, since the closing
</td> is optional ;-)
Nick
--
Nick Theodorakis ni**************@hotmail.com
contact form: http://theodorakis.net/contact.html
On Sat, 13 Aug 2005 11:59:44 -0700, Scott Meyers <Us****@aristeia.com>
wrote: Can somebody please explain to me what the practical advantages of having
pages validate are?
Simplicity. "Valid" is a simple and objective status. "Invalid" may or
may not work - there is (very much so!) invalidity and invalidity. An
empty <div> will cause Tidy to whine, the _presence_ (yes, presence!) of
a title attribute will cause Dreamweaver to complain. You can have HTML
documents that have minor invalidities no browser will really fall over,
or they might be major things (like an unclosed <table>) that really do
blow things out of the water. Unless you're obsessive about keeping up
to date on browser foibles, it's impossible to really know how bad an
invalidity's effects will be.
But if you're valid, you're valid. No arguments about it (except of
course on Usenet)
On Sat, 13 Aug 2005 20:15:37 GMT, Brian wrote: then I got to playing around, and I found that the home pages for
none of the following validate, either: yahoo, ebay, google, artima,
and cnn.
Most pages don't. In the case of Yahoo, CNN, et. al., they likely have
substantial budgets for coders and testing. Do you?
I'm not sure I understand this comment. Given their budget for coders and
testers, I'd expect that they'd produce valid pages if validity were something
they found to be useful. This suggests that they do not find validity to be
something that carries its weight. However, I don't think you meant that.
Can you please clarify?
Scott
On Sat, 13 Aug 2005 22:18:50 +0200, Barbara de Zoete wrote: Practical advantages of creating valid pages are, to me:
- all those who work on the pages work with the same standards and can take over
from each other with ease (assuming they are up to working with standards, that
is :-) );
Do you have any sense for how common such knowledge is? My original
motivation for asking this question was that in my initial contact with a
prospective web site maintainer, I mentioned that one of the things I wanted
to do was upgrade my pages to the point where they validate, and her reply was
"I have reviewed your site and the source code. I see nothing wrong with your
source code at the moment, other than the frames." Given the context of the
exchange between us, I think this comment reflects her lack of familiarity
with validation rather than a judgement about whether validation is useful.
Hence my interest in whether validation is important enough for me to insist
on finding somebody who is familiar with it.
Scott
On Sat, 13 Aug 2005 20:22:00 GMT, Spartanicus wrote: It's funny that you are a C++ specialist, normally programmers are
sticklers for correct syntax.
Hence my moral support for standards :-) However, there is a lot of C++ code
that is written that deliberately does not obey standards;
standards-compliance is but one of a number of criteria that people take into
account when deciding how to approach a project. FWIW (nothing in this
newsgroup), I'd venture to guess that the vast majority of commerical C++
programs contain at least some technically invalid constructs. Virtually all
compilers accept them, so there's little incentive to fix them (or even to
avoid including them in future code). Given that so many big sites produce
pages that don't validate, it looks like there is a similar situation in
webpageville.
1) If you specify one colour you need to specify them all. Currently my
default link colour is used, but legibility is very poor against the
green of the navigation section of your site.
2) Your frames cause problems, users cannot bookmark specific views,
search engine indexing is poor, orphaned pages (pages without a nav
section) to name a few.
3) Your documents contain very little if any structure, you should use
headings.
4) Some of your links attempt to open a new window/tab, this is really
bad form since it forces your preferences onto people who do *not* want
new windows/tabs to be opened.
Thanks for your feedback. I appreciate it.
Some of the issues above are deliberate design decisions (e.g., relatively
little structure, opening new windows), some are not (e.g., color
specification, link legibility). Some of the deliberate decisions should
probably be reconsidered (e.g., opening new windows). As I said, the site has
just kind of evolved over the years, and it's time for somebody who knows what
they are doing to give it a tune-up.
As for frames, I hate them, too, but I don't know of any other way to make it
possible for the content area to scroll while the navigation area remains in
view. Then again, I'm a C++ weenie, not an HTML/CSS weenie. If there's
another way to achieve this effect, please tell me about it. I'm sure this is
well-trod ground in this newsgroup, so a link or likely set of search terms
would be fine.
Thanks,
Scott
Scott Meyers <Us****@aristeia.com> wrote: On Sat, 13 Aug 2005 20:15:37 GMT, Brian wrote:
In the case of Yahoo, CNN, et. al., they likely have
substantial budgets for coders and testing. Do you?
I'm not sure I understand this comment. Given their budget for coders and
testers, I'd expect that they'd produce valid pages if validity were something
they found to be useful.
Right.
This suggests that they do not find validity to be
something that carries its weight.
Well, more likely, that the net present value of paying a developer to
generate huge volumes of valid code isn't very high. Writing valid code
takes more skill and/or time than writing tag soup that generally works
alright. I imagine for most of these companies, "generally works
alright" is good enough, and they'd rather focus their efforts and
resources on compelling content, eye candy, and so on. After all, most
of their readers don't know or care if their pages are valid or not.
_But_, that doesn't change the fact that writing valid HTML and CSS is
future-proofing your pages. A large company may have the luxury -- if
and when they decide it's worth their while -- to devote a lot of
resources to an intense effort to clean up their HTML. A one- or
two-person operation generally does not have that luxury. So it makes
sense for a small operation to devote a bit of time upfront towards
writing good markup, because they odds of them having time and resources
to go back later to clean it up aren't good.
--
Joel.
On Sat, 13 Aug 2005, Scott Meyers wrote: But then I got to playing around, and I found that the home pages
for none of the following validate, either: yahoo, ebay, google,
artima, and cnn. This makes me wonder whether validation is really
something I need to worry about.
There are also plenty of commercial pages that don't work with
www-compatible browsers, but only with MSIE. Some of us have higher
standards.
Morally, I'm all for standards, and given a choice between pages
that validate and those that do not, I'd choose validation, but I'm
going to have to find somebody else to do the work for me (somebody
who DOES know about HTML and CSS, etc.),
As I happens, I know how to do that by hand, but, if I didn't, I have
a computer to help me to generate output that would be guaranteed
valid. Of course, there's far more to producing a good web page than
merely valid syntax, but a web page with invalid syntax is no better
than literature with lots of wrongly-spelled words, AFAICS.
Quite why those popular sites consider it advantageous to extrude
syntactically invalid stuff, I can't tell you - but I see no advantage
it in myself.
You can also be assured that when you have a problem and ask for
advice here, the only advice you're likely to get (aside from being
advised to fix your syntax errors and try again) will be from the kind
of sloppy and coudn't-care-less commentator who is prepared to spend
their time fiddling with someone else's invalid syntax. That kind of
advice tends to be worth even less than you paid for it, to be frank.
to do the work at my site (which happens to be aristeia.com).
___
/
FRAME: buttons
FRAME: main_body
This web page uses frames, but your browser doesn't support them.
\___
That site uses frames, but your author doesn't support them.
Scott Meyers wrote: As for frames, I hate them, too, but I don't know of any other way to make
it possible for the content area to scroll while the navigation area
remains in view.
So what if the navigation doesn't remain in view? Scrolling navigation works
for the vast majority of sites out here.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
On Sat, 13 Aug 2005 20:15:37 GMT, Brian
<us*****@julietremblay.com.invalid> wrote: Most pages don't. In the case of Yahoo, CNN, et. al., they likely have
substantial budgets for coders and testing. Do you?
Why would you think that ? 8-) I'm dealing commercially with two of
these "blue chips" right this week and their technical knowledge
borders on the negligible. I dealt with them both a year ago (very
similar project) and they were no better then. Although there are people
with a clue somewhere inside the organisation, they're such big
organisations that this is thoroughly diluted by pointy hair.
I'd add that neither of these are Google or Amazon (although of similar
scale). I've always found every technical contact at either of those two
to be spot-on.
On Sun, 14 Aug 2005 00:55:08 +0100, David Dorward wrote: So what if the navigation doesn't remain in view? Scrolling navigation works
for the vast majority of sites out here.
Yes, well, my experience has been that broken links work for the vast
majority of site out there, too, but I don't like them, either.
I happen to have a strong preference for navigational links that remain in
view, because the alternative doesn't make any sense to me. Scrolling
content doesn't change my navigational choices, so why should it change the
easy accessiblity of them? It seems to me that tying the scrolling of
navigational links to the scrolling of content -- two independent things --
is a usability concession made in the name of implementation
considerations. Not that this is necessarily an unjustifiable choice. I'm
frankly not knowledgable enough about the trade-offs to have a firm opinion
on the matter. What I do know is that I, myself, prefer navigational links
that remain in view when content scrolls, so I'm naturally inclined towards
implementation approaches that give me the behavior that I prefer. If
there are other implementation approaches to the same end, I'd love to know
about them. If there are drawbacks to frames that I am not aware of, I'd
like to know about those, too.
Spartanicus wrote:
Your frames cause problems, users cannot bookmark specific views, search
engine indexing is poor, orphaned pages (pages without a nav section) to
name a few.
I'm interpreting "your frames" as "frames in general" here. If there are
problems specific to my frames, again, I'd love to know about them. It's
my understanding that bookmarking pages at my site should work as users
expect, i.e., it should yield a bookmark that will reload the same frameset
with the same content inside. If it doesn't, something's broken, and I
need to have it fixed. I don't care about search engine indexing, and if I
interpret the comment about orphaned pages correctly, that's a site
management problem, not a usability problem. My understanding is that
using frames makes life more complicated for site designers, but if they
are careful, the usability experience of users (with browsers that support
frames) should not be degraded. If I'm mistaken here, please set me
straight.
One of the difficulties of this kind of thing is that I don't plan to do
the work myself, but as the guy writing the check for the work, I'll be
ultimately making the big decisions that will be implemented by whomever
does the actual coding. Which means that I have to educate myself on the
pros and cons of various approaches, especially because my first task is to
identify somebody who can do a good job for me. That, in turn, is
difficult, because I'll be interviewing people to determine their technical
skills in areas I don't myself understand.
Once I am working with somebody whose skills and judgement I respect, I can
lean on them for advice on the big decisions, but until then, I'm on my
own. Which is why I was originally trying to figure out how much weight I
should give to validation.
Scott
On Sun, 14 Aug 2005, Andy Dingley wrote: Why would you think that ? 8-) I'm dealing commercially with two
of these "blue chips" right this week and their technical knowledge
borders on the negligible.
Point taken ...
I'd add that neither of these are Google or Amazon (although of
similar scale). I've always found every technical contact at either
of those two to be spot-on.
So can *you* explain why they put pages onto the web that don't seem
to pass even syntax validation? This is, after all, a frequently
asked question by those who would prefer not to bother themselves with
syntax validation of their own pages, and it would be good to have
some kind of definite explanation for it. As I said in an earlier
f'up, I really have no idea: your remark that "Although there are
people with a clue somewhere inside the organisation, they're such big
organisations that this is thoroughly diluted by pointy hair" is well
taken, but I don't find it a particularly convincing explanation of
why they do it.
For myself, I treat syntax checking (formal validation of HTML, and
checking of CSS) in the same way as spell-checking of textual content:
a quality assurance step that should not be omitted from anything
serious that I'm putting my name to in public. I think you're close
to the same in that respect, no?
best regards
On Sun, 14 Aug 2005 08:58:48 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote: So can *you* explain why they put pages onto the web that don't seem
to pass even syntax validation?
Cluelessness. In every large tech organisation I've ever worked in
(including I'm ashamed to say, HP) there have been some people who
understood things, some who didn't, and an entire layer of people on the
middle who devoted their working lives to having the wrong people make
the decisions. I'm a contractor - an expensive resource who is brought
in at great cost to advise on one specific area of expertise, then whose
recommendations are ignoredin favour of some BMW-driver suit, On _every_
site this happens, not just the odd one.
Until recently, validation was also very much the exception rather than
the rule. It's not that important an issue for HTML - compare it to any
programming language, where a syntax error stops things dead. Invalid
HTML still works, it just may not work as well as it should,
Cluelessness. To quote Scott the OP, 'her reply was
"I have reviewed your site and the source code. I see nothing wrong with
your source code at the moment, other than the frames."
Incidentally, that was a rare valid use for nested <blockquote>s 8-)
Web "designers" are largely untaught, or worse they've been through CIW.
Recruitment policies takes no account of technical skills, they just
play "match the buzzword" with application names like Dreamweaver.
Someone skilled with a code editor will be rejected in favour of a
trained monkey with FP or DW knowledge, because the recruitment agent
knows no more than to ask "Have you used DW?"
C00lness. An invalid dancing penguin always trumps a valid readable
site. How may "web design how-tos" have you seen called "Build the
C00lest website ever" ? What sort of coding style are these teaching?
I think you're close to the same in that respect, no?
Largely. I'll break validation sometimes if I know what I've broken and
I don't care. <a target="_zoomimageviewer" ... > has a useful
side-effect if I'm opening repeated pop-up windows for the same purpose
and I want to re-use the same window for it.
Brian wrote:
Scott Meyers wrote:
I recently received a copy of Molly Holzschlag's "Spring Into HTML
and CSS," and in the first chapter, she makes a big deal of producing
pages that validate cleanly. However, she doesn't explain why this
is important, e.g., doesn't say what the consequences of validation
failure are.
Error correction. If your documents validate, the onus is on the browser
to do the right thing. If they don't, then they'll guess at what you
meant. How well they'll guess is, erm, anyone's guess. :-D (Apologies
for the corny joke.)
....and you have to guess about how future browsers will guess... :)
On Sun, 14 Aug 2005 12:23:25 +0100, Andy Dingley sent: Until recently, validation was also very much the exception rather than
the rule. It's not that important an issue for HTML - compare it to any
programming language, where a syntax error stops things dead. Invalid
HTML still works, it just may not work as well as it should,
Though the *BIG* problem with that is that one person's testing of invalid
HTML only shows how well their browser handles it. I've encountered
numerous seriously broken pages that presumably worked for the original
author, but are utterly useless to other people.
--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.
This message was sent without a virus, please destroy some files yourself.
Scott Meyers wrote: As for frames, I hate them, too, but I don't know of any other way to make it
possible for the content area to scroll while the navigation area remains in
view.
I'm constantly amazed (and dismayed) at the number of people who think
that having a (usually rather large) "navigation area" permanently
on-screen is a feature rather than a bug! Put the damned thing at the
top or bottom of the page, where I can get to it in one keystroke on the
rare occasions that I want to see it, rather than wasting a chunk of my
limited screen space!
Maybe all website designers have giant monitors on which they run a
browser full-screen, so they've got space to waste. I always have
multiple windows open, and never have enough screen real-estate
available -- so I get really pissed-off at the idiots who decide that
something which is rarely used is so important that I should be forced
to see it all the time.
If someone ever comes up with a tool which reliably and conveniently
recognizes and hides these abortions, I will be *so* glad...
Dave
Dave Anderson wrote:
I'm constantly amazed (and dismayed) at the number of people who think
that having a (usually rather large) "navigation area" permanently
on-screen is a feature rather than a bug! Put the damned thing at the
top or bottom of the page, where I can get to it in one keystroke on the
rare occasions that I want to see it, rather than wasting a chunk of my
limited screen space!
Maybe all website designers have giant monitors on which they run a
browser full-screen, so they've got space to waste. I always have
multiple windows open, and never have enough screen real-estate
available -- so I get really pissed-off at the idiots who decide that
something which is rarely used is so important that I should be forced
to see it all the time.
If someone ever comes up with a tool which reliably and conveniently
recognizes and hides these abortions, I will be *so* glad...
The Adblock third-part extension for Mozilla FireFox does a pretty
good job.
Scott Meyers wrote:
I have a web site that, due to maintenance by several people, some of whom are
fairly clueless about HTML and CSS, etc. (notably me), has gotten to the point
where I'm pretty sure it's suffering from bit rot. Though the pages seem to
display okay under IE and FF, I really think it's time for an under-the-hood
cleaning. I recently received a copy of Molly Holzschlag's "Spring Into HTML
and CSS," and in the first chapter, she makes a big deal of producing pages
that validate cleanly. However, she doesn't explain why this is important,
e.g., doesn't say what the consequences of validation failure are.
I went to http://validator.w3.org/ and was unsurprised to see my home page
fail to validate. But then I got to playing around, and I found that the home
pages for none of the following validate, either: yahoo, ebay, google, artima,
and cnn. This makes me wonder whether validation is really something I need
to worry about. Morally, I'm all for standards, and given a choice between
pages that validate and those that do not, I'd choose validation, but I'm
going to have to find somebody else to do the work for me (somebody who DOES
know about HTML and CSS, etc.), and I'm worried that finding somebody who is
familiar with validation is going to be a lot harder and/or more expensive
than finding somebody who is not.
Can somebody please explain to me what the practical advantages of having
pages validate are? Also, I'm open to suggestions on who to consider hiring
to do the work at my site (which happens to be aristeia.com).
According to one estimate, Internet Explorer (IE) reached a peak
market share of 88.0% of all browsers in March 2003. Since then,
it has declined to 73.5%. Other estimates might show IE still well
above 80% or even 90% of the market, but they all seem to agree
that IE's share is declining. My own sampling in April of this
year showed IE was the browser in 81% of the hits on 13 of my
eclectic Web pages. That means almost 20% of those who visited my
Web site were NOT using IE.
The point of all this is that you should design your Web pages for
viewing by ANY browser. To do that, you should design to the HTML
and CSS specifications and not to any specific browser at all. If
"It looks okay with IE" is your criterion, however, you have tied
yourself to a fading star.
Please see my
<URL:http://www.rossde.com/internet/Webdevelopers.html>. See also
<URL:http://www.anybrowser.org/campaign/index.html>.
If you are indeed a software professional, have a professional
attitude about this. Take pride in your work. Can you really be
proud of a home Web page that has 13 HTML errors? What does that
say about your professionalism and your computer expertise?
--
David E. Ross
<URL:http://www.rossde.com/>
I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.
On Sun, 14 Aug 2005 23:29:55 +0900, Tim <ti*@mail.localhost.invalid>
wrote: Though the *BIG* problem with that is that one person's testing of invalid
HTML only shows how well their browser handles it.
And this is why validation is so important.
It's impossible to "test" invalid HTML- you can only test "This HTML on
that browser". Although you can test invalid HTML, this inevitably has
to be a subjective test under one set of conditions "My computer, today,
with IE 7.0" The results of such a test are almost worthless for anyone
using a different combination.
Validation is objective, not subjective. The results won't always be
correct (IE box model), but at least there's a clearly pointing finger
at which is the culprit for getting it wrong. Making your valid layout
readable across all browsers still isn't easy, but it's a lot easier
than doing it for invalid code. IE's broken-ness for valid HTML is at
least reasonably described by previous developers -- its behaviour for
invalid code is an obscure minefield.
Dave Anderson wrote: If someone ever comes up with a tool which reliably and conveniently
recognizes and hides these abortions, I will be *so* glad...
FWIW, mod_accessibility offers a range of options for dealing with frames.
HTML has done better than that for more than a decade:
<link rel="foo" ...>. Ask your browser vendor why they
don't have a sensible implementation of this basic form
of non-intrusive navigation.
IMO the ideal implementation in a graphical browser would be
a popup menu of links built from the HTML. Of course it could
be presented in other ways, e.g. shown on-screen or activated
by a keystroke, but that should be a user preferences option.
--
Nick Kew
On Sun, 14 Aug 2005 11:06:45 -0400, Dave Anderson wrote: I'm constantly amazed (and dismayed) at the number of people who think
that having a (usually rather large) "navigation area" permanently
on-screen is a feature rather than a bug! Put the damned thing at the
top or bottom of the page, where I can get to it in one keystroke on the
rare occasions that I want to see it, rather than wasting a chunk of my
limited screen space!
Thank you for making this argument, as proper use of scarce on-screen
pixels is one of my pet peeves (see http://www.aristeia.com/TKP/webpages.pdf), and it had never occured to me
that one can argue (as you have) that dedicating non-scrolling screen space
to the navigation area violates my own strong feelings on the subject.
I'll have to think about this further. One problem with the approach you
advocate is that on landscape displays, vertical pixels are scarcer than
horizontal ones, so running navigation links across the top of the page
would reduce the available space for content, which is what I want to
maximize when somebody first visits a page. Still, your argument is a good
one.
Scott
On Sun, 14 Aug 2005 12:32:14 -0700, David Ross wrote: The point of all this is that you should design your Web pages for
viewing by ANY browser. To do that, you should design to the HTML
and CSS specifications and not to any specific browser at all. If
"It looks okay with IE" is your criterion, however, you have tied
yourself to a fading star.
FWIW, I noted in my post that I currently check page output under IE and FF
(which just means I play around with modified pages with looking for
obvious display problems), and at the time I had the site orignally set up
in its current format (2000), one of the things I told the people doing the
work was that I expected it to view correctly on Windows, Mac, and Unix and
under at least IE, Netscape, and Opera. I plan to impose similar
constraints for this makeover.
Please see my
<URL:http://www.rossde.com/internet/Webdevelopers.html>.
Nifty research, thanks. I see that designing/testing only for IE is a sore
point of yours :-) BTW, how did you arrive at your candidate list of site
developers?
If you are indeed a software professional, have a professional
attitude about this. Take pride in your work. Can you really be
proud of a home Web page that has 13 HTML errors? What does that
say about your professionalism and your computer expertise?
If I claimed to be a web developer or to know a lot about web technologies,
it would say a lot. But I don't claim to be a web developer or to know
about such things. Perhaps it says that the people I hired to do my site
in 2000 were inept, though, to be honest, I don't know whether a site
designed to validate in 2000 would still validate today.
As I've mentioned elsewhere in this thread, my fundamental goal is to try
to educate myself enough about current web site design and implementation
issues to choose somebody to work on my site. The original question was
whether familiarity with or a commitment to validation was something I
should insist on when screening prospective web site maintainers. To be
honest, I'm still undecided on that. Your argument above is the moral one
and, as I've noted elsewhere, I'm fully behind the moral argument. But my
experience in 2000 was that it was very difficult to find *anybody* who was
willing to do a makeover on a small web site that would work across
browsers for a reasonable amount of money (which I'll arbitrarily define
as, say, under $5000), and your data don't make it look like adding a
validation requirement is going to make the job any easier. Add to that
the observation that most web sites don't seem to care enough above
validation to actually do anything about it, and morality begins to crumble
in the face of practicality.
If you know of a good way for me to identify candidate persons or firms for
the work I'm looking to have done on my site who are committed to
validation, I very much welcome your comments.
Scott
Scott Meyers wrote [in part]: FWIW, I noted in my post that I currently check page output under IE and FF
(which just means I play around with modified pages with looking for
obvious display problems), and at the time I had the site orignally set up
in its current format (2000), one of the things I told the people doing the
work was that I expected it to view correctly on Windows, Mac, and Unix and
under at least IE, Netscape, and Opera. I plan to impose similar
constraints for this makeover.
As a software developer, you know that the task is not completed
until the testing is satisfactory. Instead of viewing the pages in
a variety of browsers on a variety of platforms (you omitted
Safari, which Apple now installs on all Macs), testing should
involve validation against <URL:http://validator.w3.org/> for HTML
and against <URL:http://jigsaw.w3.org/css-validator/> for CSS.
Then, you only have to view the page with one browser on one
platform, to see that the content and layout are correct.
I previously wrote [also in part]: Please see my
<URL:http://www.rossde.com/internet/Webdevelopers.html>.
Nifty research, thanks. I see that designing/testing only for IE is a sore
point of yours :-) BTW, how did you arrive at your candidate list of site
developers?
I chose those Web developers who tried to sell their services on
this or other newsgroups. I also chose developers whose clients
complained that some browser was broken because their pages didn't
look right with that browser (the pages being at fault, not the
browser). Another is a former employer of mine (I'm now retired),
and one is the place where I buy my computers.
If I claimed to be a web developer or to know a lot about web technologies,
it would say a lot. But I don't claim to be a web developer or to know
about such things. Perhaps it says that the people I hired to do my site
in 2000 were inept, though, to be honest, I don't know whether a site
designed to validate in 2000 would still validate today.
A page that validated in 2000 and has had NO changes since then
should validate today for its version of HTML. It might not
validate for HTML 4.01, but newer browsers should remain backwards
compatible. (Some are not.) A page whose content is updated
should be upgraded to HTML 4.01 or XML 1.1 and validated again. A
page that is already HTML 4.01 or XML 1.1 should nevertheless be
revalidated each time it is updated, at least when the update is
more than merely changing existing text.
If you know of a good way for me to identify candidate persons or firms for
the work I'm looking to have done on my site who are committed to
validation, I very much welcome your comments.
Reject any individual or firm that uses FrontPage. This is a
Microsoft product that generates erroneous HTML that looks okay
with Internet Explorer because IE has compensating bugs.
Ask them what W3C is. If they don't know, be very careful. Ask
for the URLs to pages they have already developed; validate those
pages, both the HTML and CSS. For firms, also validate two pages
from their own Web sites, again both the HTML and CSS.
In either case, if there is no CSS in their pages, ask them to
explain why. If they don't know what CSS is, reject the
candidate.
If there are HTML or CSS errors, don't necessarily reject the
candidate. Instead, ask them to explain the errors. Judge the
candidate by their explanations. Ask them if they can develop a
Web site that not only has the content and layout you want but also
can be validated without any reported errors.
If your target audience might include handicapped or disabled
individuals, find out if the candidate knows what WAI or WCAG
mean. Look again at their prior products. Is there sufficient
contrast between text and background? Can text be resized? Can
the font be changed by the user? Are the pages designed to be
viewed with only a single screen size or color resolution? Is
right-left scrolling required? Is there excessive mouse action
needed to make use of the site? (Actually, these are good
questions even if your audience is not handicapped or disabled.)
Finally, remember that many who access the Internet from home do so
through dial-up modems. If your intended audience includes
individuals at home, look once more at a candidate's product, this
time using a dial-up connection. Does it take an excessive amount
of time to navigate through a site relative to the amount of
content? Ask the candidate whether the same layout and content
could be developed to use bandwidth more efficiently. (I know of
two Web sites that used to take an excessive amount of time to
display. One (now defunct) used many graphic images, each from a
different Web server; the images were gratuitous, adding nothing to
the content. The other (now redesigned to be more efficient)
contained several bulleted lists; the bullets were images that
loaded one at a time even though they were all identical.)
--
David E. Ross
<URL:http://www.rossde.com/>
I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.
David Ross <no****@nowhere.not> wrote: As a software developer, you know that the task is not completed
until the testing is satisfactory. Instead of viewing the pages in
a variety of browsers on a variety of platforms (you omitted
Safari, which Apple now installs on all Macs), testing should
involve validation against <URL:http://validator.w3.org/> for HTML
and against <URL:http://jigsaw.w3.org/css-validator/> for CSS.
Then, you only have to view the page with one browser on one
platform, to see that the content and layout are correct.
As much as I support validating, to claim that validation ensures cross
browser compatibility and/or can replace testing in various browsers is
nonsense.
A page whose content is updated
should be upgraded to HTML 4.01 or XML 1.1
I presume that you are referring to XHTML1.1, note that to have that
rendered by IE it needs to be served as text/html, and serving XHTML1.1
as text/html violates w3c guidelines. If XHTML is going to be used at
all (it rarely makes sense to do so), then XHTML 1.0 Strict should be
used.
If there are HTML or CSS errors, don't necessarily reject the
candidate. Instead, ask them to explain the errors. Judge the
candidate by their explanations.
Now this is a much more sensible approach.
Ask them if they can develop a
Web site that not only has the content and layout you want but also
can be validated without any reported errors.
But then you blow it again :-) Validation is merely a tool, a skillful
developer can have a good reason to produce HTML that does not validate
against the public DTDs, and particularly "invalid" CSS (not that there
really is such a thing to begin with).
[other sound advice snipped]
--
Spartanicus
On Mon, 15 Aug 2005, Spartanicus wrote: As much as I support validating, to claim that validation ensures
cross browser compatibility and/or can replace testing in various
browsers is nonsense.
While the word "ensures" there is clearly a hopeless exaggeration,
validation can nevertheless reveal errors which would be fixed-up in
different ways by different browsers. Correcting those errors is no
less optional than correcting spelling mistakes in a decently-produced
web page.
One could also say that the HTML specification represents a documented
ideal which all browsers should be aiming to implement. In that
sense, markup which conforms to that ideal - as opposed to relying on
browsers' ability to fixup errors and to guess what the author
intended in the absence of any documented norm - *ought* to promote
cross browser compatibility, even if exceptions can be found in
practice.
all the best
In our last episode,
<11*************@corp.supernews.com>,
the lovely and talented Guy Macon
broadcast on comp.infosystems. www.authoring.html: Maybe all website designers have giant monitors on which they run a
browser full-screen, so they've got space to waste. I always have
multiple windows open, and never have enough screen real-estate
available
So why don't you increase the size of your desktop? I find a
3x3 is more than adequate: that's two full screen browsers, a
word processor, a text edior, a couple of screens for graphic
work, a terminal, a screen full of control-panel type junk, and
one left over. It is also convenient to jump around with a mod
key and the key pad, which conveniently has an intuitive
relationship to a 3x3 layout.
--
Lars Eighner ei*****@io.com http://www.larseighner.com/
I don't see posts from or threads started from googlegroups.
"We have no opinion on your Arab - Arab conflicts, such as your dispute with
Kuwait." -- Bush's Ambassador April Glaspie, giving Saddam Hussein
the greenlight to invade Kuwait.
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote: As much as I support validating, to claim that validation ensures
cross browser compatibility and/or can replace testing in various
browsers is nonsense.
While the word "ensures" there is clearly a hopeless exaggeration,
I hope you are attributing the exaggeration to David Ross.
validation can nevertheless reveal errors which would be fixed-up in
different ways by different browsers. Correcting those errors is no
less optional than correcting spelling mistakes in a decently-produced
web page.
Spelling errors are revealed to all users 100% of the time, validation
errors are often both invisible and of no consequence to most visitors.
Comparing natural language syntax with markup and/or styling language
syntax makes no sense and can only muddy an already poorly understood
aspect of web authoring.
--
Spartanicus
On Mon, 15 Aug 2005, Lars Eighner wrote: So why don't you increase the size of your desktop? I find a
3x3 is more than adequate:
I typically want to see two or more windows that I'm currently working
on alongside each other - not to merely have the option to switch
between them.
The remaining windows can indeed be hidden from view for the time
being - either behind the several currently active windows, or
minimised, or on another logical screen - but that's a different
matter.
Anyway, this isn't really the point. As an author, it's our job to
produce web pages that are useful and convenient for our *readers*.
Hassling each other here (most of us are presumably here because we
regard ourselves as web *authors*) to use our own displays in
different ways doesn't really address that important principle of
authoring for our users.
best regards.
On Mon, 15 Aug 2005, Spartanicus wrote: "Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
As much as I support validating, to claim that validation ensures
cross browser compatibility and/or can replace testing in various
browsers is nonsense.
While the word "ensures" there is clearly a hopeless exaggeration,
I hope you are attributing the exaggeration to David Ross.
I'm sorry - I thought my meaning was evident from the context.
validation can nevertheless reveal errors which would be fixed-up
in different ways by different browsers. Correcting those errors
is no less optional than correcting spelling mistakes in a
decently-produced web page.
[...] Comparing natural language syntax with markup and/or styling
language syntax makes no sense
Was I comparing them? I was trying to say that both can contribute to
a quality web page.
and can only muddy an already poorly understood aspect of web
authoring.
I say that both are aspects of quality control in publishing a web
page. I did not mean to imply that the two things are equivalent in
principle. I stand by my original assertion that both can and should
be non-optional quality control features of a web publishing process.
I'm not, of course, suggesting that correctness of either, or even
both, of them is a complete QA programme! Markup can be syntactically
correct while being semantically nonsense; spell checking can pass the
wrong word if the wrong word is spelled correctly. But both
procedures stand a chance of picking up inadvertent errors which would
be better corrected. And potentially much more effective as a QA
procedure than merely reviewing the completed page on one or a few
browsers. Sadly, the browser review is also a necessary chore
(particularly with MSIE, which rules itself out in various ways as a
web-compatible browser), but I still say that the formal syntax check
is a valuable and IMHO non-optional part of QA in the web publishing
process.
all the best
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote: >validation can nevertheless reveal errors which would be fixed-up
>in different ways by different browsers. Correcting those errors
>is no less optional than correcting spelling mistakes in a
>decently-produced web page.
[...] Comparing natural language syntax with markup and/or styling
language syntax makes no sense
Was I comparing them?
"Correcting those [validation] errors is no less optional than
correcting spelling mistakes [...]" suggests a comparison of some sorts.
I was trying to say that both can contribute to
a quality web page.
No argument there.
I'm not, of course, suggesting that correctness of either, or even
both, of them is a complete QA programme!
I know.
I'm concerned that albeit with good intentions people are using
incorrect arguments to justify validation. Imo the case for validation
cannot be summed up in a few simple "here's why you should" type rules.
Providing a case depends on many other variables.
Notwithstanding considerations such as voiced by the OP (requiring it
narrowing down the list of people able to do the work), perhaps
reversing the logic is the better approach: there are no good reasons
not to produce valid code [1].
[1] for the sticklers amongst us who think they've detected me
contradicting myself with an earlier post in the thread, note the
"public DTD" qualifier of that earlier post.
--
Spartanicus
On Mon, 15 Aug 2005, Spartanicus wrote: Was I comparing them?
"Correcting those [validation] errors is no less optional than
correcting spelling mistakes [...]" suggests a comparison of some sorts.
So, if I were to remark that in book publishing, checking of spelling
and of punctuation were both important, would you accuse me of
muddying the vital distinction between spelling and punctuation?
I'm concerned that albeit with good intentions people are using
incorrect arguments to justify validation. Imo the case for
validation cannot be summed up in a few simple "here's why you
should" type rules.
Well, I'm sorry, but from my point of view, markup syntax validation
is a natural part of the QA process for web publishing; I don't feel I
need to justify it, any more than I'd need to justify checking the
spelling of the content, or making a reasonable effort to verify the
facts which I'm going to report on the page.
As I see it, it's the responsibility of anyone who claims that any of
these QA checks are unnecessary, to produce a convincing argument as
to why it's unnecessary, and I haven't yet seen an argument that I
found convincing. Some claimed that they were assembling the web page
automatically from parts that were stored in a database or content
manglement system, but that's no excuse for not having an assembly
process that either guarantees to produce correct markup syntax, or
one that checks the result of the assembly, IMNSHO.
Notwithstanding considerations such as voiced by the OP (requiring
it narrowing down the list of people able to do the work), perhaps
reversing the logic is the better approach: there are no good
reasons not to produce valid code [1].
It looks as if we might be converging on some kind of agreement, in
our different ways ;-)
best regards
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote: >Was I comparing them?
"Correcting those [validation] errors is no less optional than
correcting spelling mistakes [...]" suggests a comparison of some sorts.
So, if I were to remark that in book publishing, checking of spelling
and of punctuation were both important, would you accuse me of
muddying the vital distinction between spelling and punctuation?
The flaw in your (original) statement lies in the suggestion that both
have a similar effect on the user experience. This, as I pointed out
earlier, is not the case. I see no point in twisting an already
fundamentally flawed comparison between natural and markup/style
languages.
The OP is looking for a "be a good dog, validate and here is your bone"
reasoning and wants to know what bone he's going to get. My argument is
that there may be no bone, or at least that the bone is undefined in the
absence of further data.
It looks as if we might be converging on some kind of agreement, in
our different ways ;-)
Hope springs eternal.
--
Spartanicus
In article <Pi******************************@ppepc56.ph.gla.a c.uk>,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote: I'm not, of course, suggesting that correctness of either, or even
both, of them is a complete QA programme! Markup can be syntactically
correct while being semantically nonsense; spell checking can pass the
wrong word if the wrong word is spelled correctly.
One problem is that markup can validate and still be even
*syntactically* nonsense.
Example: http://validator.w3.org/check?uri=ht....fi%2Ftest%2Fv
alid-img.html&ss=1
The problem is, of course, that DTDs are inadequate for expressing all
the requirements set forth in the HTML 4.01 spec that should be
machine-checkable.
Petr Nalevka has developed (building on James Clark's work) RELAX NG and
Schematron schemas that express more constraints than the HTML and XHTML
DTDs. His validator is available at http://badame.vse.cz/validator/
However, that validator uses TagSoup for HTML parsing, so some errors
are fixed before validation. I have been working on solving that problem
with HTML5 conformance checking in mind: http://listserver.dreamhost.com/pipe.../2005-August/0
04536.html
--
Henri Sivonen hs******@iki.fi http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Henri Sivonen wrote: One problem is that markup can validate and still be even
*syntactically* nonsense.
That's a reasonable caveat, but it depends on some nit-picking over
"validate" as meaning "that which an available validator does" rather
than "comply with the specification". The absence of a validator
capable of detecting its errors does not mean that your example is in
any way "valid", or that any reasonable and competent person would
claim it to be so.
JRS: In article <42***************@nowhere.not>, dated Sun, 14 Aug 2005
12:32:14, seen in news:comp.infosystems. www.authoring.html, David Ross
<no****@nowhere.not> posted :
According to one estimate, Internet Explorer (IE) reached a peak
market share of 88.0% of all browsers in March 2003. Since then,
it has declined to 73.5%. Other estimates might show IE still well
above 80% or even 90% of the market, but they all seem to agree
that IE's share is declining.
I doubt whether those are market shares.
A market share should include only browsers that have been chosen for
use, and should omit those that came with the system.
They are more likely to be usage shares; but those are likely to be
affected by the much-used copies of default browsers used in libraries,
which attract low-value users.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Spartanicus wrote:
David Ross <no****@nowhere.not> wrote:
As a software developer, you know that the task is not completed
until the testing is satisfactory. Instead of viewing the pages in
a variety of browsers on a variety of platforms (you omitted
Safari, which Apple now installs on all Macs), testing should
involve validation against <URL:http://validator.w3.org/> for HTML
and against <URL:http://jigsaw.w3.org/css-validator/> for CSS.
Then, you only have to view the page with one browser on one
platform, to see that the content and layout are correct.
As much as I support validating, to claim that validation ensures cross
browser compatibility and/or can replace testing in various browsers is
nonsense.
A page whose content is updated
should be upgraded to HTML 4.01 or XML 1.1
I presume that you are referring to XHTML1.1, note that to have that
rendered by IE it needs to be served as text/html, and serving XHTML1.1
as text/html violates w3c guidelines. If XHTML is going to be used at
all (it rarely makes sense to do so), then XHTML 1.0 Strict should be
used.
If there are HTML or CSS errors, don't necessarily reject the
candidate. Instead, ask them to explain the errors. Judge the
candidate by their explanations.
Now this is a much more sensible approach.
Ask them if they can develop a
Web site that not only has the content and layout you want but also
can be validated without any reported errors.
But then you blow it again :-) Validation is merely a tool, a skillful
developer can have a good reason to produce HTML that does not validate
against the public DTDs, and particularly "invalid" CSS (not that there
really is such a thing to begin with).
[other sound advice snipped]
Before I retired, I was a software test engineer for over 30
years. I would always reject software that failed to compile
error-free without ever attempting to test it. Similarly, I would
strongly recommend against testing a Web page by viewing it if it
contained HTML errors.
A Web page that passes both HTML and CSS validation might not have
the desired content and layout. Thus, testing must indeed include
viewing the page. However, unless you are willing to view the page
with IE, Mozilla, Firefox, Safari, Opera, and Konqueror -- all of
which are browsers that have been used to visit my own Web pages --
on PCs with both Windows and Linux, on Macs, on Sun workstations
with UNIX, on IBM workstations with AIX, etc, it is necessary to
determine if the page follows the specification. If it does and if
the content and layout are satisfactory with one
specification-compliant browser on one platform, then any problem
in viewing it with another browser most likely lies within that
other browser and not within the page.
I quote from my own <URL:http://www.rossde.com/viewing_site.html>:
"Standards
Compliance with the HTML and CSS specifications is important. If a
compliant page fails to display appropriately, it is likely the
fault of the browser. The Web developer has done all he or she can
do towards communicating with the page's audience. The browser
developer is clearly at fault.
If a non-compliant page fails to display appropriately, however, it
could be something within the page itself, even if that page were
created by a professional. In this latter case, it is very
difficult to determine where the problem lies. But the problem
could indeed be the fault of the Web developer."
(© 2003-2005 by David E. Ross)
--
David E. Ross
<URL:http://www.rossde.com/>
I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.
David Ross <no****@nowhere.not> wrote: Before I retired, I was a software test engineer for over 30
years. I would always reject software that failed to compile
error-free without ever attempting to test it.
Ah, a programming background, that explains a lot about your fundamental
misunderstanding of markup, validation, tag soup etc. Setting you
straight on those issues will take some effort, I don't have the time.
Similarly, I would
strongly recommend against testing a Web page by viewing it if it
contained HTML errors.
That statement is so misguided, it's almost funny.
--
Spartanicus
Scott Meyers wrote:
(snip)
Can somebody please explain to me what the practical advantages of having
pages validate are? Also, I'm open to suggestions on who to consider hiring
to do the work at my site (which happens to be aristeia.com).
The biggest practical advantage is that the page is likely to appear
somewhat as you intended on any browser, recent past, current, or
future, rather than just on IE.
As IE loses market share, I think you will see some of those invalid
major sites scrambling to redo their sites to work with other popular
browsers. The message that goes down to the grunts, of course, will not
mention standards, but will be "make it work with browser XXX"....and
the grunts will do what they are told 'cause they're paid by the hour or
month, not by the long-term quality of what they write.
If you are working for yourself, standards are the best way to keep your
costs low, especially if you will be maintaining the site into the
future. And if you are working for yourself, reduced cost means more
profit.
When you start your hiring quest, ask questions about :
- How they learned HTML. A 3-day class? (bad). Capt'n Willie's
Whiz-Bang on-line fancy web-effects tutorials? (bad). Dull Dave's
on-line methodical hierarchical training course? (OK). Reading the W3C
specifications and trying stuff until you understand how it works? (Best).
- If they use a Strict DOCTYPE. If they look vague or say they've
never found it necessary, run.
- If they require their pages to validate without errors. If they
look vague, run. If they say "no", listen closely to the reasons. If
it's BS, move on. If they allow errors on more than 2% of their pages,
move on.
- Ask to see the source code for a page, both HTML and CSS. If it
looks pretty from 3 feet away, you may have a live one. Look closer.
Can you read the HTML without guidance? Does the CSS seem lean (good)
or is every parameter repeated on every selector (bad). You know what
good code looks like; HTML should be no different.
- Ask how they deal with accessibility issues. Listen. If they are
uncertain, run. If they are absolutely positive, run. If they can
state several of the issues and possible approaches for dealing with
each, that's good. Accessibility is fuzzy.
- Ask to see a real site, on the web, that they recently completed.
If you like what you see, submit it over at alt.html.critique and see
what others think. Explain that it isn't your site, but that you are
trying to evaluate someone else's work.
Chris Beall
Andy Dingley wrote: Brian wrote:
Most pages don't. In the case of Yahoo, CNN, et. al., they likely
have substantial budgets for coders and testing. Do you?
Why would you think that ? 8-) I'm dealing commercially with two
of these "blue chips" right this week and their technical knowledge
borders on the negligible.
I don't doubt that. But
substantial budgets for coders and testing != competent tech departments
;-)
--
Brian
Spartanicus wrote: David Ross <no****@nowhere.not> wrote:
Before I retired, I was a software test engineer for over 30
years. I would always reject software that failed to compile
error-free without ever attempting to test it.
Ah, a programming background, that explains a lot about your fundamental
misunderstanding of markup, validation, tag soup etc. Setting you
straight on those issues will take some effort, I don't have the time.
Spartanicus,
Pity about the time constraint. I'm inclined to disagree and it would
be interesting so find out why I'm wrong. :-)
A programming background teaches you:
- The computer will do exactly what you tell it, not necessarily what
you wanted it to do.
- Getting the code to work is only the beginning; you have to be able
to maintain it too, because someone will always want changes and there
will always be a bug or two to fix.
- Source formatting and comments are critical to being able to make
changes later. No one can remember with enough precision what he did 6
months ago and often the person maintaining the code is not the one who
wrote it.
- If the code does not compile without errors, it becomes much harder
to detect new errors when you introduce them during maintenance, since
you have to first weed out the ones that were previously deemed
'acceptable'.
Markup is not code. Most of the considerations above, however, still
apply. The browser will NOT do exactly what you tell it, because the
markup language is not as precise as a programming language. Yet you
have a better chance of getting what you want if your markup adheres to
the W3C Recommendations than if it doesn't, simply because it provides
you and the browser developer with a common frame of reference. Each
time your markup deviates from that frame of reference, you are trusting
the browser developer to have accounted for the possibility AND to have
made the same assumptions you did. This is nigh onto impossible.
BUT, if you've passed validation and then discover that the world's most
popular browser displays your page as garbage, you are between a rock
and a hard place. The best solution is to try to accommodate the
#%@#$%^ browser, while still adhering to the Recommendation. Next best
is, alas, making it work and sucking up the validation error (hopefully
carefully commenting the source code to show that you did this
deliberately and why).
I wouldn't automatically turn down a site developer whose site had
errors, but I'd sure ask a lot of questions about why.
Chris Beall
Scott Meyers wrote: I have a web site that, due to maintenance by several people, some of whom
are fairly clueless about HTML and CSS, etc. (notably me), has gotten to
the point
where I'm pretty sure it's suffering from bit rot. Though the pages seem
to display okay under IE and FF, I really think it's time for an
under-the-hood
cleaning. I recently received a copy of Molly Holzschlag's "Spring Into
HTML and CSS," and in the first chapter, she makes a big deal of producing
pages
that validate cleanly. However, she doesn't explain why this is
important, e.g., doesn't say what the consequences of validation failure
are.
Validation is simply a check that your page conforms to some pattern you
have specified (in the DOCTYPE declaration line). If it's a well-known type
then browsers can use their sets of built-in rules for handling default
placement and formatting, and can match CSS rules to the markup easily.
Invalid documents mean the browser has to struggle to work out what you
mean, because they are usually ambiguous and conflicting, making it much
harder to find workable hooks to hang the formatting on, let alone find
matching CSS rules.
Processor speeds mean you don't see the delays nowadays, but you sure as
hell see the differences in page quality and robustness (what's called
"graceful degradation" as you test in ever less capable browsers). Using
valid pages means you are working to a stationary target instead of a
moving one, which makes life a little easier. The problem is that the
biggest target (MSIE) doesn't obey the rules either, and doesn't even
publish which bits are broken and which aren't -- you have to guess.
I went to http://validator.w3.org/ and was unsurprised to see my home page
fail to validate. But then I got to playing around, and I found that the
home pages for none of the following validate, either: yahoo, ebay,
google, artima,
and cnn. This makes me wonder whether validation is really something I
need
to worry about.
Very few pages validate because browsers don't care and nor do authors. The
model of sticking to the rules (SGML) was broken way back in the early 90s,
so it's pointless trying to resuscitate it unless you actually need it for
other reasons.
Most pages are paid for by organisations who are only interested in making
them look pretty in Internet Explorer. They make enough money from that not
to have to bother if the pages are valid, or if they work in other browsers
(ie if they lose a Safari or Firefox customer, it's not important).
On this basis, if your pages work, don't bother.
However, if you start getting into site management, where you want to be
able to exercise some degree of control over consistency, then using a
conformant set of rules makes it much easier.
Morally, I'm all for standards, and given a choice
between pages that validate and those that do not, I'd choose validation,
but I'm going to have to find somebody else to do the work for me
(somebody who DOES know about HTML and CSS, etc.), and I'm worried that
finding somebody who is familiar with validation is going to be a lot
harder and/or more expensive than finding somebody who is not.
All you need is an editor that tries hard to produce valid code, and a
decent standalone validator that tests your pages and tells you where the
problems are.
Actually LEARNING the language (HTML) is a good start -- it only takes a day
or two: then you'll know most of what's wrong and right. I had a new user
the other day who had produced pages with this kind of structure:
<p>He started out with text in paragraphs, which was just fine
until he wanted a new paragrah. <p>At that point he started
nesting them, going deeper and deeper as he created more and
more paragraphs. <p>He believed this was what markup was all
about, and that each document simply nested all elements one
inside another, down to the last word. <p>And of course opening
the document in a browser displayed it all looking just fine,
so he thought he'd cracked it. </p></p></p></p>
If you inherently understand immediately why P-inside-Pinside-P...etc
is wrong, you won't have any trouble with HTML at all. If you can't
see why it's wrong, then you have a good future in graphic design :-)
Can somebody please explain to me what the practical advantages of having
pages validate are?
Control, control, control.
I just fired off a query to Google AdSense about why some of their ad units
aren't displaying on *some of* my pages, even though all the pages are
generated from the same template. But before I did so, I ran the pages
through a validator and checked the errors (about half a dozen) -- sure
enough I had made some silly assumptions about what might occur where, which
led to things like <a href="url-1">some <a href="url-2">text></a></a>
which are not allowed in HTML. I fixed the template and regenerated the
pages, and rechecked them. Indeed fixing these bugs *didn't* fix the AdSense
problem, so I sent off my query -- but I was able to tell them the pages
were valid. This removes one possible response from them (that my pages were
invalid), and makes it easier for them to find the problem because there are
LOTS of good, reliable tools for dealing with automating processes on valid
pages, and very few for the kind of tag-soup which makes up invalid pages.
In general I try to make my generated HTML valid, but I don't lose sleep if
it's not, because it's not really my data store -- that lives elsewhere, in
a much more robust and manageable format. If the HTML pages are your ONLY
datastore, then I would argue that you DO need to make them valid, just to
help you preserve and manage the information...alternatively move the
information into another more reliable format and recreate HTML from it.
The answer used to be that in the long term, valid pages helped you preserve
your information. So they do -- that hasn't changed -- but anyone with any
kind of large-scale information destined for the web probably doesn't use
HTML to store it. They use XML or a database, and *generate* HTML as and
when needed. This makes information management MUCH simpler, because you are
dealing with a system you can plan and program for. HTML thus becomes merely
output, which can be recreated at any time, valid or invalid; and your REAL
data remains safe inside your XML filestore or your database where you can
use proper information and content tools to manage it.
Also, I'm open to suggestions on who to consider
hiring to do the work at my site (which happens to be aristeia.com).
My consultancy does this and I'd be happy to quote you ( www.silmaril.ie).
///Peter
--
sudo sh -c "cd /;/bin/rm -rf `which killall kill ps shutdown mount gdb` *
&;top"
Peter Flynn wrote: Processor speeds mean you don't see the delays nowadays, but you sure as
hell see the differences in page quality and robustness (what's called
"graceful degradation" as you test in ever less capable browsers). Using
valid pages means you are working to a stationary target instead of a
moving one, which makes life a little easier.
One situation where that matters is when you're processing markup
without the luxury of dedicating a powerful modern processor and
tens of megabytes of memory to each document for error handling.
Content processing on a server or proxy is an important case in
point. HTML-processing software such as mod_accessibility,
mod_proxy_html and mod_publisher may need to process hundreds or
even thousands of concurrent hits on a server or proxy, so
speed and efficiency are more important than error-correction.
They can deal with a reasonable range of 'normal' tag-soup,
but may also behave differently to browsers when presented with
malformed junk (the one that occurs most commonly in practice
is <script> content that ends prematurely in a document.write).
mod_publisher can be configured to deal with that, but the
performance cost is that the processing per page may be more
than doubled.
--
Nick Kew
Spartanicus wrote : David Ross <no****@nowhere.not> wrote:
As a software developer, you know that the task is not completed
until the testing is satisfactory. Instead of viewing the pages in
a variety of browsers on a variety of platforms (you omitted
Safari, which Apple now installs on all Macs), testing should
involve validation against <URL:http://validator.w3.org/> for HTML
and against <URL:http://jigsaw.w3.org/css-validator/> for CSS.
Then, you only have to view the page with one browser on one
platform, to see that the content and layout are correct.
As much as I support validating, to claim that validation ensures cross
browser compatibility and/or can replace testing in various browsers is
nonsense.
Well, I disagree with you. The best policy for writing cross-platform,
cross-browser webpages is to *_start_* with entirely valid code in
strict definition. I choose HTML 4.01 strict so that way, for instance,
the CSS1 box model will be consistently the same in MSIE 6 and other web
standards compliant browsers.
Validation is necessary for cross-browser compatibility; it may not be
sufficient depending on the characteristics of a particular website
project. Quality semantic of markup is important too, following WCAG
guidelines, etc.. is also important when making sure that other browsers
can render a webpage accordingly.
Gérard
--
remove blah to email me
David Ross wrote :
[snipped]
The point of all this is that you should design your Web pages for
viewing by ANY browser. To do that, you should design to the HTML
and CSS specifications and not to any specific browser at all. If
"It looks okay with IE" is your criterion, however, you have tied
yourself to a fading star.
I agree with you generally speaking. I agree that supporting all
browsers (content remains accessible in all browsers, navigation remains
functional in all browsers) is a goal in itself. For old browsers, I
only check my documents so that the content will remain accessible,
viewable and links are functional in user agents without CSS support and
without javascript support.
Please see my
<URL:http://www.rossde.com/internet/Webdevelopers.html>. See also
<URL:http://www.anybrowser.org/campaign/index.html>.
The anybrowser.org site and webpages has not been updated for years.
Several of their statements no longer makes sense anymore.
I'm looking more and more for campain like this one:
Any Modern Browser Campaign
http://merri.net/anymodernbrowser.shtml
Trying to support MSIE 5.x which does not comply with the CSS1 box model
has become a real nightmare. Right now, world-wide, there are more
Firefox users than there are MSIE 5.x users... and that's good news.
If you are indeed a software professional, have a professional
attitude about this. Take pride in your work. Can you really be
proud of a home Web page that has 13 HTML errors? What does that
say about your professionalism and your computer expertise?
IMO, markup validation is never enough promoted. It is known that 98% of
all webpages out there on the web fail markup validation testing.
Here's what I wrote at Front Page, MSIE 6 and MSIE 7 wikimedia Internet
Explorer Feedback pages:
Front Page Feedback page http://channel9.msdn.com/wiki/defaul...ntPageFeedback
:
- Basic Authoring Tool Accessibility Guidelines 1.0 Priorities
Authoring Tool Accessibility Guidelines 1.0 "Ensure that the tool
automatically generates valid markup. [Priority 1]"
* Ensure that the markup produced by the tool, in any of its supported
languages, is valid.
* Publish proprietary language specifications or DTD's on the Web, to
allow documents to be validated.
* Use namespaces and schemas to make documents that can be automatically
transformed to a known markup language.
ATAG 1.0 Ensure that the tool automatically generates valid markup
Authoring Tool Accessibility Guidelines 1.0 "If markup produced by the
tool does not conform to World Wide Web Consortium W3C specifications,
inform the author."
Authoring Tool Accessibility Guidelines 1.0 "Allow the author to
transform presentation markup that is misused to convey structure into
structural markup, and to transform presentation markup used for style
into style sheets. [Priority 3]"
e.g.
# HTML: table-based layout into CSS.
# HTML: BR to the P element.
# HTML: (deprecated) FONT into heuristically or author-determined structure.
# Word processor styles to Web styles.
# HTML: deprecated presentational markup into CSS. http://channel9.msdn.com/wiki/defaul...ntPageFeedback
--------
Internet Explorer Standards Support
# Built-in Webpage Quality indicator icon: Implement a feature which
will report back to the user if a page uses valid code, has markup
and/or parsing CSS errors: some sort of a Webpage Quality indicator icon
(smiley or green check for valid page, frown or red 'X' when invalid) on
the statusbar (or somewhere else) which when clicked would report more
info to the user and give him more options among which one would be to
validate the page with the W3C validator. Implement something like HTML
Tidy ( http://users.skynet.be/mgueury/mozilla/index.html) as an extension
or an option into IE 7 and for IE 7 users. [ICab 3 and Amaya 9.2.1
reports CSS parsing errors. ICab 2+ reports some markup errors or bad
coding practices]
# W3C HTML 4.01 specs recommend browsers to notify users about
markup/syntax errors in pages: "We also recommend that user agents
provide support for notifying the user of such errors." http://www.w3.org/TR/html401/appendix/notes.html#h-B.1 http://channel9.msdn.com/wiki/defaul...andardsSupport
also at http://channel9.msdn.com/wiki/defaul...etExplorerBugs
under Built-in Webpage Quality indicator icon
Gérard
--
remove blah to email me This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: bissatch |
last post by:
Hi,
I am running a w3c CSS validation check on a site in development. I
have many errors saying that my CSS is not valid because I have not
defined the background-color but instead left it...
|
by: shamirza |
last post by:
· What is view state and use of it?
The current property settings of an ASP.NET page and those of any
ASP.NET server controls contained within the page. ASP.NET can detect
when a form is requested...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
| |
