“HTML5 (also sometimes referred to as Web Applications 1.0) is a technology developed by the WHATWG, an open community started by three of the four major browser vendors: Mozilla, Opera, and Apple. HTML5 is not so much a replacement for HTML 4.01 or XHTML 1.0 as it is an upgrade or evolution. It aims for backwards compatibility, tries to remove undefined behavior in HTML 4.01 by defining it, and looks at the various browsers’ tag-soup parsing behavior to try to define the best solution that doesn’t break the web. At the same time, it adds sorely needed semantic elements for things such as improved form validation, interactive elements, and persistent storage.

HTML on the Web Today

While HTML 4.01 is formally an SGML-based document format, the only clients actually treating HTML that way are validators. Browsers, on the other hand, treat HTML documents as tag soup—they try to make sense out of, and display, even the most horridly broken document to their best ability. Very little content on the web is valid HTML 4.01; most of it is invalid and ill-formed, but browsers still have to parse it, or they will soon be disregarded as users switch to browsers that support their favorite sites.

Tag-soup handling—trying to correct errors in documents—is essential, but every browser does it a little differently. All browsers try to get as close as possible to how their largest competitors do it, but even when broken content works the same in different browsers, it doesn’t necessarily mean that they are performing error correction in the same way, just the way that both works for the common case and is most practical for them. HTML5 tries to put an end to this need for reverse engineering of competing browsers by defining exactly how this error correction is to be done. HTML5 doesn’t just define how valid documents are to be parsed, it also defines how parsing should work if documents are invalid, ill-formed, and broken, so that browser vendors can make their products fully interoperable with each other.”

Read the full article at Digital Web Magazine

“Although MPEG (Moving Picture Experts Group) also looks at content and coding, SMIL is more web-centric unlike MPEG, which is more media centric and involves more than just content and coding. A close comparison would be D-HTML (dynamic hypertext markup language). However, D-HTML uses scripted definitions of local behaviours, without a notion of the presentation’s context. Actions such as timed events are therefore difficult to co-ordinate.

Then there are W3C technologies such as cascading style sheets (CSS) which are compatible with SMIL, which means CSS can be created for media-based SMIL, with CSS code complementing SMIL layout. So why not simply use CSS?

There is a difference between CSS’s text-flow and SMIL’s time-flow documents. Although the XML nesting tells a lot about text layout, it tells very little about temporal layout, which is what SMIL is good for. The non-modularised nature of CSS also induces too much overhead and there are conceptual limitations to CSS for time-based presentations.

SMIL, on the other hand, is basically an XML document with defined XML DTD (document type definition) and schema. It is a declarative, integration language with the media elements referred to and not included. This allows SMIL documents to be hand-authored, though probably few would try since there are already many tools available, such as an SMIL authoring tool known as Fluition and RealNetwork’s RealProducer G2 Authoring Kit.”

Read the full article from Deaf Today.

Web developer James Edwards would probably almost go so far as to say that it’s offensive to him when people complain that web accessibility is a cumbersome process. To help fight this idea, he has created an article bringing up something that many of us may not think of; mouse-less navigation. “Most of us use a mouse for the majority of our graphic interface navigation, but some people can’t, and must therefore navigate using the keyboard instead. For a person who has a hand tremor, for example, the precision control required to use a mouse effectively may simply be impossible. For users of assistive technologies such as screen readers, the keyboard is the primary method of interaction. After all, it’s rather difficult to use a mouse when you can’t see the pointer!

Providing for keyboard access also creates better usability, because many people who can use a mouse nonetheless prefer to use a keyboard for certain tasks or at certain times. These tend to be power users — people who are generally more familiar with how their computers work, and expect to be able to interact with functionality using either the mouse or the keyboard as their needs dictate.

If you’re not in the habit of navigating sites with the keyboard, try it now! Spend some time on your own site, and on other sites you visit regularly, to get a feel for what it’s like to surf without a mouse. Discover where difficulties arise, and think about how those issues could be avoided.”

Read the full article from Sitepoint and make your web site more accessible today!

The legality behind web semantics is something that many of us may not think about. Not true for Joel Alleyne:
“One of the things that surprised me when I started working with law firms is that most firms and most tech people ask one question repeatedly that seems to stifle innovation and the development of new concepts and ideas. When presented with something new, most ask: “which other law firm is doing this?’ While this makes some sense and provides a way of weeding out wacky ideas with no traction, it also limits innovation and creativity. What about ideas emanating from other professional service firms? Other service firms? From industry in general?

