tremby
commented
9 years ago Obviously it's not ideal that the HTML serializer needs to work in two different ways. One solution would be to change over to using DOM across the board to build HTML. If that sounds good I may find some time to implement it.
It would additionally be useful to expose the built-in serializer (perhaps as its own class with an __invoke method) so a custom serializer can call the built-in one and then modify its output, rather than only having the choice to serialize the HTML from scratch or use the built-in one as is, as is currently the case.
erwan
The link resolver is now passed to the HTML serializer, as the third parameter. This allows HTML serializers to be a little more flexible and reusable.
The type of the HTML serializer is now explicitly described as "callable", since this shows that it can be not only a lambda but also any other kind of callable like a string function name, an array of class name and method or object and method or an object which implements the __invoke method.
The HTML serializer is now passed to the method which turns spans within blocks into HTML as well as the method which turns blocks into HTML. This allows finer control.
However, since internally blocks and spans are currently turned into HTML quite differently (blocks with string manipulation and spans with the DOM) an implementation of HTML serializer needs to handle each type differently. In particular, it must return a string of HTML if the $element passed to it is an instance of BlockInterface and a DOMElement if $element is an instance of SpanInterface. As before, it can also return null to skip this element and defer to the built-in serialization routines.
Some documentation has been added to this effect.