Ticket #11300 (closed PLIP: fixed)

Opened 6 years ago

Last modified 4 years ago

Switch to HTML5

Reported by: spliter Owned by: spliter
Priority: major Milestone: 4.2
Component: Templates/CSS Version: 4.1
Keywords: Cc: alecm, plip-advisories@…

Description

Proposer: Denys Mishunov
Seconder: Alexander Limi

Motivation

For years Plone has been considered a "cutting egde" in it's support of standards and new technologies. During the last years the new exciting versions of "web cornerstone" technologies like HTML5, CSS3 became more and more popular. Even though these technologies are not complete standards and are still in a review process by W3C it is considered safe to use them in the contemporary projects. Projects like Google, YouTube, TypeKit, Twitter, LinkedIn are already using HTML5 as their main markup language.

Assumptions

The PLIP assumes smooth transition to HTML5 support. Due to excellent backwards compatibility of HTML5 specification pretty much any XHTML can become HTML5 with very few if any fixes. Microformats, ARIA roles, CSS3 and other related technologies are beyond the scope of the PLIP. The PLIP is only about the markup used in Plone.

Proposal & Implementation

As already mentioned almost any XHTML1 document can be considered valid HTML5. Though due to backwards compatibility and current state of HTML5 specification we can not use all new elements introduced in HTML5 we can start by taking a smooth transition path.

First of all we will need to switch the doctype to <!doctype html> - the valid doctype of HTML5. After this the full validation process (for different views) has to be done to spot validation errors and fix those. From my experience of doing HTML5 on Plone it's the matter of a couple of fixes. Might be more in some cases ;)

This will give a very good basis for those who want to use up-to-date technologies. At the same time will let those who want to keep writing XHTML1 keep doing this even though within HTML5 doctype.

Deliverables

The PLIP doesn't need any special deliverables except, updated documentation. Main point - even though HTML5 allows both - HTML (no need to self-close the tags etc) and XHTML styles, templates for Plone should be written in XHTML style to keep them sane and predictable.

Risks

Risks are minimal since the HTML5 doctype is very backwards compatible. Though there might be an issue with using DIazo if developers ignore XHTML-style for the markup and write HTML instead. In this case more testing with Diazo should be done.

Participants

