CSS versus HTML tables

[Tim]

Re: CSS versus HTML tables

Michael Rozdoba wrote:
[color=blue][color=green]
>> Indeed. Given the motivation was to present guidelines on how browser
>> authors can adopt a structured approach to parsing broken html, it
>> does leave one feeling rather down.[/color][/color]


"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue]
> At the risk of triggering apoplexy all round, ponder what would happen if
> browsers adopted the proposals in a fairly consistent way. Suppose that (say)
> 80% of web pages can be handled by that set of proposals in a consistent way.
>
> In effect, this would define a new de facto standard, "HTML 4.01 Repairable",
> which 80% of web sites would comply with.
>
> Gosh - widespread standards-compliance! Just not a de jure standard - unless
> it got recommended formally.[/color]

You don't work for Microsoft, by any chance? (Let's redesign the specs
to suit how our software behaves, rather than redesign our broken
software to adhere to the specs.)

A fantastic improvement to web browsers would be a refusal to display
broken HTML, instead displaying a full-screen, bright red, FAILED
response. Then a few idiot web authors might *instantly* find out that
they've got broken HTML, and fix it. They'd have to if they knew that
nobody was going to get to see their broken HTML.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.

[Barry Pearson]

Re: CSS versus HTML tables

Tim wrote:
[snip][color=blue]
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
>[color=green]
>> At the risk of triggering apoplexy all round, ponder what would
>> happen if browsers adopted the proposals in a fairly consistent way.
>> Suppose that (say) 80% of web pages can be handled by that set of
>> proposals in a consistent way.
>>
>> In effect, this would define a new de facto standard, "HTML 4.01
>> Repairable", which 80% of web sites would comply with.
>>
>> Gosh - widespread standards-compliance! Just not a de jure standard
>> - unless it got recommended formally.[/color]
>
> You don't work for Microsoft, by any chance? (Let's redesign the
> specs to suit how our software behaves, rather than redesign our
> broken software to adhere to the specs.)[/color]

I thought there was a risk of apoplexy! Stay calm. (And it was an IBM
principle before that: "it isn't a bug, it's a feature").

No - I used to work for a different company, in the architecture group, and we
were thought of as fanatical ruthless assassins, who would wipe out a design
just with the phrase "it isn't architectural". But that attitude had its
place - we were developing a secure mainframe system that needed the potential
to evolve for decades. We were doing so in an environment where we could (at
least in theory) control such things.

But the web isn't like that. There is no plausible way to "redesign our broken
pages to adhere to the specs". They are out there, and they won't go away.
More are added every day - perhaps between 100,000 & 1 million (or perhaps
lots more?) invalid pages every day. And there is no reason at the moment for
that to stop.

There is actually nothing wrong with the principle of changing the spec. to
match practice. For example, parts of CSS2.1 appear to be exactly like that -
making parts of CSS match what browsers do.
[color=blue]
> A fantastic improvement to web browsers would be a refusal to display
> broken HTML, instead displaying a full-screen, bright red, FAILED
> response. Then a few idiot web authors might *instantly* find out
> that they've got broken HTML, and fix it. They'd have to if they
> knew that nobody was going to get to see their broken HTML.[/color]

Any browser that tried that would not be used, except by a few purists! Why
would people who want to browse the web ever consider such a browser? They
want to access whatever they are after without fuss. I now write valid 4.01
Strict, and would like a browser that would easily validate my pages while
there were still on my PC. But I *use* the web with a tolerant browser that
most authors have checked their pages against - IE 6. All I really want is to
see the pages as the author intended, which probably means as IE 6 renders
them.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Michael Rozdoba]

Re: CSS versus HTML tables

Barry Pearson wrote:

[snip]
[color=blue]
> A technique for part of that (table layout) that I used for months, and still
> do sometimes, was to browse (IE) with a local CSS containing:
> table { border: 1px dotted blue; }
>
> Obviously that isn't nearly as good as having proper statistics, but variants
> on this can be useful for personal reasons. (And my crude estimate is about
> 99% of the pages I saw used them!)[/color]

