|
in reply to Larry vs. Joel vs. Ovid
The web browser is an excellent example; the problem started, however, before NS was even NS -- the initial versions of Mosiac offered no clues to the user that the web page was malformed, and that trend has continued since. Is this necessarily a good idea? It's a big if, of course, but I would suspect that if my browser told me every time I encounted a page that didn't meet W3C standards, I'd be very very tired of getting that warning nearly all the time. From a UI stand-point, some would argue that not informing the user of a bad layout in a web page is a good thing (You should only tell the user that there's a serious error if they are supposed to take action to do something about it). But here, the problem was that there was no way of using the browser alone to determine bad makeup.
This lead to the development of the first generation of WYSIWYG tools that did produce bad layout as well. These became popular, so the second generation of browsers decided to make sure that they could accept those. Begin vicious cycle.
Nowadays, we're still stuck in the HTML problem, and I don't think that will ever be cured. But for so-called web application or interprocess communications, we have XML. There is *no* reason not to be able to write valid XML given the large number of tools, free, commercial, compiled, interpreted, or otherwise, out there; nor is there any reason not to read in only strict XML. However, the advantage of XML as a format is that one can include excess or alternative data to the format, which client A might not completely understand but can still produce an intended result, while client B can take advantage of. But the key point here is that the XML *must* be well-formed. If one gets bad XML, what should the error be the user? Hopefully, those that have worked with HTML over the years understand that malformed XML is potentally more dangerous than malformed HTML, and will take steps to tell the user of such.
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important
|
Re(2): Larry vs. Joel vs. Ovid vs. Masem vs. Web browsers
by FoxtrotUniform (Prior) on Nov 21, 2001 at 01:34 UTC
|
The web browser is an excellent example; the problem
started, however, before NS was even NS -- the initial
versions of Mosiac offered no clues to the user that the
web page was malformed, and that trend has continued since.
Is this necessarily a good idea? It's a big if, of course,
but I would suspect that if my browser told me every time I
encounted a page that didn't meet W3C standards, I'd be
very very tired of getting that warning nearly all the
time. From a UI stand-point, some would argue that not
informing the user of a bad layout in a web page is a good
thing (You should only tell the user that there's a serious
error if they are supposed to take action to do something
about it). But here, the problem was that there was no way
of using the browser alone to determine bad makeup.
I wouldn't want the browser to pop up with a big freaky
modal dialog every time I loaded a page with somewhat
suspect HTML, but I would like to see some indication
that the page isn't well-formed -- perhaps a message in the
ubiquitous status bar to the effect of "This page is not
valid HTML, and may not be displayed properly". As a user,
I'd like to be told if the page I'm looking at is garbled
(often one can tell immediately if a page hasn't rendered
the way the designer would have liked, but I think it's
reasonable to believe that some pages would be mis-rendered
with subtle, important errors), and as a developer I'd sure
like to know. (Of course, as a developer, I have plenty of
HTML validators at my fingertips.)
And bringing this back on topic... this point generalizes
fairly well to programming in general. That's why compilers
have warnings as well as error messages. I see no reason
why all programs, especially those that talk to people,
should insist on conservatively correct input. If you get
suspicious input, emit a warning and do the best you can.
That way, if you're relying on vaguely bogus input from
someone else's software (for instance), you can still get
work done. The difference between this model and the web
browser problem is that Our Favourite Web Browsers(tm)
don't give any (easily accessible) warnings about malformed
HTML, so Joe Luser has no idea that they've just
written awful markup.
That said, within your own code strict adherance to
contracts (for instance) is an excellent idea. If you're
generating bogus data, you're going to want to know about
it, not fudge it and hope for the best, and it's much more
difficult to ignore a confess than a carp.
--
:wq
| [reply] |
|
|
I would like to see some indication that the page isn't well-formed
Yes, and iCab does that, by putting a little smiley-face/frowny-face icon on the location panel. Of course, it's always frownyface on PerlMonks, so you can press it to get the errors. Here are the errors for this page as
I type this:
http://www.perlmonks.org/index.pl?title=%28FoxUni%29%20Re%282%29%3A%20
+Larry%20vs.%20Joel%20vs.%20Ovid%20vs.%20Masem%20vs.%20Web%20browsers&
+parent=126653&lastnode_id=126653&node=Offer%20your%20reply&parent_nod
+e=126653
Altogether 79 errors found. Only 25 errors are listed below.
Error (9/4): The tag <layer> is not part of HTML 4.0.
Error (9/93): The end tag </layer> is not part of HTML.
Warning (9/162): In the tag <TD> the attribute "WIDTH" should only con
+tain absolute pixel values.
Error (9/285): In the tag <IFRAME> the attribute "FRAMESPACING" is not
+ allowed.
Warning (9/606): In the tag <TD> the attribute "WIDTH" should only con
+tain absolute pixel values.
Warning (9/665): In the tag <TD> the value of the attribute "WIDTH" mu
+st be enclosed in quotes.
Warning (9/665): In the tag <TD> the attribute "WIDTH" should only con
+tain absolute pixel values.
Error (10/166): In the tag <INPUT> the attribute "BORDER" is not allow
+ed.
Warning (16/106): The tag <FONT> should no longer be used since HTML 4
+.0.
Error (16/120): The character '&' must be written as '&'.
Error (16/120): The character '&' must be written as '&'.
Error (16/200): The character '&' must be written as '&'.
Error (16/263): The character '&' must be written as '&'.
Error (16/1175): The character '&' must be written as '&'.
Warning (21/1): The tag <CENTER> should no longer be used since HTML 4
+.0.
Warning (24/3): In the tag <TD> the attribute "WIDTH" should only cont
+ain absolute pixel values.
Error (27/78): The character '&' must be written as '&'.
Warning (84/3): In the tag <TD> the attribute "WIDTH" should only cont
+ain absolute pixel values.
Error (85/32): The color name "eedddd" is not valid.
Error (86/1): In the tag <TR> white space is missing as separator afte
+r the attribute "BGCOLOR".
Error (86/1): In the tag <TR> the value of attribute "BGCOLOR" is miss
+ing.
Error (86/1): The attribute "000000" is not part of HTML.
Error (86/1): In the tag <TR> the value of attribute "" is missing.
Warning (88/8): The tag <FONT> should no longer be used since HTML 4.0
+.
Warning (95/4): The tag <FONT> should no longer be used since HTML 4.0
+.
Error (102/1): In the tag <TR> white space is missing as separator aft
+er the attribute "BGCOLOR".
Error (102/1): In the tag <TR> the value of attribute "BGCOLOR" is mis
+sing.
Error (102/1): The attribute "000000" is not part of HTML.
Error (102/1): In the tag <TR> the value of attribute "" is missing.
Warning (104/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (111/4): The tag <FONT> should no longer be used since HTML 4.
+0.
Error (112/13): The character '&' must be written as '&'.
Warning (112/79): The tag <FONT> should no longer be used since HTML 4
+.0.
Warning (113/1): The tag <FONT> should no longer be used since HTML 4.
+0.
Error (114/286): The character '&' must be written as '&'.
Error (121/1): In the tag <TR> white space is missing as separator aft
+er the attribute "BGCOLOR".
Error (121/1): In the tag <TR> the value of attribute "BGCOLOR" is mis
+sing.
Error (121/1): The attribute "000000" is not part of HTML.
Error (121/1): In the tag <TR> the value of attribute "" is missing.
Warning (123/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (133/1): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (135/254): The tag <FONT> should no longer be used since HTML
+4.0.
Warning (135/1488): The tag <FONT> should no longer be used since HTML
+ 4.0.
Warning (147/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (154/4): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (164/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (168/31): The tag <FONT> should no longer be used since HTML 4
+.0.
Warning (168/148): The tag <FONT> should no longer be used since HTML
+4.0.
Warning (168/277): The tag <FONT> should no longer be used since HTML
+4.0.
Warning (168/438): The tag <FONT> should no longer be used since HTML
+4.0.
I'm still trying to work with the Everything-engine people to get them to put the right ampersand escaping in URLs. Most of the rest of that goes away if you start using CSS instead of explicit tags. But there's still the odd things, like unquoted parameters, for which all we can say is "sloppy coding, please fix up!".
-- Randal L. Schwartz, Perl hacker | [reply]
[d/l] |
|
|
Erm. Not sure if you really needed to post all 25 errors. But anyway, it seems like a nice feature - is there an option to change the level of errors it detects? For instance, if I don't care about anything implemented in HTML 3 or above (say I'm on a contract for a company that has Netscape 2 as the default browser company wide or something)?
I'll probably be able to answer this myself soon though as I'm downloading iCab now.
| [reply] |
|
|
I was going to comment on this to tye's post, but it's just as valid here.
"What if" Mosaic 0.9 had a pop up dialog that warned of invalid HTML, from day one? Where would we be now? Let me extrapolate:
Since it would be expected that web page designers would check their own pages using the first generation browsers, they would early on discover their page errors and fix them. The typical end user would have never seen these errors save from sloppy HTML writers that didn't test.
When the first generation HTML editors would be introduced, they would be careful to make sure that they produced clean, valid HTML code as to make less work on the end writer to clean up this code before it was put on the web.
From that point on, you'd get the same circle of dependacy as we had in reality, but this time with adherence on strictness. All HTML that would be published today, save by those that lack any QA, would be clean and well-formed...
...however, there is the Microsoft factor to consider here. It can be easily suggested that MS would have been to first to disable this pop up dialog to an option that could be turned off after the first instance, or disabled it completely. The implications of this are hard to determine; it could have speed up their 'domination' of the web by offering a solution that allowed 'bad' code through mostly unnoticably, or it could have caused them to be shuned by the community for trying to hide bad code. But once someone did that, others would have followed, and we might be back exactly where we are today, save for the lack of some HTML atrocities like BLINK and FRAME.
In the today of this history, we would have never accepted that pop-up message during causal browsing, but if history was slightly different, we may have been upset to not find it there when it was needed.
That's why I refer to the strength of XML; we as a collective computer community are not simply looking at XML as tag soup as HTML was originally, but as a well-structured document in terms of opening and closing tags with attributes. Assuming that you can properly write out this format (which is easy) and read in this format without accepting flaws (difficult, but people have put solutions in place for this already, no need to reinvent said wheel), then the rest of XML which allows for free format of data items is in place. And people do realize that, and are making sure that while they may be sending XML documents that have extra or lacking data, the XML is well formed and does not fail in parsing. This is a very good first step in more adaptable and usable data formats.
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important
| [reply] |
|
|