Denys Mishunov [spliter @ #plone]

Change History

comment:1 Changed 6 years ago by hannosch

Chameleon actually requires templates to be valid XML, that's why we just fixed all templates in our stack to comply to this. Going back to a non-XML HTML version is therefor not an option for us.

We'll also need to check if Chameleon and Zope in general can handle the new doctype. I'd image it should be fine on serving pages. But there might be some code in transformations like safe_html, or encoding guessing code for uploaded content that doesn't support it yet. This could be considered to be outside the scope for this PLIP though.

comment:2 follow-up: ↓ 3 Changed 6 years ago by kleist

Note that an HTML5 document might very well be well-formed XML. Hence, there is no inherent opposition between HTML5 and Chameleon.

comment:3 in reply to: ↑ 2 Changed 6 years ago by spliter

Replying to kleist:

Note that an HTML5 document might very well be well-formed XML. Hence, there is no inherent opposition between HTML5 and Chameleon.

Absolutely. I suppose what Hanno meant is that HTML5 is not strict about XHTML syntax so developers will not be poked by a validation error if they write HTML-style document. But Chameleon (and potentially Diazo) might have problems with this. It's beyond the scope of this PLIP but would be nice to add some markup checker in our Hudson build that would validate markup for XML-conformance. Though it is quite expensive check so we might consider doing such check up in another way... somehow... :)

comment:4 Changed 6 years ago by kleist

Maybe the XML parser pyXRP (from the open source ReportLab libs) is faster than whatever Hudson uses today?

 http://www.reportlab.com/software/opensource/pyrxp/

comment:5 Changed 5 years ago by spliter

  • (In [47743]) Configuration file for PLIP11300;
  • (In [47745]) Added plonetheme.sunburst to PLIP 11300's configuration;
  • (In [47748]) pinned correct package (Products.CMFPlone instead of Plone) for working with Plone core;
  • (In [47749]) switched doctype in main_template to HTML5;
  • (In [47750]) replaced obsolete in HTML5 <acronym> element with <abbr>;

comment:6 follow-up: ↓ 9 Changed 5 years ago by spliter

I wonder what do we do about non-valid HTML5 things like

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

or

<meta http-equiv="imagetoolbar" content="no" />

Could we simply ditch those? The last one is related to IE6 only and the first one is to toggle IE8 into IE8 mode no matter what (without an option to be rendered in IE7 mode). I propose just to ditch 2 of these. On the other hand failing validation on these doesn't mean the site is not rendered in a browser, it's just disagreement between browsers and the validator.

comment:7 follow-up: ↓ 8 Changed 5 years ago by spliter

In general the first step in transition to HTML5 is done — we have HTML5 site when built with

bin/buildout -c plips/plip11300-switch-to-html5.cfg

But the validation is failing on the <meta /> declarations mentioned in the previous comments. In addition there is a nasty issue with the classic theme where I can not get where the personal_bar is coming from :-P And that bar raises the validation error as well. Everything shows that the template is served from plonetheme.classic/browser/personal_bar.pt but changing template there doesn't give me any updates. Changing it in portal_view_customizations on the other hand fixes the issue. Any hint on this would be appreciated.

comment:8 in reply to: ↑ 7 Changed 5 years ago by spliter

  • Status changed from new to assigned

Replying to spliter:

In general the first step in transition to HTML5 is done

A note — the first step means the views should be ok. Didn't work with the edit forms yet though. But those are not valid even in XHTML 1.0 Transitional that we used to have ;) I suppose updating forms and widgets to conform with HTML5 deserves the separate PLIP on it's own.

comment:9 in reply to: ↑ 6 Changed 5 years ago by limi

Replying to spliter:

I wonder what do we do about non-valid HTML5 things like

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

We can set this using HTTP headers instead, IE supports that.

<meta http-equiv="imagetoolbar" content="no" />

…and let's just drop this one. Not important.

comment:10 Changed 5 years ago by spliter

(In [48044]) fixed main_template's HTML5 validation for Sunburst

comment:11 Changed 5 years ago by spliter

(In [48045]) fixed main_template's HTML5 validation for Plone Classic and Plone Default

comment:12 Changed 5 years ago by spliter

(In [48051]) Fixed validation of the personal bar for anonymous user.

comment:13 Changed 5 years ago by spliter

Due to un-known reasons, configuration file in plips/ folder doesn't work with mrdeveloper. Had to move the config to buildout's root, so the new command to build HTML5 Plone is just:

bin/buildout -c plip11300-switch-to-html5.cfg

comment:14 Changed 5 years ago by spliter

  • Milestone changed from 4.x to 4.2

I think this is ready for implementation in 4.2 even if there might be some validation issues on the auto–generated forms.

comment:15 Changed 5 years ago by rossp

Considering this PLIP to supersede #9300.

comment:16 Changed 5 years ago by ldr

Diazo / plone.app.theming does not require valid xhtml for input, the problem is that diazo output will now have to be html serialized -- <br> -- instead of xhtml serialized -- <br /> -- (xml serialization is something different again, <br/>) as the only way to trick libxml2 to output xml in an xhtml compatible manner is to set one of the xhtml1.0 doctypes.

comment:17 in reply to: ↑ description ; follow-up: ↓ 19 Changed 5 years ago by esteele

Replying to spliter:

Denys, the Framework Team would like to hear a stronger case for why this is necessary. We can understand the desire to be "cutting edge", but that's not enough to sway the opinion at this point.

comment:18 Changed 5 years ago by elvix

Eric and FWT: This is not about being cutting edge, but about being up-to-date. There are a bunch of new technologies we can start using (for example for making forms usable for mobile technologies) when we are running html5. It is the current way of doing web-frontend. We need this in order to easily use new possibilities in frontend development.

comment:19 in reply to: ↑ 17 Changed 5 years ago by spliter

Replying to esteele:

Denys, the Framework Team would like to hear a stronger case for why this is necessary. We can understand the desire to be "cutting edge", but that's not enough to sway the opinion at this point.

Dear Eric and FWT, Excuse me that this took me so long to respond to this. Frankly, it caused some confusion on my side, so I decided to investigate the question by reading books and thinking on the subj because apparently the benefits of HTML5 are not as obvious to people. You are right that we need stronger points to using smth in Plone rather than just being a "cutting edge". So, I would like to highlight some key points that make me use HTML5 in pretty much every project these days.

  • Significantly improved semantics of the markup language. Instead of meaningless <div/> elements for building the structure, HTML5 provides elements that actually make sense like <header/>, <footer/>, <section/> etc. As an example — this should provide proper elements for structuring portlets, because portlets ARE NOT <dl/> elements. <dl/> is beter than generic <div/> of course, but they are not definition lists.
  • Browsers are catching up with the HTML5 pretty fast. This means that we can expect native support for such exciting APIs as (without any order):
  • Backwards compatibility with HTML4/XHTML1.1. Pretty much any HTML4/XHTML1.1 is HTML5 document. Some minor adjustments might stil be needed though.
  • In the future I assume HTML5 is going to be way better accessibility-wise because of it's semantics. Plus I can not believe it's going to take long for search engines to catch up with better indexing of HTML5 sites due to clear semantic structure.

In ideal world we would like to go all the way to fixing semantics of Plone's markup but it's a lot of work and should be done in steps to keep backwards compatibility and not to start fixing everything at the same time. This is the beauty of HTML5 as well —  HTML5 is a sliding scale.

But, of course, nothing in this world is ideal - there some things to keep in mind.

  • the most sensible one is that Diazo/plone.app.theming can not output HTML5 doctype due to libxml2 limitations. This could be worked around with XHTML1.0 Strict doctype as  an obsolete permitted DOCTYPE string, but it's dirty and is neither valid XHTML1.0 Strict nor HTML 5 when you run your markup through a validator. So, for Diazo we should either fix libxml2 or find other ways of outputting proper HTML5.
  • This PLIP proposes the very first step in moving to HTML5 - simple doctype update and fixes to validation of the resulted HTML5 output. The next step would be to make a number of PLIPs for different Plone markup things like (forms, generic structure aka main_template etc) to update those. And since HTML5 is a sliding scale, we can do those whenever we have resources. But even by providing HTML5 doctype only we give freedom to those developers willing to use HTML5 in full-speed - it's up to them to make themes with HTML5 features they want, use HTML5 elements like <video />, use HTML5 APIs etc.

In general, my personal opinion is - if we can support the rapidly growing technology with much better features than what we are using now, without paying a fortune for it, why not?

comment:20 Changed 5 years ago by spliter

… and one more advantage of HTML5 that leads to better, meaningful markup comparing to XHTML:

  • <a/> element can contain any elements in HTML5 including block-level ones (like <div/>, <article/>, <section/> <p/> etc.). In practice this means we could, for example, wrap the whole list items in the listings, like folder_summary_view, in one <a/> element instead of having discreet links for the title, image, 'Read more' links. In case of HTML5 we could even ditch the later at all if wish to do so.

comment:21 Changed 5 years ago by eleddy

  • Cc alecm added

FWT approved for 4.2. Alecm will be your FWT champion here. There is some concern that everyones CSS doesn't break and more importantly, that Diazo/p.a.theming needs to work.

comment:22 Changed 5 years ago by alecm

Denys, could you provide a more concrete set of deliverables here? For Plone 4.2 would this just be a matter of changing the doctype? Are there some specific markup fixes which are likely to be needed on top of that?

If Diazo outputs HTML5 Plone pages with an XHTML doctype, would there be cases where the resulting page is actually invalid?

Any clarification on the specific changes intended for a Plone 4.x implementation of this PLIP would be greatly appreciated.

comment:23 Changed 5 years ago by spliter

Hello,

Thought about this for quite a while and, frankly, I am not as optimistic about this PLIP as I used to be.

First of all, this PLIP was simply about changing the doctype indeed. Changing the doctype and fixing HTML5 validation by some minor markup updates in plone.app.layout.

Secondly, this will work cross-browser only if no new HTML5 elements are used. Otherwise, IE will be choked with them. IE8 and below doesn't understand any of the new elements to the point where you can not apply styles to them — IE will not understand those styles. To workaround this, we need to supply a shim like  http://remysharp.com/2009/01/07/html5-enabling-script/ or go all the way to the top and integrate Modernizr ( http://www.modernizr.com/). Integration of any of these might require a separate PLIP. And if a new PLIP is going to be submitted I would desperately vote for Modernizr option.

Thirdly, Diazo doesn't output HTML5 as it has been mentioned above. It can output XHTML Strict doctype and it seems to be allowed obsolete doctype in HTML5 specification, but, let's be honest — it stinks. The resulted document is neither HTML5, nor it is XHTML Strict. Validator throws errors, not-aware developers are confused, customers are furious. So, if Plone is set (and I believe it is) on Dizao as the only way of doing Plone themes, I suppose HTML5 has no place in the pipeline while Diazo, due to libxml's limitations, can not do as simple operation as outputing

<!doctype html>

even if we set some strict requirements to the templates and such. To myself, I have solved this issue by using Diazo only in exceptional cases where I have pre-made XHTML from another markup authors or when we need to "merge" more backends with Plone. In all other cases I just do old plain Plone theme, based on HTML5.

I don't really see any possibility of having HTML5 in Plone as long as we have Diazo as the only one option for theming. If we would have an option to disable Diazo and use what Plone under the hood gives us instead, then one of the possible scenarios would be:

  • introduce Modernizr;
  • switch Doctype to HTML5 (already done in the branch)
  • not use any of the new HTML5 elements, but stick with XHTML we have and just fix the validation for HTML5 (already in the branch, though there might be a case when HTML5 validation passes and XHTML one does not)
  • Let Diazo output whatever doctype it wants. Should be safe as long as we don't introduce new HTML5 elements
  • Let those, who want to work with HTML5, disable DIazo and do the theme in old fashion, but using any new elements and benefits of HTML5.

In ideal world, fixing either Diazo or libxml to output HTML5 doctype would be the best, of course. This would make things so much simpler.

In the meantime, while we are not in the ideal world, I have started the new package collective.html5boilerplate ( https://github.com/mishunov/collective.html5boilerplate) that I am building as the regular Plone theme package without Diazo being involved. The purpose of the package is to introduce full-throttle HTML5 to Plone with the set of the new elements and, possibly, some javascript API's that are part of HTML5 specification.

IMPORTANT NOTE about Plone, Diazo and backends, different from Plone. There are more and more projects showing up these days that are marked up with HTML5. They are not just the new doctype, but real HTML5 with wide set of new elements. There are more and more cases when such a backend needs to be "integrated" into Plone. I wonder how do we address this in Diazo story? There are 2 problems with this as far as I can see:

  • Plone will output the merged result as XHTML Strict at best when integration is done with Diazo. As mentioned above the result is not going to be valid XHTML Strict nor will it be valid HTML5 for the validators.
  • the result without HTML5 elements being filtered out will look broken in IE up to and including IE8 due to styles being not applied to the new elements coming from that HTML5 backend. Integration of a shim or Modernizr will solve this issue.

comment:24 Changed 5 years ago by ldr

I think it's worth noting here that Diazo copes just fine with HTML5 as input, even with the new elements or elements you make up yourself, so it should not impact on the decision whether we start using new HTML5 attributes or elements in core Plone. I think the decision is more on what sort of changes we are happy with seeing in a point release.

Introducing modernizr or another html library and radically changing our markup seems too invasive for a point release. But should be fine for a Plone 5 or a Deco/Tiles based theme.

Introducing backwards compatible HTML5 such as the new input types or data attributes should be no problem as they don't cause any problems for existing browsers.

It's certainly possible to modify Diazo to generate the "<!DOCTYPE html>" so long as we are happy with and HTML serialization as output (rather than our current XHTML serialization [*].) We could also simply replace the doctype in a string operation in plone.app.theming on the way out. Or simply add in a comment directing people to the  relevant part of the HTML5 spec explaining how the page they have just rendered is valid HTML5 despite it's obsolete permitted doctype string and that the w3c html5 validator is still very much experimental ;) I'm happy to receive patches that implement any of the above, but implementing them is not currently high on my todo list at the moment.

[*] Serializations. In short we have XML which uses <br/>, HTML which uses <br> and XHTML which uses <br /> (there are some other differences too, but those are minor really). XHTML has the advantage that it may be parsed with either an XML or HTML parser, though some information may get lost.

comment:25 Changed 5 years ago by alecm

Laurence,

So would having Diazo generate "<!DOCTYPE html>" cause the existing markup in the theme or content to be altered such that e.g. '<br />' becomes '<br>'? That seems unfortunate since my understanding is that both forms are considered valid under HTML 5, and it's probably best if markup is altered as little as possible. Would having Diazo use that doctype ease potential validation issues during the transform as well?

It seems to me that Diazo might be best off adopting the doctype of the theme if that's possible, since the essential HTML structure will generally be coming from the theme. This is probably a discussion that belongs on the p.a.theming/Diazo PLIP though.

comment:26 Changed 5 years ago by ldr

The HTML5 people don't really consider XHTML served as text/html as a valid use case. See  http://hixie.ch/advocacy/xhtml. The focus in the HTML5 standard for XHTML it defining a XML serialization to be served with content type application/xhtml+xml. However I would like to persevere with our HTML compatible XHTML approach as with Diazo we actually get well formed output - without it Plone tends to emit output which is not well formed wherever content has been entered through the visual editor.

If we wanted to generate the "<!DOCTYPE html>" from diazo itself and therefore from libxml2/libxslt directly then we would need to either set the serialization method="html" and have end up with <br> tags or serve it as "application/xhtml+xml" and get <br/> tags - libxml2's XML serializer only turns on the HTML compatible XML serialization mode for the XHTML 1.0 doctypes.

We could solve this in plone.app.theming instead though and just lop off the libxml2 generated doctype and replace it with whatever we want. This isn't an option if you run diazo in apache or nginx, but then that's a minority sport anyway and at the end of the day this is an aesthetic consideration - any doctype string starting <!DOCTYPE html is valid HTML5.

A more interesting question for diazo will be whether we attempt to support  HTML5+RDFa - as diazo parses the input document using libxml2's HTML parser, attributes (for that's what they are in HTML) like xmlns:dc="http://purl.org/dc/elements/1.1/" get parsed without the namespace prefix. The same stripping happens to tags which makes ESI or the Facebook XFBML elements tricky to work with. Of course we could parse using the XML parser, but that probably places too high an expectation on Plone to ensure user generated content is well formed.

