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.
pgpxcIM4NzBdC.pgp
Description: PGP signature
_______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
