If i'm not mistaken ie8 does not support xhtml
Check this out:
[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 outcome of this is uncertain. However, I think in terms of standards and semantics, XHTML is clearly superior here.
To be honest, the ideal markup for ME would be:
Also, the form element would have an option to post the form live and load the resulting server output into a certain element, for example:
Code html:<form action="process.php" method="get" result="SomeElementID" />
It's semantic, describes elements well and is quite simple. Elements are also named properly without ambiguous or shortened names.
The equivelent in HTML would look something like this, extra functionality obviously not included:
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona
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.
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.
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)Originally Posted by zcorpan
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.
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.no matter what way you wish to spin it an acronym is NOT an abbreviation.
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.
At least one forum member here uses them to navigate SitePoint.
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.
So for example:
HTML - Abbr
CSS - Abbr
NATO - Acronym
BOHICA - Acronym
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.
Okay, this is new to me!
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.
I'm also unsure about how to implement that <section /> and the <header />, but it'll be fun figuring it out!
XSLT, here I come!
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona
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 believe XSLT has conditions and counters you can use. I'll have to look to be sure.I'm also unsure about how to implement that <section /> and the <header />, but it'll be fun figuring it out!
Analysis of the new order
New elements: section, video, progress, nav, meter, time, aside, canvas
the new input element attributes: the date and time, email, url
New generic attribute: ping, charset, async
Global attributes: id, tabindex, repeat
Remove elements: center, font, strike
Well this doesn't help at all in achieving "Code once and work in all browsers" !
Chris, Programmer/Developer, Chrisranjana.com
Chennai, Tamil Nadu, India.
Software Company. Php Web developers
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).
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".
Common pattern here? "Abréviation".
Of course other languages have different concepts altogether.
And you people wonder why I think having a <SH> (short hand) tag would be so much simpler, it would cover the language discrepancies.
I guess it is just me being picky, I tend to get pretty stringent about everything when it comes to html semantics, which is probably why IE6 makes me want to hit something