9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] libhtml vs. <pre> tags
@ 2005-10-20  1:56 erik quanstrom
  2005-10-20  2:17 ` erik quanstrom
  0 siblings, 1 reply; 30+ messages in thread
From: erik quanstrom @ 2005-10-20  1:56 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 30+ messages in thread
* Re: [9fans] libhtml vs. <pre> tags
@ 2005-10-21  4:34 Federico G. Benavento
  2005-10-21  5:09 ` Federico Benavento
  0 siblings, 1 reply; 30+ messages in thread
From: Federico G. Benavento @ 2005-10-21  4:34 UTC (permalink / raw)
  To: quanstro, 9fans, 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.



^ permalink raw reply	[flat|nested] 30+ messages in thread
* Re: [9fans] libhtml vs. <pre> tags
@ 2005-10-21 13:40 Federico G. Benavento
  2005-10-21 13:51 ` erik quanstrom
  0 siblings, 1 reply; 30+ messages in thread
From: Federico G. Benavento @ 2005-10-21 13:40 UTC (permalink / raw)
  To: quanstro, 9fans, 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.



^ permalink raw reply	[flat|nested] 30+ messages in thread
* RE: [9fans] libhtml vs. <pre> tags
@ 2005-10-21 13:47 Trickey, Howard W (Howard)
  2005-10-21 13:55 ` erik quanstrom
                   ` (4 more replies)
  0 siblings, 5 replies; 30+ messages in thread
From: Trickey, Howard W (Howard) @ 2005-10-21 13:47 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> ...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


^ permalink raw reply	[flat|nested] 30+ messages in thread
* RE: [9fans] libhtml vs. <pre> tags
@ 2005-10-21 14:02 Federico G. Benavento
  2005-10-21 14:16 ` rog
  0 siblings, 1 reply; 30+ messages in thread
From: Federico G. Benavento @ 2005-10-21 14:02 UTC (permalink / raw)
  To: trickey, 9fans

>> ...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



^ permalink raw reply	[flat|nested] 30+ messages in thread
* RE: [9fans] libhtml vs. <pre> tags
@ 2005-10-21 14:21 Federico G. Benavento
  2005-10-21 14:40 ` C H Forsyth
  0 siblings, 1 reply; 30+ messages in thread
From: Federico G. Benavento @ 2005-10-21 14:21 UTC (permalink / raw)
  To: forsyth, 9fans

>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



^ permalink raw reply	[flat|nested] 30+ messages in thread
* RE: [9fans] libhtml vs. <pre> tags
@ 2005-10-21 14:37 Federico G. Benavento
  0 siblings, 0 replies; 30+ messages in thread
From: Federico G. Benavento @ 2005-10-21 14:37 UTC (permalink / raw)
  To: forsyth, 9fans

>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)?



^ permalink raw reply	[flat|nested] 30+ messages in thread
* RE: [9fans] libhtml vs. <pre> tags
@ 2005-10-21 18:16 Trickey, Howard W (Howard)
  0 siblings, 0 replies; 30+ messages in thread
From: Trickey, Howard W (Howard) @ 2005-10-21 18:16 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

>> 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


^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2005-10-21 19:20 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-20  1:56 [9fans] libhtml vs. <pre> tags erik quanstrom
2005-10-20  2:17 ` erik quanstrom
2005-10-20 17:04   ` Federico Benavento
2005-10-21  4:01     ` erik quanstrom
2005-10-21  4:34 Federico G. Benavento
2005-10-21  5:09 ` Federico Benavento
2005-10-21  9:49   ` Kenji Okamoto
2005-10-21  9:51     ` Kenji Okamoto
2005-10-21 13:19   ` erik quanstrom
2005-10-21 13:25   ` erik quanstrom
2005-10-21 13:40 Federico G. Benavento
2005-10-21 13:51 ` erik quanstrom
2005-10-21 13:47 Trickey, Howard W (Howard)
2005-10-21 13:55 ` erik quanstrom
2005-10-21 14:06 ` Wes Kussmaul
2005-10-21 14:16 ` C H Forsyth
2005-10-21 15:04 ` Uriel
2005-10-21 18:45   ` Wes Kussmaul
2005-10-21 19:12     ` Uriel
2005-10-21 19:20       ` Wes Kussmaul
2005-10-21 17:35 ` Skip Tavakkolian
2005-10-21 17:51   ` David Tolpin
2005-10-21 14:02 Federico G. Benavento
2005-10-21 14:16 ` rog
2005-10-21 14:20   ` LiteStar numnums
2005-10-21 15:09   ` Wes Kussmaul
2005-10-21 14:21 Federico G. Benavento
2005-10-21 14:40 ` C H Forsyth
2005-10-21 14:37 Federico G. Benavento
2005-10-21 18:16 Trickey, Howard W (Howard)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).