IE4 does not conform to HTML4
Mike Piff
OK, <dir> is deprecated, but that means we should be trying to get people to use
stylesheets instead, and what better platform than IE4? (Unless you use a Unix box.)
Anyway, according to the HTML4 specification, <dir> only allows <li> content, and excludes
block-level markup, eg, nested <dir> elements.
So, what does IE4 do when it encounters
<dir><dir><dir>
where someone is using it as a tab-stop? It nests the tabbing. :-(
Please, Microsoft, if you want to get people to use HTML4, CSS, etc, change this behaviour
so that any block-level content terminates a <dir> , the same as <p> terminates another <p>.
<dir> is no more nestable than <p> is!
Mike Piff
--
http://www.shef.ac.uk/~cs1mjp mailto:M.P...@shef.ac.uk
Stephen Traub
"Mike Piff" <M.P...@shef.ac.uk> wrote:
>Anyway, according to the HTML4 specification, <dir> only allows <li>
>content, and excludes
>block-level markup, eg, nested <dir> elements.
>
>So, what does IE4 do when it encounters
>
><dir><dir><dir>
>
>where someone is using it as a tab-stop? It nests the tabbing. :-(
Despite one of your intelligent conclusions that HTML hacks should be
avoided and style sheets are the better way to go [in many cases], the
conclusion in your title is wrong. <DIR><DIR><DIR> is invalid HTML. MS IE
4.0 according to the recommendation, therefore, can do whatever it damn
well pleases with it and it would still be in conformance with HTML 4.0.
No rules exist in HTML, as to what a browser MUST do when it stumbles across
invalid HTML.
So your example is not proof or even support for one of your apparent theses
that "IE4 does not conform to HTML 4".
I'm not claiming that IE 4.0 does conform in other respects -- only that the
example you gave doesn't prove that or prove anything with regard to HTML
conformance on MS IE.
MS might be better off to include a validator with each browser that the
author COULD -- if he/she chose to -- to toggle on to validate his/her page
(or anyone elses) and know if the page were valid or not. Many authors just
check their page visually in a browser or two and if it looks okay (often as
a result of error recovery) the author gets a false sense of security that
WTheySIWOthersG.
Of course this assumption (especially if invalid HTML is present) could be
wrong.
Nevertheless, I agree with your other theme that using HTML hacks to get a
specific visual effect is not a reliable method.
And CSS is beginning to phase out the need to resort to these unreliable
HTML hacks.
Steve
--
Web Page Re<p>air - Widen your Web site's audience.
http://www.shore.net/~straub/wpr.htm
Property Valuation Advisors - Commercial Real Estate
Appraisal in New England http://www.shore.net/~straub/
Tor Iver Wilhelmsen
On Wed, 4 Feb 1998 12:16:46 -0000, "Mike Piff" <M.P...@shef.ac.uk>
uttered:
>Please, Microsoft, if you want to get people to use HTML4, CSS, etc, change this behaviour
>so that any block-level content terminates a <dir> , the same as <p> terminates another <p>.
><dir> is no more nestable than <p> is!
Howerver: If it "prioritizes" error recovery, it might be throwing in
some <LI> elements there, effectively making the DIR "nested".
But _I_ definitely agree with you.
(My IE frustration is that the 4.01/SDK 2.01 VM doesn't work properly
with swing-0.7; it's lazy when it comes to rendering some JFC
elements.)
--
"We're only healthy if the industry as a whole is healthy and
thriving. Most types of software aren't appropriate for us to do.
For those that are, we'll always have competition." - Bill Gates
to...@online.no http://www.pvv.org/%7etoriver/
Mike Piff
Stephen Traub wrote in message <6babin$d...@fridge.shore.net>...
>Despite one of your intelligent conclusions that HTML hacks should be
>avoided and style sheets are the better way to go [in many cases], the
>conclusion in your title is wrong. <DIR><DIR><DIR> is invalid HTML. MS IE
>4.0 according to the recommendation, therefore, can do whatever it damn
>well pleases with it and it would still be in conformance with HTML 4.0.
>
>No rules exist in HTML, as to what a browser MUST do when it stumbles across
>invalid HTML.
This seems to me to be a fundamental failing in HTML which needs to be addressed.
My suggestion would be that if if <a> excludes <b> then <b> should be replaced by </a><b>
and the input re-scanned. Now probably </a> will force some extra markup to be inserted for
opened elements with mandatory close tags.
I must go away and check exactly what object model has been built by IE4 for
<dir><dir><dir>
but whatever it is, surely my contention still holds, that that object model is in conflict with the HTML4 specification? It must have nested <dir> objects in it, else the tabbing effect would not be there?
(Just a guess.)
Hell, I was being kind! This doesn't even conform with HTML3.2!!
>
>So your example is not proof or even support for one of your apparent theses
>that "IE4 does not conform to HTML 4".
Not proof, I agree. I would argue strong support. ;-)
>MS might be better off to include a validator with each browser that the
>author COULD -- if he/she chose to -- to toggle on to validate his/her page
>(or anyone elses) and know if the page were valid or not. Many authors just
>check their page visually in a browser or two and if it looks okay (often as
>a result of error recovery) the author gets a false sense of security that
>WTheySIWOthersG.
>
I agree with that excellent suggestion. In fact, an immediate view of the object model built by the browser for comparison with what was intended a la Panorama or HoTMetaL would be good.
However, with Java support we don't even get a console window, just <half a status line, so what hope an object view?
>Nevertheless, I agree with your other theme that using HTML hacks to get a
>specific visual effect is not a reliable method.
>
>And CSS is beginning to phase out the need to resort to these unreliable
>HTML hacks.
>
Thanks, Steve. My hope is that Microsoft will force the issue (of using stylesheets) by making it trivial to achieve visual effects by these means and rather difficult by invalid HTML hacks.
Mike
Mike Piff
Tor Iver Wilhelmsen wrote in message <34d9aba5....@news.eunet.no>...
>>Please, Microsoft, if you want to get people to use HTML4, CSS, etc, change this behaviour
>>so that any block-level content terminates a <dir> , the same as <p> terminates another <p>.
>><dir> is no more nestable than <p> is!
>
>Howerver: If it "prioritizes" error recovery, it might be throwing in
>some <LI> elements there, effectively making the DIR "nested".
>
OK, so it converts
<dir><dir>
to
<dir><li><dir>
Well, first it doesn't because that markup produces a list item marker in IE4.
Second, it is still in trouble, as the specification still excludes the second <dir>.
From the illegal markup
<dir>
<li>
<dir>---excluded by dir
<li>
</li>
</dir>
</li>
</dir>
it produces an object model with nested <dir> elements, illegal in HTML3.2! Any error recovery that produces valid HTML4 as output would convert the above to:
<dir>
<li>
</dir>
<dir>
<li>
</li>
</dir>
</li>---discarded, no element to end
</dir>---discarded, no element to end
and then finally to
<dir>
<li>
</li>
</dir>
<dir>
<li>
</li>
</dir>
which has an entirely different appearance in IE4.
>But _I_ definitely agree with you.
Thanks, Tor.
Mike
Chris Gray
In article <6bc2rv$8mv$1...@bignews.shef.ac.uk> "Mike Piff" <M.P...@shef.ac.uk>
writes:
> Stephen Traub wrote in message <6babin$d...@fridge.shore.net>...
< > [...]
> >No rules exist in HTML, as to what a browser MUST do when it stumbles =
> across=20
> >invalid HTML.
>
> This seems to me to be a fundamental failing in HTML which needs to be =
> addressed.
No. Once you start to specify exactly how a browser should treat invalid
HTML, you effectively create syntax rules which include invalid markup as
well as invalid: so under the new rules the invalid markup is also valid.
> My suggestion would be that if if <a> excludes <b> then <b> should be =
> replaced by </a><b>
> and the input re-scanned.
This is a good example. Optional closing tags are handled in just the
way you describe: for example if <a> is <p> and <b> is the openening tag
for any other block-level element. So your proposal actually results in
a new grammar in which almost any closing tag is optional. Note that:
1. Optional closing tags are one of the things which make and SGML or HTML
parser a non-no-brainer to write.
2. Partly for that reason, XML says: there are no optional closing tags.
3. Browsers have a history of making a mess of optional closing tags -
* <P ALIGN=Center> not being cancelled by following <P>
* Nested tables confuse Netscape if optional </TD> and </TR> omitted
As an error recovery strategy, what you describe would often be the least
dumb thing. (If you submit such a code to one of the online validators
you'll see that they seem to do it this way.) But to mandate such behaviour
would be a big mistake.
> Now probably </a> will force some extra =
> markup to be inserted for
> opened elements with mandatory close tags. =20
>
> I must go away and check exactly what object model has been built by IE4 =
> for
>
> <dir><dir><dir>
>
This does add a new urgency to these questions, doesn't it? Not so long
ago, the only thing most authors cared about was "how will it render in
browsers tweedle-A and tweedle-B"? Now they also need to know "how do
I write to the contents of my <dir><dir><dir> in J*Script?", or "which
stylesheet rule applies in the middle of <A>...<FONT>...</A>...</FONT>?"
--
Chris Gray
Jedi Master Yoda
[NGs trimmed because I feel like it]
Chris Gray wrote:
>
> No. Once you start to specify exactly how a browser should treat invalid
> HTML, you effectively create syntax rules which include invalid markup as
> well as invalid: so under the new rules the invalid markup is also valid.
Beautifully put. And worth adding that if your invalid document doesn't
render as you'd like it to, fix the document, not HTML.
> 1. Optional closing tags are one of the things which make and SGML or HTML
> parser a non-no-brainer to write.
Erm... 'a brainer', shurely.
> 3. Browsers have a history of making a mess of optional closing tags -
Optional closing tags, feh. Browsers have a history of making a mess of
HTML. Now stylesheets have allowed us to override the awful default
presentation of the Mosaic-spawn, we find that their implementation has
been sabotaged by... the Mosaic-spawn.
> > I must go away and check exactly what object model has been built by IE4 =
> > for
> >
> > <dir><dir><dir>
It's amusing that people used to say to Netscape, 'Publish the DTD that
describes the HTML your browser recognises'. And Netscape sayeth unto
them, 'No. Uhm... we don't feel like it today.'
But the real reason of course was that the browser was and is a
streaming tagsoup processor implementing procedural markup, and the
dialect of HTML it recognises cannot be described in a DTD. Which is
jolly bad eggs for anyone who wants to make Netscape-valid documents (if
that's not an oxymoron).
JM "[INLINE] elcome to the soclogo.gif (21K) [Society for Web
Accessibility Logo] [ISMAP]" Y
Mike Piff
Chris Gray wrote in message ...
>In article <6bc2rv$8mv$1...@bignews.shef.ac.uk> "Mike Piff" <M.P...@shef.ac.uk>
>No. Once you start to specify exactly how a browser should treat invalid
>HTML, you effectively create syntax rules which include invalid markup as
>well as valid: so under the new rules the invalid markup is also valid.
>
I don't entirely agree with that, although I do agree with the sentiment. I fell
you can keep separate the validity rules and the error recovery rules. I feel
there is much more of a risk in not specifying the latter. If the object model
used by a script is not well-specified, how do you stop a script from crashing
on another browser, or have some confidence it won't crash?
>> My suggestion would be that if if <a> excludes <b> then <b> should be =
>> replaced by </a><b>
>> and the input re-scanned.
>
>This is a good example. Optional closing tags are handled in just the
>way you describe: for example if <a> is <p> and <b> is the openening tag
>for any other block-level element. So your proposal actually results in
>a new grammar in which almost any closing tag is optional. Note that:
>
>1. Optional closing tags are one of the things which make and SGML or HTML
> parser a non-no-brainer to write.
>
>2. Partly for that reason, XML says: there are no optional closing tags.
I thoroughly agree with that!!!
>
>3. Browsers have a history of making a mess of optional closing tags -
> * <P ALIGN=Center> not being cancelled by following <P>
> * Nested tables confuse Netscape if optional </TD> and </TR> omitted
>
>As an error recovery strategy, what you describe would often be the least
>dumb thing. (If you submit such a code to one of the online validators
>you'll see that they seem to do it this way.) But to mandate such behaviour
>would be a big mistake.
>
It is precisely because of 3. above and my <dir><dir><dir> example, which was
not just academic by the way, but a real case of someone trying to tab past a
background with a vertical LH strip, that I would say YES, mandate certain behaviour.
If you leave it to the browser writer, who knows what they will allow?
>> Now probably </a> will force some extra =
>> markup to be inserted for
>> opened elements with mandatory close tags. =20
>>
>> I must go away and check exactly what object model has been built by IE4 =
>> for
>>
>> <dir><dir><dir>
>>
>
>This does add a new urgency to these questions, doesn't it? Not so long
>ago, the only thing most authors cared about was "how will it render in
>browsers tweedle-A and tweedle-B"? Now they also need to know "how do
>I write to the contents of my <dir><dir><dir> in J*Script?", or "which
>stylesheet rule applies in the middle of <A>...<FONT>...</A>...</FONT>?"
>
That's right! In the past, the markup was slapped on the page and forgotten,
but now it is there all the time, and we need to know what object model is
being used. My contention is that Microsoft is using one in which <dir>s
can be nested, and that is incorrect. Moreover, the model has a *direct*
inclusion of one <dir> within another, ie, content (li)+ is being ignored in
favour of ((li)+|anything). Fair enough, <dir> is deprecated, but it makes you
wonder whether any of the SGML is being followed in the object model.
Where is their rule that the children of a <dir> must be <li>s? Surely
any script would rely on that fact.
The alternative, of having a rule that browsers ignore any markup that is illegal
according to the SGML spec, would be acceptable too! That way, anything
but an <li> within a <dir> would not be rendered.
Mike
Alan J. Flavell
On Thu, 5 Feb 1998, Jedi Master Yoda wrote:
> JM "[INLINE] elcome to the soclogo.gif (21K) [Society for Web
> Accessibility Logo] [ISMAP]" Y
Neatly put!
Phundria seems to go into the issues in more detail:
http://www.homeusers.prestel.co.uk/pax/phun/onlineawards/pages/how.html
extract: "There is a risk that ALT texts might make images intelligible
to browsers with images turned off, so that visitors to the site might
avoid viewing them"
;-}
Chris Gray
In article <34D9BA...@dagoba.org> Jedi Master Yoda <yo...@dagoba.org>
writes:
> It's amusing that people used to say to Netscape, 'Publish the DTD that
> describes the HTML your browser recognises'. And Netscape sayeth unto
> them, 'No. Uhm... we don't feel like it today.'
Hm, a bit stronger than that I'd say. See for instance
<URL: http://www2.cibola.net/~bhgiza/webfolks/03webflk.htm>
--
Chris Gray
Chris Gray
In article <6bcgci$g2o$1...@bignews.shef.ac.uk> "Mike Piff" <M.P...@shef.ac.uk>
writes:
> [...] I fell
> you can keep separate the validity rules and the error recovery rules. =
> I feel
> there is much more of a risk in not specifying the latter. If the =
> object model=20
> used by a script is not well-specified, how do you stop a script from =
> crashing
> on another browser, or have some confidence it won't crash?
The object model should be well-defined *provided that* the HTML is valid,
i.e. it obeys the rules given in the DTD. Otherwise the result, as they
say, is undefined; Garbage In -> Garbage Out.
A browser might wish to protect itself against damage by simply refusing
to build an object model from syntactically invalid HTML: representing the
better paradigm, Garbage In -> Meaningful Error Messages Out. Trouble is,
both information consumers and providers seem to take the attitude that
if there exists one browser which succeeds in making sense of a document
then the document itself is korekt, and any browser which cannot handle it
is broken. So some re-education may be required ...
--
Chris Gray
Mike Piff
Chris Gray wrote in message ...
>The object model should be well-defined *provided that* the HTML is valid,
>i.e. it obeys the rules given in the DTD. Otherwise the result, as they
>say, is undefined; Garbage In -> Garbage Out.
>
Yes, but I would have hoped that the object model would conform to valid
HTML, and any invalid HTML forced to that object model, so it became valid
again. Otherwise, I have no confidence that the browser will convert valid
HTML to a valid object representation, either!
There is also an awful lot of non-conforming HTML out there. I guess most
of the stuff here is non-conforming.
>A browser might wish to protect itself against damage by simply refusing
>to build an object model from syntactically invalid HTML: representing the
>better paradigm, Garbage In -> Meaningful Error Messages Out. Trouble is,
>both information consumers and providers seem to take the attitude that
>if there exists one browser which succeeds in making sense of a document
>then the document itself is korekt, and any browser which cannot handle it
>is broken. So some re-education may be required ...
I agree with that, but the problem is more subtle, and maybe connected with
some other product of Microsoft's. I was talking to someone on the stairs
here a short while ago, and discovered that he had found that tabbing in his
left border in Word and then saving as HTML produced documents with
<dir><dir><dir>s in them. Maybe that is why Microsoft cannot admit that
<dir>s should not be nested, because one of their products with millions of
paying users thinks that <dir> is a tabstop.
I had a look at their HTML reference on-site and there is no mention of
excluded/valid content, by the way, just an example correctly using <li>s.
Mike
Chris Gray
In article <6bcmif$jmo$1...@bignews.shef.ac.uk> "Mike Piff" <M.P...@shef.ac.uk>
writes:
> I was talking to someone on the =
> stairs
> here a short while ago,
:)
> and discovered that he had found that tabbing in =
> his
> left border in Word and then saving as HTML produced documents with
> <dir><dir><dir>s in them. Maybe that is why Microsoft cannot admit that
> <dir>s should not be nested, because one of their products with millions =
> of
> paying users thinks that <dir> is a tabstop.
Oh sure, a lot of the Garbage Out There was generated using Microsoft's
tools. So they should fix the tools, and tell the paying millions it's
time for another upgrade. ;>
--
Chris Gray
phun...@quuxuum.org
In article <Pine.A41.3.95a.980205151759.60072B-100000@sp068>,
"Alan J. Flavell" <fla...@mail.cern.ch> wrote:
>
> On Thu, 5 Feb 1998, Jedi Master Yoda wrote:
>
> > JM "[INLINE] elcome to the soclogo.gif (21K) [Society for Web
> > Accessibility Logo] [ISMAP]" Y
>
> Neatly put!
Lovely!
>
> Phundria seems to go into the issues in more detail:
>
> http://www.homeusers.prestel.co.uk/pax/phun/onlineawards/pages/how.html
>
> extract: "There is a risk that ALT texts might make images intelligible
> to browsers with images turned off, so that visitors to the site might
> avoid viewing them"
>
> ;-}
We're delighted to accept nominations of suitable sites from contributors
to c.i.w.a.h for inclusion in our OnlineAwards section. We'd particularly
like to know about European and UK sites that are paid for out of public
funds.
Custard Pies Dept.,
Phundria
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Arjun Ray
In <34d9aba5....@news.eunet.no>,
to...@online.no (Tor Iver Wilhelmsen) writes:
[ On bogosities such as <dir><dir><dir> ]
| Howerver: If it "prioritizes" error recovery,
Error recovery in the Mosaic spawn is mostly if not entirely mythical.
The processing paradigm is basically:
<tag> == command/procedure
For instance, what happens with this:
<dir>Some text
<ul>More text
</dir>Even more text
</ul>
Yes, this is utterly broken HTML. But consider an *implementation
strategy* modeled on the following CSS-style pseudo code (i.e.
pattern-action pairs) to be applied in a context-free fashion:
dir { indent: in }
/dir { indent: out }
ul { indent: in }
/ul { indent: out }
Moral: there's no such thing as error recovery without error
*detection* first.
That said, it's likely that IE4 probably differs from the rest in this
regard: the extensive support for an object model would suggest that
it has some notion of elements internally, as opposed to the see-a-tag
do-something approach so many people seem to like.
:ar
Mike Piff
Arjun Ray wrote in message <34daa494....@news.nyct.net>...
> dir { indent: in }
> /dir { indent: out }
> ul { indent: in }
> /ul { indent: out }
I like it, I like it! Let's keep it simple!
Now we have the makings of HTML5, and the DTD will be half a page long.
In fact, let's have a <tab> element to tab, an <li> to produce a marker and
get rid of all that logical markup rubbish!!! That will keep the punters happy. ;-)
Mike Piff
Paul Clark
Arjun Ray wrote:
> Moral: there's no such thing as error recovery without error
> *detection* first.
Very true.
> That said, it's likely that IE4 probably differs from the rest in this
> regard: the extensive support for an object model would suggest that
> it has some notion of elements internally, as opposed to the see-a-tag
> do-something approach so many people seem to like.
Yes, but to do this its error recovery only has to enforce correct
nesting (=either ignore end-tags you weren't expecting, or unwind until
you would expect it, or some tag-specific combination). It doesn't have
to know about DTD structure rules, or if it does, it has to ignore them,
otherwise the object model will not be what the attached script
'expects', as the original poster pointed out.
This is the crunch really, isn't it. Even if you had a perfect DTD
validating browser, what can it do with all the awful input that people
are expecting to still work? Someone on ciwah (Daniel Greene, in
<6b912h$hcg$1...@ha2.rdc1.sdca.home.com>, "The Sky Is Falling Down!!!")
recently said:
>...am I the only HTML/CSS author who is having a near-schizophrenic
>panic attack from how buggy the browsers out there are?...
One might turn it round and say:
>...am I the only browser author who is having a near-schizophrenic
>panic attack from how buggy the HTML/CSS out there is?
As a browser author you can't really get your users involved in the war
against bad HTML - they don't have (and shouldn't need to have) any
understanding of the issues. Neither does it seem satisfactory to let
bad HTML go past without comment when authors are 'testing' (ahem!)
their HTML. The problem is that authors are users too, but in different
contexts.
The best solution seems to be a (reluctant) simulation of the
non-validating browsers, while giving an prominent index of validation
quality to both authors and end-viewers - it'll only take a few VP's
Marketing to say "Oi! My browser says your HTML is crap! Fix it!" to
sort things out.
Of course, it'll be a bit embarrassing for some browser vendors when
their own sites, and the sites created with their tools, have little
pictures of shanty-town shacks (or whatever) in the toolbar. Doesn't
bother some of us, though ;-)
Paul
--
Paul Clark mailto:p...@sysmag.com
Systems Magic Ltd. http://www.sysmag.com
Paul Clark
Not so much HTML 5.0 as ASCII 1.0, I think. Remember all those useful
things like SI and SO? Bring back golfball teletypes, I say!
Mike Piff
Paul Clark wrote in message <34DB031F...@sysmag.com>...
>This is the crunch really, isn't it. Even if you had a perfect DTD
>validating browser, what can it do with all the awful input that people
>are expecting to still work?
Interesting! I noticed while doing ASPs that some of the error messages
from queries got lost if I executed the query after opening a <select> element.
Here is an example to illustrate why: Try this in IE4.
<form method="post" action="">
<select name="option">
<h1>You can choose between the following options:
<option value="a">a</option>
<option value="b">b</option>
or not as the case might be...
</select>
</form>
Now, isn't that fascinating? The author clearly expects the text to appear, but
it doesn't. Why enforce the rules here and not for <div><div>? This hypothetical
bad-HTML-producing user had better complain!
And what happens in NC4.04? The first line of text doesn't appear, but the second
line appears in the second option...
You see, leaving error recovery to chance doesn't necessarily please anyone!
Mike
Arjun Ray
In <6besvu$qp6$1...@bignews.shef.ac.uk>,
"Mike Piff" <M.P...@shef.ac.uk> writes:
| I like it, I like it! Let's keep it simple!
Why not *really* simple?
| Now we have the makings of HTML5, and the DTD will be half a page long.
Why bother with a DTD?
| In fact, let's have a <tab> element to tab, an <li> to produce a marker
No no no. Call a spade a spade. Toss the LI (who needs a "List Item"?)
for a <marker>.
| and get rid of all that logical markup rubbish!!!
Yep. Get rid of: UL, OL, DIR, LI, DL, DT, DD, DIV, H1-H6, etc., the
lot. Instead, work with: Indent, Color, Size, Tab, NewLine, Center,
and a few more, er, primitives (in this era of feelgoods, these should
probably be called "advanceds" instead?) that escape me just now.
Oops, I just remembered MARKER.
| That will keep the punters happy. ;-)
And, not to forget, call it all "advanced technology for the majority"
or somesuch -- never mind that the roff family is 20 years old -- and
have a media blitz to that effect. Perfect.
:ar
Arjun Ray
| Even if you had a perfect DTD validating browser, what can it do with
| all the awful input that people are expecting to still work?
Why not toss it into a tag-slurper helper app? The stuff *was* written
for bloated trailing-edge crippleware, after all. Not to mention that
the care that went into its preparation says everything about it: high
turnover rate, short half-life. Seriously, you should look into what
DTD-aware browsers such as Panorama can do already, and how its power
depends critically on structure-controlled data.
Writing such a browser to do something *intelligent* with tag-soup --
which was *intended* for stupid processors -- is a waste of time.
| >...am I the only browser author who is having a near-schizophrenic
| >panic attack from how buggy the HTML/CSS out there is?
Depends not only on what you want to support, but also why.
| As a browser author you can't really get your users involved in the
| war against bad HTML - they don't have (and shouldn't need to have)
| any understanding of the issues. Neither does it seem satisfactory
| to let bad HTML go past without comment when authors are 'testing'
| (ahem!) their HTML. The problem is that authors are users too, but
| in different contexts.
That's the issue isn't it? Authors using browsers as "validators", and
the lack or disuse of structure-aware *editors*.
| The best solution seems to be a (reluctant) simulation of the
| non-validating browsers, while giving an prominent index of validation
| quality to both authors and end-viewers - it'll only take a few VP's
| Marketing to say "Oi! My browser says your HTML is crap! Fix it!" to
| sort things out.
Your real problem is to put that browser in front of the VP, when all
he may happen to read in the trade and marketing literature is frantic
bleating and braying about the glories of the Tweedles. It's important
to realize that the true market of the tag-slurpers is the people
charmed that they can actually get paid to toss tag salad. They will
continue to push their Wowser Du Jour at end-viewers, for obvious
reasons. And they won't have the foggiest idea of what your browser
could offer instead.
:ar
Arjun Ray
| > Moral: there's no such thing as error recovery without error
| > *detection* first.
|
| Very true.
And completely buried under a slew of comfortable shibboleths. There
are hierophants and hagiographers who feel compelled to justify the
popularity of the Mosaic spawn, in case there are lurkers who haven't
seen the Right Way or learnt the Right Think. And so they attribute
all sorts of praiseworthy feelgoods to their beloved totems: "robust",
"sophisticated", "advanced" etc. etc. The post hoc fairy tales about
these tag-slurpers supposedly "recovering" from "bad HTML" is no more
than just that: an effort to obfuscate the stupidity of reducing
markup to isolated procedural primitives, when the movement away from
that started nearly thirty years ago. See
<URL:http://www.sgmlsource.com/history/index.htm>
The fact of the matter is that the Mosaic spawn process *correct HTML*
only by accident! The *design*, such as it is, addresses a different
syntax (and implied semantics) altogether. This is why the forms of
correct HTML that *are* recognized by the Mosaic spawn constitute a
subset of valid syntax: that subset which coincidentally happens to
square with their RTFM-challenged notion of find-a-tag. Consider, for
example:
<!DOCTYPE HTML "-//IETF//DTD HTML 2.0//EN" [
<!ENTITY do-it "You can have it done" >
]>
<TITLE/Trilemma/
<P/Of these three:/
<UL/
<LI/&do-it; cheap./
<LI/&do-it; fast./
<LI/&do-it; right.//
<P/Pick any <EM/two/./
Check this with the SGML-based validators, and then try it with a tag
slurper. It may even be instructive to see the handling of a fragment
such as this:
<UL<LI>First item</LI<LI>Second item</LI</UL>
which, in the Mosaic spawn, rates to be "equivalent" to this:
<UL>First item</LI>Second item</LI>
Considering that the syntax involved has been part of an international
standard since 1986, any and all talk of "support for open standards"
emanating from certain quarters is a colossal disingenuous fraud.
:ar
Robert F. Harrison
On Sat, 7 Feb 1998 00:44:58 GMT, ar...@nmds.com (Arjun Ray) wrote:
>In <6besvu$qp6$1...@bignews.shef.ac.uk>,
>"Mike Piff" <M.P...@shef.ac.uk> writes:
>
>| I like it, I like it! Let's keep it simple!
>
>Why not *really* simple?
>
>Yep. Get rid of: UL, OL, DIR, LI, DL, DT, DD, DIV, H1-H6, etc., the
>lot. Instead, work with: Indent, Color, Size, Tab, NewLine, Center,
>and a few more, er, primitives (in this era of feelgoods, these should
>probably be called "advanceds" instead?) that escape me just now.
>Oops, I just remembered MARKER.
Actually, I believe there was a proposal for an HTML a few steps down
the road where the only tag is <END> with absolutely nothing else
allowed in the document at all. As far as I'm concerned, there are a
lot of sites that could benefit by compliance with that.
Alan J. Flavell
On Sat, 7 Feb 1998, Arjun Ray wrote:
> Yep. Get rid of: UL, OL, DIR, LI, DL, DT, DD, DIV, H1-H6, etc., the
> lot. Instead, work with: Indent, Color, Size, Tab, NewLine, Center,
> and a few more, er, primitives (in this era of feelgoods, these should
> probably be called "advanceds" instead?) that escape me just now.
> Oops, I just remembered MARKER.
How about SPACER? Is that "primitive" enough for them? :-{
Chris Gray
> In <34DB031F...@sysmag.com>, Paul Clark <p...@sysmag.com> writes:
>
> | Even if you had a perfect DTD validating browser, what can it do with
> | all the awful input that people are expecting to still work?
>
> Why not toss it into a tag-slurper helper app? The stuff *was* written
> for bloated trailing-edge crippleware, after all.
Excellent idea! How about the following approach:
1. Try to parse the document as HTML. Employ reasonable error recovery
techniques(*), but increment a bogosity counter each time.
2. If a user-defined threshold is reached, pop up a "document bwoken"
message and offer to open it in "mosaic mode".
(*)IOW behave much as the nsgmls-based validators do: closing elements
on encountering inadmissible content, etc..
--
Chris Gray
Mike Piff
Alan J. Flavell wrote in message ...
I think what you really need is tabstops. Tabstops will solve all problems.
Tabstops are available in all bespoke wordprocessing programs and
mechanical typewriters. Never underestimate tabstops...
Tabstops---the true tool for the visual age...
Now---with DYNAMIC tabstops...
Mike
>
Arjun Ray
In <GRAYC.98F...@btm0qt.btm0qt>,
| In article <34dbd798....@news.nyct.net> ar...@nmds.com (Arjun Ray) writes:
| > In <34DB031F...@sysmag.com>, Paul Clark <p...@sysmag.com> writes:
| >
| > | Even if you had a perfect DTD validating browser, what can it do with
| > | all the awful input that people are expecting to still work?
| >
| > Why not toss it into a tag-slurper helper app? The stuff *was* written
| > for bloated trailing-edge crippleware, after all.
|
| Excellent idea! How about the following approach:
|
| 1. Try to parse the document as HTML. Employ reasonable error recovery
| techniques(*), but increment a bogosity counter each time.
|
| 2. If a user-defined threshold is reached, pop up a "document bwoken"
| message and offer to open it in "mosaic mode".
Discussing this on an ISP newsgroup in Summer '95, I called it "bozo
mode". Somebody promptly provided a set of icons for a toolbar button:
the idea was to have a clown face, which would gradually turn to a
frown and then eventually gag, all the while changing color too, as
the bogosities accumulated. Selecting the bozo button (which would
remain grayed out until the first brokenness) would immediately stop
any rational HTML processing and reprocess the file in "bozo mode".
Back then, this was a serious consideration: missing end-quotes still
"worked", A <TITLE> anywhere in the file still changed the window
title, entity names were "recognized" as substrings, and so on (not to
mention that Netscape's "new and improved" brainlessness with comment
declarations has just appeared.) Even some of the "perfeshnal tools"
hitting the market then were incorporating these bogosities as SOP.
For instance, Sandstone Technologies' Visual Parse (overall, a very
good product) had an "HTML grammar" as an already prepared module,
according to which missing end-quotes "worked". Email correspondence
with one of the principals of the company, suggesting that it be
called a "Mosaic grammar" and a correct grammar be provided also so
that developers could make an informed choice, went nowhere. Of
course, a few months later Netscape 2.0 had everybody rethinking all
of this, but that's another story.
But even today, I think the issue of valid syntax is still relevant.
If there were an open forum such as the IETF's HTML WG, I would
seriously consider re-opening the discussion.
<URL:http://www.nyct.net/~aray/htmlwg/rcs.html>
:ar
Chris Gray
> In <GRAYC.98F...@btm0qt.btm0qt>,
> gr...@btm0qt.btm0qt (Chris Gray) writes:
> | [...] How about the following approach:
> |
> | 1. Try to parse the document as HTML. Employ reasonable error recovery
> | techniques(*), but increment a bogosity counter each time.
> |
> | 2. If a user-defined threshold is reached, pop up a "document bwoken"
> | message and offer to open it in "mosaic mode".
>
> Discussing this on an ISP newsgroup in Summer '95, I called it "bozo
> mode". Somebody promptly provided a set of icons for a toolbar button:
> the idea was to have a clown face, which would gradually turn to a
> frown and then eventually gag, all the while changing color too, as
> the bogosities accumulated. Selecting the bozo button (which would
> remain grayed out until the first brokenness) would immediately stop
> any rational HTML processing and reprocess the file in "bozo mode".
Hm, that's interesting: I think it would be around then that Alexander
Clauss started work on his CAB browser. CAB displays a frowning face
on the menu bar when it encounters syntax errors; clicking on the face
yields a message such as "zu viel </B>, </I> oder </TT>". Maybe he
was inspired by this discussion?
--
Chris Gray
Cowboy
"Mike Piff" <M.P...@shef.ac.uk> wrote:
>OK, <dir> is deprecated, but that means we should be trying to get =
>people to use
>stylesheets instead, and what better platform than IE4? (Unless you use =
>a Unix box.)
>
>Anyway, according to the HTML4 specification, <dir> only allows <li> =
>content, and excludes
>block-level markup, eg, nested <dir> elements.
>
>So, what does IE4 do when it encounters=20
>
><dir><dir><dir>
>
>where someone is using it as a tab-stop? It nests the tabbing. :-(
>
>Please, Microsoft, if you want to get people to use HTML4, CSS, etc, =
>change this behaviour
>so that any block-level content terminates a <dir> , the same as <p> =
>terminates another <p>.
><dir> is no more nestable than <p> is!
>
>Mike Piff
>
>--=20
>http://www.shef.ac.uk/~cs1mjp mailto:M.P...@shef.ac.uk
>
HTML 4 is not approved yet; the jury is out. Microsoft would like to
see all of its implementation of things made as a standard, but this
certainly scares me. Just work with it, you're gonna have to change
your site in the future anyway.
GB
mr. freedom X
Cowboy wrote in message ...
>HTML 4 is not approved yet; the jury is out.
Come in from the North forty and leave them cows alone. HTML 4.0 became a
recommendation on 18-Dec-1997.
>Microsoft would like to see all of its implementation
>of things made as a standard, but this certainly
>scares me.
Mooooooo!
later,
gordon
Liam Quinn
On Tue, 17 Feb 1998 23:50:35 GMT, goalbld@NoOoO...SPAMmindspring.com
(Cowboy) wrote:
>HTML 4 is not approved yet
Then what is this: <http://www.w3.org/Press/HTML4-REC>?
[Follow-ups narrowed]
--
Liam Quinn
Web Design Group Enhanced Designs, Web Site Development
http://www.htmlhelp.com/ http://enhanced-designs.com/
Russell Steven Shawn O'Connor
In article <34ea2206...@news.mindspring.com>,
Cowboy <goalbld@NoOoO...SPAMmindspring.com> wrote:
>
>HTML 4 is not approved yet; the jury is out. Microsoft would like to
>see all of its implementation of things made as a standard, but this
>your site in the future anyway.
HTML 4.0 became a W3C Recommendation on 1997-12-18.
--
Russell O'Connor roco...@uwaterloo.ca
<URL:http://www.undergrad.math.uwaterloo.ca/%7Eroconnor/>
"And truth irreversibly destroys the meaning of its own message"
-- Anindita Dutta, "The Paradox of Truth, the Truth of Entropy"