Summary: hack the doctype with string substitution in plone.app.theming.

comment:27 Changed 5 years ago by alecm

The preface of that xhtml advocacy document seems to disagree with what you're saying about it. It indicates that the document itself is not really relevant to HTML5, and that XML-like syntax (e.g. "<br />") is fine when using "<!DOCTYPE HTML>" and content type "text/html".

I agree that just replacing the theme doctype from plone.app.theming is probably the simplest solution here. Though it doesn't solve the larger Diazo HTML5 compatibility problem, which will inevitably arise with non-Plone uses of Diazo, that problem is not particularly relevant to either this PLIP or a plone.app.theming PLIP.

comment:28 Changed 5 years ago by ldr

I took another look into this and it seems that libxml2 2.7.2 added the XML_SAVE_XHTML xmlSaveOption. That should make it possible for the Apache and Nginx xslt plugins to drop the XHTML1.0 doctype requirement. I don't think lxml supports setting this option yet, but we should be able to use it when it does.

comment:29 Changed 5 years ago by spliter

  • Cc plip-advisories@… added

So, I supose the conclusion about HTML5/Diazo can be made as: plone.app.theming should give HTML5 doctype in the output. I suppose we can postpone tinkering with core Diazo, when served from Apache or Nginx, for now. This is great. Ideal situation would be, of course, as Alec mentions to serve whatever doctype is defined in the theme though. But it's for p.a.theming PLIP.

