xhtml to html5

colak · 2011-07-09 13:39:39

With a lot of new sites designed in html5 how difficult will it be to convert existing xhtml sites to html5?

I know that this is too much of a general question but to clarify, I am not referring to the templates which need to change manually but to the – sometimes 1000s of articles – whose line breaks have self closing tags and other deprecated code automatically generated by textile (<strike> and <acronym> come to mind).

I realise that html5 accepts self closing tags but what I’m talking about here is a strict html5 markup.

Zanza · 2011-07-09 14:13:21

May this be of any use? I was thinking same think and not tried yet.

Gocom · 2011-07-09 15:15:29

colak wrote:

I realise that html5 accepts self closing tags

See parsing model. Void elements can be self-closed, not all. Which is completely valid, there is no reason to remove the slashes validity-wise.

Personally I use self-closing on void elements when working with HTML5. I like to know where tag ends without needing to read the whole line.

If we are going by the fact that it saves some bytes, then… you could as well drop optional closing tags, as not all elements need closing pair.

strict html5 markup.

HTML5 doesn’t have strict mode.

Zanza wrote:

May this be of any use? I was thinking same think and not tried yet.

Note that jmd_html, as-it-is, will modify output buffer globally. It strips ending slashes from everything blasted out by Textpattern, including file downloads, plugin specific output (pdf/XML/JavaScipt files) etc.

That could be fixed by simple modification tho. Instead of executing the ob handler globally, one could run it only on textpattern callback. For example something like (untested):

/**
 * @name         jmd_html
 * @description  Converts XHTML to HTML
 * @author       Jon-Michael Deldin
 * @author_uri   http://jmdeldin.com
 * @version      0.4
 * @type         0
 * @order        9
 */

if (txpinterface == 'public')
    register_callback('jmd_html_start', 'textpattern');

/**
 * Start output buffering
 */
function jmd_html_start()
{
    ob_start('jmd_html');
}

/**
 * Converts XHTML ('/>') to HTML.
 *
 * @param string $buffer
 */
function jmd_html($buffer)
{
    return preg_replace('/(\s+)?\/>/', '>', $buffer);
}

Hope the code snippet, slightly updated, highly untested jmd_html, proves useful.

colak · 2011-07-09 15:36:58

thanks guys!

What happens with the existing articles though? In neme we currently have about 1250 articles, in some we have strike and others acronym how do I go about those? will this be the job of smd_where_used or is there a more automated way?

michaelkpate · 2011-07-09 16:45:41

colak wrote:

whose line breaks have self closing tags and other deprecated code automatically generated by textile

If the entries are actually in textile, isn’t it just a matter of making sure the output is correct for HTML5? That should be one of the virtues of an intermediate markup language.

colak · 2011-07-09 16:51:27

I thought that when we save an article, it is saved twice. Once in textile and another in html. That would mean re-saving all articles… Wouldn’t it?

Gocom · 2011-07-09 16:57:16

colak wrote:

That would mean re-saving all articles… Wouldn’t it?

Yes.

colak · 2011-07-09 17:00:38

Gocom wrote:

Yes.

oops:( That was what I was worried about.

So there’s no automated method for now.

Bloke · 2011-07-09 18:51:29

colak wrote:

That would mean re-saving all articles

While such a tool doesn’t exist yet to my knowledge, it’s a cinch to write one. In fact it could (should?) be part of smd_where_used. I was thinking of extending it one day so the process is:

search for something
get results
with {entire result set or highlighted entries} do xyz

xyz could be “replace a with b” or it could be “re-textile” which would save the chosen articles again and thus regenerate the HTML. I’ve not really thought such a system through or even figured out how to do it from the UI, so it’s just an idea that might never reach fruition at the moment.

The main reason I’ve not looked further into this (aside from the time to code it) is because of the textile project’s HTML system support. As you know, it currently outputs XHTML-style tags with our favourite self-closers. Longer term it looks like the output of Textile will be configurable to one or the other styles (it sounds as if net-carver’s plugin might do the trick now, but I admit to not having tried it yet).

It may be that the act of replacing classTextile.php with a different version, or simply loading a textplug will do the trick. Or it might be some switch you specify that determines the output method. Either way, smd_wu doesn’t strictly care — it’ll just resave all the articles you dictate and the output saved in body_Html will be whatever Textile spits out in its current configuration. But all the while Textile’s feature set is experimental I don’t see much need to offer this functionality.

Some might argue that it’s handy now when moving articles from one site to another to recreate all static links, and I’ve certainly had to get my hands dirty in MySQL once or twice to do jobs like that. Perhaps those people are right and it should be easier now so we’re all geared up for when Textile gets this functionality. The few times I’ve had to do it I’ve wished a tool existed, but those times are just that: few and far between. So to have a tool loaded and ready to do the job when it’s only used 0.1% of the time… well, is it worth it when a single line of SQL can do the same? I mean, how many times would you switch formats? Maybe once in a site’s life?

If someone can convince me such functionality in smd_wu is a vital tool that would be more widely used — perhaps as a more generic ‘do x with y’ suite — then I’ll try and find time to play with it. Until then (or until someone can artificially elevate my priority stack :-) I’m a bit snowed under with client work to play with a feature that might not be that useful.

Thoughts?

Last edited by Bloke (2011-07-09 18:58:26)

colak · 2011-07-10 07:18:00

Bloke wrote:

While such a tool doesn’t exist yet to my knowledge, it’s a cinch to write one. In fact it could (should?) be part of smd_where_used. I was thinking of extending it one day so the process is:

search for something

get results

with {entire result set or highlighted entries} do xyz

Sounds good:)

I guess it will depend on where textile will go but I would think that the acronym html tag could easily be replaced with abbr and strike with span class="strike"

If the way I am thinking is correct. Then

A new classTextile.php could be uploaded where (by use of a plugin/preference pane/whatever) the user is choosing xhtml or html5.)
Search with smd_where_used but only search the html (not the textile text)
with {entire result set or highlighted entries} do xyz

The above assumes that the textile syntax of acronym to abbr and strike to span class="strike" will remain the same.

Bloke · 2011-07-10 08:27:01

colak wrote:

the acronym html tag could easily be replaced with abbr and strike with span class="strike"

Note Robert’s comment on the acronym issue.

A new classTextile.php could be uploaded where (by use of a plugin/preference pane/whatever) the user is choosing xhtml or html5.

Yes, or a textplug could be installed. Gocom has already put an experimental plugin together for that.

The above assumes that the textile syntax of acronym to abbr and strike to span class="strike" will remain the same.

I doubt the Textile syntax will change. There’s no need. It’s what it spits out that should be configurable.

philwareham · 2011-07-10 11:02:44

I think you’d want to use <del> to replace <strike> in html5 not a span with a class – that has no semantic meaning.

Textpattern CMS

Textpattern CMS support forum

#1 2011-07-09 13:39:39

xhtml to html5

#2 2011-07-09 14:13:21

Re: xhtml to html5

#3 2011-07-09 15:15:29

Re: xhtml to html5

#4 2011-07-09 15:36:58

Re: xhtml to html5

#5 2011-07-09 16:45:41

Re: xhtml to html5

#6 2011-07-09 16:51:27

Re: xhtml to html5

#7 2011-07-09 16:57:16

Re: xhtml to html5

#8 2011-07-09 17:00:38

Re: xhtml to html5

#9 2011-07-09 18:51:29

Re: xhtml to html5

#10 2011-07-10 07:18:00

Re: xhtml to html5

#11 2011-07-10 08:27:01

Re: xhtml to html5

#12 2011-07-10 11:02:44

Re: xhtml to html5

Board footer