Re: [Framework-Team] Plone 5 - rough roadmap

[Raphael Ritz]

Laurence Rowe wrote:

[..]
I don't think we'll persuade libxml2 to implement it the  as xhtml output until the standard is
finalised, it's already been changed from  in the last few months.

More on this here.
http://www.contentwithstyle.co.uk/content/xslt-and-html-5-problems

  


I'm probably missing the obvious but assuming we'll
be in a WSGI pipeline anyway can't we set the doctype
explicitly in a very last step to whatever we want (simple
regex fu) and have it set to whatever lxml/libxml2 or
others need before?

Raphael


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone 5 - rough roadmap

[Laurence Rowe]

On 16 March 2010 23:37, Alexander Limi  wrote:
> On Tue, Mar 16, 2010 at 4:27 PM, Laurence Rowe  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  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  as xhtml output until the standard is
finalised, it's already been changed from  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

[Alexander Limi]

On Tue, Mar 16, 2010 at 4:27 PM, Laurence Rowe  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  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.


> 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.

-- 
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

[Laurence Rowe]

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  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  (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  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:
>
> 
>
> …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  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  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  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  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 
>> >> > 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
>> >> >> 
>> >> >> 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

Re: [Framework-Team] Plone 5 - rough roadmap

[Alexander Limi]

Right, I don't see a reason to do that, though — it doesn't buy us anything.

The reason the HTML5 doctype is simply:



…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  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  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  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  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 
> >> > 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  >
> >> >> 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

[Laurence Rowe]

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  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  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  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 
>> > 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 
>> >> 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

[Alexander Limi]

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  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  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 
> 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 
> >> 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

[Laurence Rowe]

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  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  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 
>> 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

[Alexander Limi]

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  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 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 [image: 
> Groundwire]
> --
> 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

Re: [Framework-Team] Plone 5 - rough roadmap

[Wichert Akkerman]

On 3/16/10 18:40 , Alexander Limi wrote:

On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman 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

[Alexander Limi]

On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman  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

Re: [Framework-Team] Plone 5 - rough roadmap

[Alexander Limi]

On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman  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

Re: [Framework-Team] Plone 5 - rough roadmap

[Hanno Schlichting]

On Tue, Mar 16, 2010 at 12:45 PM, Wichert Akkerman  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

[Wichert Akkerman]

On 3/16/10 12:34 , Laurence Rowe wrote:

On 15 March 2010 09:13, Alexander Limi  wrote:

2010/3/12 Hanno Schlichting


On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe  wrote:

On 12 March 2010 15:07, Hanno Schlichting  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

[Laurence Rowe]

On 15 March 2010 09:13, Alexander Limi  wrote:
> 2010/3/12 Hanno Schlichting 
>>
>> On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe  wrote:
>> > On 12 March 2010 15:07, Hanno Schlichting  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

[Eric Steele]

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

[Hanno Schlichting]

On Mon, Mar 15, 2010 at 4:58 PM, Nate Aune  wrote:
> On Fri, Mar 12, 2010 at 11:07 AM, Hanno Schlichting 
> 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

[Nate Aune]

On Fri, Mar 12, 2010 at 11:07 AM, Hanno Schlichting wrote:

> 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

[Hanno Schlichting]

On Mon, Mar 15, 2010 at 10:13 AM, Alexander Limi  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

[Alexander Limi]

2010/3/12 Hanno Schlichting 

> On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe  wrote:
> > On 12 March 2010 15:07, Hanno Schlichting  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

[Hanno Schlichting]

On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe  wrote:
> On 12 March 2010 15:07, Hanno Schlichting  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

Re: [Framework-Team] Plone 5 - rough roadmap

[Laurence Rowe]

On 12 March 2010 15:07, Hanno Schlichting  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

[Framework-Team] Plone 5 - rough roadmap

[Hanno Schlichting]

Hi there,

with Plone 4 beta 1 out the door and the 4.0 framework team having
done its job, it's time to look ahead into the future a bit.

Eric has started the discussion around Plone 4.1 already, I'll let him
drive that process :)

But I had a look at the PLIP's we have seen and feature discussion we
had in the past.

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

I think there's lots of good stuff in there. I think with Plone 4.0 as
a new technical basis we need some time to make Plone the product
better again. Image and media handling, better usability, better
support for common tasks, more content lifecycle management, ...
there's a lot we can and should do here. Figuring out what exactly
should be part of Plone Core won't be easy, but I have a feeling our
feature set is lacking behind the competition in various ways now.

On the "future" side we have:

- Chameleon
- Deco / Blocks
- Dexterity
- WSGI
- xdv as the default theming story
- deprecate portal_skins
- ...

I don't want to go into the details of any one of those, but my
general feeling is that none of these are anywhere ready to be shipped
as part of Plone Core.

My current idea would therefor be to aim for a Plone 5.0 release
roughly 18 to 24 months after Plone 4.0 final is released. We could
aim for 18 months if we only do a 4.1 release, but I assume we are
going to do a 4.2 release as well (both taking about 9 months from
experience). At that point 24 months is more realistic.

That means these technologies and projects will need to evolve outside
the core for some time. I'd hope they could bring up some PLIP's for
4.1 and 4.2 which will make their life easier - much like Dexterity
has already done with CMF 2.2 and Plone 4.0. Sometimes these might
just be events, interfaces and some more adapters to make things
independent of Archetypes.

Does this kind of roadmap has general agreement?

Hanno

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team