Make it possible to temporarily override output method when calling _IncrementalWriter.write

[plq]

Behold:

>>> from lxml import html, etree
>>> from lxml.builder import E
>>> html.tostring(E.foo(selected="bar"))
'<foo selected></foo>'
>>> etree.tostring(E.foo(selected="bar"))
'<foo selected="bar"/>'

With custom elements, HTML is no more a tag soup of predefined tag names. As can be seen in: https://user-content-dot-custom-elements.appspot.com/PolymerElements/paper-dropdown-menu/v1.4.2/paper-dropdown-menu/demo/index.html we may need to have the value of the selected attribute.

My solution to this is the ability to override the output method temporarily in write calls.

Stefan, If the patch is as simple as this, could you advise about the actual value to pass to write() when overriding method?

Thanks & best regards

[scoder]

See a bit further up in the file, there is a helper function for this:

    c_method = _findOutputMethod(method)

Seems like a nice feature. I'd like to see a bit of documentation added, though, and a test for what the different output methods do in this context.

[plq]

Just added tests. If you like it so far, I can add some docs as well. Where do you think we should talk about this?

[plq]

According to https://developers.google.com/web/fundamentals/getting-started/primers/customelements custom elements must contain a dash in tag names. Shold we maybe make this automatic for elements with dash in them?

[plq]

Hmmm, that'd be a bad idea. .write() call would have to go through the entire tree to see whether there are any tags with dash in them. never mind :)

[scoder]

Looks good so far. I think that extending the docstring would be enough.

The problem with the HTML attributes that you showed is because the serialisation is done manually directly in the writer, and it doesn't actually know about HTML. I agree that it should be fixed, but I'm not sure how exactly this should be done.

[plq]

Looks good so far. I think that extending the docstring would be enough.

Done. Anything else?

The problem with the HTML attributes that you showed is because the serialisation is done manually directly in the writer, and it doesn't actually know about HTML.

I think it'd be possible to add the method argument to element() function, subsequently add method information to _FileWriterElement class which in turn could use that info to generate the correct byte stream using two sets for void elements and void attributes, just like libxml does.

Whether we should add missing void elements to that list and introduce another incompatibility with what libxml does is a decision you will need to make.

[plq]

I think that's a discussion for another issue.

[scoder]

Agreed. Thanks for your contribution.