Quite believable. I'm sure they were all displaying tabular data too...
And yes, I have read the previous long threads on such discussions which
you're so fond of ;)

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Michael Rozdoba]

Collecting validation statistics (Was: CSS versus HTML tables)

Nick Kew wrote:
[color=blue]
> In article <40353fd3$0$245 89$fa0fcedb@lov ejoy.zen.co.uk> ,[/color]
[color=blue]
> Interesting you should mention that: there are a few people working right
> now on adding validation (fully local, not using a web-based svc) to MSIE.
> It appears as an additional bar at the top of the browser, and could
> presumably be extended to collect stats.
>
> When your post reaches google I'll point Bjoern at it and see if he thinks
> this looks like an extension he might be interested to pursue.[/color]

No harm in raising the idea.
[color=blue][color=green]
>>Does this seem at all feasible? I wonder if any of the developers would
>>consider the idea.[/color]
>
> I don't mind helping out with a validation component the opensource browsers
> could incorporate, but I don't have the time or the hardware to start hacking
> browser code itself.[/color]

I don't know enough about sampling, but to get relevant stats, one would
need many users to ensure a representative cross section of usage, if
the stats are to be indicative of general web content. Other issues
would need to be addressed - the scheme obviously needs to be at the
choice of the user, but one really needs to persuade potential users to
leave the option on long term; privacy issues would need to be
convincingly addressed.

It would be best if this could be integrated into a mainstream browser
release for all of these reasons, however your suggestion would be an
interesting test case.

Any ideas on how to persuade users to take up such a feature? Maybe
teams with rankings according to how many pages processed, ala
distributed computing projects?

As another approach to the design problem, though this is getting away
from the above, one could adopt a web proxy system, which would give a
system which was compatible with any browser.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Nick Kew]

Re: Collecting validation statistics (Was: CSS versus HTML tables)

In article <40367def$0$245 97$fa0fcedb@lov ejoy.zen.co.uk> ,
Michael Rozdoba <mroz@nowhere.i nvalid> writes:
[color=blue][color=green]
>> When your post reaches google I'll point Bjoern at it and see if he thinks
>> this looks like an extension he might be interested to pursue.[/color][/color]

Now done.
[color=blue]
> No harm in raising the idea.[/color]

http://sourceforge.net/projects/ieqabar

[color=blue]
> I don't know enough about sampling, but to get relevant stats, one would
> need many users to ensure a representative cross section of usage, if
> the stats are to be indicative of general web content. Other issues[/color]

Indeed - I'm now planning to raise this at the next scheduled meeting
of W3C/qa-dev.
[color=blue]
> As another approach to the design problem, though this is getting away
> from the above, one could adopt a web proxy system, which would give a
> system which was compatible with any browser.[/color]

That's close to another idea that's been discussed (in the context
of accessibility).

Are you expressing a "would-be-nice" wish, or might you be interested
to participate actively in setting up such a study? Feel free to email
me privately if you'd care to discuss getting involved in a W3C context.
(Disclaimer: I don't work for W3C, let alone speak for them or invite
third parties to participate in working groups. I just think the
ideas you're putting forward have potential to make you welcome).

--
Nick Kew

[Brian]

Re: CSS versus HTML tables

Barry Pearson wrote:[color=blue]
> Tim wrote:
>[color=green]
>> Barry Pearson <news@childsupp ortanalysis.co. uk> wrote:
>>[color=darkred]
>>> At the risk of triggering apoplexy all round, ponder what would
>>> happen if browsers adopted the proposals in a fairly
>>> consistent way.
>>>
>>> In effect, this would define a new de facto standard, "HTML
>>> 4.01 Repairable", which 80% of web sites would comply with.[/color]
>>
>> You don't work for Microsoft, by any chance? (Let's redesign the
>> specs to suit how our software behaves, rather than redesign our
>> broken software to adhere to the specs.)[/color]
>
> I thought there was a risk of apoplexy! Stay calm.[/color]

Except that Tim's response was not apoplectic, and was perfectly calm.
You aren't trolling for a fight, are you?

--
Brian (follow directions in my address to email me)

