Re: [xml] XHTML Doc serialization and meta element

[Daniel Veillard <veillard redhat com>]

On Thu, Aug 25, 2005 at 10:14:02PM -0400, Rob Richards wrote:
> Daniel Veillard wrote:
> 
> >
> > Okay I read the patch, this is basically the way I would prefer to see
> >this implemented. Of course there might be some details to get right,
> >I would expect for example the serialization to be the same to the old
> >code in the majority of the cases (i.e. running the test suite would raise
> >a difference only for the XHTML document with an http-equiv meta element
> >in head assuming we have any of those). Goal is to have the least surprize
> >possible for those already using the feature whithout knowing :-), and
> >avoid the modification of the tree which is nasty.
> >
> > So I like it but the devil is in the details :-)
> > 
> >
> Here is what I have come up with for this. HTMLTree serialization not 
> included here - had started it but it breaks about half of the HTML 
> tests so not so sure if this would be a good thing. If the HTMLTree 
> serialization is to be left alone, I would suggest removal of the 
> htmlSetMetaEncoding calls from the htmlSaveFileFormat function as this 
> is the only function to implement it making it inconsistant with the 
> rest of the HTMLTree serialization functions.

  yes the call from the HTML serializer will have to go too for basically
the same reason but one step at a time is fine :-)

> On to the patch. It doesn't break any of the tests (there was an XHTML 
> document with the meta tag but it was already using the defaulting 
> values), but it does alter the old behavior a bit.
> - calling xmlNodeDumpOutput with a head element will produce the meta 
> element if not present, its parent is an html element and doc is XHTML.
> - meta element only added if a meta element with the http-equiv attr 
> having value Content-Type does not exist
>    Old functionality always added and would remove a meta element with 
> http-equiv attribute having value Content-Type and a content attribute
>    An existing meta element is no longer required to have the content 
> attribute

  I think this is fine, I would not consider this behaviour wrong,
it's more correct than the old one precisely :-)

> That was really all I could see for behavior changes.

  You have CVS access now, could you commit this ? :-) 

   thanks !

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/