Take for example the semantic web:

• “… a project that intends to create a universal medium for information exchange by putting documents with computer-processable meaning (semantics) on the World Wide Web”
• “… an evolving extension of the World Wide Web in which web content can be expressed not only in natural language, but also in a form that can be understood, interpreted and used by software agents, thus permitting them to find, share and integrate information more easily”

The original vision for this is credited to Sir Tim Berners-Lee as an extension to his original invention (the world wide web). You can find an outline of the concept penned by Tim himself here. Much has been done to establish this framework which is aimed at making web content more accessible and usable — especially by machines.”

Read the full article at Canada’s own Slaw.

In the beginning it was to overcome a specific problem. Now it’s there just for the joy of web developers everywhere.

“The essence of Pixy’s Fast Rollovers involves creating one image for each navigation item that includes normal, hover and active states stacked on top of each other. Later, we’ll use CSS to change the background-position to reveal each state at the appropriate time.Figure 1.1 on the right shows an example image that I’ve created and used for Fast Company’s new navigation. Each state is 20px tall with a total image height of 60px. The top 20px is the normal state, the next 20px shows the hover state and final 20px shows the active state (which is also used for the “you are here” effect). There are similar images for each tab we’d like to use.

Using one image for each state allows us to toss out ugly Javascript and instead make use of simple CSS rules for hover effects. This is good. It also eliminates the “flicker” effect that other CSS methods suffer from, where separate on/off images are used. This is good. We also don’t have to pre-load any additional images. Again… this is good.

The CSS: This is Where the Magic Happens

First we’ll set up the rules that all navigation items will need. This will save us from writing duplicate rules for each tab. Then we’ll add a separate rule for each list item id, giving the li it’s own background-image and width — the only two variables that will be different for each tab.”

Read the full article from SimpleBits.

“Misunderstanding #1: “We Need Separate Print Pages” We’ve all seen this – a separate print page, linked to from a crowded, table-layoutish HTML page, aiming to serve no other need than being printed out (it fails, because bloggers link to print pages – they’re mostly easier to read and not split up into multiple pages). The good thing about these pages is that the user gets an instant impression of what the print-out will look like. Of course, the right way to do this would be to serve a separate stylesheet for medium print, and if the browser does it right, it will show the visitor a print preview.

This is old news, but why do I consider it noteworthy? Because it’s the #1 application where media-dependent CSS, on top of media-independent HTML, ought to come into play… and yet, and I’m guessing, only 5% of all pages make use of it. You’d think after years of evangelizing done by web developers, the likes of CNN or Wired would have gotten the point.”

Read the full article hosted by the Google Blogoscope.

“APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.

Structure

An APNG stream is a normal PNG stream as defined in the PNG Specification, with three additional chunk types describing the animation and providing additional frame data.

To be recognized as an APNG, an ‘acTL’ chunk must appear in the stream before any ‘IDAT’ chunks. The ‘acTL’ structure is described below.

Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the ‘IHDR’ chunk.

The default image may be included as the first frame of the animation by the presence of a single ‘fcTL’ chunk before ‘IDAT’. Otherwise, the default image is not part of the animation.

Subsequent frames are encoded in ‘fdAT’ chunks, which have the same structure as ‘IDAT’ chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in ‘fcTL’ chunks. The full layout of ‘fdAT’ and ‘fcTL’ chunks is described below.

The boundaries of the entire animation are specified by the width and height parameters of the PNG ‘IHDR’ chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.

Each frame is identical for each play, therefore it is safe for applications to cache the frames.”

Read the full article at the Mozilla Developer’s web page.

“Audio and video podcasts are not accessible to deaf (audio) or blind (video) individuals. Accessibility of emerging technologies is always an issue that I try to deal with early on in the process of rolling it out. Being at a diverse university, and it is highly important that all that my team does be usable and accessible. We set up a usability testing lab last year and incorporated accessibility testing equipment/software as well. We run our web sites and applications through rigorous testing, but what to do with podcasts?

