From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: erik quanstrom Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Message-Id: <20051020015629.41CB5130256@dexter-peak.quanstro.net> Date: Wed, 19 Oct 2005 20:56:29 -0500 Subject: [9fans] libhtml vs. 
 tags
Topicbox-Message-UUID: 9d66bd74-ead0-11e9-9d60-3106f5b1d025

as long as we're on the subject of html, it seems like

 tags are not properly rendered by libhtml --
all the information gets to render() except the 
formatting flag.

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

erik


From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom 
To: 9fans@cse.psu.edu, erik quanstrom 
References: <20051020015629.41CB5130256@dexter-peak.quanstro.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <20051020015629.41CB5130256@dexter-peak.quanstro.net>
Subject: [9fans] libhtml vs. 
 tags
Message-Id: <20051020021707.8C4F613025C@dexter-peak.quanstro.net>
Date: Wed, 19 Oct 2005 21:17:07 -0500
Cc: 
Topicbox-Message-UUID: 9d70e2a4-ead0-11e9-9d60-3106f5b1d025

to be more exact: this


1	2



yields 2 tokens

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

render() never sees the 
 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  writes

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


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <32d987d50510201004o56dec138t27e4050410f7ca59@mail.gmail.com>
Date: Thu, 20 Oct 2005 14:04:35 -0300
From: Federico Benavento 
To: erik quanstrom ,
	Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] libhtml vs. 
 tags
In-Reply-To: <20051020021707.8C4F613025C@dexter-peak.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20051020015629.41CB5130256@dexter-peak.quanstro.net>
	<20051020021707.8C4F613025C@dexter-peak.quanstro.net>
Cc: 
Topicbox-Message-UUID: 9d9ff21a-ead0-11e9-9d60-3106f5b1d025

hi

On 10/19/05, erik quanstrom  wrote:
> to be more exact: this
>
> 
> 1       2
> 

>
> yields 2 tokens
>
> '1        ' ('1' + ' '*8)
> '2'
>
> render() never sees the 
 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:

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


From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom 
To: 9fans@cse.psu.edu, Federico Benavento 
References: <20051020015629.41CB5130256@dexter-peak.quanstro.net> 
	<20051020021707.8C4F613025C@dexter-peak.quanstro.net> 
	<32d987d50510201004o56dec138t27e4050410f7ca59@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <32d987d50510201004o56dec138t27e4050410f7ca59@mail.gmail.com>
Subject: Re: [9fans] libhtml vs. 
 tags
Message-Id: <20051021040143.6102C13024B@dexter-peak.quanstro.net>
Date: Thu, 20 Oct 2005 23:01:43 -0500
Cc: 
Topicbox-Message-UUID: 9dbd0940-ead0-11e9-9d60-3106f5b1d025

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

| 
| hi
| 
| On 10/19/05, erik quanstrom  wrote:
| > to be more exact: this
| >
| > 
| > 1       2
| > 

| >
| > yields 2 tokens
| >
| > '1        ' ('1' + ' '*8)
| > '2'
| >
| > render() never sees the 
 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:
| 
, 
, 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.


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <40b9e3a7bb5b21a2fd6f1fee8d9b8731@yourdomain.dom>
To: quanstro@quanstro.net, 9fans@cse.psu.edu, benavento@gmail.com
Subject: Re: [9fans] libhtml vs. 
 tags
From: "Federico G. Benavento" 
Date: Fri, 21 Oct 2005 01:34:15 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: 
Topicbox-Message-UUID: 9dd15f30-ead0-11e9-9d60-3106f5b1d025

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <32d987d50510202209h61161a7esb38c8dd5e4b635@mail.gmail.com>
Date: Fri, 21 Oct 2005 02:09:52 -0300
From: Federico Benavento 
To: quanstro@quanstro.net, 9fans@cse.psu.edu, benavento@gmail.com
Subject: Re: [9fans] libhtml vs. 
 tags
In-Reply-To: <40b9e3a7bb5b21a2fd6f1fee8d9b8731@yourdomain.dom>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <40b9e3a7bb5b21a2fd6f1fee8d9b8731@yourdomain.dom>
Cc: 
Topicbox-Message-UUID: 9dd52584-ead0-11e9-9d60-3106f5b1d025

