Although a couple of the posters are being a little cruel in the tone of their jokes, I do agree that this is a good concept with the wrong approach.
I, also, started down a similar road to this 7 or 8 years ago, but quickly decided it was a dead end. For one thing, pages written this way won't validate. You have two options for validation: create your own DTD with your extended tags defined or process server-side. Of the two, I would choose option 2 for two reasons: (1) option 1 is going to be wrought with browser conflicts, especially among old browsers, "lite" browsers, or browsers that fit special purposes (screen readers, search engine bots, etc). (2) option 1 is an long, uphill battle to get a new DTD recognized -- HTML5 is still being worked on and it's been how many years?
So I would agree that it should be done server-side, not client-side.
You could, as suggested, write a PHP library. That would be a great option. However, I think there may be better options than that. An option that sounds good to me is (A) create your own DTD to use server-side, thereby avoiding the problems discussed above and allowing you to create pages the way you already are (B) use Node.js to process your document and (C) send compatible HTML to the client.
Last edited by nathanwall; 04-18-2012 at 11:55 AM.
Sorry for the delay and thanks very much for your post Nathanwall!
It's great to hear you like the idea as such, even though I agree that the approach might not be ripe for the market quite yet. You even researched this yourself that long ago. Yes, my research also goes back to that time.
You, Charles and NoEffinWay seem to agree that things could be even a bit more server side in PHP.
At the moment, the architecture is such, that the page with extended tags is being pulled into the DOM, if Ajax is enabled. Otherwise, in a noscript tag, a redirect is performed with the tags also being extended, but obviously no JS functionality. This gives rise to the effect that a short version of the HTML with the abbreviations can be viewed in the browser and by the search engine alike. This results in all the SEO advantages that are possible.
I have talked to my main client page manager and he says the SEO effects are desirable and seem to work well and without risk. So I don't want to loose them completely.
I'm easy about the W3C validator, if that's what you mean. At the moment, the tags are only parsed in text nodes (i.e. at the very left of them). They're only text. Therefore they validate, even if the underlying HTML is faulty! I spawned a whole thread on the DTD topic and agree that it is a very cumbersome route. No, not necessary, as these "tags" are text anyway...
We seem to agree that a PHP library is the minimum route. That would be very safe play. Don't mean to be cheeky but I'm aiming a bit higher than that. One of the biggest advantages of these "text tags" is that they're completely platform independent. You can route them into the mid-tier or even into the back-end. It doesn't matter, whether the user uses PHP or Java, for example. What I'm coding in PHP doesn't marry the user to PHP.
That should stay that way, if possible...
Maybe you can explain what you mean by:
"(B) use Node.js to process your document and (C) send compatible HTML to the client." (as we can skip (A) ) ?
Maybe Charles or NoEffinWay can explain what further pre-processing can be done in PHP?
Noble effort, but it looks like you try to reinvent the wheel. In fact your wheel is squared.
HTML is a mark-up language, not a scripting one, so that you can not use the self paradigms of HTML to create a sort of custom HTML "library/framework" without altering its DTD, which is not of a general purpose utility.
Well, in fact, a "New HTML tags" mark-up language was already invented. Its name is XML.