Symphony.

it caused unintended side effects (submission of placeholder data was one)

FYI: the latest version of the jQuery Placeheld plugin no longer has that problem (my bad).

Good to know, makenosound. For my own sites where I know the audience, I’m quite happy to just not support features like this on substandard browsers. It’s good incentive for people to upgrade away from slow, old and nasty browsers like IE and Firefox (Oh yes, I just lumped the Firefox in with IE - it’s a bloated mess of an app on the Mac these days).

I just lumped the Firefox in with IE - it’s a bloated mess of an app on the Mac these days

Indeed it is. I feel a little dirty every time I open it for testing (whereupon FF gives me 10 minutes of alone time while it updates itself).

I’ve relegated Firefox to testing only - I still find Firebug to be the best tool for testing on front end. There was even a point a couple of weeks back where Firefox was utilising over 800mb in ram and around 20% of my cpu! Since I’ve moved to Chrome, I’ve had a better experience all round.

I must say its a happy day when firefox is the new IE (and ie6 is down to 4.7%).

Hahaha! Yeah, well, I stopped supporting IE6 outright when I heard Google was dropping it. I have a friend who does work with Microsoft, building sites for some of their products and more and more lately he’s been told not to bother with IE6 at all so I use that one on my clients: “Even Microsoft doesn’t want to touch it anymore.”

Problem is, we still have IE7. My hope is that when IE9 comes out people will upgrade in droves.

People won’t upgrade, especially IT people.

Where I work, we have to support IE6 to the nth degree as the IT policy is to have it installed on every machine in every country my employer is based in, which is global. Poorly designed IT systems in the 90’s rely heavily on the crap in IE6, so much so that companies are mostly unwilling to shell out the cash to fix their issues.

I bang on about it so much at work, I’ve been disciplined for a ‘negative attitude towards company policy’… Yeah.

Poorly designed IT systems in the 90’s rely heavily on the crap in IE6

That’s where I’ve seen the biggest resistance, in institutional intra/extranets and monolithic proprietary web apps. I just wonder, once those systems are eventually upgraded (which they must be in the process of), what will be the spec’ed browser they will be developed for?

Hi, I’m heading upwards on the symphony learning curve and don’t really get all the bits and pieces of the XSL examples for creating the “!DOCTYPE html” required for HTML5.

I’m abit worried about what this HTML5 vs XSLT means for the future versions of each language. Are we gonna be able to write HTML5 markup without hacks?

And whats the best solution at the time?

sry for noobiness ;)

Thanks

heigustaf

Check the attached, it will output a valid HTML5 page, hack free. The only thing you’d need to do to make this pure HTML5 is to swap out div tags with a class of article and so forth and make them article tags.

Also, this template minifies your HTML by default. Remove <xsl:strip-space elements="*"/> and change indent="no" to indent="yes" if you don’t want that.

Attachments:

master.xsl

Doug, maybe you could submit this file in the XSLT utilities for reference?

Doug, maybe you could submit this file in the XSLT utilities for reference?

Done and done. You can view the utility here and discuss it here for anyone who wants to suggest changes and whatever.

New W3C draft on Polyglot Markup:

A document that uses polyglot markup is an HTML5 document which is at the same time an XML document and an HTML document, and which meets a well defined set of constraints. Polyglot markup that meets these constraints as interpreted as compatible, regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification. Polyglot markup uses a specific doctype, namespace declarations, and a specific case—normally lower case but occasionally camel case—for element and attribute names. Polyglot markup uses lower case for certain attribute values. Further constraints include those on empty elements, named entity references, and the use of scripts and style.

…

It is often valuable to be able to serve HTML5 documents that are also valid XML documents. An author may, for example, use XML tools to generate a document, and they and others may process the document using XML tools. These documents are served as text/html. The language used to create documents that can be parsed by both HTML and XML parsers is called polyglot markup. Polyglot markup is the overlap language of documents which are both HTML5 documents and XML documents.

Thanks Czheng, I’d say that puts this template firmly in the realm of HTML5.

By the way guys, if there’s something you’d like to see in this template let me know.

I’m with Tony, I’m using the following:

<xsl:output method="html"
    omit-xml-declaration="yes"
    media-type="text/html"
    encoding="utf-8"
    doctype-system="about:legacy-compat" />

Nothing else is required, and I get a decent (polygot compatible) HTML5 doctype:

<!DOCTYPE html SYSTEM "about:legacy-compat">

