This should be optional - The compact design of the current class is part of the beauty of it.
So you prefer a compact class over valid XML?
When the overhead of checking is unnecessary, or not required (which is more often the case.)
Try using an attribute with value "PEAR&PECL", this will result in invalid HTML. Maybe you know that entities must be used, but a lot of novice users do not know this. I've been developing a lot of XML-related packages for PEAR (and other repositories) and I know that users have problems with XML from the feedback I get.
replacentities effectly does : htmlspecialchars($var, *ENT_QUOTES) - I'm not sure this method should even exist???
I'm not sure the attributesToString method is a good enough justification to force a dependancy - I've implemented the same routine in HTML_Template_Flexy_Element. - Most of the apps I write try to get away with < 20 files included per request, which is high already.. - but not too bad (considering only 1 v.small file is request specific), so stripping dependancies down is often quite important..
If you depend on a whole package for just 1 simple method - From what I remember it has already been said that, copy&paste may be more efficient..
*
Then why don't you use createTagFromArray()?
I know that you are a fan of methods that accept one array as parameter, but a lot of people are not. So XML_Util provides methods for both variations.
Anything that encourages people to write code that is impossible to read is never a good idea :) - I would recomend marking the 'non_array' version as depreciated, or at least sticking a warning, noting that, using all the arguments will make you code very difficult to read....
It could optionally also use XML_HTMLSax.
AFAIK XML_HTMLSax assumes that the HTML is XML parseable????? - which is rarely the case???
Regards
Alan