[9fans] libhtml vs. <pre> tags

[9fans] libhtml vs. <pre> tags

[erik quanstrom]

as long as we're on the subject of html, it seems like
<pre> tags are not properly rendered by libhtml --
all the information gets to render() except the <pre>
formatting flag.

i'm working on fixing it, but was wondering if somebody
else has beat me to it.

erik

[9fans] libhtml vs. <pre> tags

[erik quanstrom]

to be more exact: this

<pre>
1	2
</pre>

yields 2 tokens

'1        ' ('1' + ' '*8)
'2'

render() never sees the <pre> tag and renderrunes()
eats the trailing spaces yielding

1 2

i'm not sure if this is the spec or not, but it's not what
one expects, based on most browsers.

erik

erik quanstrom <quanstro@quanstro.net> writes

| 
| as long as we're on the subject of html, it seems like
| <pre> tags are not properly rendered by libhtml --
| all the information gets to render() except the <pre>
| formatting flag.
| 
| i'm working on fixing it, but was wondering if somebody
| else has beat me to it.
| 
| erik

Re: [9fans] libhtml vs. <pre> tags

[Federico Benavento]

hi

On 10/19/05, erik quanstrom <quanstro@quanstro.net> wrote:
> to be more exact: this
>
> <pre>
> 1       2
> </pre>
>
> yields 2 tokens
>
> '1        ' ('1' + ' '*8)
> '2'
>
> render() never sees the <pre> tag and renderrunes()
> eats the trailing spaces yielding
>
> 1 2
>
I'm aware of this,

> i'm not sure if this is the spec or not, but it's not what
> one expects, based on most browsers.
>

You are right, there are a lot of things to be improved:
<pre>, <table>, justified text, etc.  And to
do this the whole render process need to be changed,
I still don't know how to solve this.
Charon solves this by using the Line struct (layout.b),
and braking the html items list into a list of Lines.
I don't want to brake the list of items,I'm short
of ideas about how to do this, but i'm still thinking.

Suggestions are welcome.

--
Federico G. Benavento

Re: [9fans] libhtml vs. <pre> tags

[erik quanstrom]

in my hasty reading of libhtml i was thinking that the tokenization is almost
correct. the only change needed is to not translate \t to 8 spaces. on output,

for rendering, perhaps the solution is to add a flag indicating that the output 
is <pre>-formatted and just memcpy() the text in render.

i was impressed with how little the tokenizing and rendering code was 
special cased, given how ad hoc html is. however, otoh, maybe <pre> should be
handled in a special manner, with the tokenizer just converting character
sets and entities and treating that result as one big Bytes*.

erik


Federico Benavento <benavento@gmail.com> writes

| 
| hi
| 
| On 10/19/05, erik quanstrom <quanstro@quanstro.net> wrote:
| > to be more exact: this
| >
| > <pre>
| > 1       2
| > </pre>
| >
| > yields 2 tokens
| >
| > '1        ' ('1' + ' '*8)
| > '2'
| >
| > render() never sees the <pre> tag and renderrunes()
| > eats the trailing spaces yielding
| >
| > 1 2
| >
| I'm aware of this,
| 
| > i'm not sure if this is the spec or not, but it's not what
| > one expects, based on most browsers.
| >
| 
| You are right, there are a lot of things to be improved:
| <pre>, <table>, justified text, etc.  And to
| do this the whole render process need to be changed,
| I still don't know how to solve this.
| Charon solves this by using the Line struct (layout.b),
| and braking the html items list into a list of Lines.
| I don't want to brake the list of items,I'm short
| of ideas about how to do this, but i'm still thinking.
| 
| Suggestions are welcome.

Re: [9fans] libhtml vs. <pre> tags

[Federico G. Benavento]

>in my hasty reading of libhtml i was thinking that the tokenization is almost
>correct. the only change needed is to not translate \t to 8 spaces. on output,

I don't think this is needed since when there is a <pre> tag,
libhtml set the Item->flag to IFwrap, so this item should be treated
in a different way, this is what abaco should do.