Now abaco handles 
 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, 
 is my problem.

cheers

On 10/21/05, Federico G. Benavento  wrote:
> >in my hasty reading of libhtml i was thinking that the tokenization is a=
lmost
> >correct. the only change needed is to not translate \t to 8 spaces. on o=
utput,
>
> I don't think this is needed since when there is a 
 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 
-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 
 shou=
ld be
> >handled in a special manner, with the tokenizer just converting characte=
r
> >sets and entities and treating that result as one big Bytes*.
>
> cheers
>
> Federico G.Benavento
>
> ---
> /bin/fortune:
> The system is ready.
>
>


--
Federico G. Benavento


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: 
To: 9fans@cse.psu.edu
Subject: Re: [9fans] libhtml vs. 
 tags
From: Kenji Okamoto 
Date: Fri, 21 Oct 2005 18:49:29 +0900
In-Reply-To: <32d987d50510202209h61161a7esb38c8dd5e4b635@mail.gmail.com>
MIME-Version: 1.0
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 9de1c60e-ead0-11e9-9d60-3106f5b1d025

Hi,

> Now abaco handles 
 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 
 tag.
This is very common also for other applications...

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

Kenji



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <77348c06fd1045878d6b0e6b583f1155@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] libhtml vs. 
 tags
From: Kenji Okamoto 
Date: Fri, 21 Oct 2005 18:51:24 +0900
In-Reply-To: 
MIME-Version: 1.0
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 9de5c376-ead0-11e9-9d60-3106f5b1d025

Awawawa---

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

Kenji



From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom 
To: 9fans@cse.psu.edu
References: <40b9e3a7bb5b21a2fd6f1fee8d9b8731@yourdomain.dom> 
	<32d987d50510202209h61161a7esb38c8dd5e4b635@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <32d987d50510202209h61161a7esb38c8dd5e4b635@mail.gmail.com>
Subject: Re: [9fans] libhtml vs. 
 tags
Date: Fri, 21 Oct 2005 08:19:38 -0500
Message-Id: <20051021134702.0ACBB130256@dexter-peak.quanstro.net>
Topicbox-Message-UUID: 9df6d062-ead0-11e9-9d60-3106f5b1d025

okay, i was using htmlfmt to try to turn some 
-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 
 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  writes

| 
| Now abaco handles 
 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, 
 is my problem.
| 
| cheers
| 
| On 10/21/05, Federico G. Benavento  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 
 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 
-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 
 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


From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom 
To: 9fans@cse.psu.edu, Federico Benavento 
References: <40b9e3a7bb5b21a2fd6f1fee8d9b8731@yourdomain.dom> 
	<32d987d50510202209h61161a7esb38c8dd5e4b635@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <32d987d50510202209h61161a7esb38c8dd5e4b635@mail.gmail.com>
Subject: Re: [9fans] libhtml vs. 
 tags
Message-Id: <20051021132528.21B1F130256@dexter-peak.quanstro.net>
Date: Fri, 21 Oct 2005 08:25:28 -0500
Cc: 
Topicbox-Message-UUID: 9deac358-ead0-11e9-9d60-3106f5b1d025

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

-- erik

Federico Benavento  writes

| 
| Now abaco handles 
 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, 
 is my problem.
| 
| cheers


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7e7c9c9f8f0044a90eb44f0c1c01771a@yourdomain.dom>
To: quanstro@quanstro.net, 9fans@cse.psu.edu, benavento@gmail.com
Subject: Re: [9fans] libhtml vs. 
 tags
From: "Federico G. Benavento" 
Date: Fri, 21 Oct 2005 10:40:53 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: 
Topicbox-Message-UUID: 9deef2fc-ead0-11e9-9d60-3106f5b1d025

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
From: "Trickey, Howard W (Howard)" 
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: RE: [9fans] libhtml vs. 
 tags
