-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Tonico Strasser wrote: > >>Philipp von Weitershausen schrieb: >> >> >>>Tonico Strasser wrote: >>> >>> >>>>Philipp von Weitershausen schrieb: >>>> >>>> >>>> >>>>>Tonico Strasser wrote: >>>>> >>>>> >>>>> >>>>>>Philipp von Weitershausen schrieb: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I'm not so sure that this is such a good thing. ZPT seems to enforce >>>>>>>*guidelines* that not everyone might want to follow (e.g. if I >>>>>>>want to >>>>>>>output my XHTML as c14n or something similar). For me, ZPT's HTML >>>>>>>mode >>>>>>>just does too many things, most of which won't hurt to be the >>>>>>>template >>>>>>>author's responsibility. I definitely consider <br/> vs. <br /> >>>>>>>one of >>>>>>>them. >>>>>> >>>>>> >>>>>> >>>>>>You have different use cases, obviously. For me, HTML mode is a good >>>>>>thing including <br/> to <br /> conversion. (I don't like to write <br >>>>>>/> all the time, all our web pages are served as text/html for >>>>>>non-XHTML >>>>>>browsers like MSIE, and we follow the compatibility guidelines from >>>>>>the >>>>>>XHTML standard). >>>>> >>>>> >>>>> >>>>> >>>>>That's good and I agree that there should be tools that aid you in >>>>>making your HTML work better with the guidelines. But if that means >>>>>introducing weird obstacles for ZPT authors, I don't think these tools >>>>>should be part of the ZPT renderer. If you don't want to write <br /> >>>>>all the time, use a "guideline compliance maker" tool (maybe xmllint >>>>>will do) and feed your template to it... Templating XML is part of >>>>>ZPT's >>>>>job; I question if it should do much more at this point. >>>> >>>>But that's why ZTPs have HTML mode, no? >>> >>>Yes. But rather than helping us, those features are more and more in our >>>way. And with XML and HTML modes being incompatible, I rather opt for >>>XML mode and sacrifice a small convenience that I could even bring back >>>by using additional tools. >>> >>> >>>>>>I agree that it should be possible to trigger XML mode without the >>>>>>prolog for use cases like yours. >>>>> >>>>> >>>>>That won't help because HTML mode macros and XML mode macros aren't >>>>>compatible. I really would like to see XML be the default, including >>>>>Zope 3's skin macros. >>>> >>>> >>>>Yes, would also like to see this. >>> >>>Ah, good. It wasn't at all clear that you actually supported the >>>proposal :). >> >>Yes, if it's still possible to trigger HTML mode. But what about >>backwards compatibility if we make XML the default mode? > > > Well, the namespace stuff would probably account for a major breakage. > Thus, over the span of two Zope releases, XML mode could be forgiveful > when people forget to register namespace declarations. Of course, it > would render deprecation warnings. > > I can't imagine a smooth transition for the other "features" of HTML > mode because they are like on/off switches. Either you convert <br/> to > <br /> or you don't. Same with <script ...></script> vs. <script ... /> > and the other things. > > I think it's time to sketch out a proposal :).
+1 Do you want to write it ? J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDFxUnGhoG8MxZ/pIRAvEMAJ0XxFB4peOaIgPyLtdDXIy+j85X0wCcDs4S z76EIi9Zd8UU8SbqVUaQZtw= =qWcz -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com