[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev TEXTAREA (was Re: LYNX-DEV Using Lynx woth web "forums")
From: |
Howard Kaikow |
Subject: |
lynx-dev TEXTAREA (was Re: LYNX-DEV Using Lynx woth web "forums") |
Date: |
Fri, 24 Apr 1998 08:05:22 -0400 |
What is the status of the fix to the TEXTAREA?
At 08:00 AM 3/28/1998 -0500, Howard Kaikow wrote:
>The following is from the 28 March 1995 draft of HTML 3. It states that the
>number of rows "should" not limit the text entered.
>
>TEXTAREA
>
> To let users enter more than one line of text, use the TEXTAREA
> element. For example:
>
> <TEXTAREA NAME="address" ROWS=64 COLS=6>
> HaL Computer Systems
> 1315 Dell Avenue
> Campbell, California 95008
> </TEXTAREA>
>
>
> The text up to the end tag is used to initialize the field's value.
> The initialization text can contain SGML entities, e.g. for accented
> characters, but is otherwise treated as literal text. This end tag
> is always required even if the field is initially blank. When
> submitting a form, the line terminators are implementation
> dependent. Servers should be capable of recognizing a CR immediately
> followed by an LF, or separate CRs and LFs as all signifying the
> ends of lines. User agents should tolerate the same range of line
> terminators within the initialization text.
>
> In a typical rendering, the ROWS and COLS attributes determine the
> visible dimension of the field in characters. The field is rendered
> in a fixed-width font. User agents should allow text to grow beyond
> these limits by scrolling as needed. The user agent is recommended
> to wrap words as they are entered, to fit within the textarea field.
> It is further recommended that a means is provided for users to turn
> this feature off and on.
>
> Note: In the initial design for forms, multi-line text fields were
> supported by the INPUT element with TYPE=TEXT. Unfortunately, this
> causes problems for fields with long text values as SGML limits the
> length of attribute literals. The HTML 2.0 DTD allows for up to 1024
> characters (the SGML default is only 240 characters).
>
>Permitted Attributes
>
> ID
> An SGML identifier used as the target for hypertext links or for
> naming particular elements in associated style sheets.
> Identifiers are NAME tokens and must be unique within the scope
> of the current document.
>
> LANG
> This is one of the ISO standard language abbreviations, e.g.
> "en.uk" for the variation of English spoken in the United
> Kingdom. It can be used by parsers to select language specific
>
>Dave Raggett Page
133
>HTML 3.0 28th March
1995
>
> choices for quotation marks, ligatures and hypenation rules etc.
> The language attribute is composed from the two letter language
> code from ISO 639, optionally followed by a period and a two
> letter country code from ISO 3166.
>
> CLASS
> This a space separated list of SGML NAME tokens and is used to
> subclass tag names. By convention, the class names are
> interpreted hierarchically, with the most general class on the
> left and the most specific on the right, where classes are
> separated by a period. The CLASS attribute is most commonly used
> to attach a different style to some element, but it is
> recommended that where practical class names should be picked on
> the basis of the element's semantics, as this will permit other
> uses, such as restricting search through documents by matching
> on element class names. The conventions for choosing class names
> are outside the scope of this specification.
>
> NAME
> The formal name of the field which is used in the form's
> contents list.
>
> ROWS
> This gives the visible number of text lines shown by the field.
> User agents should allow text to grow beyond these limits by
> scrolling as needed.
>
> COLS
> The visible number of characters across the field. User agents
> should allow text to grow beyond these limits by scrolling as
> needed.
>
> DISABLED
> When present, the field should be rendered as normal, but can't
> be modified by the user. Where practical the rendering should
> provide a cue that the field is disabled e.g. by graying out the
> text, changing the color of the background or similar.
>
> ERROR
> This attribute specifies an error message explaining why the
> field's current value is incorrect. When this attribute is
> missing, the field can be assumed to be ok. User agents are
> recommended to provide a cue to indicate that the field is in
> error.
>
> ALIGN
> Take values TOP or MIDDLE or BOTTOM, defining whether the top or
> middle or bottom row of the field should be aligned with the
> baseline for the text line in which the TEXTAREA element
> appears. The default is align=top.
>
> With ALIGN=LEFT, the field will float down and over to the
> current left margin, and subsequent text will wrap around the
>
>Dave Raggett Page
134
>HTML 3.0 28th March
1995
>
> right hand side of the field. Likewise for ALIGN=RIGHT, the
> field aligns with the current right margin and, and text wraps
> around the left.
>
>
>
>
>At 12:55 AM 3/28/1998 +0000, David Woolley wrote:
>>> >
>>> >Apparently some buffer is overflowing and the charaacters are getting
sent
>>> >to Lynx commands.
>>
>>Based on a fifteen minute look at the code, Lynx 2.7.2 violates the
>>July draft of HTML 4.0. What I think it is doing is converting textarea
>>into a series of text field internally and then re-assembling them when
>>it submits the form. As a result it can't scroll vertically. The
>>HTML 4.0 draft I have in hard copy says that neither the number of
>>rows nor columns should limit the amount of data entered.
>>
>>The problem then arises for Lynx of: how do you get out of the text area.
>>At the moment an excess CR or downarrow will do this, but if you make it
>>scrollable, you need another way out.
>>
>>However, I would say you are using the wrong approach if you try and
>>manipulate the screen; you should be using -post_data on the command
>>line.
>>
>>> ><P><FORM METHOD=POST ACTION="http://www.wopr.com/lounge/index.cgi?post">
>>
>>That parameter set should be compatible with -post_data; you just have
>>to remember to URL encode everything.
>>
>>> >spaces)<br><STRONG>Message:</STRONG><BR><TEXTAREA COLS=60 ROWS=5
>>> >NAME="body" WRAP=VIRTUAL>
>> ^^^^ This parameter doesn't appear to exist in HTML 4.0
>> unless it is a core attribute, which I doubt.
>>
>>
>
>