missing void elements
Hello,
Where's the lxml issue tracker? I couldn't find it?
Void elements are html tags that don't need a closing tag. <br> is a well known example:
from lxml.builder import E html.tostring(E.br())
'<br>'
etree.tostring(E.br())
'<br/>'
<p> is not a void element, so:
html.tostring(E.p())
'<p></p>'
etree.tostring(E.p())
'<p/>'
see the full list:
http://www.w3.org/TR/html5/syntax.html#elements-0
While working on etree.htmlfile, I noticed that the following tags are not treated as void:
embed, keygen, source, track, wbr
see: https://github.com/lxml/lxml/pull/142#issuecomment-55588559
because of this, lxml can produce invalid html.
once this issue is resolved, the tuple at:
https://github.com/lxml/lxml/commit/c039e03798d84ac3f897354f0780f15346da1361...
needs to be updated.
best, burak
Where's the lxml issue tracker? I couldn't find it?
http://lxml.de/index.html#bug-tracker
Cheers, Holger
Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart
Burak Arslan schrieb am 16.09.2014 um 10:12:
Void elements are html tags that don't need a closing tag. <br> is a well known example:
from lxml.builder import E html.tostring(E.br())
'<br>'
etree.tostring(E.br())
'<br/>'
<p> is not a void element, so:
html.tostring(E.p())
'<p></p>'
etree.tostring(E.p())
'<p/>'
see the full list:
http://www.w3.org/TR/html5/syntax.html#elements-0
While working on etree.htmlfile, I noticed that the following tags are not treated as void:
embed, keygen, source, track, wbr
see: https://github.com/lxml/lxml/pull/142#issuecomment-55588559
because of this, lxml can produce invalid html.
It's libxml2 serialising them, though. lxml has no word in this.
OTOH, it might be a good idea to make xf.element() aware of self-closing tags in HTML mode and let it a) write them out without closing tag and b) raise an exception when users attempt to write content into them.
You'd then write
with xf.element('meta', ...): pass
which isn't really worse than
xf.write(etree.Element('meta', ...))
That's another inconsistency, because the latter would still serialise some self-closing elements with closing tags. But I still consider it an improvement to provide a way for users to get it right at all.
Stefan
On 09/25/14 19:59, Stefan Behnel wrote:
It's libxml2 serialising them, though. lxml has no word in this.
OTOH, it might be a good idea to make xf.element() aware of self-closing tags in HTML mode and let it a) write them out without closing tag and b) raise an exception when users attempt to write content into them.
I disagree. If the user explicitly wants to write something inside, say, an input element, (s)he should be free to do so, just like the user is free to write namespaced elements. This may be for good reason -- e.g. for a fancy javascript framework that expects that kind of input.
You'd then write
with xf.element('meta', ...): passwhich isn't really worse than
xf.write(etree.Element('meta', ...))That's another inconsistency, because the latter would still serialise some self-closing elements with closing tags.
Which ones? How come? I'm testing every single one of them here:
https://github.com/lxml/lxml/blob/f8bdb7d48b5cf4403aa6bbbf10f5f8da6a4a510e/s...
Best, Burak
Burak Arslan schrieb am 30.09.2014 um 10:05:
On 09/25/14 19:59, Stefan Behnel wrote:
It's libxml2 serialising them, though. lxml has no word in this.
OTOH, it might be a good idea to make xf.element() aware of self-closing tags in HTML mode and let it a) write them out without closing tag and b) raise an exception when users attempt to write content into them.
I disagree. If the user explicitly wants to write something inside, say, an input element, (s)he should be free to do so, just like the user is free to write namespaced elements. This may be for good reason -- e.g. for a fancy javascript framework that expects that kind of input.
Granted.
So, what you're saying is that even
with xf.element('meta', ...): pass
should write an opening and a closing tag?
You'd then write
with xf.element('meta', ...): passwhich isn't really worse than
xf.write(etree.Element('meta', ...))That's another inconsistency, because the latter would still serialise some self-closing elements with closing tags.
Which ones? How come? I'm testing every single one of them here:
https://github.com/lxml/lxml/blob/f8bdb7d48b5cf4403aa6bbbf10f5f8da6a4a510e/s...
Yes, and you put a comment there that said:
""" # FIXME: These don't get serialized as void elements. """
Stefan
On 09/30/14 11:20, Stefan Behnel wrote:
So, what you're saying is that even
with xf.element('meta', ...): passshould write an opening and a closing tag?
yes.
You'd then write
with xf.element('meta', ...): passwhich isn't really worse than
xf.write(etree.Element('meta', ...))That's another inconsistency, because the latter would still serialise some self-closing elements with closing tags.
Which ones? How come? I'm testing every single one of them here:
https://github.com/lxml/lxml/blob/f8bdb7d48b5cf4403aa6bbbf10f5f8da6a4a510e/s...
Yes, and you put a comment there that said:
""" # FIXME: These don't get serialized as void elements. """
Ah, sure :) So am I supposed to file a bug in https://bugzilla.gnome.org/buglist.cgi?product=libxml2 ?
There are almost 2000 open issues there, that's scary.
Best, Burak
Burak Arslan schrieb am 30.09.2014 um 10:32:
On 09/30/14 11:20, Stefan Behnel wrote:
So, what you're saying is that even
with xf.element('meta', ...): passshould write an opening and a closing tag?
yes.
I don't really have a preference here, so the current way of working (i.e. the above) is ok with me.
You'd then write
with xf.element('meta', ...): passwhich isn't really worse than
xf.write(etree.Element('meta', ...))That's another inconsistency, because the latter would still serialise some self-closing elements with closing tags.
Which ones? How come? I'm testing every single one of them here:
https://github.com/lxml/lxml/blob/f8bdb7d48b5cf4403aa6bbbf10f5f8da6a4a510e/s...
Yes, and you put a comment there that said:
""" # FIXME: These don't get serialized as void elements. """
Ah, sure :) So am I supposed to file a bug in https://bugzilla.gnome.org/buglist.cgi?product=libxml2 ?
There are almost 2000 open issues there, that's scary.
Yes. It usually helps to write the patch yourself and send it to the mailing list instead. :)
Should be easy in this case, as the functionality is already there, so it's most likely just about extending a list somewhere in the HTML code.
Stefan
Stefan Behnel schrieb am 30.09.2014 um 10:56:
Burak Arslan schrieb am 30.09.2014 um 10:32:
So am I supposed to file a bug in https://bugzilla.gnome.org/buglist.cgi?product=libxml2 ?
There are almost 2000 open issues there, that's scary.
Yes. It usually helps to write the patch yourself and send it to the mailing list instead. :)
Should be easy in this case, as the functionality is already there, so it's most likely just about extending a list somewhere in the HTML code.
... and *right now* would be an excellent time to do that, as the next release of libxml2 is scheduled in two weeks time.
Stefan
participants (3)
-
Burak Arslan -
Holger Joukl -
Stefan Behnel