About the current PLIP. In order to have this PLIP finished, I actually, need to introduce some JS shim for Internet Explorer. I would definitely want to have Modernizr in Plone and don't agree with Laurence that it is not suitable for a point release. Modernizr should not break backwards-compatibility in Plone but instead should let authors write HTML5 and, what can be important as well, eliminates any separate stylesheets for IE-only styles. Modernizr applies special CSS class like ie-6 or ie-7, etc. on <html> element. Also no need in conditional comments for IE-specific stylesheets in <head>.

Alec, I suppose I need to submit a new PLIP for Modernizr's integration. Is it correct?

comment:30 follow-up: ↓ 31 Changed 5 years ago by alecm

Having looked at the Modernizr docs, it looks like a pretty good idea to me. However, if it's not required for implementing some aspect of the HTML5 transition, I'm not sure that it belongs here instead of in a separate PLIP.

Similarly, I'm not sure it makes sense to PLIP it on its own unless the PLIP provides some specific ways that Plone can make direct and immediate use of Modernizr features. If it's just something people can use to help implement better HTML5 themes and content (e.g. compatible across browsers), then it may be best to just create an add-on that installs it in Plone (similar to collective.js.jqueryui).

comment:31 in reply to: ↑ 30 Changed 5 years ago by spliter

Replying to alecm:

Having looked at the Modernizr docs, it looks like a pretty good idea to me. However, if it's not required for implementing some aspect of the HTML5 transition, I'm not sure that it belongs here instead of in a separate PLIP.

In order to complete this PLIP, we need to introduce support for HTML5 elements in Internet Explorer. More reading on the topic —  http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/. Even though we are not going to introduce any new HTML5 elements now, the end integrators will do so and Plone should support the elements out of the box. Hence we need a shim to provide the support in IE. There are 2 ways:

At some point Modernizr should be part of Plone in my opinion. So, integrating separate shim and then, hopefully, Modernizr doesn't really make sense to me if we can integrate Modernizr now and get the shim.