http://dev.w3.org/html5/spec/Overview.html#doctype-legacy-string

Happy days!

We’ve just hit a snag where we needed to output XML (XHTML) so that we could include Facebook namespaces (which didn’t work when the output type was html). The last resort is an HTML string parsing hack.

Guys,

I’ve read some of the threads on HTML5 and I am still confused. I’m running into various issues with HTML5. Most of these are not that important (indenting, adding an ‘oldschool’ charset definition) but there’s one nagging issue: using the XML output method empty elements (for example <textarea ...></textarea>) are re-formatted (<textarea .../>) which breaks the site. It also happens with standard <script></script> elements.

This behaviour prevents me from using the XML ouput method. However, with the HTML output method I lose my XHTML syntax and some of the niceties of HTML5 such as the brief charset definition:

output=”html” and indent=”yes”:

• Indents newlines only, no tabs (LibXSLT bug?)
• Ignores/Overrides the shorter HTML5 charset with the ‘oldskool’ meta charset definition
• Overrides the XHTML syntax in HTML5 to HTML syntax (<br /> becomes <br> etc.)

output=”xml” and indent=”yes”:

• ‘Proper’ element indenting (tabs+newlines)
• Keeps the HTML5 charset as is
• Keeps XHTML syntax as is
• BUT: reformats empty elements: <textarea ...></textarea> becomes <textarea ... /> which breaks the site. The same with ‘empty’ script elements <script src="..."></script> becomes <script src="..." /> which breaks the site and does not execute (load?) the script.

(I’m guessing this goes for all empty elements?)

Indentation is not that important but I’d like to continue to use the XHTML syntax in HTML5 and would therefore go with the XML output method. But (obviously) I would rather not ‘workaround’ strange empty element handling etc. It seems unclear when exactly these issues popup.

What I don’t understand is that it’s said that XHTML (e.g. XHTML strict) is no problem in combination with the xml output method. Does it not re-format empty elements in XHTML? Is the doctype really that important for the XSL parser?

I’ve tested with both the HTML5 doctype ‘text hack’ and a standard ‘legacy-compat’ doctype which does not seem to make a difference.

It seems impossible, therefore, to have ‘properly indented’ HTML5 markup, written in XHTML syntax, that makes use of some of the niceties of HTML5 (shorter meta definition etc.) without converting empty elements (and thus breaking the site).

Please tell me I’m wrong ;-)

PS: I noticed Marc Greenstocks site uses HTML in combination with XSLT (homegrown, not Symphony :-/). He uses output method XML and therefore has pretty indentation. He also uses XHTML syntax with a standard XHTML Strict doctype which seems to fix the re-format-empty-elements problem. He simply replaces the XML namespace and doctype to HTML5 with a post-parse script. http://marcgreenstock.com/2010/02/18/html5-is-the-new-xhtml/

This seems to give me everything I want: proper indentation, XHTML syntax, and the fancy HTML5 syntax for doctype and charachter set. Without the nasty re-formatting of empty elements. Can this be done simply in Symphony? Are there drawbacks?

I apologize for the lengthy comment. Hopefully it is of help to other people working with HTML5 in Symphony.

Try:

<textarea><![CDATA[]]></textarea>

Just to clarify, it seems that LibXSLT honours empty elements and do not self-close when using the XHTML doctype so this is only an issue if you’re going with HTML 5.

Thanks allen,

Yup, only with the [unrecognized] HTML5 doctype. However, it also does occurs with the legacy-compat doctype.

I’m using HTML5 (plus it’s auto-strict-mode doctype) everywhere now and, honestly, going back to (X)HTML4 just because of these XSLT issues is not really an option imho.

PS: Just CDATA did not work (Firefox, Chrome) but:

<textarea><xsl:text><![CDATA[]]></xsl:text></textarea>

.. did work. (unsurprising really, since the element is no longer empty. At least the placeholder functionality works in this case)

It’s not an ideal situation though, since I’m not exactly sure when these issues (with empty elements and maybe more) occur.

Let me rephrase my question and see if there’s other options:

It seems impossible to have ‘properly indented’ HTML5 markup, written in XHTML syntax, that makes use of some of the niceties of HTML5 (shorter meta definition etc.) without ‘patching’ all possible empty elements…

If this is the case, I would like to investigate the option of a post-parse script simply replacing the XHTML Strict doctype (which does not have the self-close-empty-elements ‘behaviour’) and the XML prolog, etc.

PS: Is everybody else using the HTML output method (- and syntax) with HTML5?