Forum Moderators: open
Drafts of HTML 5, Differences from HTML 4 Published
The HTML Working Group has published Working Drafts of HTML 5 and HTML 5 differences from HTML 4. In this version of HTML5, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability.
HTML 5 differences from HTML 4
2009-02-12 - [w3.org...]
Page development and semantic construction for some is going to become a bit more scientific. I wonder how Content Management Systems will deal with this? Or should I say Authors?
Since HTML 5 has separate conformance requirements for authors and user agents there is no longer a need for marking things "deprecated".
Are they saying "no longer a need for deprecated markup" or no longer a need to cry "BAH, you're using deprecated markup?"
* The use of imperative definitions rather than abstract definitions with the requirement of black-box equivalence in implementations.
This one flies right by me. :-(
<!DOCTYPE html>
I've always loved this, but does this mean sloppy doctypes that exist today with this will be interpreted as HTML5 (if it validates)? Pretty cool would it be . . . .
eventsource is used to set up a persistent connection with a server of which messages (events) can be received.
This one has the largest focus of my attention. I've read all I can find on eventsource, if it's what it sounds like this is huge for programmers. Does this mean it's going to keep the connection open? No more timeouts on long processes, we can send progress messages from the server without refresh or forks? (hope of hopes!)
>> * The use of imperative definitions rather than abstract definitions with the requirement of black-box equivalence in implementations.This one flies right by me. :-(
It's been in the working draft for a couple years. As I understand it, this means that instructions for user-agent implementation are "imperative" and the full meaning is associated with a technically defined keyword, such as "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and others. It's a technical tightening of the recommendation document, of most importance to user-agent programmers.
---
I noticed this changed element with interest:
The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance... The strong element now represents importance rather than strong emphasis. The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose
What these mean is, in my view, not determined by what the HTML5 defines, but by how bold and italic text all over the world are used, in all kinds of texts. This is how people are going to use them, unless they want to use <strong> and <em> or other tags that are commonly rendered as bold and italic text in useragents.
So, as for HTML5, I take it as that they want us to use other tags, but will not remove <b> and <i> from the spec.
acronym is not included because it has created lots of confusion. Authors are to use abbr for abbreviations.
<aside>I love this new element!</aside>
acronym is not includedGood move.
not really - for accessibility a screen reader should know whether the letters are spelled out or pronounce phonetically.
SCUBA
NATO
RADAR
SONAR
LIDAR
for accessibility a screen reader should know whether the letters are spelled out or pronounce phonetically.
Interesting, but to take the names of the auto industry:
AUDI: Auto Union Deutschland Ingolstadt
BMW: Bayerische Motoren Werke
Little difference in origin there, but I've yet to hear somebody spell out A.U.D.I, vs. I'd like to see somebody try to pronounce BMW in one word.
Moreover I think there are a number of these where there is a cultural influence as well as to spell out the letters or pronounce it as one word.
I can't find an English example right now.
Nonetheless the difference between an acronym and and abbreviation is easy enough, I don't get how they can combine bringing in <b> and <i> in addition to <strong> and <em> while throwing out <acronym>.
AUDI: Auto Union Deutschland Ingolstadt
having said that, i had misunderstood what i previously read about acronyms, which i thought were all pronounceable as "words".
acronyms include initialisms such as BMW, WWW and SQL.
so i partially retract what i said about acronyms always being pronounceable.
this is the reference i was thinking about when i wrote about providing accessible pronunciations:
[w3.org...]
Note that abbreviations and acronyms often have idiosyncratic pronunciations. For example, while "IRS" and "BBC" are typically pronounced letter by letter, "NATO" and "UNESCO" are pronounced phonetically. Still other abbreviated forms (e.g., "URI" and "SQL") are spelled out by some people and pronounced as words by other people. When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form.
however acronyms are not the same as abbreviation such as Inc., vs., Mr., etc.
another relevant accessibility reference:
Providing definitions for abbreviations by using the abbr and acronym elements [w3.org]
(i disagree with the use of <abbr> in example 1.)