Date: Fri, 21 Oct 2005 09:47:50 -0400
MIME-Version: 1.0
Content-Type: text/plain
Topicbox-Message-UUID: 9df34636-ead0-11e9-9d60-3106f5b1d025

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

And I predict 
 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


From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom 
To: 9fans@cse.psu.edu, "Federico G. Benavento" 
References: <7e7c9c9f8f0044a90eb44f0c1c01771a@yourdomain.dom>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <7e7c9c9f8f0044a90eb44f0c1c01771a@yourdomain.dom>
Subject: Re: [9fans] libhtml vs. 
 tags
Message-Id: <20051021135155.3661713025C@dexter-peak.quanstro.net>
Date: Fri, 21 Oct 2005 08:51:55 -0500
Cc: 
Topicbox-Message-UUID: 9dfacbea-ead0-11e9-9d60-3106f5b1d025

that's a very good reason.

erik

"Federico G. Benavento"  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 :)


From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom 
To: 9fans@cse.psu.edu,
	"Trickey, Howard W (Howard)" 
References: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
Subject: RE: [9fans] libhtml vs. 
 tags
Message-Id: <20051021135514.9CCC513025C@dexter-peak.quanstro.net>
Date: Fri, 21 Oct 2005 08:55:14 -0500
Cc: 
Topicbox-Message-UUID: 9e0286be-ead0-11e9-9d60-3106f5b1d025

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

"Trickey, Howard W (Howard)"  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. [...]


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: 
To: trickey@lucent.com, 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
From: "Federico G. Benavento" 
Date: Fri, 21 Oct 2005 11:02:21 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: 
Topicbox-Message-UUID: 9dfea080-ead0-11e9-9d60-3106f5b1d025

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

>And I predict 
 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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4358F5EC.5030808@village.com>
Date: Fri, 21 Oct 2005 10:06:36 -0400
From: Wes Kussmaul 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] libhtml vs. 
 tags
References: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
In-Reply-To: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 9e065d5c-ead0-11e9-9d60-3106f5b1d025

Trickey, Howard W (Howard) wrote:

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

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


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

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: 
To: 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
Date: Fri, 21 Oct 2005 15:16:24 +0100
From: rog@vitanuova.com
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 9e0e1100-ead0-11e9-9d60-3106f5b1d025

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: 
To: 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
From: C H Forsyth 
Date: Fri, 21 Oct 2005 15:16:26 +0100
In-Reply-To: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 9e1350fc-ead0-11e9-9d60-3106f5b1d025

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <283f5df10510210720u7dafed5wcab8092b6c76ec9@mail.gmail.com>
Date: Fri, 21 Oct 2005 10:20:38 -0400
From: LiteStar numnums 
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] libhtml vs. 
 tags
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_11546_9535976.1129904438947"
References: 
	
Topicbox-Message-UUID: 9e7ffbbc-ead0-11e9-9d60-3106f5b1d025

------=_Part_11546_9535976.1129904438947
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

On 10/21/05, 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>>

------=_Part_11546_9535976.1129904438947
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 t=
o which suicide is a solution to the absurd. The 
principle can be estab=
lished that for a man who does not cheat,
what he believes to be true mu=
st 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 i=
mcompre-

hensible condition. I am speaking, of course, of men
inclined to be =
in harmony with themselves.
  << Albert Camus>>

------=_Part_11546_9535976.1129904438947--


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4e10b53912120d99e02ffac24dad3255@yourdomain.dom>
To: forsyth@vitanuova.com, 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
From: "Federico G. Benavento" 
Date: Fri, 21 Oct 2005 11:21:31 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: 
Topicbox-Message-UUID: 9e8bc64a-ead0-11e9-9d60-3106f5b1d025

>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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <751e874d486953fac9c814afe11fdc5e@yourdomain.dom>
To: forsyth@vitanuova.com, 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
From: "Federico G. Benavento" 
Date: Fri, 21 Oct 2005 11:37:13 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: 
Topicbox-Message-UUID: 9ea97f50-ead0-11e9-9d60-3106f5b1d025

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <0e04c608ddb5a56f8fda7469bc15da90@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
From: C H Forsyth 
Date: Fri, 21 Oct 2005 15:40:37 +0100
In-Reply-To: <4e10b53912120d99e02ffac24dad3255@yourdomain.dom>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-lasstluhsuxypodqothghdjlny"
Topicbox-Message-UUID: 9e9ec718-ead0-11e9-9d60-3106f5b1d025

