Support for Supertags was an accident

The W3C HTML5 specification doesn't mention supertags anywhere. In fact, for more than a decade, support for HTML supertags by web browsers was just an artifact of how they parsed web pages. Some browsers, such as Firefox, early on adopted a more flexible generic approach for HTML tag parsing that accommodated user-defined supertags, whereas other web browsers either hard-coded the behavior for each tag, or limited tags to a specific subset.

The last of the browsers to adopt the "if it's between a < and a >, treat it as a tag" approach was Microsoft's Internet Explorer, version 9.

 

What does the W3C HTML5 Specification say about user-defined HTML tags?

The HTML5 spec (currently section 2.2.3 - but don't count on the section number staying the same between drafts) allows tags in the format <x-vendor-element> ... where vendor is a short representation of the vendor name. An example would be x-xs for xmlsucks. So, is allowed by the spec.

The only difference with respect to supertags is getting rid of the x-vendor-specific portion. It's simply not needed, because you shouldn't run into instances where you get collisions between multiple vendors in the same document unless you're doing weird stuff, or loading content from another site. Tag collision still isn't much of a problem because, after all, don't you want to apply YOUR local format of a <story> to a story, no matter what the source?

With the release of IE9, we can add Internet Explorer to the list of web browsers that support HTML Supertags.

What about users of Windows XP, who can't run IE9? They can still install Chrome, Firefox, Opera, or Safari, all of which support Windows XP.

As of this writing, IE6 usage is below 10% (with more than half of those being in China). Generally, users of IE7 or above are able to upgrade - IE6 is usually kept by business to support legacy applications.

With all XP support ending in 2-1/2 years (April 8th, 2014), there really is no reason not to make use of both supertags and the many features of HTML5, such as the border-radius property, to clean up both your html and css.

I first discovered "super-tags" more than half a decade ago, when I wondered what would happen if I tried to create and style my own tags, instead of just using the ones that are pre-defined in the html spec.

Most browsers "do the right thing" (and no, you don't need a special doctype declaration or DTD to do this) - they recognize ALL tags between a "<" symbol and a ">" symbol as html, and let you style them via css.

So for years, you've had the ability to use, style, and manipulate custom html tags such as <article>, <section>, <sectionheading>, <footnote>, <book>, <chapter>, <sonata>, <brand>, <ad>, <flying_monkey>, <underpantsgnome> , <etc>

The only exception, of course, is IE, which uses a fixed set of tags internally, and tag-specific handling code, rather than applying rules to togs in a general way.

CSS tags are somewhat confusing - for example vertical-align aligns things vertically, but text-align aligns things (not just text) horizontally. This fixes a lot of that, as well as unifying the syntax between CSS and HTML.

[box] syntax for css files

Simple CSS source files adopt the same standard as simple HTML source files - tags (or in this case, css selectors) and their values are enclosed within square brackets.

In addition, several keywords have been changed, and some new concepts introduced, to make writing (and reading) CSS source files easier. The parser will transform the source file into a proper .css file. which can be uploaded to your server.

This first example of using the [bracket-style syntax] for describing web pages is basically how Paring down HTML as a first step would be re-written.

I've taken one liberty, since this is only an example - since the actual codes aren't being interpreted, I haven't escaped them using the "extra space" mechanism.

Some of you will notice how it borrows from python, in that leading tabs are significant in some situations. This lets you visually format things like lists and definitions without requiring extra markup..

Important note: This is not a server-side templating language. This is a document description language. It is run through a code generator to create a web page such as html, php, perl, python, or jsp, which you upload to your web server.

Nobody uses tags such as <isindex> or <menu> any more (and the menu tag is certainly counter-intuitive - it doesn't create what most people would consider a "real menu").

More importantly, people can easily understand [b for bold] and [i for italic], and that one blank line inserts a new line, and two produces a new paragraph - they don't want to be told that they should use <em> - for "emphasis" to get italics </em> or <strong> for bolded text </strong>. They also don't want to clutter up their page with <br>s and <p>s; when a couple of new-lines would do a better job.

HTML has always had useless tags; before adding new tags, the first step is to get rid of tags and attributes that aren't needed, or should be user-defined, as well as

1. provide a simple mechanism for new tag types - make it user-extendable
2. include data operations as part of the base language;
3. encourage code re-use by making libraries part of the work flow;
4. make pages self-documenting
5. emphasize the separation of style from content with both style sheets and self-contained re-usable code objects.

Note: Most tags also have a long name, to make page generation code more self-documenting. Example: [bold this is also bold] and [numbered list] for [1list]

The problems began right out of the gate - the first implementation of HTML was already a "tag soup", with tags that might have seemed like a good idea at the time, but not only haven't done the job they were intended to do, but have been usurped because they were a stupid idea in the first place.

How many HEADings do you need?

If you consider the Web as a library, a website would be a collection of books. A book is known by its' title, and consists of a collection of pages. Those pages are usually divided into chapters, and those chapters might be divided into sections, each with a heading. For most purposes that's more than enough.

XML is bloated. XMLis fugly. XML is only "human-readable" if you're willing to stretch the definition of "human-readable." The same goes for the proposed bloatware of HTML5. Anyone looking at the spec must be shaking their heads. Sure, it's better than the now-abandoned xhtml 2.0, but that's not saying much. I've given a lot of thought to the matter, and made the following conclusion: what is needed is a declarative language that has the following features:

• a simple, declarative syntax
• a clear separation of design and implementation
• support for multiple output from the same source - web page, javascript classes, or wxWidget program

First, let's look at bbCode, which is used to simplify html on many bulletin board systems

Welcome to xmlsucks.com

XML is great - until you have to work with it. This is going to be the place to go when someone is trying to get you to adopt xml as a "solution" because they've been playing buzzword bingo one time too often, or something equally retarded.

This domain was a zombie until 23:50 on December 27th, 2009. It has been re-animated. You can see its' some of its' previous incarnations via the wayback machine here.and here. Feel free to suggest links, stories, etc.