You are not logged in.
Since html5 is quite popular now, and we need to keep backwards compatibility with XHTML for existing sites. Maybe a preference toggle to select either output would be the answer. Things like self closing tags can stay as they are still valid in both, so I don’t think there would be too much work involved.
Maybe a preference toggle to select either output would be the answer.
Txp itself isn’t such a big task (errr, I don’t think — taghandlers would need combing, as would the tag builder). I reckon the big hurdle is Textile. It’s fairly simple to patch to choose a system at
new Textile() instantiation time — and that could then be filtered back to a Txp preference ready to pass in. I’ve demonstrated this is feasible (this week, as it happens). But it’d only be a short-term solution.
I have it on good authority that, longer term, Textile is undergoing some radical changes to help separate the input from output so other modules can be plugged into it, as well as allow plugins to interact with it (I suppose one such ‘plugin’ might well be Txp itself, but I really don’t know the specifics yet so I might be talking rubbish).
Since the Textile project has been spun away from Txp development, and other people are putting ideas into the melting pot for the various ports, it’s really starting to take off. I’d say this is where the focus should be for anyone wanting to get involved.
As far as Txp is concerned, off the top of my head I’m not sure which bits need changing. If self-closing tags and quoted attributes are staying, what needs attention to bring it inline? acronym/abbr? (does the core use that anywhere or it just Textile?) Some of the meta tags? And the rel attribute, maybe? Anyboody have a handle on which bits/tags are not up to spec? That might give us an indication of how big the job is.
I’ll have a comb through the code next week and let you know. I also think the remaining inline CSS should be removed.
Thanks. And [OT] yeah, inline CSS is long overdue for killing. It’s an enhamperment(?) for plugins too who want to use the core functions and find they come saddled with unwanted
style elements (though there are not many left now, thank goodness).
The worst offenders are the
/include/txp_* files. Of those, only article, auth, category, css, form, page, and section are clear of inline wrangling. That leaves 12 files that need attention and some decent, general-purpose style rules making. I think the remainder are just in
It was beyond my CSS knowledge to do it properly in 4.3.0. Maybe now’s a good time to pool resources and get it out of the interface for good?
Last edited by Bloke (2012-01-30 12:25:01)
I can get on that, but how do I pull request code back to the SVN on google code?
*shrug* never done it. Can SVN even do that? Might have to be a classic patch .diff submission?
I’ve created issue 132 to track this request.
this is cool news.
What happens to large(ish) sites whose owners wish to migrate to html5? will there be a script to help with the migration of existing articles? I am thinking of deprecated tags such as
acronym but also the closing slash of line breaks.
will there be a script to help with the migration of existing articles?
… the closing slash of line breaks.
<br /> is valid HTML5.
Last edited by wet (2012-01-30 09:16:46)
The worst offenders are the
I believe none of those renders any output to the public side, and as I don’t think we want the backend to become a HTML5 document, do we?