http://www.tsmchughs.com/

[Michael Rozdoba]

Re: Collecting validation statistics (Was: CSS versus HTML tables)

Nick Kew wrote:

[snip]
[color=blue]
> Are you expressing a "would-be-nice" wish, or might you be interested
> to participate actively in setting up such a study? Feel free to email
> me privately if you'd care to discuss getting involved in a W3C context.
> (Disclaimer: I don't work for W3C, let alone speak for them or invite
> third parties to participate in working groups. I just think the
> ideas you're putting forward have potential to make you welcome).[/color]

Taken to email.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Tilman Hesse]

Re: CSS versus HTML tables

(Nick Kew in comp.infosystem s.www.authoring.stylesheets)
[color=blue]
>In article <40353fd3$0$245 89$fa0fcedb@lov ejoy.zen.co.uk> ,
> Michael Rozdoba <mroz@nowhere.i nvalid> writes:
>[color=green]
>> When considering how to collect this info, the thesis author listed as
>> an option using a customised browser to do the validation, but dismissed
>> this due to time constraints, needing to reach a wide browser user base
>> & as users would not be happy with this going on behind their backs.[/color]
>
>Interesting you should mention that: there are a few people working right
>now on adding validation (fully local, not using a web-based svc) to MSIE.
>It appears as an additional bar at the top of the browser, and could
>presumably be extended to collect stats.[/color]

Or they could make it a plugin to Frontpage.



Tilman
--
Der statistische Tote ist dir eal. Der stochastische Tote bist du selber.

[DU]

Re: CSS versus HTML tables

Matthias Gutfeldt wrote:
[color=blue]
> DU wrote:
>[/color]

[snipped]
[color=blue]
> For validation purposes there's no need to include the Doctype. The W3C
> validator has a Doctype override feature.
>[/color]

I'm sorry. I do not understand... You say the W3C validator has a
Doctype override feature? But this is not an automatic feature like the
WDG validator. You manually have to select a doctype decl. in case there
is no doctype declaration.
[color=blue]
>
>[color=green]
>> The doctype decl. is important for other purposes: to trigger well
>> above 80% of all browsers (MSIE 6, all Mozilla-based browsers, Opera
>> 7.x) in use out there into standards compliant rendering mode
>> (preferable for tons of reasons) or not. No doctype decl.
>> automatically means your webpage will always be using a backward
>> compatible rendering mode where errors are deliberately "corrected" ,
>> tolerated and dealt with.[/color]
>
>
> The Doctype switch is an abomination.
>
>
> Matthias
>[/color]

Well, abomination is a strong word. If Microsoft drops entirely this
doctype trigger in MSIE 7 and only renders documents according to W3C
web standards, then this doctype trigger will have served its purpose
with MSIE 6: to give time to people to upgrade their markup code.

DU

[Tim]

Re: CSS versus HTML tables

"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue][color=green][color=darkred]
>>> At the risk of triggering apoplexy all round, ponder what would
>>> happen if browsers adopted the proposals in a fairly consistent way.
>>> Suppose that (say) 80% of web pages can be handled by that set of
>>> proposals in a consistent way.
>>>
>>> In effect, this would define a new de facto standard, "HTML 4.01
>>> Repairable", which 80% of web sites would comply with.[/color][/color][/color]


Tim wrote:
[color=blue][color=green]
>> You don't work for Microsoft, by any chance? (Let's redesign the
>> specs to suit how our software behaves, rather than redesign our
>> broken software to adhere to the specs.)[/color][/color]


"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue]
> I thought there was a risk of apoplexy! Stay calm. (And it was an IBM
> principle before that: "it isn't a bug, it's a feature").
>
> No - I used to work for a different company, ...[snip]...
>
> But the web isn't like that. There is no plausible way to "redesign our broken
> pages to adhere to the specs". They are out there, and they won't go away.
> More are added every day - perhaps between 100,000 & 1 million (or perhaps
> lots more?) invalid pages every day. And there is no reason at the moment for
> that to stop.[/color]

