Re: [Framework-Team] Plone 5 - rough roadmap
On 15 March 2010 09:13, Alexander Limi l...@plone.org wrote: 2010/3/12 Hanno Schlichting ha...@hannosch.eu On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe l...@lrowe.co.uk wrote: On 12 March 2010 15:07, Hanno Schlichting ha...@hannosch.eu wrote: Currently listed for Plone 4.x are things like: ... - Well formed, valid XHTML (as a foundation for easier theming via xdv) That's really good to hear. Though I think semantic HTML or sensible ids/classes to identify elements in pages is what I had in mind with this point. Well besides the valid XHTML which is a requirement for Chameleon as well. It's also likely that we'll transition to using HTML5 (the XHTML-compatible phrasing, ie. HTML5, but close your tags), and Deco as a layout engine will be much happier if we do a revamp of the existing HTML structure. It's quite messy in parts from the 8+ years in production, and while it has held up well, it's time to adjust to how the web has evolved since then, especially with focus on our upcoming theming capabilities. We will almost certainly have to use an obsolete permitted doctype string to get lxml / libxml2 to output xhtml correctly. This means the intersection of the lists in http://svn.gnome.org/svn/libxml2/trunk/xmlsave.c and http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - xhtml 1.0 strict. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On 3/16/10 12:34 , Laurence Rowe wrote: On 15 March 2010 09:13, Alexander Limil...@plone.org wrote: 2010/3/12 Hanno Schlichtingha...@hannosch.eu On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowel...@lrowe.co.uk wrote: On 12 March 2010 15:07, Hanno Schlichtingha...@hannosch.eu wrote: Currently listed for Plone 4.x are things like: ... - Well formed, valid XHTML (as a foundation for easier theming via xdv) That's really good to hear. Though I think semantic HTML or sensible ids/classes to identify elements in pages is what I had in mind with this point. Well besides the valid XHTML which is a requirement for Chameleon as well. It's also likely that we'll transition to using HTML5 (the XHTML-compatible phrasing, ie. HTML5, but close your tags), and Deco as a layout engine will be much happier if we do a revamp of the existing HTML structure. It's quite messy in parts from the 8+ years in production, and while it has held up well, it's time to adjust to how the web has evolved since then, especially with focus on our upcoming theming capabilities. We will almost certainly have to use an obsolete permitted doctype string to get lxml / libxml2 to output xhtml correctly. This means the intersection of the lists in http://svn.gnome.org/svn/libxml2/trunk/xmlsave.c and http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - xhtml 1.0 strict. I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Tue, Mar 16, 2010 at 12:45 PM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. We'll discuss the pros/cons of switching once we get a full PLIP for this in time for Plone 5 in a year or so from now. From what I can tell today, we'll still need to support IE 7+ at that point, which puts clear limits on what we can do. I can see us using a lot of the new input elements which degrade nicely in older browsers for example. But switching the doctype won't be anything our default theme can do. Everyone is free to build a new theme himself experimenting with HTML5, but I don't see that as part of the core. Our default will have to be conservative, aiming for maximum compatibility. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv http://ejohn.org/blog/html5-shiv/ for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv http://ejohn.org/blog/html5-shiv/ for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On 3/16/10 18:40 , Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net mailto:wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Some very basic things I've run into: some browsers can't style the legend tag, some browsers can't style input (esp. file) elements, some browsers drop the value of button elements, some browsers do weird things if you offset the body (to the point where jQuery no longer even tries to support that). Given that today you can use div elements with classes to get the same results as HTML5 would give I don't see any point in trying to hasten a change to HTML5. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.netwrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv http://ejohn.org/blog/html5-shiv/ for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- *Veda Williams* Web Developer Groundwire 206.286.1235x23 v...@groundwire.org [image: Groundwire]http://groundwire.org?utm_source=Groundwire.org-emailutm_medium=Emailutm_campaign=email-signature;utm_content=Logo -- ONE/Northwest is now Groundwire! Read all about our new namehttp://groundwire.org/about/our-new-name?utm_source=Groundwire.org-emailutm_medium=Emailutm_content=Read%2Ball%20about%20our%20new%20nameutm_campaign=email-signature . -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi l...@plone.org wrote: What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Veda Williams Web Developer Groundwire 206.286.1235x23 v...@groundwire.org ONE/Northwest is now Groundwire! Read all about our new name. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
The way it works is that you can use the XHTML spelling (ie. closing your tags), but you serve it up as normal HTML. http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F There's no Strict or similar thing in HTML5, AFAIK. (There is also something informally referred to as XHTML5 which is serving it as XML, which isn't what we want to do) On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe l...@lrowe.co.uk wrote: By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi l...@plone.org wrote: What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Veda Williams Web Developer Groundwire 206.286.1235x23 v...@groundwire.org ONE/Northwest is now Groundwire! Read all about our new name. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
It is listed as an obsolete permitted doctype string http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - i.e. we can lie about the doctype. I'm not sure why xhtml 1.0 transitional is not allowed. Laurence On 16 March 2010 22:18, Alexander Limi l...@plone.org wrote: The way it works is that you can use the XHTML spelling (ie. closing your tags), but you serve it up as normal HTML. http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F There's no Strict or similar thing in HTML5, AFAIK. (There is also something informally referred to as XHTML5 which is serving it as XML, which isn't what we want to do) On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe l...@lrowe.co.uk wrote: By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi l...@plone.org wrote: What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Veda Williams Web Developer Groundwire 206.286.1235x23 v...@groundwire.org ONE/Northwest is now Groundwire! Read all about our new name. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
Right, I don't see a reason to do that, though — it doesn't buy us anything. The reason the HTML5 doctype is simply: !DOCTYPE html …is that it's the shortest possible string that will trigger strict/standards parsing (ie. not quirks mode) in all browsers, including IE6. On Tue, Mar 16, 2010 at 3:34 PM, Laurence Rowe l...@lrowe.co.uk wrote: It is listed as an obsolete permitted doctype string http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - i.e. we can lie about the doctype. I'm not sure why xhtml 1.0 transitional is not allowed. Laurence On 16 March 2010 22:18, Alexander Limi l...@plone.org wrote: The way it works is that you can use the XHTML spelling (ie. closing your tags), but you serve it up as normal HTML. http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F There's no Strict or similar thing in HTML5, AFAIK. (There is also something informally referred to as XHTML5 which is serving it as XML, which isn't what we want to do) On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe l...@lrowe.co.uk wrote: By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi l...@plone.org wrote: What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Veda Williams Web Developer Groundwire 206.286.1235x23 v...@groundwire.org ONE/Northwest is now Groundwire! Read all about our new name. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Alexander Limi · http://limi.net -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
Unfortunately it's not possible to generate that from an xslt processor / libxml2 / lxml, and in order to trigger the xhtml output mode (so you get br / with the space) you need to specify an xhtml 1.0 doctype to be output. It seems quite likely with deco / blocks / xdv that we will have an lxml based output chain, so we will be restricted in what's possible. This has been brought up previously on the libxml2 list, though without resolution (I can't find the reference to that right now). We might want to start campaigning now for !DOCTYPE HTML SYSTEM about:legacy-compat (and indeed -//W3C//DTD XHTML 1.1//EN) to be added to the doctypes that trigger xhtml compatible output in libxml2's xmlsave.c Also here http://www.w3.org/2008/08/cleantheweb/libxml and here http://wiki.whatwg.org/wiki/FAQ#What_MIME_type_does_HTML5_use.3F it states the Content-Type should be application/xhtml+xml for the xml serialization, so I guess absolute conformity may be impossible, though self-closing tags seem to be allowed for the html serialization too so maybe we're ok there. Laurence On 16 March 2010 22:50, Alexander Limi l...@plone.org wrote: Right, I don't see a reason to do that, though — it doesn't buy us anything. The reason the HTML5 doctype is simply: !DOCTYPE html …is that it's the shortest possible string that will trigger strict/standards parsing (ie. not quirks mode) in all browsers, including IE6. On Tue, Mar 16, 2010 at 3:34 PM, Laurence Rowe l...@lrowe.co.uk wrote: It is listed as an obsolete permitted doctype string http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - i.e. we can lie about the doctype. I'm not sure why xhtml 1.0 transitional is not allowed. Laurence On 16 March 2010 22:18, Alexander Limi l...@plone.org wrote: The way it works is that you can use the XHTML spelling (ie. closing your tags), but you serve it up as normal HTML. http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F There's no Strict or similar thing in HTML5, AFAIK. (There is also something informally referred to as XHTML5 which is serving it as XML, which isn't what we want to do) On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe l...@lrowe.co.uk wrote: By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi l...@plone.org wrote: What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Veda Williams Web Developer Groundwire 206.286.1235x23 v...@groundwire.org ONE/Northwest is now Groundwire! Read all about our new name. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org
Re: [Framework-Team] Plone 5 - rough roadmap
On 16 March 2010 23:37, Alexander Limi l...@plone.org wrote: On Tue, Mar 16, 2010 at 4:27 PM, Laurence Rowe l...@lrowe.co.uk wrote: Unfortunately it's not possible to generate that from an xslt processor / libxml2 / lxml, and in order to trigger the xhtml output mode (so you get br / with the space) you need to specify an xhtml 1.0 doctype to be output. It seems quite likely with deco / blocks / xdv that we will have an lxml based output chain, so we will be restricted in what's possible. This has been brought up previously on the libxml2 list, though without resolution (I can't find the reference to that right now). I'm thinking it will be easier to get libxml2/lxml to add this than to change the HTML5 spec. I don't think we'll persuade libxml2 to implement it the !DOCTYPE HTML SYSTEM about:legacy-compat as xhtml output until the standard is finalised, it's already been changed from !DOCTYPE html PUBLIC XSLT-compat in the last few months. More on this here. http://www.contentwithstyle.co.uk/content/xslt-and-html-5-problems Also here http://www.w3.org/2008/08/cleantheweb/libxml and here http://wiki.whatwg.org/wiki/FAQ#What_MIME_type_does_HTML5_use.3F it states the Content-Type should be application/xhtml+xml for the xml serialization, so I guess absolute conformity may be impossible, though self-closing tags seem to be allowed for the html serialization too so maybe we're ok there. Yes, that's what I meant. HTML serialization, but self-closing tags. This is the polyglot / overlap language from http://wiki.whatwg.org/wiki/HTML_vs._XHTML Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
2010/3/12 Hanno Schlichting ha...@hannosch.eu On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe l...@lrowe.co.uk wrote: On 12 March 2010 15:07, Hanno Schlichting ha...@hannosch.eu wrote: Currently listed for Plone 4.x are things like: ... - Well formed, valid XHTML (as a foundation for easier theming via xdv) That's really good to hear. Though I think semantic HTML or sensible ids/classes to identify elements in pages is what I had in mind with this point. Well besides the valid XHTML which is a requirement for Chameleon as well. It's also likely that we'll transition to using HTML5 (the XHTML-compatible phrasing, ie. HTML5, but close your tags), and Deco as a layout engine will be much happier if we do a revamp of the existing HTML structure. It's quite messy in parts from the 8+ years in production, and while it has held up well, it's time to adjust to how the web has evolved since then, especially with focus on our upcoming theming capabilities. Also, while on the subject of release management, it would be possible to split up these major new technologies in smaller releases, but we'd have to look at which things should land together. E.g. xdv and Deco should likely be in the same release —but don't *have* to — whereas Dexterity might be a requirement for tiles/blocks. (I'm inventing dependencies here, so no need to point out that any of these assumptions aren't correct ;) We could also take a page from how Firefox is looking to change their release management strategy, ie. landing stuff that has only infrastructural impact in a 4.x release (out-of-process plugins in FF's example, which will land in the 3.6 series, for Plone 4.x, it could be something like WSGI). Of course, that's what we're already doing, but pushing the less risky parts that were previously considered only for Plone 5 might be a good approach, and reduce risk. Landing too much at once in Plone 5 is definitely a real risk, as is a too-long release cycle for Plone 5. So evaluating each of the things we land in Plone 5 for possible inclusion in a future 4.x release is probably a good tactic. I'd love to see a shorter release cycle for Plone 5, but as usual, it's hard to determine, and I don't think the currently suggested estimates are unreasonable. I think an increased focus on Tech Preview releases (ie. what alpha used to mean :P ) could provide useful checkpoints for people to rally around when it comes to development. We shouldn't underestimate the power of self-imposed deadlines, I think it was used well in the Plone 4 release cycle, and even if Plone 5 is a release with a longer release cycle, we should try to do several checkpoints along the way to avoid landing too much at once, and get stuff out there for people to test in carefully managed projects, similar to what Jarn and others have been doing for Plone 4. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Mon, Mar 15, 2010 at 10:13 AM, Alexander Limi l...@plone.org wrote: We could also take a page from how Firefox is looking to change their release management strategy, ie. landing stuff that has only infrastructural impact in a 4.x release (out-of-process plugins in FF's example, which will land in the 3.6 series, for Plone 4.x, it could be something like WSGI). I think we can introduce some technologies already in 4.x releases, but make them opt-in. For example shipping Chameleon but disabling it by default. We will only get WSGI with a new Zope 2 release, which will bring a number of other changes with it, among those another basket full of updated Zope Toolkit packages. It's yet too early to say what these changes will be. Maybe we can upgrade to Zope 2.13, but that depends a lot on how Zope 2 maintenance and development will proceed and how the ZTK will play out. One thing to be aware of, is that in contrast to Firefox nobody uses a bare-bone Plone, but we are highly dependent on our add-ons. And that's not just two dozen most often used ones. We have therefor been careful not to break any add-ons during a major release cycle. Unfortunately all our major framework level changes have a tendency to just do that. Of course, that's what we're already doing, but pushing the less risky parts that were previously considered only for Plone 5 might be a good approach, and reduce risk. Landing too much at once in Plone 5 is definitely a real risk, as is a too-long release cycle for Plone 5. So evaluating each of the things we land in Plone 5 for possible inclusion in a future 4.x release is probably a good tactic. Sure. We can split some of these up. But I don't think we can include either Deco/Blocks, xdv or Dexterity as a whole into any 4.x release. Changing the default story for any of those areas is too much a change. That's why I like them to follow Dexterity's lead and push down parts of them into 4.x releases. Stuff that makes their life outside the core easier. And both Deco/Blocks and xdv still have to prove themselves in real production projects outside the core. Dexterity has yet to work out its evolution story for Archetypes based add-ons and content. I'd love to see a shorter release cycle for Plone 5, but as usual, it's hard to determine, and I don't think the currently suggested estimates are unreasonable. Oh yeah, my schedule is realistic, but not inspiring or visionary in any way ;) I think an increased focus on Tech Preview releases (ie. what alpha used to mean :P ) could provide useful checkpoints for people to rally around when it comes to development. We shouldn't underestimate the power of self-imposed deadlines, I think it was used well in the Plone 4 release cycle, and even if Plone 5 is a release with a longer release cycle, we should try to do several checkpoints along the way to avoid landing too much at once, and get stuff out there for people to test in carefully managed projects, similar to what Jarn and others have been doing for Plone 4. I had some idea about doing some more longer running agile process initially for my Plone release. But it turned out that this doesn't work with any of our processes or how volunteers can pledge their time. We are going to have one PLIP review cycle for Plone 5.0. Once that process starts, we have a couple of months to go, until we hit a feature freeze and some more weeks or months until we have fixed all the bugs. But that means that any major PLIP needs to be ready before we start the PLIP process. Another thing I learned from all my experimental changes, is that we can only merge things to trunk, once they are really finished or some of the more unstable changes can bring the entire release to a halt. So if we want to ensure that some of those big changes make it into Plone 5, the only variable we have, is to start the PLIP process at an appropriate time. Once that process starts, it's going to be all time based and we'll release whatever is ready by the end of the PLIP process. So my timeline tries to give those major changes a chance of making it into Plone 5. But that means we aren't going to work on the official Plone 5 release at all for the next 12 months. There won't be any code for the official Plone 5 for a long time. All interesting work will have to be made in add-ons outside the core. And the process for that work needs to be driven by interested people on their own terms. Just my take on this, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Fri, Mar 12, 2010 at 11:07 AM, Hanno Schlichting ha...@hannosch.euwrote: Currently listed for Plone 4.x are things like: - Include plone.app.registry - Include z3c.form - Improved commenting infrastructure - Improving the event type with recurrence, etc. - New roles : Webmaster/site administrator and novice users - Unified interface for lists of content - New collections UI - Well formed, valid XHTML (as a foundation for easier theming via xdv) - ... tons of new or better features What about Amberjack for self-guided tours/help? http://dev.plone.org/plone/ticket/9324 Is that still on the roadmap for landing in Plone 4.1? Nate -- // Learn the easiest way to theme Plone! // http://plone-theming-with-deliverance-natesig.eventbrite.com/ Nate Aune - na...@jazkarta.com http://www.jazkarta.com http://card.ly/natea http://tungle.me/natea +1 (617) 517-4953 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Mon, Mar 15, 2010 at 4:58 PM, Nate Aune na...@jazkarta.com wrote: On Fri, Mar 12, 2010 at 11:07 AM, Hanno Schlichting ha...@hannosch.eu wrote: - ... tons of new or better features What about Amberjack for self-guided tours/help? http://dev.plone.org/plone/ticket/9324 The entire list is at http://dev.plone.org/plone/report/24. I didn't feel like repeating all 26 items, but subsumed lots of them in my ... line. Is that still on the roadmap for landing in Plone 4.1? At some point there will be a new PLIP deadline for 4.1. If someone champions the PLIP, makes sure it gets implemented and has a plan to ensure the help texts will get continuous updates in the future ... then it will get into 4.1. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Mar 15, 2010, at 4:58 PM, Nate Aune wrote: What about Amberjack for self-guided tours/help? http://dev.plone.org/plone/ticket/9324 Is that still on the roadmap for landing in Plone 4.1? It certainly is if someone resubmits it. I asked the implementers to continue developing it outside of Plone 4 with the idea that they could start building tutorials against something stable in the release candidates and could give it some time to mature on its own after the release is out. Then, we could include it as part of the core for 4.1. I've been gearing up for the sprint, so I haven't had a chance to reply to the discussion. My general plan for 4.1 was to wrap up as many of the nearly-done PLIPs from 4.0. If we can make significant progress this week, I think we could drop a 4.1 very shortly after 4.0 that includes plone.app.discussion and events, search results, and collections improvements (and by extension plone.registry and z3c.form). That'd be one hell of a dot-x release. Even just two of those packages would be enough for me for 4.1. Or we could space them out so we don't raise expectations for 4.2 too much. ;) Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On 12 March 2010 15:07, Hanno Schlichting ha...@hannosch.eu wrote: Currently listed for Plone 4.x are things like: ... - Well formed, valid XHTML (as a foundation for easier theming via xdv) Just to note that xdv uses the HTMLParser which is really very tolerant of badly formed markup (an earlier problem with the Nginx implementation running plone.org is now fixed). The output is wellformed and forced into the xhtml namespace, though no validation is performed. The only downside to the HTMLParser is that inline elements in other namespace (e.g. esi, svg) are not allowed in the content or template, though they may be included in the rules. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe l...@lrowe.co.uk wrote: On 12 March 2010 15:07, Hanno Schlichting ha...@hannosch.eu wrote: Currently listed for Plone 4.x are things like: ... - Well formed, valid XHTML (as a foundation for easier theming via xdv) Just to note that xdv uses the HTMLParser which is really very tolerant of badly formed markup (an earlier problem with the Nginx implementation running plone.org is now fixed). The output is wellformed and forced into the xhtml namespace, though no validation is performed. The only downside to the HTMLParser is that inline elements in other namespace (e.g. esi, svg) are not allowed in the content or template, though they may be included in the rules. That's really good to hear. Though I think semantic HTML or sensible ids/classes to identify elements in pages is what I had in mind with this point. Well besides the valid XHTML which is a requirement for Chameleon as well. Denys did a heroic job at this already for Plone 4.0. But I expect there's much more to do and especially many more add-ons to fix. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
