On Sat, Jul 02, 2016 at 03:11:58PM -0700, Kevin Carhart wrote:
> There's a lot to do basically.  I see tidy errors, but I gravitate to the JS
> errors, I guess partially because they are autonomous for us to fix, while
> messages from tidy involve making threads with the tidy developers, fun and
> worthy in its own right, but the path of least resistance takes you to
> something you can work on right away.  (Dang, here's a toast to the tidy
> group!  It underpins everything now and it's so good I don't think about it!
> We only integrated tidy around 1 year ago.)

Agreed, it's worked well and simplified the code-base as well as handling much of the oddness in modern html for us.

> We could add things to availableTags one by one as we find them but this
> will go forever.  I experimented adding a "placeholder" to availableTags and
> editing html.c so that if the call to newTag fails to find a string,
> it will create your element as a "placeholder."  But I don't know what I'm
> doing - I was also seeing some infinite loops in renderNode, which I
> probably caused by adding placeholder.  I don't know what the TAGACT or
> flags should be for a made-up placeholder.

I think that we should probably treat them as... div... elements may be so at least things are rendered.  May be print a debug message at a relatively high
debug level so that we can track unimplemented tags and hopefully clean up some of the more common ones.  The trick here is (as I said in a previous email to
Karl) to expose the provided element type to js.  In some cases, i.e. with non-text elements, this may not necessarily be possible but I suspect that doing this
will hopefully fix a few things with just one task.

Cheers,
Adam.