Description: ------------ While it was already fixed in HTML_Common2 (2006-06-23: revision 1.3), the problem still exists with PHP4 version of this package. Reason is usage of php trim function. We should keep the blanks before and after the value of 'value' attribute. Test script: --------------- <?php require_once 'HTML/Common.php'; $a = 'name="remove" value=" << " type="button"'; $r = HTML_Common::_parseAttributes($a); var_export($r); ?> Expected result: ---------------- array ( 'name' => 'remove', 'value' => ' << ', 'type' => 'button', ) Actual result: -------------- array ( 'name' => 'remove', 'value' => '<<', 'type' => 'button', )

Pity that so much depends on this package that won't probably be able to migrate: * HTML_CSS * HTML_Page * HTML_Page2 * HTML_Progress * HTML_Progress2 * HTML_QuickForm * HTML_QuickForm_advmultiselect * HTML_QuickForm_altselect * HTML_Select * HTML_Table ... otherwise I'd suggest its a wontfix -> migrate to HTML_Common2.

Daniel, The migration to HTML_Common2 is not a valid solution. 1. as HTML_Common2 is a pure PHP5 package, the new parseAttributes() method is protected access and should be call by a parent inherit class 2. parseAttributes() method accept only a string as parameter, while HTML_Common::_parseAttributes() accept both string and array Why not just to fix the problem. Have a look at HTML_Common::_parseAttributes() behavior : - with array parameter no trim to keys, values - with string parameter, keys and values are trimmed

I think Laurent is right and that is definitely a bug that should be fixed in HTML_Common.

Fixed in release 1.2.5 Note though, that it won't make much difference, as HTML spec [1] says: > User agents may ignore leading and trailing white space in CDATA attribute values (e.g., " myval " may be interpreted as "myval"). Authors should not declare attribute values with leading or trailing white space. [1] http://www.w3.org/TR/html401/types.html