The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

[QUOTE=cooper.semantics;4222402]If i'm not mistaken ie8 does not support xhtml QUOTE]

You are not mistaken, it doesn't.

Of course no browser supports HTML 5 - fortunately.

The way that HTML 5 is going this could lead to the web being split into two separate sections with the professionals moving toward XHTML 2 and the hobbyists going for HTML 5. People may end up needing two different browsers on their computer if they want to be able to access both types of pages.

The way that HTML 5 is going this could lead to the web being split into two separate sections with the professionals moving toward XHTML 2 and the hobbyists going for HTML 5. People may end up needing two different browsers on their computer if they want to be able to access both types of pages.

If you want to write your markup like that, Arkinstall. Instead of waiting for your desired language to appear, make your own. All you need to do it create an XML language, either use a DTD or an XML Scheme. Then learn a little XSLT to transform your newly created language into something browsers support (aka. HTML).

Avoids the whole standardization slowness.

Logic without the fatal effects.
All code snippets are licensed under WTFPL.

Zcorpan: true in retrospect having a color well does have some semantic value for the example you suggested. While it is true that iFrames were not depreciated at the point the sandbox features were proposed I still have to wonder how detrimental it will be to accessibility and I cannot help but think this is going to do some long term damage of its own. Renaming the tag would not be a pointless endeavour, no matter what way you wish to spin it an acronym is NOT an abbreviation. What is occurring with bundling them both together under the single tag name is essentially violating the semantics of the English language. If they want to include the two tags together under a single element to reduce confusion, this is perfectly fine however they should not do so using a simply flawed and incorrect naming convention. Just because some microformats do not specify a head profile does not mean they are not in use under certain circumstances (even if just referencing a URL). I feel indifferent about removing it to be honest but considering the profile was being used by some groups, I do have to wonder about the benefit of removing it. You have contradicted yourself, you said that Access keys have not received proper research, yet you then state that studies show they have a harmful role. If what you said about proper research not being done is correct, no firm results on usability could be concluded, and I have read usability studies where people have stated, if access keys are available on a website they do make regular use of them, so I guess even due to the differences between browsers implementation, they were clearly of some benefit to some people.

logic_earth, while making a DTD and your own syntax language might sounds like a fun thing, I am unaware if any browsers actually read the DTD and will make use of any custom elements you produce? Either way, it seems a bit over the top to make your own standard just because you feel that things move to slowly.

No, rather, after having researched and carefully considered feature X, it gets specified. Of course there was much noise generated from the fact that pet feature X was lacking in the specification but that did not really affect the result.

That everyone had to scream and push for just that "look" was what was so sad about it. When prominent members who are respected in the community start right out saying stuff like "nobody uses it" "authors don't know how to use it" "nobody's shown it in use/the need for it" it's kindof dangerous because a lot of people will just listen to that (due to the respect the speaker has in the community). I saw/read people stating basically that there was no reason to even consider headers/pet-x which, it really ought to be the other way around-- research in order to drop, instead of research in order to reinstate. (I know a lot of people want to drop the cruft of HTML4, that's understandable)

And I heard plenty of people in that community saying such things, so I know that there are plenty in the group of "research-to-drop" group as well.

no matter what way you wish to spin it an acronym is NOT an abbreviation.

I'm not sure I see the point in two different elements. Neither of them exist to tell the user or the user agent whether the BLAHBLAH is an acronym or an abbreviation, but to tell the user/user agent WHAT that BLAHBLAH an acronym or abbreviation is OF.

I see it the same as using an <anchor> to open hyperlinks, and an <anchor> to open documents like PDF. Someone somewhere could have said no let's have <anchor> for hyperlinks and <document> (or whatever) to open programs on the user's machine. But they do the same thing and the user/user agent doesn't look to see WHAT exactly the difference is (when they do, then of course it matters what the tag actually is, because what it is conveys information. But plenty of tags merely do stuff).

Stomme, there was not any reason to have both an ACRONYM and ABBR element (even though initialised ABBR’s were not even considered in the spec), but in the English language, an acronym and an abbreviation are two completely different formations of words. To classify one as another is semantically incorrect from the offset, which is why it would be preferential to simply retire ACRONYM and ABBR and replace them both with something like <SH> (shorthand) which semantically speaks to both definitions without the absurdities of confusing and incorrectly defining tags.

Alex: According to my dictionary, an acronym is a subset of an abbreviation. So it is proper to say that an acronym is an abbreviation. However, none of actually matters that much. The element could have been called <foobar> and still be defined to represent an acronym or abbreviation.