Only because software is too tolerant. We won't get new correct pages,
if the browsers don't insist on it. We've got a new standard emerging,
XHTML, which is supposed to be correct or fail absolutely. If that
actually happened, all would be well. But no, we're getting hacks and
work-arounds, already (the clueless are demanding things be broken to
accommodate them). It could be done, as it's a new standard, it doesn't
have to accommodate old non-compliant software, it has its fresh start.
We have the ability to say this is XHTML treat it as such, and this is
HTML treat it as such (differently than each other).
[color=blue]
> There is actually nothing wrong with the principle of changing the spec. to
> match practice. For example, parts of CSS2.1 appear to be exactly like that -
> making parts of CSS match what browsers do.[/color]

There is. All those that have designed something to the spec (data or
programs), doing it properly, suddenly have had their designs ruined.

Those changes to CSS are an example of what's bad about such changes.
CSS goes even one step worse as not having any way to define whether its
CSS 1 or 2. At least HTML has the doctype, which could be intelligently
used to handle pages (though it never is).

How can I design something without a target? How can I make something
work if the target keeps changing?
[color=blue][color=green]
>> A fantastic improvement to web browsers would be a refusal to display
>> broken HTML, instead displaying a full-screen, bright red, FAILED
>> response. Then a few idiot web authors might *instantly* find out
>> that they've got broken HTML, and fix it. They'd have to if they
>> knew that nobody was going to get to see their broken HTML.[/color][/color]
[color=blue]
> Any browser that tried that would not be used, except by a few purists! Why
> would people who want to browse the web ever consider such a browser? They
> want to access whatever they are after without fuss. I now write valid 4.01
> Strict, and would like a browser that would easily validate my pages while
> there were still on my PC. But I *use* the web with a tolerant browser that
> most authors have checked their pages against - IE 6. All I really want is to
> see the pages as the author intended, which probably means as IE 6 renders
> them.[/color]

You've written something to a specification, yet feel that it'd be okay
for that specification to be changed? ;-) (According to your prior
comments.)

I still say it'd be a fantastic improvement to web browsers (emphasis on
the plural, i.e. all of them). If they all failed to render broken
pages, there'd be very few broken pages. Just the same as software
which crashes and doesn't do its job, doesn't become widely accepted
(though somehow Microsoft manages to evade natural selection). ;-)

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.

[Alan J. Flavell]

Re: CSS versus HTML tables

On Sun, 22 Feb 2004, Tim wrote:
[color=blue][color=green]
> > But the web isn't like that. There is no plausible way to
> > "redesign our broken pages to adhere to the specs". They are out
> > there, and they won't go away. More are added every day - perhaps
> > between 100,000 & 1 million (or perhaps lots more?) invalid pages
> > every day. And there is no reason at the moment for that to stop.[/color]
>
> Only because software is too tolerant. We won't get new correct pages,
> if the browsers don't insist on it.[/color]

Unfortunately, we won't get new intolerant browsers, because their
developers know (or at least believe) that their users will compare
them unfavourably to MSIE (which doesn't even rate as a WWW browser).
[color=blue]
> We've got a new standard emerging, XHTML, which is supposed to be
> correct or fail absolutely. If that actually happened, all would be
> well. But no, we're getting hacks and work-arounds, already (the
> clueless are demanding things be broken to accommodate them).[/color]

Welcome to Appendix C, from the W3C. Who's clueless now?
[color=blue]
> It could be done, as it's a new standard, it doesn't
> have to accommodate old non-compliant software, it has its fresh start.[/color]

That was the original plan: the W3C even trademarked XHTML to give
the opportunity to take action against those who abused the privilege:
but the W3C seems to have got cold feet, and gave us Appendix C.
Which in turn gave us XHTML-flavoured tag soup.
[color=blue]
> We have the ability to say this is XHTML treat it as such, and this is
> HTML treat it as such (differently than each other).[/color]

And very few browsers which "treat it as such".
[color=blue][color=green]
> > There is actually nothing wrong with the principle of changing the
> > spec. to match practice. For example, parts of CSS2.1 appear to be
> > exactly like that - making parts of CSS match what browsers do.[/color][/color]