>for rendering, perhaps the solution is to add a flag indicating that the output 
>is <pre>-formatted and just memcpy() the text in render.

As I said the flag is already there, In my opinion libhtml is ok,
charon uses it (libhtml was a part of "I" web browser, which is a charon's translation
from limbo to c), what needs to be improved is abaco.

>i was impressed with how little the tokenizing and rendering code was 
>special cased, given how ad hoc html is. however, otoh, maybe <pre> should be
>handled in a special manner, with the tokenizer just converting character
>sets and entities and treating that result as one big Bytes*.

cheers

Federico G.Benavento

---
/bin/fortune:
The system is ready.

Re: [9fans] libhtml vs. <pre> tags

[Federico Benavento]

Now abaco handles <pre> text in a different way,
this a quick and dirty change, since when the line
width is bigger than the screen width the text is not
showed. I knew that this was easy to fix, but I didn't
because, right now, <table> is my problem.

cheers

On 10/21/05, Federico G. Benavento <benavento@gmail.com> wrote:
> >in my hasty reading of libhtml i was thinking that the tokenization is almost
> >correct. the only change needed is to not translate \t to 8 spaces. on output,
>
> I don't think this is needed since when there is a <pre> tag,
> libhtml set the Item->flag to IFwrap, so this item should be treated
> in a different way, this is what abaco should do.
>
> >for rendering, perhaps the solution is to add a flag indicating that the output
> >is <pre>-formatted and just memcpy() the text in render.
>
> As I said the flag is already there, In my opinion libhtml is ok,
> charon uses it (libhtml was a part of "I" web browser, which is a charon's translation
> from limbo to c), what needs to be improved is abaco.
>
> >i was impressed with how little the tokenizing and rendering code was
> >special cased, given how ad hoc html is. however, otoh, maybe <pre> should be
> >handled in a special manner, with the tokenizer just converting character
> >sets and entities and treating that result as one big Bytes*.
>
> cheers
>
> Federico G.Benavento
>
> ---
> /bin/fortune:
> The system is ready.
>
>


--
Federico G. Benavento

Re: [9fans] libhtml vs. <pre> tags

[Kenji Okamoto]

Hi,

> Now abaco handles <pre> text in a different way,
> this a quick and dirty change, since when the line
> width is bigger than the screen width the text is not
> showed. 

This font width problem is also seen when Japanese fonts
are used other than the case of <pre> tag.
This is very common also for other applications...

I'm not forcing you to fix this, rather just reporting.

Kenji

Re: [9fans] libhtml vs. <pre> tags

[Kenji Okamoto]

Awawawa---

I didn't want this to over the world, sorry everyone.

Kenji

Re: [9fans] libhtml vs. <pre> tags

[erik quanstrom]

okay, i was using htmlfmt to try to turn some <pre>-formatted
character tables into something useful. this is what i did:

rcsdiff html.c
===================================================================
RCS file: RCS/html.c,v
retrieving revision 1.1
diff -r1.1 html.c
84a85,100
> static void
> renderprerunes(Bytes* b, Rune* r)
> {
> 	char *s;
> 	int nr;
> 
> 	nr = r ? runestrlen(r) : 0;
> 	if (!nr)
> 		return;
> 	s = smprint("%.*S", runestrlen(r), r);
> 	growbytes(b, s, strlen(s));
> 	free(s);
> 	col = 0;			// just print it.
> 	inword = 0;
> }
> 
211c227,230
< 			renderrunes(t, it->s);
---
> 			if (il->state & IFwrap)
> 				renderrunes(t, it->s);
> 			else
> 				renderprerunes(t, it->s);

this does not fix the problem of converting \t → spaces
and "col = 0" in renderprerunes() is wrong. but it doesn't
look like col is reset when il->state == IFbrk or IFbrksp.

i still think this would be easier if everything inside
the <pre> were one token. that way we would know
when we would be done and be able to more easily/
accurately set the end state.

erik

Federico Benavento <benavento@gmail.com> writes

