Daniel Veillard wrote:
You keep an handle to the meta element while it was already inserted in the tree ?
Yup
That would also work. Had just thought of a few other ways to handle this as well depending upon what changes should be made.Another way would be to make libxml2 not touch anything if it detects any http-equiv meta tag, and if it doesn't detect one try to put the tag serialization in the output buffer, but not in the tree itself. This would requires some tweaking of the serialization code but should not be too hard. This would be more satisfactory from an API POV since serialization would not modify the input tree, and would not disturb headers if the application is already taking care of it, while still adding the meta if the application is ignorant about it. What do you think ?
1. Add to tree if non existing otherwise do nothing.2. Same as 1 but if existing add any missing attributes and only change attribute values (if they should even be changed) so element and atts are re-used and not free'd (If existing att values changed then no possible breaking for existing apps) 3. Only for serializing - not sure why some of the output functions do not handle the meta, but doing this would now make them all handle it. Don't know if this is good or bad actually. For instance within the HTML serialization code only htmlSaveFileFormat mods the tree while the other functions done touch meta tag. Also this will change behavior if any apps are coded (for some strange reason) expecting this element to have been created for them in the tree. This would be ideal, but dont know about the final impact on other exisintg apps.
Rob