Not so very different from HTML3.2(spit), eh? Or am I one of the few
around here who actually remembers that disappointment?
[color=blue]
> There is. All those that have designed something to the spec (data or
> programs), doing it properly, suddenly have had their designs ruined.
>
> Those changes to CSS are an example of what's bad about such changes.
> CSS goes even one step worse as not having any way to define whether its
> CSS 1 or 2. At least HTML has the doctype, which could be intelligently
> used to handle pages (though it never is).
>
> How can I design something without a target? How can I make something
> work if the target keeps changing?[/color]

I was hoping for an improvement to font-size-adjust. Instead they
took it away altogether. Wibble.
[color=blue]
> I still say it'd be a fantastic improvement to web browsers (emphasis on
> the plural, i.e. all of them). If they all failed to render broken
> pages, there'd be very few broken pages.[/color]

But unless/until the great unwashed wake up to the fact that their
favourite operating system component isn't a WWW browser (which isn't
very likely: if the DoJ effectively conceded defeat, what hope does an
individual have?), that agenda isn't going to come to pass.
[color=blue]
> Just the same as software which crashes and doesn't do its job,
> doesn't become widely accepted[/color]

That'll be why everyone out there is running linux, right? (wrong,
unfortunately). Experience shows that in a head to head between
technical competence and marketing, marketing wins every time.
[color=blue]
> (though somehow Microsoft manages to evade natural selection). ;-)[/color]

You see? Despite UK accessibility legislation to the contrary, some
UK banks are still apparently telling their customers that WWW
browsers are not supported - they must use the operating system
component instead.

[Barry Pearson]

Re: CSS versus HTML tables

Tim wrote:
[snip][color=blue]
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:[/color]
[snip][color=blue][color=green]
>> But the web isn't like that. There is no plausible way to "redesign
>> our broken pages to adhere to the specs". They are out there, and
>> they won't go away. More are added every day - perhaps between
>> 100,000 & 1 million (or perhaps lots more?) invalid pages every day.
>> And there is no reason at the moment for that to stop.[/color]
>
> Only because software is too tolerant. We won't get new correct
> pages, if the browsers don't insist on it. We've got a new standard
> emerging, XHTML, which is supposed to be correct or fail absolutely.
> If that actually happened, all would be well. But no, we're getting
> hacks and work-arounds, already (the clueless are demanding things be
> broken to accommodate them). It could be done, as it's a new
> standard, it doesn't have to accommodate old non-compliant software,
> it has its fresh start. We have the ability to say this is XHTML
> treat it as such, and this is HTML treat it as such (differently than
> each other).[/color]

The web *isn't* too tolerant, by the desires of most of the people who publish
and use it and otherwise help to pay for it.
[color=blue][color=green]
>> There is actually nothing wrong with the principle of changing the
>> spec. to match practice. For example, parts of CSS2.1 appear to be
>> exactly like that - making parts of CSS match what browsers do.[/color]
>
> There is. All those that have designed something to the spec (data or
> programs), doing it properly, suddenly have had their designs ruined.[/color]

I said "... making parts of CSS match what browsers do". How does that ruin
someone's design? What happens to those designs in CSS2?

What this is doing is helping to turn a de facto standard into a de jure
standard. Sometimes, that can be a productive way of building standards.
[color=blue]
> Those changes to CSS are an example of what's bad about such changes.
> CSS goes even one step worse as not having any way to define whether
> its CSS 1 or 2. At least HTML has the doctype, which could be
> intelligently used to handle pages (though it never is).[/color]

I agree with that point. I'm uncomfortable with the idea of material, written
to a standard, that doesn't identify the standard. If it is guaranteed to
remain forward compatible, so a CSS written to (say) CSS1 looks *and* behaves
precisely like a subset of one written to CSS2 and CSS2.1, then OK. But that
doesn't appear to be the case.