| 
| Now abaco handles <pre> text in a different way,
| this a quick and dirty change, since when the line
| width is bigger than the screen width the text is not
| showed. I knew that this was easy to fix, but I didn't
| because, right now, <table> is my problem.
| 
| cheers
| 
| On 10/21/05, Federico G. Benavento <benavento@gmail.com> wrote:
| > >in my hasty reading of libhtml i was thinking that the tokenization is almost
| > >correct. the only change needed is to not translate \t to 8 spaces. on output,
| >
| > I don't think this is needed since when there is a <pre> tag,
| > libhtml set the Item->flag to IFwrap, so this item should be treated
| > in a different way, this is what abaco should do.
| >
| > >for rendering, perhaps the solution is to add a flag indicating that the output
| > >is <pre>-formatted and just memcpy() the text in render.
| >
| > As I said the flag is already there, In my opinion libhtml is ok,
| > charon uses it (libhtml was a part of "I" web browser, which is a charon's translation
| > from limbo to c), what needs to be improved is abaco.
| >
| > >i was impressed with how little the tokenizing and rendering code was
| > >special cased, given how ad hoc html is. however, otoh, maybe <pre> should be
| > >handled in a special manner, with the tokenizer just converting character
| > >sets and entities and treating that result as one big Bytes*.
| >
| > cheers
| >
| > Federico G.Benavento

Re: [9fans] libhtml vs. <pre> tags

[erik quanstrom]

why can't long lines just wrap around? why do you need special processing?

-- erik

Federico Benavento <benavento@gmail.com> writes

| 
| Now abaco handles <pre> text in a different way,
| this a quick and dirty change, since when the line
| width is bigger than the screen width the text is not
| showed. I knew that this was easy to fix, but I didn't
| because, right now, <table> is my problem.
| 
| cheers

Re: [9fans] libhtml vs. <pre> tags

[Federico G. Benavento]

> why can't long lines just wrap around? why do you need special processing?

Because when I wrote that I was very tired,
and the changes needed where more than 10 lines of code :)

> 
> -- erik
> 

Federico G.Benavento

---
/bin/fortune:
Go suck on an infinite tube.

Re: [9fans] libhtml vs. <pre> tags

[erik quanstrom]

that's a very good reason.

erik

"Federico G. Benavento" <benavento@gmail.com> writes

| 
| > why can't long lines just wrap around? why do you need special processing?
| 
| Because when I wrote that I was very tired,
| and the changes needed where more than 10 lines of code :)

RE: [9fans] libhtml vs. <pre> tags

[Trickey, Howard W (Howard)]

> ...I knew that this was easy to fix, but I didn't
> because, right now, <table> is my problem.

And I predict <table> will remain your problem for quite some time.
I wrote charon and did the abortive attempt to convert it to c (i).

Tables have always been a complete bitch in rendering HTML. Part of the problem is that it is easy to inconsistently overspecify a table (e.g., the whole table must have width 3in but there are only two columns each of which must have width 2 in), and you have to experiment with, say, Internet Explorer, to see how it resolves the problem.

I'm pretty sure Tom Duff stopped work on mothra because he hit the table wall and couldn't think of an elegant way to get past it. I stopped work on i because I had another more important project, but I was fighting table bugs, mostly, at the end.

Good luck!

- Howard

RE: [9fans] libhtml vs. <pre> tags

[erik quanstrom]

elegant ... html. words that should not be used in positive conjunction.

"Trickey, Howard W (Howard)" <trickey@lucent.com> writes

| I'm pretty sure Tom Duff stopped work on mothra because he hit the table wall and couldn't think of an elegant way to get past it. [...]

Re: [9fans] libhtml vs. <pre> tags

[Wes Kussmaul]

Trickey, Howard W (Howard) wrote:

> you have to experiment with, say, Internet Explorer, to see how it resolves the problem.

Or Firefox, where you have the benefit of source code to look at.


-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group 
(village.com) ensure that only intended recipients receive your 
confidential messages.

RE: [9fans] libhtml vs. <pre> tags

[C H Forsyth]

> I'm pretty sure Tom Duff stopped work on mothra because he
> hit the table wall and couldn't think of an elegant way to get past it. 

