Re: lynx-dev <BR> does not accumulate

[Philip Webb]

[ to remind everyone where we got to ]
980812 Al Gilman sermonettised (his word):
> 980812 Philip Webb disputed:
>> no, the HTML 4.0 spec is not properly thought-out by its authors:
>> they tell us to collapse input white-space sequences,
>> but they don't tell us what to collapse them to!
>> even collapsing spaces & tabs is not simple:
>> no doubt, multiple spaces become  1 space  & multiple tabs become  1 tab ,
>> but what does  1 space + 1 tab  collapse to:  1 space  or  1 tab ?
>> newlines have no effect, even without multiple white-space char's;
>> OTOH  <BR> + space  collapses to  <BR> , not to  space  (presumably).
>> 
>> i'ld say it's patent that the authors of HTML 4.0 didn't think it thro',
>> including  <BR>  as a white-space character in one paragraph,
>> then instructing collapse of such characters in another paragraph,
>> without noticing that there are cases in which ambiguity results.
>> since the authors plainly didn't get everything clean & consistent,
>> Lynx has no reason to follow their instructions to the letter,
>> esp as collapsing <BR>'s misrepresents the intentions of document authors,
>> as shown by many WWW sites whose pages Lynx users then complain about.
>> 
>> i will alter my assessment "Lynx 2-8 doesn't comply with HTML 4.0"
>> to "Lynx 2-8 can't comply with HTML 4.0 at this point,
>> since HTML 4.0 does not give consistent unambiguous instructions";
>> that leaves it upto the Lynx community to decide how to treat  <BR><BR>
>> & i recommend they be rendered as  2  fresh lines,
>> following common sense & the intentions of most document authors.
> I haven't studied the full HTML 4 specification well enough
> to take a position whether HTML 4 really mandates the omission
> of a whitespace line on encountering <BR><BR>.
> I agree with Philip that Lynx should not follow
> the consensus documents slavishly, but seek common-sense answers.
> Working with a 24-line screen, there are common-sense reasons
> for conserving vertical space and eliding excess whitespace
> on encountering repeated <BR> elements.
> from my involvement in the closing days of HTML 4 development
> Fote's implementation complies with
> but is not dictated by the spirit of HTML 4.
> There was a strong desire to define structure topologically in HTML
> and reserve layout to CSS2, with style defaults supplied by the browser
> when there is no explicit stylesheet invoked.
> So the spirit of HTML 4 is: it's up to us to decide what makes sense.
Dave Eaton spoke up for strict adherence to HTML 4.0;
David Henderson supported a real-life approach to HTML interpretation.

i seem to have persuaded AG & i don't believe anyone else has rebutted
the analysis i offered (above) of what's really going on in the specs.
today, i suggest there are  2  things to do.

first, i'm prepared to make my case to the authors of HTML 4.0
that they should amend their recommendations for <BR> in HTML 4.1 .
they should delete the sentence stating it is a white-space character
& create a separate section for <BR> in a category of its own
distinct from blocks (eg <P>) & white-space (space, tab, newline): eg

  <BR> forces the start of a fresh line; any white-space characters
  occurring immediately before or after <BR> are ignored.
  if <BR><BR> , ie just one pair of tags, is encountered,
  it is treated as equivalent to a <P> without closing tag
  & one blank line is inserted in the text.
  if any longer sequence of <BR> tags is encountered,
  it is treated as equivalent to <BR><BR>, ie the extra tags are ignored.

this would match common sense & the way in which <BR> is in fact used
almost always out there in the real Wide World of HTML;
it would also thwart people who thoughtlessly enter many <BR>'s,
screwing up normal screen display of the text
(they would have to use <PRE> if they really wanted that effect).

second, Lynx should now adopt the above behaviour in anticipation
& because we should try to make Lynx genuinely useful for ordinary users.
that should be the default, with the FM version an option in  lynx.cfg :
i continue to assert that it has no valid justification in HTML 4.0
-- ie that FM read his own sense into wording which is inconsistent --
& that it is unhelpful for users (like the man who started this thread)
who are captive to the Lynx of a sysadmin who left  lynx.cfg  unaltered,
most likely thro' ignorance of the presence or implication of the option.

generally, people who draw up sets of rules for other people to follow
need to have some sanction at back of them or they're wasting their time.
a burocrat has the backing of statute law with prescribed penalties;
dictionaries & grammar books can perhaps rely on school discipline
or the authority of publishers, employers & the like;
the Systeme International ("metric system") has elegance behind it.
HTML OTOH has no sanction of any kind, esp given the anarchy of cyberspace,
in which every self-styled `Web designer' can do as s/he likes.
at most, the HTML specs -- if self-consistent -- are a guide for the wise,
preventing collapse of the Internet into a babel of tongues,
but to be interpreted in a common-sense manner for real-life use.

so can we change the Lynx default to not collapse <BR><BR>
-- & perhaps add the feature that additional <BR>'s will be collapsed --
& can someone -- AG ? -- tell me how to contact the HTML authors?

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto