W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 13769] WF3: Add trim="" attribute to <textarea>, <input type=text/search>, <form>, and <fieldset> (applying to all contained fields of appropriate types) that strips leading and trailing whitespace from the value

From: <bugzilla@jessica.w3.org>
Date: Thu, 06 Oct 2011 15:52:22 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RBqFC-0005Hz-F6@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13769

--- Comment #29 from Marat Tanalin | tanalin.com <mtanalin@yandex.ru> 2011-10-06 15:52:18 UTC ---
(In reply to comment #27)
> Trimming from the start of <textarea> seems dangerous, as it might change the
> meaning of the value (consider, e.g., a use pasting in some python code).

Since using trim attribute is completely optional (unlike to embedding trimming
to 'required' attribute functionality) and therefore, if used, is purely
intentional, there are no problems at all.

If author adds 'trim' attribute, then he exactly knows that trimming for
particular field is needed and is OK anyway. If trimming for the field is not
needed, author will just not add 'trim' attribute.

(In reply to comment #28)
> (In reply to comment #27)
> > Could you elaborate on the use case for trim="" on <fieldset>?
> 
> I believe like for <form>: applying to all descendants.

Exactly. For example, required fields (which values are needed to be trimmed
always in real world) could be groupped into a separate fieldset.

For example:

    <fieldset trim>
        <input name="lorem" />
        <input name="ipsum" />
        <textarea name="dolor"></textarea>
    </fieldset >

would be equivalent to:

    <fieldset>
        <input name="lorem" trim />
        <input name="ipsum" trim />
        <textarea name="dolor" trim></textarea>
    </fieldset >

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 6 October 2011 15:52:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:05 UTC