Re: lynx-dev patch - "JUSTIFY"

[Klaus Weide]

On Tue, 13 Jul 1999, Vlad Harchev wrote:
> On Tue, 13 Jul 1999, David Woolley wrote:
> > 
> > My initial reaction to the actual code is that it is short sighted and
> > changed in the wrong place.  A proper CSS implementation would allow
> > justification to be turned back on in nested structures (and possibly
> > not turned on at the outermost level).  This implementation assumes
> > that it is turned on by the HTML element, inherited through most,
> > and turned off by a few, and once off it it off until the element
> > that turned it off is popped from the parse stack.
> 
>  Currenlty justification is turned on by element, but for elements that can't
> contain anything reasonable to justify (except CENTER), they are
>  BANNER,CENTER, H[1-6], PRE, SAMP, TABLE, XMP
>  so IMO there is no loss in flexibility.  And as for CENTER, I seems only
> badly formatted document use it (the style sheets should be used for this),
> so we don't loose a lot (at least documents that are wrapped in CENTER are
> very rare).

Vlad, I admit I haven't looked at the code yet, so I cannot comment much;
but please pay attention to David, what he says seems to make much sense.
:)

> > It has also be associated with parsing information for elements, when
> > it really belongs with the style information for elements.

I think I saw what this means in the patch to HTMLDTD.c (a change for
CENTER).  Indeed, style information doesn't seem to belong there.

>  Currently, no CSS support is present in the lynx. 

There is no "cascading style sheet support" in lynx, but there is a
paragraph style model, and has been there from the beginning - or
I assume since the time Lynx started the libwww.  See HTStyle.c and
DefaultStyle.c.

It's a valid question whether that (simple) model should be reused,
and extended as needed, for implementing style-like features (maybe, one
day, up to something CSS-like) - or whether every new style-like thing
should circumvent the existing model and do it "my own way".

> I wished to implement
> justification in a bound period of my time (so entire patch was completed 
> in 3 days). And there are a few styles lynx has now, so binding justification-
> ability to them will make html model very rough (eg there is no style for
> TABLE, for BANNER).

If there is no style for TABLE or BANNER - then maybe there should be one?
Adding more entries to the DefaultStyle.c list isn't hard.  Letting them
actually be used in HTML.c would be a bit harder, but should take less
than 3 days.

> > A full CSS implementation would associate at least the following
> > possibilities with each element (actually with a style selector pattern):
> > inherit, right, left, centre, or justify, not just the inherit and 
> > don't justify of the current patch.

And there already is an "alignment" element in each of Lynx's classic
paragraph styles, which can be HT_LEFT, HT_RIGHT, HT_CENTER, or
HT_JUSTIFY.  It's just that HT_JUSTIFY was treated the same as HT_LEFT,
as long as justification wasn't implemented.  The logical thing would
have been to implement HT_JUSTIFY as separate from HT_LEFT, and do
justification for styles with HT_JUSTIFY.

I gather from David's descriptions (second-hand for me, by you didn't
question them so I assume they are fair) and from the snippet I have
seen that now HT_LEFT and HT_JUSTIFY are still treated the same.  If
that's so, there's something very wrong with it...

> As for CSS implementation in lynx (I said it several times, but I repeat):
> IMO it will be bad thing to parse CSSes included in or referenced by the
> documents that are read from the web (since they are suited for GUI browsers).

David's characterization of what "a full CSS implementation" would do
doesn't just apply to CSS<N> (any version), or to how CSS is currently
used for graphical browser.  It just makes sense as part of a base, on
which anything else can be implemented: CSS, another style language du
jour, a subset thereof specific for lynx, or a format private to lynx
(as we have in lynx.lss, for one limited aspect of style).  The language
doesn't really matter that much.

But Lynx could still use the general mechanism of LINK and STYLE elements
to specify styles - they don't have to be CSS, or even anything official.
AFAIK all those ways of specifying styles have a 'type' attribute.
Lynx doesn't understand type=text/css, maybe never will, but it could use
styles that are explicitly type=text/x-lynx-lss (or whatever), and later
maybe type=text/x-lynx-blockstyle or type=text/x-lynx-subset-of-css.
 
> But lynx should have something to contol various things like justification, 
> alignment, indents, spaces before and after, etc, I agree. But it can have any
> format of description - so (it seems to me) it will be the one that is easier
> to parse (or write parser for), not that W3C recommends.
> 
> What additional style sheets do you think should be added to lynx?

How about starting with exposing the already existing-from-the-beginning
HTStyles, by making them changeable from the DefaultStyle.c settings
on a per document basis?  Use a style language (to be invented? or
reuse something?) that can express what's in a HTStyle, let users
change the default using a "user default stylesheet" written in that
language.  Could then also be loaded at runtime for HTML documents
with <LINK REL=stylesheet TYPE="text/our-type" ...> (well this currently
would work at most for local file://localhost/... stylesheets, because
of lacking multithreading etc., I guess).

All the addition would be in parsing the format and associating the result
with a document-to-be-rendered.  No deep changes to the mess that is now
HTML.c.  But it would make visible the flexibility that is already
built-in in the HTStyle.c (but unused because styles are hardcoded),
then we could see whether it's useful or not.

> Have you tried this patch? 
> 
> Anyway, you are can turn justification off if you don't like it.

The issue, as I see it, is not whether Devid is forced to use your
addition.  Of course he isn't.  The issue is whether development
of the lynx code is going in a direction that makes more sensible
treatment of styles harder in the future.

Hey I don't say my ideas are necessarily good in that sense.  But
"it works" and "it took only 3 days" should not be the only factors.

   Klaus