a `table wall' sounds an interesting object!

i looked at adding tables to mothra and had a small go at it many years ago:
the problem (as i recall duff explained it) was that html up to mothra had no tables, and could
be rendered in a single pass, and mothra relied on that property.  adding tables breaks that.
i had a variant that (i suppose) could be regarded as doing what
diversions do in troff: shunt the table somewhere else to size it
and ponder it, then having assigned sizes, pull it back.
it wasn't easy in the structure of mothra and i'm not surprised
he stopped rather than rewrite it.

| > As I said the flag is already there, In my opinion libhtml is ok,
| > charon uses it (libhtml was a part of "I" web browser, which is a charon's translation
| > from limbo to c), what needs to be improved is abaco.

libhtml's rules might not be the same as charon's because chris locke
had several goes at re-doing charon's handling of various layouts
(my experience was that it did better than originally but i still find
sites that confuse it, possibly for reasons such as howard trickey's example).
there are plenty of sites still that display well in IE but not much else.

Re: [9fans] libhtml vs. <pre> tags

[Uriel]

On Fri, Oct 21, 2005 at 09:47:50AM -0400, Trickey, Howard W (Howard) wrote:
> And I predict <table> will remain your problem for quite some time.
> I wrote charon and did the abortive attempt to convert it to c (i).
> 
> Tables have always been a complete bitch in rendering HTML. 
Tables are a piece of cake compared to the CSS layout model. 

And web designers have been moving away from tables and to CSS for quite
some time.

> Good luck!
I think that to write a web browser this days you need more than just
luck.

What I would like to see is someone working on a replacement for the web
that follows the Plan 9 design style. (yea, it's in my TODO list, but who
knows when I will get to it, and I really would like to see what others
come up with)

uriel

Re: [9fans] libhtml vs. <pre> tags

[Wes Kussmaul]

Uriel wrote:

> What I would like to see is someone working on a replacement for the web
> that follows the Plan 9 design style. (yea, it's in my TODO list, but who
> knows when I will get to it, and I really would like to see what others
> come up with)

What you're talking about is what AJAX wants to be and would be if its 
creators knew about the Plan 9 way of doing things.

The noise level in the public square prevents the development of elegant 
things there. But that's not to say that elegant things can't be 
successfully introduced in the public square when they're ready.


-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group 
(village.com) ensure that only intended recipients receive your 
confidential messages.

Re: [9fans] libhtml vs. <pre> tags

[Uriel]

On Fri, Oct 21, 2005 at 02:45:56PM -0400, Wes Kussmaul wrote:
> What you're talking about is what AJAX wants to be and would be if its 
> creators knew about the Plan 9 way of doing things.
You got to be kidding me... 

AJAX: the web(which already was braindamaged from the start) +
JavaScript + XML; all pretending to be a WIMP application development
platform. The result is the most hideous monstrosity mankind has seen.
And the people at Google that created such monster shall burn in hell
for the rest of eternity.

When I hear AJAX I feel so much nausea I can't even reach for my MP5 and
I have to run for the bathroom to empty my stomach.


I want something like the acme Wiki but that is more general and works
across servers.

uriel

Re: [9fans] libhtml vs. <pre> tags

[Wes Kussmaul]

Uriel wrote:

> AJAX: the web(which already was braindamaged from the start) +
> JavaScript + XML; all pretending to be a WIMP application development
> platform. The result is the most hideous monstrosity mankind has seen.
> And the people at Google that created such monster shall burn in hell
> for the rest of eternity.
> 
> When I hear AJAX I feel so much nausea I can't even reach for my MP5 and
> I have to run for the bathroom to empty my stomach.

C'mon, don't hold back, tell us how you REALLY feel.


-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group 
(village.com) ensure that only intended recipients receive your 
confidential messages.

RE: [9fans] libhtml vs. <pre> tags

[Skip Tavakkolian]

> Tables have always been a complete bitch in rendering HTML. Part of the problem is that it is easy to inconsistently overspecify a table (e.g., the whole table must have width 3in but there are only two columns each of which must have width 2 in), and you have to experiment with, say, Internet Explorer, to see how it resolves the problem.

one would think that knuth had solved it for τεχ. any of it applicable to html?

Re: [9fans] libhtml vs. <pre> tags

[David Tolpin]

On 21/10/2005, at 22:35, Skip Tavakkolian wrote:

>> Tables have always been a complete bitch in rendering HTML. Part  
>> of the problem is that it is easy to inconsistently overspecify a  
>> table (e.g., the whole table must have width 3in but there are  
>> only two columns each of which must have width 2 in), and you have  
>> to experiment with, say, Internet Explorer, to see how it resolves  
>> the problem.
>>
>
> one would think that knuth had solved it for τεχ. any of it  
> applicable to html?
>

This is specified in CSS2, clearly and unambiguously. If the sum of  
columns' widths is less than the table's width, one must increase the  
column widths so that they fill the tables width. You don't have to  
experiment with implementations to comply to the specification.  
Unless you have to deal with multipage tables, formatting table, even  
with auto-layout, is a relatively easy task.

And you don't need Knuth and TEX for that.

David

RE: [9fans] libhtml vs. <pre> tags

[Federico G. Benavento]

>> ...I knew that this was easy to fix, but I didn't
>> because, right now, <table> is my problem.

>And I predict <table> will remain your problem for quite some time.

yep

>I wrote charon and did the abortive attempt to convert it to c (i).

yes, but you made libhtml in the process, which is what I'm using :)

>Tables have always been a complete bitch in rendering HTML. Part of the problem is that it is easy to inconsistently overspecify a table (e.g., the whole table must have width 3in but there are only two columns each of which must have width 2 in), and you have to experiment with, say, Internet Explorer, to see how it resolves the problem.

>I'm pretty sure Tom Duff stopped work on mothra because he hit the table wall and couldn't think of an elegant way to get past it. I stopped work on i because I had another more important project, but I was fighting table bugs, mostly, at the end.

yeah, it is not about just rendering tables, but doing it in elegantly,
well if I can't do it this way, I'll have to do it in another one,
time will tell :)

>Good luck!

thanks

>- Howard

Federico G.Benavento

---
/bin/fortune:
We are changing the alignment, not the membership.  -John Mayo

RE: [9fans] libhtml vs. <pre> tags

[rog]

the real difficulty is that, no matter what the HTML spec
says, if the final result looks different from internet explorer,
it will be classified as "wrong".

Re: [9fans] libhtml vs. <pre> tags

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Well, that and the fact that most of the time IE doesn't even use the spec.

On 10/21/05, rog@vitanuova.com <rog@vitanuova.com> wrote:
>
> the real difficulty is that, no matter what the HTML spec
> says, if the final result looks different from internet explorer,
> it will be classified as "wrong".
>
>


--
The subject of this essay (the Myth of Sisyphus) is precisely
this relationship between the absurd and suicide, the exact
degree to which suicide is a solution to the absurd. The
principle can be established that for a man who does not cheat,
what he believes to be true must determine his action.
Belief in the absurdity of existence must then dictate his
conduct. It is legitimate to wonder, clearly and without
false pathos, whether a conclusion of this importance
requires forsaking as rapidly possiblean imcompre-
hensible condition. I am speaking, of course, of men
inclined to be in harmony with themselves.
<< Albert Camus>>

[-- Attachment #2: Type: text/html, Size: 1356 bytes --]

Re: [9fans] libhtml vs. <pre> tags

[Wes Kussmaul]

rog@vitanuova.com wrote:
> the real difficulty is that, no matter what the HTML spec
> says, if the final result looks different from internet explorer,
> it will be classified as "wrong".

This is changing fairly rapidly. Sites that a year ago could go along 
with IE's liberties are having to change to keep their audience.



-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group 
(village.com) ensure that only intended recipients receive your 
confidential messages.

RE: [9fans] libhtml vs. <pre> tags

[Federico G. Benavento]

>libhtml's rules might not be the same as charon's because chris locke
>had several goes at re-doing charon's handling of various layouts

I didn't know about this.


Federico G.Benavento

---
/bin/fortune:
This is not LINUX!  This is Plan 9.  There are rules.  -boyd/walter

RE: [9fans] libhtml vs. <pre> tags

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 120 bytes --]

there was quite a bit of work in other areas, including extending the
javascript implementation, by chris and others.

[-- Attachment #2: Type: message/rfc822, Size: 3091 bytes --]

From: "Federico G. Benavento" <benavento@gmail.com>
To: forsyth@vitanuova.com, 9fans@cse.psu.edu
Cc: 
Subject: RE: [9fans] libhtml vs. <pre> tags
Date: Fri, 21 Oct 2005 11:21:31 -0300
Message-ID: <4e10b53912120d99e02ffac24dad3255@yourdomain.dom>

>libhtml's rules might not be the same as charon's because chris locke
>had several goes at re-doing charon's handling of various layouts

I didn't know about this.


Federico G.Benavento

---
/bin/fortune:
This is not LINUX!  This is Plan 9.  There are rules.  -boyd/walter

RE: [9fans] libhtml vs. <pre> tags

[Federico G. Benavento]

>there was quite a bit of work in other areas, including extending the
>javascript implementation, by chris and others.

btw, I've ported the javasccript engine that firefox uses natively, 
so at some should be used.

Federico G.Benavento

---
/bin/fortune:
$ Editor (vi or emacs)?

RE: [9fans] libhtml vs. <pre> tags

[Trickey, Howard W (Howard)]

>> Tables have always been a complete bitch in rendering HTML. Part  
>> of the problem is that it is easy to inconsistently overspecify a  
>> table (e.g., the whole table must have width 3in but there are  
>> only two columns each of which must have width 2 in), and you have  
>> to experiment with, say, Internet Explorer, to see how it resolves  
>> the problem.
>>
>
>> one would think that knuth had solved it for τεχ. any of it  
>> applicable to html?
>

> This is specified in CSS2, clearly and unambiguously. If the sum of  
> columns' widths is less than the table's width, one must increase the  
> column widths so that they fill the tables width. You don't have to  
> experiment with implementations to comply to the specification.  
> Unless you have to deal with multipage tables, formatting table, even  
> with auto-layout, is a relatively easy task.
>
> And you don't need Knuth and TEX for that.

I hadn't been following CSS2 closely, as I'm out of that business, but you raised my hopes that someone had finally thought out all these cases and set down rules.  But I just looked at the CSS2 spec and that doesn't seem to be true.  First, while an 'auto layout' algorithm is described, it says "UA's are not required to implement this algorithm; they can use any other algorithm". Also, I was just giving off the top of my head an overspecification, and you are right that it is covered by the CSS2 algorithm, but other cases of overspecification are left ambiguous: e.g.,

 "A percentage value for a column width is relative to the table width.
 If  the table has 'width: auto', a percentage represents a constraint
 on the   column's width, which a UA should try to satisfy. (Obviously,
 this is not always possible: if the column's width is '110%', the
 constraint cannot be satisfied.)"

It doesn't say what to do when you can't satisfy constraints (there are obvious guesses of course, and they are usually right).  However, I do think CSS2 now does a much better job than the original HTML specs that I had to work from at tying down layout questions.

This doesn't even get into the problems of ill-formed HTML.  I couldn't see anything in the spec about what to do about

	<TR> row stuff ... </TR>JUNK<TR> another row ... </TR>

Does one render the JUNK, and if so, how?

I do agree with Uriel, however, that my initial whine about the pain of tables ignores that HTML usage has marched on, and the new problems with CSS and javascript leave libhtml woefully unprepared.  Sorry.

Oh - and the comment about TEX: Knuth was a better designer of table specification - all the questions about how to apportion space in tables come down to simply applying the general rules re stretchable "glue".  So the algorithm isn't hard, and also doesn't help with the "bad HTML table specification" problem.

Sorry to ramble on.  I guess I'm indulging in nostalgia.

- Howard