Re: [Zope3-dev] Re: XML header and TAL interpretor
Sidnei da Silva wrote: That smells to me like we need a mime-type negotiator or something, pretty much like we have a language negotiator for deciding which language to use for translations. No really, all this thread seems to have really uncovered so far is that macros in different ZPT modes are currently reported as incompatible. Are they really? Should they be? mime-type negotiation and the like seems like an app level thing, or at the very least the responsibility of a different component. Page Templates should be kept as clean and simple as possible, that way they'll be much mroe generically useful... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Andreas Reuleaux schrieb: On Thu, Sep 01, 2005 at 06:58:42PM +0200, Tonico Strasser wrote: ... What's your point? Well, from reading your conversation with Philipp I got the impression, that you wanted to say something like XML-Mode in PTs respectively XHTML is useless if served with the wrong MIME type --- You did not use the term useless so I might have overinterpreted what you wrote, sorry for that. I want to point out that if XML mode is the *default* mode for page templates in Zope 3, everything that does not override the mime type will be served as XML. (That's the current behaviour, it might change in the future?). At least we would need to be able to trigger HTML mode. Fact is, that XML-Mode in PTs / XHTML is *not* made useless by any MIME-Type, the MIME-Type application/xhtml+xml is just another way of assuring your XHTML is correct. See above. I'm not saying that pages in XML mode are useless. Basically you are free to choose any method that helps you write valid XHTML pages: * that can be Zope's XML-Mode for PTs * that can just as well be external validation * or that can be the browser, that is unforgiving if serverd application/xhtml+xml But if your XHTML is valid (e. g. if you have checked your page at validator.w3.org) then application/xhtml+xml won't show you any additional otherwise hidden mistakes. Not mistakes, but there is a huge difference IMHO: Pages are parsed as XML not as HTML http://mail.zope.org/pipermail/zope3-dev/2005-September/015554.html The onliest thing that can make your XHTML useless is doctype switching, say a wrong doctype or a bug that causes IE to go into quirks mode (mentioned before). -Andreas PS: I have also just read your second answer to my E-mail and I am glad you could make some sense of it. :) Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Fred Drake schrieb: On 8/31/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote: HTML4 mode exists because ... - it enforces some HTML document type (as mentioned before); no idea why it does that I'm just guessing you're referring to its understanding of the allowed nesting structures. This is done so that the partial well-formedness it requires mixed with the careless infliction of pain commonly performed by old-style HTML authors produces as few surprises as possible. The only well-formedness it directly enforces is for elements that actually have TAL, METAL, and I18N attributes. Whether this was the right thing to do is debatable. Another reason for the HTML mode is that many of the HTML editors deployed when we first developed TAL were not generating XHTML, and weren't expected to do so in the immediate future. We definately wanted page templates to be editable in WYSIWYG-type editors. And, as long pages are served as text/html they are treated as old-style HTML by browsers anyway[1]. XHTML pages served as text/html must follow the compatibility guidelines[2]. E.g. in ZPT HTML mode, elements like br/ will be converted to br / automagically (with space before the slash). That is a good thing IMHO. [1] Serving XHTML 1.0 http://www.w3.org/International/articles/serving-xhtml/ [2] HTML Compatibility Guidelines http://www.w3.org/TR/xhtml1/#guidelines Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Tonico Strasser wrote: Fred Drake schrieb: On 8/31/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote: HTML4 mode exists because ... - it enforces some HTML document type (as mentioned before); no idea why it does that I'm just guessing you're referring to its understanding of the allowed nesting structures. This is done so that the partial well-formedness it requires mixed with the careless infliction of pain commonly performed by old-style HTML authors produces as few surprises as possible. The only well-formedness it directly enforces is for elements that actually have TAL, METAL, and I18N attributes. Whether this was the right thing to do is debatable. Another reason for the HTML mode is that many of the HTML editors deployed when we first developed TAL were not generating XHTML, and weren't expected to do so in the immediate future. We definately wanted page templates to be editable in WYSIWYG-type editors. And, as long pages are served as text/html they are treated as old-style HTML by browsers anyway[1]. XHTML pages served as text/html must follow the compatibility guidelines[2]. E.g. in ZPT HTML mode, elements like br/ will be converted to br / automagically (with space before the slash). That is a good thing IMHO. 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. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Derrick Hudson wrote: On Wed, Aug 31, 2005 at 03:54:45PM +0200, Philipp von Weitershausen wrote: | Julien Anguenot wrote: [...] | If you change the header like this then it can be succesfully included : | | ?xml version=1.0 encoding=UTF-8? | html xmlns=http://www.w3.org/1999/xhtml; |xmlns:tal=http://xml.zope.org/namespaces/tal; |xmlns:metal=http://xml.zope.org/namespaces/metal; |xmlns:i18n=http://xml.zope.org/namespaces/i18n; |i18n:domain=zope | body | | What kind of issue could we have changing the headers like this on all | the standard macros since it's xhtml already ? | | I'm not sure if this is a good idea. Because once Zope3's macros are XML | mode, all other templates using those macros need to be XML mode. That, | in turn, means that all templates need to carry the ?xml ...? | processing instruction because that's the only way XML mode is currently | triggered. Since that processing instruction is optional (as opposed to | namespace declarations which are mandatory), I wouldn't want to force it | on template authors. Don't forget that IE will then have an insane tendency to render the pages wrong. I don't recall all of the details, but it was something like if the document began with ?xml ? IE would switch to quirks mode and do funny things with boxes, margins, and the overall layout. The details are in this list's archives (if they aren't it's in the zope@zope.org list archives). I know about quirks mode and how it's provoked with ?xml ... ?. Exactly because of that it has been impossible to use ZPT's XML mode to render web pages -- because IE will choke on the ?xml ... ? that is necessary to put the ZPT machinery into XML in the first place... a vicious circle so to speak. If we make XML the default mode, I don't see how it would impact IE very much. After all, the ?xml ... ? processing instruction would then be optional and could be left out for XHTML pages. It would finally be possible to properly embed XForms, SVG etc. into XHTML though. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
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. 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. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Philipp von Weitershausen schrieb: If we make XML the default mode, I don't see how it would impact IE very much. IE would try to dowload HTML pages not served as text/html. Pages in XML mode should be served as XML not text/html. Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Philipp von Weitershausen schrieb: Tonico Strasser wrote: Philipp von Weitershausen schrieb: If we make XML the default mode, I don't see how it would impact IE very much. IE would try to dowload HTML pages not served as text/html. Pages in XML mode should be served as XML not text/html. I think that last sentence is a bit strong and IMO even plain wrong. ZPT's mode of operation has nothing to do with how it's served in an HTTP response. I thougth this is part of the XML spec. No? http://www.xml.com/pub/a/2004/07/21/dive.html http://www.ietf.org/rfc/rfc3023.txt Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
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? 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. Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
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 :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: XML header and TAL interpretor
-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 RD (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
Re: [Zope3-dev] Re: XML header and TAL interpretor
Julien Anguenot wrote: I think it's time to sketch out a proposal :). +1 Do you want to write it ? I can start, then you, Tonica and others can pad it out in the wiki. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Philipp von Weitershausen schrieb: 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 ask because I don't know: if I serve a ZPT page in Zope 3 in XML mode, which mime type is sent to the browser? Is this independent of the ZTP XML/HTML mode? Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
On Thu, Sep 01, 2005 at 05:00:37PM +0200, Tonico Strasser wrote: | Philipp von Weitershausen schrieb: | 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 ask because I don't know: if I serve a ZPT page in Zope 3 in XML mode, | which mime type is sent to the browser? Is this independent of the ZTP | XML/HTML mode? As I just stated in the other subthread, I believe the HTTP Content-Type is (should be) independent of the mode the ZPT machinery uses to process the template. The browser:page directive or some other suitable explicit configuration should control the browser-specific items like content-type. I suppose maybe the publisher could add its two sense and handle IE and Mozilla differently presenting a facade to IE so it doesn't trip over itself and presenting the more-correct-by-the-spec information to Mozilla. -D -- If you want to know what God thinks about money, just look at the people He gives it to. -- Old Irish Saying www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Philipp von Weitershausen wrote: Julien Anguenot wrote: I got a problem with the standard macros use and the XML header. I've a view defined like the one below : ?xml version=1.0 encoding=UTF-8? html xmlns:tal=http://xml.zope.org/namespaces/tal; xmlns:metal=http://xml.zope.org/namespaces/metal; body metal:use-macro=context/@@standard_macros/page !-- content -- /body /html And there, I got the following error when Zope's trying to render it : [snip] (`macroName`, `mode`), self.position) METALError: macro u'context/@@standard_macros/page' has incompatible mode 'html', at line 6, column 3 If I remove the xml header the error disappears. It sucks, don't it? Has anyone tried removing the macro mode check (in TALIntepreter.do_userMacro)? What would break? At least I think it wouldn't be a problem to allow inclusing of a XML macro in an HTML slot (or maybe the other way round -- I guess one of them works, as one is always stricter than the other). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Andreas Reuleaux schrieb: On Thu, Sep 01, 2005 at 11:44:48AM +0200, Tonico Strasser wrote: ... And, as long pages are served as text/html they are treated as old-style HTML by browsers anyway[1]. XHTML pages served as text/html must follow the compatibility guidelines[2]. E.g. in ZPT HTML mode, elements like br/ will be converted to br / automagically (with space before the slash). That is a good thing IMHO. [1] Serving XHTML 1.0 http://www.w3.org/International/articles/serving-xhtml/ [2] HTML Compatibility Guidelines http://www.w3.org/TR/xhtml1/#guidelines Tonico ... Tonico, I think you misunderstood something: While it is true that pages served as text/html are treated as HTML by browsers, there are still quite some differences how they treat the HTML, i. e. in which mode they operate (doctype switching). After rereading your posting, I think I understand what you mean. If you serve a XHTML page as text/html, a browser will treat this page as HTML4.x *not* XHTML. I'm not talking about browser rendering modes. That's why pages served as text/html should follow the XHTML compatibility guidelines, I think. You can test this, create a HTML page and insert a document.write with JavaScript somewhere. You will notice, that it does not work in pages served as application/xhtml+xml. (You must use a browser which understands XHTML e.g. Mozilla, Opera or Konqueror). Why document.write() doesn't work in XML http://ln.hixie.ch/?start=1091626816count=1 Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Julien Anguenot wrote: I got a problem with the standard macros use and the XML header. I've a view defined like the one below : ?xml version=1.0 encoding=UTF-8? html xmlns:tal=http://xml.zope.org/namespaces/tal; xmlns:metal=http://xml.zope.org/namespaces/metal; body metal:use-macro=context/@@standard_macros/page !-- content -- /body /html And there, I got the following error when Zope's trying to render it : [snip] (`macroName`, `mode`), self.position) METALError: macro u'context/@@standard_macros/page' has incompatible mode 'html', at line 6, column 3 If I remove the xml header the error disappears. It sucks, don't it? big time yeah... It's really a huge problem because it means Zope3 'as it' can't render valid XML pages with standard macros... Any idea how to fix thix problem without having to rewrite the standard macros ? My use case is the inclusion of XForms within the Page Template and the mozilla plugin requires the page to be XML valid and thus to have the xml header. Any hints welcome. [...] So, instead of proposing to radically get rid of HTML4 mode, I propose this: - XML mode of ZPT becomes the standard mode. +1 - We keep HTML4 mode around as long people need it, but it's not the standard mode. The switch whether to use XML or HTML4 mode is done via ZCML and not some sniffing in the PageTemplate contents. I don't have any opinion on this. Yes, I realize that this will suddenly introduce the requirement that all templates need to carry namespace declarations. That's not a problem. I think that's a good thing. They're not dead chickens. Namespace declarations are meaningful and useful and they're what XML-capable people and tools are used to. To sum it up: it's the spec. I've always found it much harder to explain why Zope wouldn't support the spec in this or that particular case than just sticking with the spec in such cases. clearly. I would be willing to work this out as a full-blown proposal together with Julien. great ! J. - -- Julien Anguenot | Nuxeo RD (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 iD8DBQFDFakfGhoG8MxZ/pIRAmJ9AJ47mCTNwIBx62Vq0hekv4kB/WAa6ACeLhoh svXXo+MgmusOVhrFmmIiblM= =K9kd -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Julien Anguenot wrote: Ok the problem is the doctype declaration on top of the macro files that force the tal interpretor to enter html mode and as far as I understand you can't have mix moded macros. Exactly. I forgot to mention that in my follow-up... Btw, doctype declaration is something else. You probably just mean the XML processing instruction. If you change the doctype declaration with the xml header and add the xmlns declaration for tal, metal and i18n then everything's fine after. See for instance the navigation macros : http://svn.zope.org/Zope3/trunk/src/zope/app/rotterdam/navigation_macros.pt?rev=28163view=auto If you change the header like this then it can be succesfully included : ?xml version=1.0 encoding=UTF-8? html xmlns=http://www.w3.org/1999/xhtml; xmlns:tal=http://xml.zope.org/namespaces/tal; xmlns:metal=http://xml.zope.org/namespaces/metal; xmlns:i18n=http://xml.zope.org/namespaces/i18n; i18n:domain=zope body What kind of issue could we have changing the headers like this on all the standard macros since it's xhtml already ? I'm not sure if this is a good idea. Because once Zope3's macros are XML mode, all other templates using those macros need to be XML mode. That, in turn, means that all templates need to carry the ?xml ...? processing instruction because that's the only way XML mode is currently triggered. Since that processing instruction is optional (as opposed to namespace declarations which are mandatory), I wouldn't want to force it on template authors. I would think changing the headers like the above AND changing the default mode to XML mode at the same time would probably be more appropriate because it would only introduce one upgrade hurdle (the mandatory namespace declarations). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
On Wed, Aug 31, 2005 at 03:54:45PM +0200, Philipp von Weitershausen wrote: | Julien Anguenot wrote: [...] | If you change the header like this then it can be succesfully included : | | ?xml version=1.0 encoding=UTF-8? | html xmlns=http://www.w3.org/1999/xhtml; |xmlns:tal=http://xml.zope.org/namespaces/tal; |xmlns:metal=http://xml.zope.org/namespaces/metal; |xmlns:i18n=http://xml.zope.org/namespaces/i18n; |i18n:domain=zope | body | | What kind of issue could we have changing the headers like this on all | the standard macros since it's xhtml already ? | | I'm not sure if this is a good idea. Because once Zope3's macros are XML | mode, all other templates using those macros need to be XML mode. That, | in turn, means that all templates need to carry the ?xml ...? | processing instruction because that's the only way XML mode is currently | triggered. Since that processing instruction is optional (as opposed to | namespace declarations which are mandatory), I wouldn't want to force it | on template authors. Don't forget that IE will then have an insane tendency to render the pages wrong. I don't recall all of the details, but it was something like if the document began with ?xml ? IE would switch to quirks mode and do funny things with boxes, margins, and the overall layout. The details are in this list's archives (if they aren't it's in the zope@zope.org list archives). (not that I'm a fan of IE, but I do recall that being a problem for some people) -D -- He is no fool who gives up what he cannot keep to gain what he cannot lose. --Jim Elliot www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
On Wed, Aug 31, 2005 at 02:48:11PM +0200, Philipp von Weitershausen wrote: [...] | PageTemplates know two different modes, HTML4 mode and XML mode: [...] | So, instead of proposing to radically get rid of HTML4 mode, I propose this: | | - XML mode of ZPT becomes the standard mode. | | - We keep HTML4 mode around as long people need it, but it's not the | standard mode. The switch whether to use XML or HTML4 mode is done via | ZCML and not some sniffing in the PageTemplate contents. +1 | Yes, I realize that this will suddenly introduce the requirement that | all templates need to carry namespace declarations. I think that's a | good thing. They're not dead chickens. Namespace declarations are | meaningful and useful and they're what XML-capable people and tools are | used to. To sum it up: it's the spec. I've always found it much harder | to explain why Zope wouldn't support the spec in this or that particular | case than just sticking with the spec in such cases. I'm all too familiar with arguments of this form (but the spec says to do it that way and we aren't). I, for one, am almost always in favor of adhering to specifications and doing things right. I think it would be beneficial to encourage the use of XHTML this way. -D -- [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: XML header and TAL interpretor
On Wednesday 31 August 2005 10:05, Julien Anguenot wrote: Don't forget that IE will then have an insane tendency to render the pages wrong. I don't recall all of the details, but it was something like if the document began with ?xml ? IE would switch to quirks mode and do funny things with boxes, margins, and the overall layout. The details are in this list's archives (if they aren't it's in the zope@zope.org list archives). (not that I'm a fan of IE, but I do recall that being a problem for some people) Having IE full of bugs is not a reason to not support standards such as the xml processing instruction (which makes a document *not* XML valid if it's not present on top of the document) We'll think about buggy browsers in a second step ;) If there is an IE issue it needs to be addressed and a solution be found before any action can be taken. IE still has the majority market share and we cannot be ignorant about it. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: XML header and TAL interpretor
On Aug 31, 2005, at 10:46 AM, Stephan Richter wrote: On Wednesday 31 August 2005 10:05, Julien Anguenot wrote: Don't forget that IE will then have an insane tendency to render the pages wrong. I don't recall all of the details, but it was something like if the document began with ?xml ? IE would switch to quirks mode and do funny things with boxes, margins, and the overall layout. The details are in this list's archives (if they aren't it's in the zope@zope.org list archives). (not that I'm a fan of IE, but I do recall that being a problem for some people) Having IE full of bugs is not a reason to not support standards such as the xml processing instruction (which makes a document *not* XML valid if it's not present on top of the document) We'll think about buggy browsers in a second step ;) If there is an IE issue it needs to be addressed and a solution be found before any action can be taken. IE still has the majority market share and we cannot be ignorant about it. +1 Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
On Wed, Aug 31, 2005 at 10:46:34AM -0400, Stephan Richter wrote: | On Wednesday 31 August 2005 10:05, Julien Anguenot wrote: | Don't forget that IE will then have an insane tendency to render the | pages wrong. I don't recall all of the details, but it was something | like if the document began with ?xml ? IE would switch to quirks | mode and do funny things with boxes, margins, and the overall layout. | The details are in this list's archives (if they aren't it's in the | zope@zope.org list archives). | | (not that I'm a fan of IE, but I do recall that being a problem for | some people) | | Having IE full of bugs is not a reason to not support standards such as | the xml processing instruction (which makes a document *not* XML valid | if it's not present on top of the document) | | We'll think about buggy browsers in a second step ;) | | If there is an IE issue it needs to be addressed and a solution be found | before any action can be taken. Ok, here you go: http://mail.zope.org/pipermail/zope3-dev/2005-July/014924.html http://mail.zope.org/pipermail/zope3-dev/2005-July/014911.html | IE still has the majority market share and we cannot be ignorant | about it. Yeah. I never deal with it though, fortunately. -D -- A violent man entices his neighbor and leads him down a path that is not good. Proverbs 16:29 www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