There are a couple ways to go about making your podcasts more accessible. Podcast transcription services and closed captioning services are available. Podcasting accessibility not only opens up your podcast to individuals with disabilities, it allows consumers who like to receive their information in a different media type the opportunity to do so. I’m not saying that accessibility for the disabled is not a good enough reason to do some of the things I’m going to mention, but there are many other benefits that you have to consider.

Since this issue is so large, I’m going to dedicate this week to discussing it with you. If you have any questions surrounding the accessibility of podcasts, be it this week or in the future, email them to me. I’ll try to answer all the questions that I’ve received so far, as well as give you a run down of the services out there with my recommendations. I also will focus on a day on building your own transcription studio.”

Read the full article at Jeffery Daniel Frey’s personal blog and make your pod casts accessible today!

Debates on the XML-DEV and XSL mailing lists over the last two weeks concern the futures of XSLT, XPath, and, the latest addition to the W3C XML toolkit, XML Query. There are no signs of these debates ending this week. Discussion on XML-DEV about the design of XML Query rages on.

Reinventing the Wheel

The focus of last week’s XML-Deviant was the concern expressed by several XML-DEV contributors that the interdependence of several W3C specifications may have exceeded the dictates of software reuse and become instead a tangled mess. Suggestions were floated for a refactoring of several standards in order to separate the component parts.

This debate has focused on XML Query in particular this week, following Evan Lenz’s claim that the overlap between XML Query and XSLT is so great that they are not really separate languages.

After reviewing the XQuery spec, I’m concluding that the overlap between XQuery and XSLT is far too great for the W3C to reasonably recommend them both as separate languages. If XSLT (or XSLT 2.0) isn’t considered adequate as an XML query language by itself, then the development of an XML query language should still build from the same semantic and syntactic base as XSLT.

Lenz has fully documented his opinion in a paper he’ll be presenting at the XSLT-UK conference in April. The most obvious overlap between XML Query and XSLT is their shared use of XPath. Indeed, the XML Query and XSLT Working Groups are coordinating on the development of XPath 2.0. XPointer took a similar approach, layering itself on XPath 1.0. At first glance this seems a reasonable approach.

However, Lenz believes that the overlappings go deeper than sharing XPath.

The “navigation part” is only a small part of the overlap. The result construction mechanisms, the flow control mechanisms, the variable binding mechanisms — these are all virtually indistinguishable (other than syntax) from XSLT’s mechanisms for doing the same. I demonstrate all of this in my paper.

The introduction of datatypes is making its way not only into XQuery but the XPath 2.0 and XSLT 2.0 requirements. Regardless of whether datatypes are only part of query or are part of both query and transformations, there should be a common semantic and syntactic core for XSLT and XQuery, rather than an invention of an entirely new syntax.

Lenz characterized XML Query as a subset of XSLT (no template rules, no abbreviated XPath axes) with the addition of data typing, and he claimed that this should be the model upon which XML Query is developed. Noting concerns over the optimizability of XSLT, Lenz pointed out that the XSLT 2.0 requirements refer to an XPath subset that could be used to develop XML Query.

Read full story at XML.com http://www.xml.com/pub/a/2001/02/28/deviant.html

The accesskey attribute sounds like a great idea at first. Being able to attach a keyboard shortcut to elements in an HTML document allows users to quickly jump to different parts of the page or trigger functionality without having to use a mouse.

The problem, as has been stated by Derek Featherstone in More reasons why we don’t use accesskeys, John Foliot in Using Accesskeys - Is it worth it?, and Jukka Korpela in Using accesskey attribute in HTML forms and links, to name a few, is that most current web browsers do not prevent shortcuts assigned through an accesskey attribute from clashing with existing keyboard shortcuts specified by the browser or operating system. Even if they did do that, there would still be issues with internationalisation and key availability.

Because of this, I rarely use the accesskey attribute. In fact, I am considering not using it at all. Looking forward (way forward), the accesskey attribute is not included in current drafts of XHTML 2, since it has been replaced by the access element. Unfortunately it looks like the access element will suffer from the same problems as the accesskey attribute.

John Foliot explains why in ACCESS + KEY still = ACCESSKEY - The XHTML Role Access Module still flawed, an open letter to the draft editors of XHTML 2. Ian Lloyd at Accessify agrees and points to a system that lets users specify their own shortcut keys in The Trouble With Accesskeys.

Source: 456 Bereastreet