HTML5 is defined in a way that it is backwards compatible with the way user agents handle deployed content, but the specification will not be considered finished before there are at least two complete implementations of it. The W3C’s goal is to ensure that the specification is implementable and usable by designers and developers once it is finished. The most eye-catching novelty of HTML5 is that it allows designers to replace Flash-based content with ‘ordinary’ HTML code. HTML5 will have consequences for both web designers and developers of HTML editors.Publishers of web sites will not need as many external technologies as they used to need if they wanted to design web application-alike content—think video and audio content, presentations, etc.
The following areas defined in HTML5 are believed to impact the Web architecture according to W3C itself:
- The use of the DOM as a basis for defining the language.
- The concept of browsing contexts.
- The distinction between user agent requirements and authoring requirements.
- The use of imperative definitions rather than abstract definitions with the requirement of black-box equivalence in implementations.
- The new content model concepts (replacing HTML4’s block and inline concepts).
- The focus on accessibility as a built-in concept for new features (such as the hidden attribute, the progress element, et cetera) instead of an add-on (like the alt attribute).
- The focus on defining the semantics in detail (e.g. the outline algorithm, replacing the vague semantics in HTML4).
- The menu and command elements.
- The origin concept.
- Offline Web application caches.
- The definition of the browsing context “navigation” algorithm and the related session history traversal algorithms.
- The content-type sniffing and character encoding sniffing.
- The very explicit definition of a parser.
- The contentEditable feature and the UndoManager feature.
- The Drag and Drop and Copy and Paste architecture.
- The new sandboxing features for iframe.
The HTML5 specification is already creating a stir amongst developers of HTML editors. Adobe is believed to be trying to sabotage the HTML5 specification in favour of its Flash technology. We don’t believe it will succeed, given the fact that HTML5 is based on a broad consensus of developers and designers grouped in the W3C’s workgroup.
We’ll continue this story covering the consequences for users of Adobe applications and of QuarkXPress 7 and 8. The rest of this article requires you to be logged in.
{++}
For Adobe InDesign and Dreamweaver CS3 and CS4 users, little will change. The code editor of Dreamweaver ‘supports’ whatever code you enter, so that’s not a problem. The problem will be that Dreamweaver won’t be able to show what you have just coded in its Design panel.
InDesign HTML will suffer even more –you won’t be able to use any HTML5 code at all, and even with InDesign CS5 you’ll be stuck with InDesign’s Flash capabilities.
The question now will be if Adobe is going to provide Dreamweaver CS5 with support for HTML5. Upon asking Adobe spokespeople, they couldn’t tell, hiding behind the “this is till beta, so we don’t know” excuse software developers often use.
QuarkXPress 7 and 8 will suffer the same limitations. QuarkXPress Flash capabilities may become obsolete as HTML5 grows more popular, but worse is that QuarkXPress HTML functionality –which has always been more outspoken and efficient than InDesign’s– won’t be able to handle HTML5. Given the fact that QuarkXPress 8 doesn’t target die-hard HTML coders, HTML5 content will not show up in QuarkXPress projects unless Quark would update or upgrade the application in order to incorporate support.
Smaller developers are already working on HTML5 support. Pure HTML editors like Coda and Espresso, and even innovative web design programs like Flux on Mac OS X are already including HTML5 tags. Used by many professional HTML developers, these programs are at the forefront of HTML programming and can’t afford to lag behind with the implementation of new standards.
Ultimately, the result of HTML5 will be that programming a web page with all the extra functionality users today expect will become much simpler and less dependent on proprietary technologies. Pages will load faster and browser support will be better, especially because even Microsoft has stepped aboard the HTML5 train.
Related Information
No related information.
This entry was posted in Web Design. Bookmark the
permalink. Both comments and trackbacks are currently closed.
.
HTML5. Why publishers should care and what they can expect from HTML editor developers
HTML5 is defined in a way that it is backwards compatible with the way user agents handle deployed content, but the specification will not be considered finished before there are at least two complete implementations of it. The W3C’s goal is to ensure that the specification is implementable and usable by designers and developers once it is finished. The most eye-catching novelty of HTML5 is that it allows designers to replace Flash-based content with ‘ordinary’ HTML code. HTML5 will have consequences for both web designers and developers of HTML editors.Publishers of web sites will not need as many external technologies as they used to need if they wanted to design web application-alike content—think video and audio content, presentations, etc.
The following areas defined in HTML5 are believed to impact the Web architecture according to W3C itself:
The HTML5 specification is already creating a stir amongst developers of HTML editors. Adobe is believed to be trying to sabotage the HTML5 specification in favour of its Flash technology. We don’t believe it will succeed, given the fact that HTML5 is based on a broad consensus of developers and designers grouped in the W3C’s workgroup.
We’ll continue this story covering the consequences for users of Adobe applications and of QuarkXPress 7 and 8. The rest of this article requires you to be logged in.
{++}
For Adobe InDesign and Dreamweaver CS3 and CS4 users, little will change. The code editor of Dreamweaver ‘supports’ whatever code you enter, so that’s not a problem. The problem will be that Dreamweaver won’t be able to show what you have just coded in its Design panel.
InDesign HTML will suffer even more –you won’t be able to use any HTML5 code at all, and even with InDesign CS5 you’ll be stuck with InDesign’s Flash capabilities.
The question now will be if Adobe is going to provide Dreamweaver CS5 with support for HTML5. Upon asking Adobe spokespeople, they couldn’t tell, hiding behind the “this is till beta, so we don’t know” excuse software developers often use.
QuarkXPress 7 and 8 will suffer the same limitations. QuarkXPress Flash capabilities may become obsolete as HTML5 grows more popular, but worse is that QuarkXPress HTML functionality –which has always been more outspoken and efficient than InDesign’s– won’t be able to handle HTML5. Given the fact that QuarkXPress 8 doesn’t target die-hard HTML coders, HTML5 content will not show up in QuarkXPress projects unless Quark would update or upgrade the application in order to incorporate support.
Smaller developers are already working on HTML5 support. Pure HTML editors like Coda and Espresso, and even innovative web design programs like Flux on Mac OS X are already including HTML5 tags. Used by many professional HTML developers, these programs are at the forefront of HTML programming and can’t afford to lag behind with the implementation of new standards.
Ultimately, the result of HTML5 will be that programming a web page with all the extra functionality users today expect will become much simpler and less dependent on proprietary technologies. Pages will load faster and browser support will be better, especially because even Microsoft has stepped aboard the HTML5 train.
Related Information
No related information.