Similarly, I'm not sure it makes sense to PLIP it on its own unless the PLIP provides some specific ways that Plone can make direct and immediate use of Modernizr features. If it's just something people can use to help implement better HTML5 themes and content (e.g. compatible across browsers), then it may be best to just create an add-on that installs it in Plone (similar to collective.js.jqueryui).

Modernizr does provide features that Plone might start using right away:

  • aforementioned HTML5 elements support in IE
  • special CSS classes on <html> element for writing IE-specific styles that are valid CSS (not, silly "* html" hacks). With this we could deprecate ie.css an ie.js (or whatever they are called) since both of those can take advantage of the CSS classes.
  • In addition we get the main feature of Modernizr — feature detection. This lets us build future proof application that just get better and better over time when browsers support more and more of HTML5 natively.

Second point requires main_template.pt changes so, integration of Modernizr through an add-on doesn't feel like the right thing to do.

comment:32 Changed 5 years ago by alecm

Sounds like a good set of reasons to keep it a part of this PLIP then!

comment:33 Changed 5 years ago by elvix

A tiny comment advocating why the move to html5 is useful:  http://buytaert.net/html5-in-drupal-8

comment:34 follow-up: ↓ 35 Changed 5 years ago by ldr

It seems difficult to justify adding extra javascript if we're not going to be using any of the new HTML5 elements in vanilla Plone - it would just add unnecessary page weight for most users.

Moving to modernizr.js seems justifiable if we can remove the IE conditional css/js as that will reduce the number of requests for those users. It weighs in at 3.7kb compressed, about 10% of our existing javascript for anonymous users.

comment:35 in reply to: ↑ 34 Changed 5 years ago by spliter

Replying to ldr:

It seems difficult to justify adding extra javascript if we're not going to be using any of the new HTML5 elements in vanilla Plone - it would just add unnecessary page weight for most users.

Just to make it clear, we are not going to use HTML5 elements in vanilla Plone *now* as in "within this PLIP". The purpose is, of course, to convert templates and viewlets to proper HTML5 elements at some point, but not within this PLIP since it would be way to much as for a point release. Introducing new DOCTYPE is a first step that would let developers start using HTML5 in their projects without constant customization of templates in every project (to get valid HTML5). At this point Plone is going to give the basis for further progress of it's frontend.

Introducing Modernizr.js is just the result of us willing to support IE. We can not avoid supporting IE. And we can not tell users: "Well, here is the new doctype, go fetch the shim of your choice yourself elsewhere" because they have to have the shim in order to be able to style new HTML5 elements in IE. Hence Plone should provide support for this case if we start HTML5 path.

SIDENOTE: Currently I, for example, do the same routines in each and every project over and over again - customize main_template (to add new doctype), fix validation, add Modernizr.js, selectivizr, less and some other very useful libs (along with removing about half of existing JS in Plone). And I do this for every project. Well, not all of it anymore after starting collective.html5boilerplate. But I would like to have some basis coming from Plone instead.

comment:36 Changed 5 years ago by spliter

This will be ready for the feature freeze on June 30th.

comment:37 Changed 5 years ago by alecm

Thanks Denys, that's great news. Let me know if there's anything you need from the FT to make sure your work is ready in time.

The one concern the framework team had during our last meeting was that it would be best if Modernizr were actually used explicitly within Plone if we're going to include it. To that end it would be a good idea to replace the current IE specific CSS/JS using Modernizr techniques. This would provide the following advantages:

1) Eating our own dog food and providing basic guidance for how to use Modernizr in a Plone context 2) Possibly reducing the number of resources served to IE clients.

Does that seem like something you could include as part of the implementation?

Also, do you feel there's a particular subset of Modernizr that we could/should use to minimize payload, or would it be best to include the full library?

comment:38 Changed 5 years ago by spliter

I think starting using Modernizr right away is a good idea. If using it as an HTML shim in order to make IE able to style new HTML5 elements is not enough, I will deprecate our IE-specific stylesheet/js with Modernizr techniques.

On the other hand, I suppose Modernizr would be a great helper for me in my other PLIP #9352, where I could use native browsers' support for some HTML5 javascript APIs and cater a fallback for less capable browsers using Modernizr's yepnope.js integration. On the other hand while these 2 are still separate PLIPs I think it would make sense to, sort of, prepare a basis for this but do actual work of Modernizr's usage for #9352 in the next Plone version.

Concerning the sub-set, I think including full Modernizr is the smartest thing to do for such a generic thing as Plone. We will also need to document what features of Modernizr we are using, how and where exactly. I could do this, since I am the one who is going to integrate the library.

Important Note. Currently I figured out some issues with the custom rel= attributes we have in Plone's <head> on some <link> elements. Somehow validator suddenly stopped validating them as they are not really part of the specification, but XHTML1.1 is more loyal to them. Those custom rel attributes are used as the hooks mainly for JS and majority of those is related to KSS. I am thinking about a workaround for this atm.

comment:39 follow-up: ↓ 40 Changed 5 years ago by spliter

(In [50331]) Removed plone.links.navigation viewlet (<link rel='home'/> and <link rel='contents'/>) since the keywords using in those links are not valid in HTML5 according to the validator. References #11300

comment:40 in reply to: ↑ 39 ; follow-up: ↓ 41 Changed 5 years ago by mj

Replying to spliter:

(In [50331]) Removed plone.links.navigation viewlet (<link rel='home'/> and <link rel='contents'/>) since the keywords using in those links are not valid in HTML5 according to the validator. References #11300