This is a multi-part message in MIME format.
--upas-lasstluhsuxypodqothghdjlny
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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

--upas-lasstluhsuxypodqothghdjlny
Content-Type: message/rfc822
Content-Disposition: inline

Received: from mail.cse.psu.edu ([130.203.4.6]) by doppio;
	Fri Oct 21 15:21:36 BST 2005
Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 99A3DC681D
	for ; Fri, 21 Oct 2005 10:22:43 -0400 (EDT)
X-Original-To: 9fans@cse.psu.edu
Delivered-To: 9fans@cse.psu.edu
Received: from localhost (localhost [127.0.0.1])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 106A463451
	for <9fans@cse.psu.edu>; Fri, 21 Oct 2005 10:22:14 -0400 (EDT)
Received: from mail.cse.psu.edu ([127.0.0.1])
	by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 23202-01-11 for <9fans@cse.psu.edu>;
	Fri, 21 Oct 2005 10:22:12 -0400 (EDT)
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 1DE4B634A5
	for <9fans@cse.psu.edu>; Fri, 21 Oct 2005 10:22:12 -0400 (EDT)
Received: by wproxy.gmail.com with SMTP id i32so259801wra
	for <9fans@cse.psu.edu>; Fri, 21 Oct 2005 07:22:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:to:subject:from:date:mime-version:content-type:content-transfer-encoding;
	b=DOCgrF+ilzvI/+axHKqMZ+l5M+jq5tzgjAsPl+TvkEaODyhAsM6CoJzm4Cdyc5IPkN9Ie+ZVdaixrLPCCVFQMvwsBXVnfDRkJVbWNSTZozXTv0MtOKaxGnr/qbBqfWCZENMdRiJw94PK/l7Sr95Bmb2zTW0Nd+u0LFgXWYJY7N8=
Received: by 10.54.82.16 with SMTP id f16mr1539742wrb;
	Fri, 21 Oct 2005 07:22:10 -0700 (PDT)
Received: from lotte ( [201.235.103.152])
	by mx.gmail.com with ESMTP id 65sm7249359wra.2005.10.21.07.22.08;
	Fri, 21 Oct 2005 07:22:10 -0700 (PDT)
Message-ID: <4e10b53912120d99e02ffac24dad3255@yourdomain.dom>
To: forsyth@vitanuova.com, 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
From: "Federico G. Benavento" 
Date: Fri, 21 Oct 2005 11:21:31 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at cse.psu.edu
Cc: 
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-Mailman-Copy: yes
Sender: 9fans-bounces+forsyth=vitanuova.com@cse.psu.edu
Errors-To: 9fans-bounces+forsyth=vitanuova.com@cse.psu.edu

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


From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 21 Oct 2005 16:04:30 +0100
From: Uriel 
To: 9fans@cse.psu.edu
Subject: Re: [9fans] libhtml vs. 
 tags
Message-ID: <20051021150430.GD16835@server4.lensbuddy.com>
References: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
User-Agent: Mutt/1.5.11
Topicbox-Message-UUID: 9eb61cba-ead0-11e9-9d60-3106f5b1d025

On Fri, Oct 21, 2005 at 09:47:50AM -0400, Trickey, Howard W (Howard) wrote:
> And I predict 
 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


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <435904A7.9060600@village.com>
Date: Fri, 21 Oct 2005 11:09:27 -0400
From: Wes Kussmaul 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] libhtml vs. 
 tags
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 9eba686a-ead0-11e9-9d60-3106f5b1d025

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=20
with IE's liberties are having to change to keep their audience.



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

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: 
To: 9fans@cse.psu.edu
Subject: RE: [9fans] libhtml vs. 
 tags
Date: Fri, 21 Oct 2005 10:35:34 -0700
From: Skip Tavakkolian <9nut@9netics.com>
In-Reply-To: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 9ed4046e-ead0-11e9-9d60-3106f5b1d025