[snip][color=blue][color=green]
>> Any browser that tried that would not be used, except by a few
>> purists! Why would people who want to browse the web ever consider
>> such a browser? They want to access whatever they are after without
>> fuss. I now write valid 4.01 Strict, and would like a browser that
>> would easily validate my pages while there were still on my PC. But
>> I *use* the web with a tolerant browser that most authors have
>> checked their pages against - IE 6. All I really want is to see the
>> pages as the author intended, which probably means as IE 6 renders
>> them.[/color]
>
> You've written something to a specification, yet feel that it'd be
> okay for that specification to be changed? ;-) (According to your
> prior comments.)[/color]

I wouldn't like 4.01 to change (and certainly not if previously valid pages
ceased to be valid!) But I see no objection in principle to having a 4.02,
with its own DOCTYPE.

I want browsers to render a valid 4.01 document according to the formatting
recommendations in the W3C material, for reasons similar to yours - I want my
design handled properly. But I want to use a tolerant browser when accessing
invalid material (whether because it hasn't a DOCTYPE or just doesn't conform
to the DTD).
[color=blue]
> I still say it'd be a fantastic improvement to web browsers (emphasis
> on the plural, i.e. all of them). If they all failed to render broken
> pages, there'd be very few broken pages. Just the same as software
> which crashes and doesn't do its job, doesn't become widely accepted
> (though somehow Microsoft manages to evade natural selection). ;-)[/color]

I use a lot of MS software, because on the whole it does the job I want. Yes,
W2000 & IE sometimes crash. (Although not nearly as often for me as claims I
hear - I would normally expect them to stay up for several days, perhaps a
week or two, at a time). But they typically do what I bought them for.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Re: CSS versus HTML tables

Alan J. Flavell wrote:[color=blue][color=green]
>>Barry Pearson wrote ...[/color][/color]
[snip][color=blue][color=green][color=darkred]
>> > There is actually nothing wrong with the principle of changing the
>> > spec. to match practice. For example, parts of CSS2.1 appear to be
>> > exactly like that - making parts of CSS match what browsers do.[/color][/color]
>
> Not so very different from HTML3.2(spit), eh? Or am I one of the few
> around here who actually remembers that disappointment?[/color]
[snip]

With the benefit of hind-sight, it appears that the pioneers of the web
created a free market-place, for new ideas & new features, that then ran out
of their control.

What else could/should they have done instead of HTML 3.2? I suspect that its
seeds were sown a few years earlier. Either by (somehow) not allowing
uncontrolled development, or by dramatically reducing the need for all the
additional features that became popular and had to be accommodated.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Brian]

Re: CSS versus HTML tables

Barry Pearson wrote:[color=blue]
>
> The web *isn't* too tolerant, by the desires of most of the people
> who publish and use it and otherwise help to pay for it.[/color]

I regard IE as a seriously flawed browser, especially after testing its
ability to handle content negotiation. (Google ciwa-site-design for the
gory details.) I was forced to remove what might other be a useful
feature because of IE/Win. This is a disservice to everyone.

--
Brian (remove "invalid" from my address to email me)

http://www.tsmchughs.com/

[Brian]

Re: CSS versus HTML tables

Barry Pearson wrote:
[color=blue]
> Alan J. Flavell wrote:
>[color=green][color=darkred]
>>> Barry Pearson wrote ...[/color][/color]
>[color=green][color=darkred]
>>>> There is actually nothing wrong with the principle of changing
>>>> the spec. to match practice.[/color]
>>
>> Not so very different from HTML3.2(spit), eh? Or am I one of the
>> few around here who actually remembers that disappointment?[/color]
>
> it appears that the pioneers of the web created a free market-place,
> for new ideas & new features, that then ran out of their control.[/color]

It appears to me that they caved to the marketing desires of Netscape
et. al., which produced a new de facto standard via "extensions ."
(Anyone familiar with the history of color television standards in the
U.S. will spot a familiar pattern.)
[color=blue]
> What else could/should they have done instead of HTML 3.2?[/color]

They should have rejected those extenstions, since they were not
practical. They should have released HTML 3.0. And they should have
moved ahead with stylesheets, which had already been proposed.

--
Brian (remove "invalid" from my address to email me)

http://www.tsmchughs.com/