Warning: gzinflate() [function.gzinflate]: data error in /home/boozkerc/public_html/kneedeepincode/wp-includes/http.php on line 1787
Below is a long post about the possibilities of HTML with only 7 reserved elements which would use XML namespace syntax, a Form API, and the reserved attributes for those two APIs, which I believe, would make HTML much stronger. Let’s face it, HTML5 is already becoming so, so bloated with too much effort on backwards compatibility. If you just want to skim, here are the table of contents:
- HTML Tags
- HTML Attributes
- Form Attributes
- Some questions I’ve received when talking about this concept
What is the point of having nearly all HTML elements? What if we could simplify HTML to 7 reserved elements? Everything else is up to you plus CSS. Look at this example:
The entire HTML definition could be summed up in a few reserved tags:
<html:html>: Begins the HTML document
<html:head>: Contains information about the HTML document
<html:meta>: Contains meta data. There can be ANY type, but there are a few reserved types. See Below
<html:body>: Defined the same as the current HTML definition.
<html:media>: Anything that is not text based. Things like audio, video, images, swf, applets etc. If it isn’t a video, audio, or image the browser will look for a plugin to run the embedded media.
<html:a>: Contains a link just like current HTML
Each element has it’s on own attributes, but you can also specify any that are not taken already with the API. E.g.
selectable is NOT used by the HTML API therefore allowing you to use it and in anyway you want.
All tags have the
name attribute reserved for built in browser tool tips as well as the id and class attributes for CSS, JS, etc. Otherwise anything goes for your own tags whilst HTML API tags have their own reserved attributes (all but the
type are the same as the current HTML spec):
type (must be either: video, audio, image, or embed)
“Ah!” you say,
“What about forms?” The forms would be part of the Form API. This allows us to scale it at a different pace than HTML. The HTML API uses the Form API. Here are elements (most are just like current HTML forms):
<form:form>: Begins the form
<form:input>: Creates a new input field. For possible input types see below.
<form:select>: Creates a select input
<form:optgroup>: Groups options together. Child of
<form:option>: Creates an option for the select field Child or either/or
<form:label>: A normal form label
<form:fieldset>: Groups parts of the form together
Like the HTML API,
class are reserved for all Form API elements. Unlike the HTML API, the
name attribute will not create a browser tool tip. The
name attribute should act just like HTML Forms currently work.
type (can be: text, radio, checkbox, textarea, calendar, email, password, match, submit, button),
Some questions I’ve received when talking about this concept:
“This isn’t semantic!”
Right now we have numerous elements that should not be there at all. Such as
<i> etc. Even with the “new” HTML5 definitions, they stand for image, bold, italics and so forth. This isn’t semantic at all. This completely presentational. This method makes HTML pure semantics and pure information.
“With people naming things random names, how are search engines going to work?!”
What do we do now? Most of us use divs with ids and classes. How do search engines index this with random names? Well, they look at the ids and classes for common names. Most of us use things such as
wrapper, nav, navigation, main-content, main_content, footer, header, etc. If they can read ids and classes, I’m sure they can index tags. Plus, this cleans up the markup making it less information for them to cover.
We have to remember that if we are naming them things that search engines would have problems parsing, then there is most likely no current HTML tag that suits it now. For example, let’s take this example:
<calendar> <month> <week> <day /> <day /> <day /> <day /> <day /> <day /> <day /> </week> </month> </calendar>
To me, if I were to make a calendar with HTML, that makes more sense than:
<ul id="calendar"> <li class="month"> <ul class="weeks"> <li> <ul class="days"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> </ul> </li> </ul> </li> </ul>
And personally, I bet more people would like to mark and style it the first way. Plus, are you going to tell me that the UL method would be easier for a spider? If you decide to name your nav
<blahteeteeoop>, then sure, the search engine won’t catch on that this is a navigational element. But most of us are going to use
<nav> (my choice),
“What if we end up adding a HTML API that is named the same as one of my tags in the future?”
That’s why we use the HTML name space. When you do
<html:x> (replace x with anything) you are calling the HTML > X. The browser then would run the API for that tag. E.g.
<html:a> would tell the browser “Hey! Make me a clickable link!” while <nav> doesn’t say anything to the browser except that there is an element called <nav> in this location in the DOM.
“WTF, this is just XML with XML Namespaces, but this isn’t even valid XML! You don’t even properly close your self-closed elements! “
Correct! This would be invalid along with 90% of the “XHTML” web sites out there. They simply call themselves “XHTML” when they are not in anyway but the look of the code. If you tell the browser it’s HTML then, oh my god, guess what? It parses as HTML! Quite genius isn’t it?
I’ve decided to keep the HTML syntax, call it HTML and keep it as HTML with XML namespaces because XML namespaces work perfectly to avoid conflict among elements. We need this so we can scale with this new method and avoid people naming elements the same as something that might later become included in the HTML API.
I don’t self close tags because this isn’t XML. However, you can use whatever elements you would like just like XML with a few minor exceptions to attributes.
“Over half of all websites are outdated by html 4.01 standards and switching to something new would completely break things on those old sites”
Correct, moving to a completely new system would break every form of HTML/XHTML currently out. This is why browsers would just need to retain the current standards as they are built in as I write this. Once HTML5 is completely implemented we could simply stop and switch to the new system. Allowing browsers to keep what they have and keep old sites working while, using the same technologies, implement this form of HTML.
For example to make an image display, the browser could say, if HTML5 or less,
<img> == an image OR
<html:media type="image"> == an image, but both ways would do the same thing. If you are using the new system, you could take advantages of the technologies in the new form of HTML.
This change would not be hard at all because browsers already accept XML, most of my HTML API method is built on current HTML standards, and you could very simply run the browser in a standard HTML mode without changing any current code.
Personally, I think this is a much more scalable and easier to maintain because we can add modules and not have to wait years upon years for an entire spec to come out for the entire language it’s self. We can write a spec on, for example, the media element, and spend maybe an entire year working on it. Then the browsers can pick up that single module and add support for it. People could even write plugins to run those specific tags if we truly built this as a HTML API.
This also clears all presentational elements. All elements included have a reason they are there and the elements wouldn’t need any default styling because they are there for functionality.
This is not XML, but a form of more liberal HTML, and I personally believe, a more powerful HTML at that.