Re: Hubbub "has_children" tree callback no longer used?

Thanks for your assessment, much appreciated!

Ralf

On 12.02.2014 19:05, John-Mark Bell wrote:

> Please reply to the list and not directly to me. Thanks.
>
> On Wed, Feb 12, 2014 at 06:05:28PM +0100, Ralf Junker wrote:
>
>> On 12.02.2014 17:01, John-Mark Bell wrote:
>>
>>> On Tue, Feb 11, 2014 at 05:10:35PM +0100, Ralf Junker wrote:
>>>
>>>> Hence I believe that the "has_children" callback could (and should?) be
>>>> removed from the hubbub_tree_handler.
>>>
>>> That would be an ABI break, which we strive to avoid. However, the next
>>> release of Hubbub already breaks the ABI in other areas, so I'm inclined
>>> to take the opportunity to remove that treebuilder callback entry.
>>
>> I am all for it, unless ...
>>
>>> Of course, it might resurface later, should we ever get around to
>>> bringing Hubbub's implementation back in line with the specification.
>>> Somewhat embarrassingly, it's nearly 5 years out of date.
>>
>> ... Hubbub requires the has_children callback to meet the specification.
>> If so, I would prefer to leave it in now to avoid ABI breaks in the
>> future.
>
> Well, fundamentally, I don't think we're anywhere near a position where
> the Hubbub's ABI can be called stable, regardless of this specific case.
> 5 years of specification changes will have a great deal of impact. Until
> Hubbub is updated, it's almost impossible to know what will change.
>
>> Since documentation is somewhat scarce, could you name parts of the
>> specifications Hubbub currently does not conform to? I am not asking for
>> an exhaustive list, just some clues to give me a rough idea.
>
> The only part of the HTML specification which is relevant to Hubbub is
> the chapter on parsing (and anything it references). I'm not going to
> quote the section numbers, as that's liable to change as the
> specification evolves.
>
> As docs/Updated states, the last time Hubbub matched the specified
> behaviour was 2009-03-10. The specification has changed a great deal
> since then (and no, we have not done a gap analysis to see where the
> differences lie).