Re: Tidy bug
Ben McCann <[email protected]> Tue, 20 Oct 2009 15:47:33 -0700
| Newsgroups | gmane.comp.web.html-tidy.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1322326973883826977== Content-Type: multipart/alternative; boundary=000e0cd20ff4de2615047665a581 --000e0cd20ff4de2615047665a581 Content-Type: text/plain; charset=ISO-8859-1 Hi Klaus, I see that you marked the issue I reported as rejected on SourceForge<https://sourceforge.net/tracker/?func=detail&aid=2855621&group_id=27659&atid=390963>. Can we reopen it to reflect the conversation on this email thread? I'd like it if we could work on implementing your suggestion: "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." Thanks, Ben Software Engineer Google Inc. On Sat, Oct 10, 2009 at 2:08 PM, Charlie Reitzel <[email protected]> wrote: > Yup, makes sense. > > At 12:26 PM 10/10/2009 -0700, Ben McCann wrote: > >>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 > ><<mailto:[email protected]>[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 > >><mailto:[email protected]>[email protected] > >>http://www.atmedia.net/KlausRusch/ > > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Tidy-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tidy-develop > --000e0cd20ff4de2615047665a581 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Klaus,<br>I see that you <a href=3D"https://sourceforge.net/tracker/?fun= c=3Ddetail&aid=3D2855621&group_id=3D27659&atid=3D390963">marked= the issue I reported as rejected on SourceForge</a>.=A0 Can we reopen it t= o reflect the conversation on this email thread?=A0 I'd like it if we c= ould work on implementing your suggestion: "One thing I can think of t= hat would help with this example is discarding elements for which only an end tag is found, rather than generating a corresponding start tag."<br><br>Thanks,<br>Ben<br>Softwa= re Engineer<br>Google Inc.<br><br><br><div class=3D"gmail_quote">On Sat, Oc= t 10, 2009 at 2:08 PM, Charlie Reitzel <span dir=3D"ltr"><<a href=3D"mai= lto:[email protected]">[email protected]</a>></span> 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;">Yup, makes sense.= <br> <div class=3D"im"><br> At 12:26 PM 10/10/2009 -0700, Ben McCann wrote:<br> >>One thing I can think of that would help with this example is disca= rding<br> >>elements for which only an end tag is found, rather than generating= a<br> >>corresponding start tag. Can anyone think of a reason why that migh= t not<br> >>be desirable?<br> ><br> </div><div class=3D"im">>I agree this would be desirable. =A0This would = also solve other problems I<br> >can think of. =A0For example, I think this would create much better res= ults<br> >if a tag was misordered: <table><tr></table></tr&g= t;. =A0By discarding only the<br> >end tag, we would still end up with a normal looking table instead of<b= r> >adding a new element that we probably don't want.<br> ><br> ><br> >On Sat, Oct 10, 2009 at 12:19 PM, Klaus Johannes Rusch<br> </div><div><div></div><div class=3D"h5">><<mailto:<a href=3D"mailt= o:[email protected]">[email protected]</a>><a href=3D"mailto:K= [email protected]">[email protected]</a>> wrote:<br> >>Ben McCann wrote:<br> >>>Klaus, Charlie,<br> >>>Thank you both for taking a quick look at this issue for me. = =A0I see<br> >>>what's going on here now.<br> >>>I expected behavior closer to what Charlie described. =A0I thin= k that<br> >>>discarding the extra end tag </tr> would would make the m= ost sense. =A0But<br> >>>in my opinion the behavior Charlie described would be preferabl= e to the<br> >>>current behavior.<br> >>I agree that in the specific example that would be the desirable<br= > >>behaviour. Recognizing in general that a later element may be mispl= aced<br> >>and should be moved above the current element is difficult though. = The<br> >>current behaviour is that elements are not discarded but instead re= quired<br> >>parent elements are added to the tree.<br> >><br> >>One thing I can think of that would help with this example is disca= rding<br> >>elements for which only an end tag is found, rather than generating= a<br> >>corresponding start tag. Can anyone think of a reason why that migh= t not<br> >>be desirable?<br> >><br> >>Regards, Klaus<br> >><br> >>--<br> >>Klaus Johannes Rusch<br> </div></div>>><mailto:<a href=3D"mailto:[email protected]">Kl= [email protected]</a>><a href=3D"mailto:[email protected]">Klaus= [email protected]</a><br> <div class=3D"im">>><a href=3D"http://www.atmedia.net/KlausRusch/" ta= rget=3D"_blank">http://www.atmedia.net/KlausRusch/</a><br> <br> <br> </div><div><div></div><div class=3D"h5">-----------------------------------= -------------------------------------------<br> Come build with us! The BlackBerry(R) Developer Conference in SF, CA<br> is the only developer event you need to attend this year. Jumpstart your<br= > developing skills, take BlackBerry mobile applications to market and stay<b= r> ahead of the curve. Join us from November 9 - 12, 2009. Register now!<br> <a href=3D"http://p.sf.net/sfu/devconference" target=3D"_blank">http://p.sf= .net/sfu/devconference</a><br> _______________________________________________<br> Tidy-develop mailing list<br> <a href=3D"mailto:[email protected]">[email protected]= urceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/tidy-develop" targe= t=3D"_blank">https://lists.sourceforge.net/lists/listinfo/tidy-develop</a><= br> </div></div></blockquote></div><br> --000e0cd20ff4de2615047665a581-- --===============1322326973883826977== 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 --===============1322326973883826977== 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 --===============1322326973883826977==--