Re: lynx-dev patch - "JUSTIFY"

[Vlad Harchev]

On Wed, 14 Jul 1999, Klaus Weide wrote:

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

 Binding j. info to styles will require complete implementaion of style stack
(since table elements can contain lists, parargaphs, etc). 

 And according to the logic - all text with HT_LEFT alignment can be justified
(except H[1-6]), so rather than changing each style definition in
DefaultStyle.c I prefered to do this implicitly. 
 See below..
 
> > > 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...

 Yes, HT_LEFT and HT_JUSTIFY are treated the same (both are allowed to be
aligned).
 
> > 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.

 I agree that implementing the things you propose will be a right thing. But
seems that I won't have time to do anything revolutionary like that in next 2
monthes for free. We have several directions lynx can be improved in, but all
those additions will require a lot of time so seems noone will implement them
in this year.
 
> > 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.

 I have a very few spare time for anything, and most of the time took reading
the lynx sources (in order to guess how it should be implemented). The
shortest (and very strong) agrument I have is that alsmost 98% of the part
that is relevant to justification is implementation of the justification of
a given line in GridText.c:split_line. The logic that controls whether the
given line can be justified can be (re)writtent in 10 minutes, so (at least)
we can consider that part as a good codebase for right implementation of
justification (the decision whether the current line will be justified is made
in HText_appendCharacter(..) ). But I still consider the logic selected as
sufficient for any end-user.
 
>    Klaus
> 

 Best regards,
  -Vlad