I say the validator is wrong. The HTML5 specification specifically allows for new types of link (new keywords for the "rel" attribute) to be defined:

 http://www.w3.org/TR/html5/links.html#other-link-types

This part of the specification points to a wiki page:

 http://microformats.org/wiki/existing-rel-values

and that wiki page most definitely includes the types 'home' and 'contents'.

Can we file a bug with the HTML5 validator?

comment:41 in reply to: ↑ 40 Changed 5 years ago by spliter

Replying to mj:

This part of the specification points to a wiki page:

 http://microformats.org/wiki/existing-rel-values

This is correct Martijn. But while validator implements keywords for rel attribute it will take a while. The removed elements don't change anything significantly for Plone. It is ok to remove those.

and that wiki page most definitely includes the types 'home' and 'contents'.

The problem is that 'home' is still in proposals table. Means I don't see it being added to the validator any time soon.

Can we file a bug with the HTML5 validator?

No need to in my opinion. They know about these things and update validator with the new keywords. The last update (that broke our validation) was at the end of May.

comment:42 Changed 5 years ago by ldr

I don't think these links are actually used for anything anymore, I believe Opera used to have some support but I believe it has been dropped now (maybe someone who uses that browser can chime in.)

I think the validator has a number of issues surrounding strict conformance to the specification, and while the pedantic part of me would like us to link directly to the specification and a defence of why Plone is already HTML5 compliant, the practical part of me thinks there are more interesting battles to fight ;)

comment:43 Changed 5 years ago by spliter

(In [50335]) switched <link rel="kinetic-stylesheet" type="text/css" /> to <link rel="stylesheet" data-rel="kinetic-stylesheet" type="text/kss" /> to fix HTML5 validation. References #11300

comment:44 Changed 5 years ago by spliter

(In [50336]) Removed plone.htmlhead.kss-base-url viewlet in order to get rid of <link rel='kss-base-url' /> that has not valid keyword for rel attribute. KSS should pick up standard <base/> tag in Plone instead. References #11300

comment:45 Changed 5 years ago by spliter

(In [50337]) Introduced Modernizr.js with the full set of HTML5/HTML5 JS APIs/CSS3 feature detection. References #11300.

comment:46 Changed 5 years ago by spliter

(In [50338]) Actual Modernizr 2 library, it's registration and main_template updates for Plone Classic and Plone Default. References #11300

comment:47 Changed 5 years ago by spliter

(In [50347]) No need to have IEFixes.css anymore — we are using Modernizr, so we move styles from IEFixes.css. References #11300

comment:48 Changed 5 years ago by spliter

(In [50348]) Deprecate IEFixes.css from plonetheme.sunburst

comment:49 Changed 5 years ago by spliter

(In [50349]) No need for cssregistry.xml in plonetheme.sunburst anymore — we deprecated IEFixes.css

comment:50 Changed 5 years ago by spliter

(In [50351]) Move iefixes.js of plonetheme.classic to deprecated/

comment:51 Changed 5 years ago by spliter

(In [50352]) Remove jsregistry.xml as the script it has been registering (iefixes.js) is deprecated by now. We should use Modernizr.js in order to write IE-specific javascript. References #11300

comment:52 Changed 5 years ago by spliter

(In [50354]) Upgrade step for PLIP 11300 for Plone 4.2 alpha1

comment:53 Changed 5 years ago by spliter

(In [50355]) Added Modernizr to Products.CMFPlone tests

comment:54 Changed 5 years ago by spliter

(In [50357]) updated CHANGES.txt for the branched packages. References #11300

comment:55 Changed 5 years ago by spliter

The PLIP is ready for review. Everything should be logged here. There is also an upgrade step in the branched bersion of plone.app.upgrade.

comment:56 Changed 5 years ago by spliter

For the record and for the reviewers' information. The changes made in kss.core and related changes in Products.ResourceRegistries have been reviewed by Balazs Ree for potential issues with KSS and it has been confirmed that the changes don't seem to break anything and are fine from kss' side.

comment:57 follow-up: ↓ 58 Changed 5 years ago by robgietema

(In [50595]) Added review for plip 11300. refs #11300

comment:58 in reply to: ↑ 57 Changed 5 years ago by spliter

Replying to robgietema:

(In [50595]) Added review for plip 11300. refs #11300

Thanks for the review, Rob. Would like to give some comments and explanations on it.

Replying to robgietema:

The conditional html tag at the end uses "if gt IE 8" better would be "if (gt IE 8)|!(IE)".

No other browser understands conditional comments except IE, so !(IE) part doesn't make sense to me. Rob, do you know why that addition would be useful?

Replying to robgietema:

The code changes look good. What I don't understand is why modernizr is used. The comments in the css suggest that modernizr adds the ie6, ie7 etc classes to the html document but that is not the case, they are added using conditional html comments. The PLIP states modernizr is used to strip out HTML5 specific tags but as far as I can see none are used right now. Please explain why we need modernizr at this time.

First of all, the task of this PLIP was not to introduce the new HTML5 elements, but to give a kick-start to that process by just switching to the new doctype and let end-integrators do more if they need.

Modernizr, doesn't add those classes indeed and they are added with the conditional comments. That's right. Maybe I was not clear in my explanations of what Modernizr does for IE. Will try again. The issue is that Internet Explorer, when seeing unknown element, ignores it completely and does not allow one to apply any styling to such elements. Since new HTML5 elements are aliens at the moment, they fail under this exact case — end-integrators wish to go further in HTML5 implementation in their Plone theme, do add new HTML5 elements. Out of the box, they will not be able to style those in IE since the browser simply will not be able to understand what are those. So, for Internet Explorer we do one of the following:

  • manually write JS that would add fake instances of all new HTML5 elements and then remove them. In this case, IE will be triggered to "this-guy-looks-familiar mode" when the new elements are added in the HTML. It will not give them any structural meaning of course, but at least end-users will be able to style new HTML5 elements.

