Re: lynx-dev Lynx (2.8.2rel.1) botches input type=submit value= w/spaces

[Heather]

John Hascall wrote:
> > It appears that if I have a form with:
> >     <input type=submit name=action value="   Help   ">
> > when the form is submitted I get back:
> > 
> >     action=Help
> > 
> > (that is, with no spaces).
> > 
> > Most annoying (it also appears to be rendered on the screen
> > with no spaces, but that is less of a problem).

Klaus replied:
> Ok, could you please give us some arguments why it should be changed.
> For example, some standard that you are aware of that deals with this.
> Also, what do other browsers do.  (Is there uniform behavior, only lynx
> does it differently?)
> 
> What exactly should lynx send back in this case? "+++Help+++"?  or
> "+Help+"?  (SGML rules about collapsing whitespace - do they apply
> here?)

Would it work if you use entity hardspaces? (&nbsp; - I get decent results
but improve readability, if I'm doing it for space generationg and not to
prevent wrap, by using
 &nbsp; &nbsp; &nbsp;

...for example.  But I only do that in open text, I've never done it in a
button.

BTW in the world of graphics you can't -really- know what font has been
assigned to buttons - so what looks great with extra spaces for you could
be so wide as to be rather lame-looking to someone else.  In ours at least
you know it's monospaced.  (Style nit, and not on lynx topic, but I'm not
sure -why- you need the effect.  After all if the desire is, for example,
to get the submit and reset button texts of same width, it's pretty much
doomed -except- in monospace.)

I agree that I don't see a problem with blowing off your spaces for display.  
I do think it weird that it didn't compress them down to merely one, as 
standard HTML squiching of spaces, though.  But I'm not familiar with what 
the spec says we're -supposed- to do with that. Hm.

I'd think your CGI script should be being robust and blowing off the spaces 
on its own anyway, so I'm not sure that you -should- be complaining about 
the browser.

After all, even if we end up agreeing it's a bug, you have all these older
versions of lynx in the Real World to deal with.  Theoretically "until they
upgrade" but you can read in the archives, some sites don't for looong times,
even with customers begging them to upgrade.  Theoretically CGIs can be
told a user-agent string but we know, that's not a "real" description of the
browser necessarily... between that, and issues of security (don't want a
buffer overflow) a CGI backend script needs to take a lot of annoyance 
gracefully.

If you really want characters which look to the human eye like just a touch
of spacing, but would be sure to be passed through to CGI for some reason,
what's wrong with ...Help... ?  I think period in most fonts is slim, and
in some cases may be slimmer than a space, but at least should have a finite 
width.  And it isn't an SGML entity in case you're afraid (or your tests show)
that &nbsp; would get mangled, either in display or in transmission.

> Are there other form control where this applies?

Is lynx' handling for type=submit values sharing code with pre-assigned 
values handling for text inputs?  I could see stripping leading space there...
though I don't necessarily see that being wise, either.  

> It's not that I am convinced that lynx is doing it right - in fact it
> seems to me it's not.  But somebody put the code in to strip leading
> and trailing blanks here, it is more than just an accident.  So there
> may be some reasons for keeping it that way; I wouldn't just want to
> change it without a convincing reason.
> 
>    Klaus

I'd love to hear from someone what the reasoning was, at least so its 
importance can be slipped into the code comments.  Since you say it's not 
accident, but don't know the reason, I assume the patch of code has either 
confusing or no comments.  If someone remembers the reason it's probably
important enough to note.  (This doesn't preclude it being important and
nobody remembers or knows, but would be some strength to its defense anyway.)

* Heather