> 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 o=
f which must have width 2 in), and you have to experiment with, say, Inte=
rnet Explorer, to see how it resolves the problem.

one would think that knuth had solved it for =CF=84=CE=B5=CF=87. any of i=
t applicable to html?



From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: 
References: 
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
Message-Id: <43FAE8B5-4B8D-4A03-8A1E-30B10719684F@davidashen.net>
Content-Transfer-Encoding: quoted-printable
From: David Tolpin 
Subject: Re: [9fans] libhtml vs. 
 tags
Date: Fri, 21 Oct 2005 22:51:37 +0500
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Topicbox-Message-UUID: 9ee5eb8e-ead0-11e9-9d60-3106f5b1d025


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

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

>> to experiment with, say, Internet Explorer, to see how it resolves =20=

>> the problem.
>>
>
> one would think that knuth had solved it for =CF=84=CE=B5=CF=87. any =
of it =20
> applicable to html?
>

This is specified in CSS2, clearly and unambiguously. If the sum of =20
columns' widths is less than the table's width, one must increase the =20=

column widths so that they fill the tables width. You don't have to =20
experiment with implementations to comply to the specification. =20
Unless you have to deal with multipage tables, formatting table, even =20=

with auto-layout, is a relatively easy task.

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

David=


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3BD3BB8D47F9DE4984C319EA325A006DC401C3@nj9620exch003u.mh.lucent.com>
From: "Trickey, Howard W (Howard)" 
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: RE: [9fans] libhtml vs. 
 tags
Date: Fri, 21 Oct 2005 14:16:24 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 9f1166f6-ead0-11e9-9d60-3106f5b1d025

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

> This is specified in CSS2, clearly and unambiguously. If the sum of =20
> columns' widths is less than the table's width, one must increase the =
=20
> column widths so that they fill the tables width. You don't have to =20
> experiment with implementations to comply to the specification. =20
> Unless you have to deal with multipage tables, formatting table, even =
=20
> 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

	
 row stuff ... JUNK another row ... 

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


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <43593764.2060606@village.com>
Date: Fri, 21 Oct 2005 14:45:56 -0400
From: Wes Kussmaul 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] libhtml vs. 
 tags
References: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
	<20051021150430.GD16835@server4.lensbuddy.com>
In-Reply-To: <20051021150430.GD16835@server4.lensbuddy.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 9f25e32e-ead0-11e9-9d60-3106f5b1d025

Uriel wrote:

> What I would like to see is someone working on a replacement for the we=
b
> that follows the Plan 9 design style. (yea, it's in my TODO list, but w=
ho
> 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=20
creators knew about the Plan 9 way of doing things.

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


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

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



From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 21 Oct 2005 20:12:13 +0100
From: Uriel 
To: 9fans@cse.psu.edu
Subject: Re: [9fans] libhtml vs. 
 tags
Message-ID: <20051021191213.GE16835@server4.lensbuddy.com>
References: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>
	<20051021150430.GD16835@server4.lensbuddy.com>
	<43593764.2060606@village.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43593764.2060606@village.com>
User-Agent: Mutt/1.5.11
Topicbox-Message-UUID: 9f2e5572-ead0-11e9-9d60-3106f5b1d025

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


From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <43593F8E.4080804@village.com>
Date: Fri, 21 Oct 2005 15:20:46 -0400
From: Wes Kussmaul 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] libhtml vs. 
 tags
References: <3BD3BB8D47F9DE4984C319EA325A006DC4009C@nj9620exch003u.mh.lucent.com>	<20051021150430.GD16835@server4.lensbuddy.com>	<43593764.2060606@village.com>
	<20051021191213.GE16835@server4.lensbuddy.com>
In-Reply-To: <20051021191213.GE16835@server4.lensbuddy.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 9f32891c-ead0-11e9-9d60-3106f5b1d025

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.
>=20
> When I hear AJAX I feel so much nausea I can't even reach for my MP5 an=
d
> I have to run for the bathroom to empty my stomach.

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


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

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