Modernizr has such shim built-in. So, Modernizr in this case is used to convince IE that the new elements are not aliens and it's ok to style those. More on this —  http://www.modernizr.com/docs/#html5inie

Next question is why Modernizr and not some shim-only solution. Modernizr is *the* feature detection solution these days. It's the only library that can detect certain features, a browser understands from HTML5/CSS3 and related technologies (like HTML5 javascript APIs, for example). In order to build a future-proof (for the browsers of the future) and backwards-compatible (with less capable browsers) HTML5 solution these days, one has to rely on feature detection. So, if we switch to HTML5, we need to give those, who is working with HTML5 sites a more or less solid ground to build their applications.

If we don't add Modernizr, the whole switch would not make a lot of sense, since end-integrators will need to add it to their themes anyway if they care about more than just cutting-edge browsers. In addition, once we start transition to HTML5 in Plone, we, ourselves, need the basis for extending this integration to include new elements and new attributes to Plone itself. Once again, we will have to add Modernizr later in this case.

But Modernizr has even more  http://www.modernizr.com/docs/. The good thing is that with all it's features it is packed in a quite small file size (13.4KB).

In my other PLIP #9352 I have already assumed we have Modernizr available in Plone that let's me fork the code for contemporary and not-so browsers in [50545] line 62. Well, the fallback for less capable browsers is still not there but you get the idea, I hope.

comment:59 follow-up: ↓ 61 Changed 5 years ago by alecm

(In [50941]) Added PLIP review for 11300. Refs #11300

comment:60 Changed 5 years ago by spliter

(In [50995]) Removed GenerciSetup from the configuration file. References #11300

comment:61 in reply to: ↑ 59 Changed 5 years ago by spliter

Replying to alecm:

(In [50941]) Added PLIP review for 11300. Refs #11300

Thanks for the review, Alec. Would like to comment on some moments.

  1. I am not sure about the mess with kss.core and Products.ResourceRegistries. Corresponding branches of the both packages are included in the plip11300-switch-to-html5.cfg file's auto-checkout section and should not require anything extra on your side. You can see this at  https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plip11300-switch-to-html5.cfg. I didn't change this file after your review except removing mistaken pinning of GenericSetup's version.
  1. The HTML tag being inside a conditional comment. We are using the most recent version of assigning IE-specific classes on the HTML element according to the HTML5 Boilerplate as it can be checked here —  https://github.com/paulirish/html5-boilerplate/blob/master/index.html . If more information on this topic needed, here is the discussion behind this decision in the HTML5 boilerplate —  https://github.com/paulirish/html5-boilerplate/issues/425
  1. "Validation passed with the exception of the "kinetic-stylesheet" custom rel attribute." should not be an issue, since obviously there is some conflict with pulling the correct branch of kss.core. The branch has this fixed and, configuration file for this plip should be pulling that branch without a problem.
  1. "The w3c validator complains about the http-equiv="Content-Type" meta tag, the KSS link rel attributes, and the use of an undeclared &mdash; entity in the page title." Clearly there is something wrong happening and the proper bracnhes are not pulled on your side. I can not reproduce these with the standard w3c validator.
  1. "… plone.app.kss trunk should have been included in the configuration" This is not needed. I don't change anything in that package. Only kss.core. I am almost sure that the problem you have with KSS features not working are related to the fact you are pulling that package from some place that doesn't work. I have all the KSS features, including inline editing, re-ordering of the items in the folder_contents etc. working just fine. No issues or errors in the console.

So, in my opinion all the critical issues mentioned in your review are related to some issues with the instance being built with some othr configuration, different from the most recent one. Alec, may I ask you to check this PLIP once again and make sure the issues mentioned by you are still valid?

comment:62 Changed 5 years ago by spliter

Ah! Found the place where I actually do make changes to plone.app.kss. And it's not included in the auto-checkout indeed. Will fix this. The problem is that I have made changes on p.a.kss trunk instead of branch. Stupid me! So, will clear this mess asap.

comment:63 Changed 5 years ago by spliter

(In [50997]) Reverting r50336 as it belongs to the branch and not to the trunk… at least for now ;). References #11300

comment:64 Changed 5 years ago by spliter

Checked the things now and now there has to be no validation errors. The required packages (incl. plone.app.kss) should be pulled from the branches. But after switching p.a.kss to the branch I can reproduce the issues with KSS functionality as well. So, fighting with that.

comment:65 Changed 5 years ago by spliter

(In [51001]) After playing with base-url for KSS, seems like removing that link is not gonna work fine - all KSS functionality is gone and kss.core needs to be updated in the way that might be not backwards-compatible. Instead, we update the <link /> element providing base-url for KSS with valid rel keyword ('alternate') and additional HTML5 attribute data-*. References #11300

comment:66 Changed 5 years ago by spliter

