Re: textarea attribute "wrap=hard"
Vincent Danen <[email protected]> Wed, 18 Feb 2004 00:33:43 -0700
| Newsgroups | gmane.comp.bug-tracking.anthill.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============48090077951853605==
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-sha1; boundary="Apple-Mail-9--1824434"
Content-Transfer-Encoding: 7bit
--Apple-Mail-9--1824434
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Feb 14, 2004, at 02:45, Moritz Bunkus wrote:
> Yesterday I found out that Opera is very strict when it comes to the
> "wrap=hard" attribute for the textarea form field. The problem is that
> it even breaks long URLs... If the URL is longer than the input field
> then Opera will really break, resulting in something like
>
> http://www.bunkus.org/somescript.pl?
> someparam=value&moreparams=morevalues
>
> or even stranger things. This is pretty annoying, and konqueror does
> not
> produce such broken results, so it's maybe just Opera that's acting
> weird. Removing the "wrap=hard" parameter fully restores sane
> behaviour,
> so if you don't really need it, maybe you could just remove those
> parameters? :)
The problem here is that this is a cheap and easy way to enforce decent
looking emails. For instance, without having the hard wrap in there,
I'd have to add code to wrap lines otherwise each paragraph in the
email diff messages would be a single line... really really annoying.
The hard wrap gives us sane line lengths for email messages. I don't
really want to change this.
To my knowledge, Opera must be the only browser with this quirk. I
haven't seen this with any other browser I've tried. Maybe try
emailing the Opera developers? =)
> BTW: I'm not a web designer/programmer, but selfhtml
> http://selfhtml.teamone.de has nothing nice to say about "wrap" either,
> so it might be a good thing to get rid of it.
It might be, but then I have to write extra code to compensate for it,
which I really don't want to do. I'd rather eliminate the need to do
any of that on the server side if at all possible, and this is a really
inexpensive way to do it. The problem is really big entries like log
snippets and stuff... we're already being expensive when we try to make
web links "live" by processing that text (different ball park, but
maybe you get the idea). I want to keep the speed up and the bloat
down and this is one way to do that.
---
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
--Apple-Mail-9--1824434
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFAMxVXIEPQ5f5vKv0RAiXnAKCg9q5TaeIZ0pe008uOZUd5fYXIyQCeMGVC
/Fntm8UZ9lcbCICP2r41Ap8=
=3OPr
-----END PGP SIGNATURE-----
--Apple-Mail-9--1824434--
--===============48090077951853605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Anthill-workers mailing list
Anthill-workers-+mQDA36h6dWw5LPnMra/[email protected]
http://vmlinuz.ca/mailman/listinfo/anthill-workers
--===============48090077951853605==--