Re: Tidy bug
Ben McCann <[email protected]> Sat, 10 Oct 2009 12:26:34 -0700
| Newsgroups | gmane.comp.web.html-tidy.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============6633990846248250712== Content-Type: multipart/alternative; boundary=000e0cd1d500a8d80c047599ac68 --000e0cd1d500a8d80c047599ac68 Content-Type: text/plain; charset=ISO-8859-1 > > One thing I can think of that would help with this example is discarding > elements for which only an end tag is found, rather than generating a > corresponding start tag. Can anyone think of a reason why that might not be > desirable? > I agree this would be desirable. This would also solve other problems I can think of. For example, I think this would create much better results if a tag was misordered: <table><tr></table></tr>. By discarding only the end tag, we would still end up with a normal looking table instead of adding a new element that we probably don't want. On Sat, Oct 10, 2009 at 12:19 PM, Klaus Johannes Rusch < [email protected]> wrote: > Ben McCann wrote: > >> Klaus, Charlie, >> Thank you both for taking a quick look at this issue for me. I see what's >> going on here now. >> I expected behavior closer to what Charlie described. I think that >> discarding the extra end tag </tr> would would make the most sense. But in >> my opinion the behavior Charlie described would be preferable to the current >> behavior. >> > I agree that in the specific example that would be the desirable behaviour. > Recognizing in general that a later element may be misplaced and should be > moved above the current element is difficult though. The current behaviour > is that elements are not discarded but instead required parent elements are > added to the tree. > > One thing I can think of that would help with this example is discarding > elements for which only an end tag is found, rather than generating a > corresponding start tag. Can anyone think of a reason why that might not be > desirable? > > Regards, Klaus > > -- > Klaus Johannes Rusch > [email protected] > http://www.atmedia.net/KlausRusch/ > > --000e0cd1d500a8d80c047599ac68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt= 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote">One thing I can t= hink of that would help with this example is discarding elements for which only an end tag is found, rather than generating a corresponding start tag. Can anyone think of a reason why that might not be desirable?<br></blockquote>I agree this would be desirabl= e.=A0 This would also solve other problems I can think of.=A0 For example, = I think this would create much better results if a tag was misordered: <= table><tr></table></tr>.=A0 By discarding only the end= tag, we would still end up with a normal looking table instead of adding a= new element that we probably don't want.<br> <br><br><div class=3D"gmail_quote">On Sat, Oct 10, 2009 at 12:19 PM, Klaus = Johannes Rusch <span dir=3D"ltr"><<a href=3D"mailto:[email protected]= et">[email protected]</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt = 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class=3D"im">Ben McCann wrote:<br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Klaus, Charlie,<br> Thank you both for taking a quick look at this issue for me. =A0I see what&= #39;s going on here now.<br> I expected behavior closer to what Charlie described. =A0I think that disca= rding the extra end tag </tr> would would make the most sense. =A0But= in my opinion the behavior Charlie described would be preferable to the cu= rrent behavior.<br> </blockquote></div> I agree that in the specific example that would be the desirable behaviour.= Recognizing in general that a later element may be misplaced and should be= moved above the current element is difficult though. The current behaviour= is that elements are not discarded but instead required parent elements ar= e added to the tree.<br> <br> One thing I can think of that would help with this example is discarding el= ements for which only an end tag is found, rather than generating a corresp= onding start tag. Can anyone think of a reason why that might not be desira= ble?<br> <br> Regards, Klaus<br><font color=3D"#888888"> <br> -- <br></font><div><div></div><div class=3D"h5"> Klaus Johannes Rusch<br> <a href=3D"mailto:[email protected]" target=3D"_blank">KlausRusch@atme= dia.net</a><br> <a href=3D"http://www.atmedia.net/KlausRusch/" target=3D"_blank">http://www= .atmedia.net/KlausRusch/</a><br> <br> </div></div></blockquote></div><br> --000e0cd1d500a8d80c047599ac68-- --===============6633990846248250712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference --===============6633990846248250712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Tidy-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tidy-develop --===============6633990846248250712==--