(In https://dev.plone.org/collective/changeset/241877/kukit/kukit.js/trunk/kukit 241877) Updated utils.js to take data-kss-base-url='kss-base-url' attribute into account, when on the <link /> element, providing base-url for KSS. References #11300

comment:67 Changed 5 years ago by spliter

All the critical issues should be fixed by now. Alec, Rob, may I ask you, or anybody else, to review the PLIP once again and make the decision about the inclusion into the core?

comment:68 follow-up: ↓ 69 Changed 5 years ago by alecm

(In [51036]) Update review for PLIP 11300. Refs #11300

comment:69 in reply to: ↑ 68 Changed 5 years ago by spliter

Replying to alecm:

(In [51036]) Update review for PLIP 11300. Refs #11300

Thanks for the prompt update, Alec. But, there are still two issues that bother me.

First of all, the conditional comments around the <html>. I am sure we are using the most recent and the most bullet-proof way of doing this. In the original post, mentioned in the comment in main_template.pt (the one, you reference to in your review, Alec), there is information about the (!IE) comment indeed. But, the thing is that this comment was meant to deal with Dreamweaver being too silly. At the end of that blog post, there is another, more recent, update:

2011.04.11: The HTML5 Boilerplate community dug into this and  figured out a lot more details around the syntax. Hopefully I'll get a chance to update this post with those learning...

The link in the comment leads to the issue entry of the HTML5 boilerplate. And the conclusion after resolving that issue was exactly the markup we are having in main_template now without any (!IE) thing that doesn't make sense at all -  https://github.com/paulirish/html5-boilerplate/blob/master/index.html.

I agree it looks a little bit messy, but it gives much better ground for writing hacks-less styles in the main stylesheets. And I have already put those in the stylesheets to preserve the information we had in the deprecated IEFixes.css. So, let's close this issue — the markup we have in main_template now is *the* markup and follows the best practices for dealing with IE-specific styles.

Second, I don't get &mdash; validation error on the official w3c validator. May I ask you, how do you validate the page so that I could reproduce?

comment:70 Changed 5 years ago by alecm

(In [51039]) Update review for PLIP 11300 after feedback. Refs #11300.

comment:71 follow-up: ↓ 72 Changed 5 years ago by alecm

OK, I've updated the review to reflect the fact that the conditional comment is the latest version and probably the best we can do, even if it is a little ugly :-)

Regarding the mdash validation error. I'm using the validator here:  http://validator.w3.org/#validate_by_input which is of course experimental for HTML5, but I suspect other people will use it. I view the source for the front-page in my browser and copying and pasting it into the text box. The validator automatically detects that the page is HTML5 and utf8. It has an issue with the mdash that Plone puts in the title tag, as well as with the http-equiv="Content-Type" meta tag. I don't think these are terribly important since the validator.nu validator appears to be the better one.

comment:72 in reply to: ↑ 71 Changed 5 years ago by spliter

Replying to alecm:

Regarding the mdash validation error. I'm using the validator here:  http://validator.w3.org/#validate_by_input which is of course experimental for HTML5, but I suspect other people will use it. I view the source for the front-page in my browser and copying and pasting it into the text box. The validator automatically detects that the page is HTML5 and utf8. It has an issue with the mdash that Plone puts in the title tag, as well as with the http-equiv="Content-Type" meta tag. I don't think these are terribly important since the validator.nu validator appears to be the better one.

Thanks for the explanation, Alec. Then, I suppose this is very minor issue. I validate from Firefox, using WebDeveloper Tools' "Validate local HTML" feature. It sends the local site's (in our case running on localhost:8080/Plone) output to the official w3c validator as well. In this case there are no validation errors and the document is validated as fully valid HTML5 document. Dunno, maybe the ways they process the direct input is different, but since validator.nu doesn't raise an error as well, I tend to think the 'direct input' feature of the official validator has issues.

So, I suppose, we can conclude that the ticket is really ready for merge :)

comment:73 Changed 5 years ago by alecm

Indeed, and my review conclusion says as much :-) Thanks for being so responsive.

comment:74 Changed 5 years ago by esteele

(In [51167]) Merge changes for PLIP #11300. Refs #11300.

comment:75 Changed 5 years ago by esteele

(In [51170]) Merge PLIP branch. Refs #11300.

comment:76 Changed 5 years ago by esteele

(In [51171]) Merge PLIP branch. Refs #11300.

comment:77 Changed 5 years ago by esteele

(In [51173]) Merge PLIP branch. Refs #11300.

comment:78 Changed 5 years ago by esteele

(In [51175]) Merge PLIP branch. Refs #11300.

comment:79 Changed 5 years ago by esteele

(In [51177]) Merge PLIP branch. Refs #11300.

comment:80 Changed 5 years ago by esteele

(In [51179]) Merge PLIP branch. Refs #11300.

comment:81 Changed 5 years ago by esteele

  • Status changed from assigned to closed
  • Resolution set to fixed

(In [51180]) Add new checkouts. Remove PLIP cfg. Closes #11300.

comment:82 Changed 4 years ago by davidjb

  • Status changed from closed to confirmed
  • Version set to 4.1

Is there a particular reason why the anonymous personal bar was changed from <dl> to <ul> in  https://github.com/plone/plone.app.layout/commit/72c95a1d298ae35ac931b37a2099091201a927c2 ? I note that the auth'd personal bar is still a <dl>.

Presumably this was because HTML 5 dictates a <dt> and then a <dd> are required. Wondering if this menu should be a <dl> (eg add an empty <dd>) so that all menus (including those from plone.app.contentmenu) are consistent markup.

comment:83 Changed 4 years ago by spliter

The reason for aforementioned conversion to UL was primarily validation. The second reason was my wish to have sane markup. Having definition list for marking up a user's name also with an empty definition tag doesn't sound as anything sane. I would strongly and desperately warn against using such "dirty tricks". We should show an example of best practices and not the best hacks. In my personal opinion we misuse DL elements way too much in Plone and we should have less of them rather han more.

comment:84 Changed 4 years ago by esteele

  • Status changed from confirmed to closed
Note: See TracTickets for help on using tickets.