The research there has been seems conflicting. Mostly the problem seems to be clashes with user agent shortkeys. However when they accesskeys DON'T conflict with shortcuts then some users have the ability to enjoy them.

Acronym - A word formed from the initial letters of a name, such as WAC for Women's Army Corps, or by combining initial letters or parts of a series of words, such as radar for radio detecting and ranging.

logic_earth, while making a DTD and your own syntax language might sounds like a fun thing, I am unaware if any browsers actually read the DTD and will make use of any custom elements you produce? Either way, it seems a bit over the top to make your own standard just because you feel that things move to slowly.

XSLT, Alex, it takes the custom XML language you created and turns it into standard HTML for the browsers. They will not have to read the DTD or even be aware of your custom elements because they won't be there.

Two ways you can do it, send the XML and the XSLT to the client and let it do the transformation. Or let the server do the transformation and send the output HTML. Firefox 3, Internet Explorer 6, Chrome, Opera 9, Safari 3 all have support for XML and XSLT.

Creating a language out of XML is nothing new, people have been doing it for years. MathML, SVG, XUL, XAML, etc are all custom languages made atop XML. A few went through the process of being standardized.

Logic without the fatal effects.
All code snippets are licensed under WTFPL.

Is there a way to define custom functionality that you wouldn't normally see in HTML?

For example, in the <datagrid /> element I used above, that would have clickable columns which you could use to reorder the data.

Also, the <preload /> element would preload a certain file after the rest of the content has loaded, so it's already in the cache for when they visit another page, for example.

For that stuff, you will have to use JavaScript because obviously browsers are limited. But you can use those tags in the XML as placeholders for JavaScript templates inside the XSLT file. That would be one way.

It is a very good idea to look at XSLT weather you use it to make your own markup language or not. Take any XML input and transform it into any output you can come up with. Very powerful stuff.

I'm also unsure about how to implement that <section /> and the <header />, but it'll be fun figuring it out!

I believe XSLT has conditions and counters you can use. I'll have to look to be sure.

Logic without the fatal effects.
All code snippets are licensed under WTFPL.

While it is true that an acronym is a subset of an abbreviation I feel that to cover all forms of shorthand it would make more sense to create a more generically applicable tag.

Alex, I understand that concern, but at some point in the specification process you need to remove stuff that are overly-specialized cases of an existing construct.

Plus, if you have specialized cases, it's better if they can be used universally, and not in one specific culture or language. I'm French, and i did some research on ABBR and ACRONYM last year. Turns out the concepts of "acronym" (English) and "acronyme" (French) don't match. What you would describe as an "acronym" in English is a "sigle" in French, and what French people would describe as an "acronyme" (provided they know the definition, which is rare) is not an "acronym", but a special kind of abbreviation that has no corresponding word in the English language.

I haven't done further research but my guess is that if you include other languages:
- ACRONYM can only be used in a few languages, and you have to beware of false friends like the French "acronyme" and possibly others;
- most languages out there don't have the "acronym" concept;
- most languages out there need a broad "abbreviation" concept, that doesn't strictly map to the English "abbreviation" but that would correspond to any shortened written form of a word or group of words, or of a character or group of characters (and would allow authors to specify the full form of the word/group of words/character/group of characters).

or by combining initial letters or parts of a series of words, such as radar for radio detecting and ranging

In French, "radar" is an "acronyme" because it can be read as a word. But other combinations of initial letters or parts of a series of words, when they cannot be read as a word, are just "abréviation".

HTML, for instance, is an "abréviation". It's not a "sigle", because the T is not an initial letter (hyperText). It's not an "acronyme", because HTML cannot be read as a word (you have to pronounce the letters individually).

HTML - is an "abréviation".
CSS - is a "sigle" (subset of an "abréviation")
OTAN (French for NATO) - is a "sigle acronymique", that is a "sigle" that is also an "acronyme", and of course both "sigle" and "acronyme" are subsets of "abréviation"
BOHICA - not sure what it stands for, but such a form would be an "acronyme" or a "sigle acronymique", and of course that's an "abréviation".

[*]Dates must tentatively follow the ISO 8601-format, which does not allow for dates prior to year 1 or after year 9999 without prior agreement between the parties reading the document. Therefore, it is impossible to write documents about ... dinosaurs using HTML 5, unless the articles are accessed through a form requiring such agreement.

And you people wonder why I think having a <SH> (short hand) tag would be so much simpler, it would cover the language discrepancies.

Well, no need to rename ABBR to SH. A broad definition of "abbreviation" already covers language discrepancies. So the WG's decision is sensible. Actually it has been in the air for years before HTML5 was even started, i can remember Laurent Denis (French HTML-CSS and accessibility expert) predicting this move in 2005.