W3C Team blogThis week: W3C MultilingualWeb Workshop Program, HTML5 outline algorithm, IAB joins W3C, etc.

This is the 11-18 April 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media. The next edition will be issued on Friday 9 May.

W3C and HTML5 related Twitter trends

Nothing stood out particularly this week; I noted a few mentions of:

Open Web & net neutrality

n/a

W3C in the Press (or blogs)

7 articles this week. Read more and find keywords on our Press clippings.

Planet MozillaWeb Components and you – dangers to avoid

Lego
Legos by C Slack

Web Components are a hot topic now. Creating widgets on the web that are part of the browser’s rendering flow is amazing. So is inheriting from and enhancing existing ones. Don’t like how a SELECT looks or works? Get it and override what you don’t like. With the web consumed on mobile devices performance is the main goal. Anything we can do to save on battery consumption and to keep interfaces responsive without being sluggish is a good thing to do.

Web Components are a natural evolution of HTML. HTML is too basic to allow us to create App interfaces. When we defined HTML5 we missed the opportunity to create semantic widgets existing in other UI libraries. Instead of looking at the class names people used in HTML, it might have been more prudent to look at what other RIA environments did. We limited the scope of new elements to what people already hacked together using JS and the DOM. Instead we should have aimed for parity with richer environments or desktop apps. But hey, hindsight is easy.

What I am more worried about right now is that there is a high chance that we could mess up Web Components. It is important for every web developer to speak up now and talk to the people who build browsers. We need to make this happen in a way our end users benefit from Web Components the best. We need to ensure that we focus our excitement on the long-term goal of Web Components. Not on how to use them right now when the platforms they run on aren’t quite ready yet.

What are the chances to mess up? There are a few. From what I gathered at several events and from various talks I see the following dangers:

  • One browser solutions
  • Dependency on filler libraries
  • Creating inaccessible solutions
  • Hiding complex and inadequate solutions behind an element
  • Repeating the “just another plugin doing $x” mistakes

One browser solutions

This should be pretty obvious: things that only work in one browser are only good for that browser. They can only be used when this browser is the only one available in that environment. There is nothing wrong with pursuing this as a tech company. Apple shows that when you control the software and the environment you can create superb products people love. It is, however, a loss for the web as a whole as we just can not force people to have a certain browser or environment. This is against the whole concept of the web. Luckily enough, different browsers support Web Components (granted at various levels of support). We should be diligent about asking for this to go on and go further. We need this, and a great concept like Web Components shouldn’t be reliant on one company supporting them. A lot of other web innovation that heralded as a great solution for everything went away quickly when only one browser supported it. Shared technology is safer technology. Whilst it is true that more people having a stake in something makes it harder to deliver, it also means more eyeballs to predict issues. Overall, sharing efforts prevents an open technology to be a vehicle for a certain product.

Dependency on filler libraries

A few years ago we had a great and – at the same time – terrible idea: let’s fix the problems in browsers with JavaScript. Let’s fix the weirdness of the DOM by creating libraries like jQuery, prototype, mootools and others. Let’s fix layout quirks with CSS libraries. Let’s extend the functionality of CSS with preprocessors. Let’s simulate functionality of modern browsers in older browsers with polyfills.

All these aim at a simple goal: gloss over the differences in browsers and allow people to use future technologies right now. This is on the one hand a great concept: it empowers new developers to do things without having to worry about browser issues. It also allows any developer to play with up and coming technology before its release date. This means we can learn from developers what they want and need by monitoring how they implement interfaces.

But we seem to forget that these solutions were build to be stop-gaps and we become reliant on them. Developers don’t want to go back to a standard interface of DOM interaction once they got used to $(). What people don’t use, browser makers can cross off their already full schedules. That’s why a lot of standard proposals and even basic HTML5 features are missing in them. Why put effort into something developers don’t use? We fall into the trap of “this works now, we have this”, which fails to help us once performance becomes an issue. Many jQuery solutions on the desktop fail to perform well on mobile devices. Not because of jQuery itself, but because of how we used it.

Which leads me to Web Components solutions like X-Tags, Polymer and Brick. These are great as they make Web Components available right now and across various browsers. Using them gives us a glimpse of how amazing the future for us is. We need to ensure that we don’t become dependent on them. Instead we need to keep our eye on moving on with implementing the core functionality in browsers. Libraries are tools to get things done now. We should allow them to become redundant.

For now, these frameworks are small, nimble and perform well. That can change as all software tends to grow over time. In an environment strapped for resources like a $25 smartphone or embedded systems in a TV set every byte is a prisoner. Any code that is there to support IE8 is nothing but dead weight.

Creating inaccessible solutions

Let’s face facts: the average web developer is more confused about accessibility than excited by it. There are many reasons for this, none of which worth bringing up here. The fact remains that an inaccessible interface doesn’t help anyone. We tout Flash as being evil as it blocks out people. Yet we build widgets that are not keyboard accessible. We fail to provide proper labeling. We make things too hard to use and expect the steady hand of a brain surgeon as we create tight interaction boundaries. Luckily enough, there is a new excitement about accessibility and Web Components. We have the chance to do something new and do it right this time. This means we should communicate with people of different ability and experts in the field. Let’s not just convert our jQuery plugins to Web Components in verbatim. Let’s start fresh.

Hiding complex and inadequate solutions behind an element

In essence, Web Components allow you to write custom elements that do a lot more than HTML allows you to do now. This is great, as it makes HTML extensible (and not in the weird XHTML2 way). It can also be dangerous, as it is simple to hide a lot of inefficient code in a component, much like any abstraction does. Just because we can make everything into an element now, doesn’t mean we should. What goes into a component should be exceptional code. It should perform exceptionally well and have the least dependencies. Let’s not create lots of great looking components full of great features that under the hood are slow and hard to maintain. Just because you can’t see it doesn’t mean the rules don’t apply.

Repeating the “just another plugin doing $x” mistake

You can create your own carousel using Web Components. That doesn’t mean though that you have to. Chances are that someone already built one and the inheritance model of Web Components allows you to re-use this work. Just take it and tweak it to your personal needs. If you look for jQuery plugins that are image carousels right now you better bring some time. There are a lot out there – in various states of support and maintenance. It is simple to write one, but hard to maintain.

Writing a good widget is much harder than it looks. Let’s not create a lot of components because we can. Instead let’s pool our research and findings and build a few that do the job and override features as needed. Core components will have to change over time to cater for different environmental needs. That can only happen when we have a set of them, tested, proven and well architected.

Summary

I am super excited about this and I can see a bright future for the web ahead. This involves all of us and I would love Flex developers to take a look at what we do here and bring their experience in. We need a rich web, and I don’t see creating DOM based widgets to be the solution for that for much longer with the diversity of devices ahead.

Steve Faulkner et alSome stuff that doesn’t work between the DOM and Shadow DOM

Been reading a few new articles on Web Components and accessibility, which lead me to re-read an old post I wrote: Notes on Web Components + ARIA. I noted the demo was broken, presumably as the web component syntax had changed since 2012. So I decided to make a few new tests:

What I found was that anything that relies upon an id association between content in the DOM and Shadow DOM breaks (note need to run latest Chrome or Firefox Nightly ,with web components flag enabled, to test):

Some HTML examples:

Most ARIA relationship attributes:

will this be fixed?

Discussion is occurring in regards to the ARIA issues – ARIA relationships via selector

Further reading

The post Some stuff that doesn’t work between the DOM and Shadow DOM appeared first on The Paciello Group Blog.

Planet MozillaBrowser inconsistencies: animated GIF and drawImage()

I just got asked why Firefox doesn’t do the same thing as Chrome does when you copy a GIF into a canvas element using drawImage(). The short answer is: Chrome’s behaviour is not according to the spec. Chrome copies the currently visible frame of the GIF whereas Firefox copies the first frame. The latter is consistent with the spec.

You can see the behaviour at this demo page:
animated GIF on canvas

Here’s the bug on Firefox and the bug request in Webkit to make it consistent thanks to Peter Kasting there is also a bug filed for Blink.

The only way to make this work across browsers seems to be to convert the GIF into its frames and play them in a canvas, much like jsGIF does.

Steve Faulkner et alShort note on alt in HTML

It is no longer a WCAG 2.0 conformance failure to have an <img> without an alt attribute, as long as the img element has an accessible name provided using another method such as aria-label.

It is still a conformance error in HTML  to have an <img> without an alt attribute (unless the img has a caption provided using the figure and figcaption elements)

Why are there now divergent requirements?

The HTML conformance requirement takes into account the accessibility and usability needs of users:

4.7.1.1.1 Examples of scenarios where users benefit from text alternatives for images

  • They have a very slow connection and are browsing with images disabled.
  • They have a vision impairment and use text to speech software.
  • They have a cognitive impairment and use text to speech software.
  • They are using a text-only browser.
  • They are listening to the page being read out by a voice Web browser.
  • They have images disabled to save on download costs.
  • They have problems loading images or the source of an image is wrong.

Further reading:

 

The post Short note on alt in HTML appeared first on The Paciello Group Blog.

W3C Team blogThis week: #web25 anniversary at #www2014, Real Work Modes of HTML WG, EU Data Retention Directive invalid, etc.

This is the 4-11 April 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

Nothing stood out particularly this week; I noted a few mentions of:

Open Web & net rights

W3C in the Press (or blogs)

5 articles this week. Read more and find keywords on our Press clippings.

Planet MozillaOn Windows XP and IE6

On Tuesday, Microsoft announced the end of support for Windows XP. For web developers, this meant much rejoicing as we are finally rid of the yoke that is Internet Explorer 6 and can now use all the cool things HTML5, CSS3 and other tech has to offer. Right? Maybe.

xp

When I started web development my first real day-to-day browser was IE4 and then Netscape Navigator Gold moving on to Netscape Communicator 4. I saw the changes of IE5, 5.5 and finally IE6. I was pretty blown away by the abilities IE6 had. You had filters, page transitions, rotation, blurring, animation using marquee and even full-screen applications using the .hta extension. In these applications you had full JScript access to the system, you can read and write files, traverse folders and much more. Small detail: so had attackers as the security model wasn’t the best, but hey, details…

None of this was a standard, and none of it got taken on by other browsers. That probably wasn’t possible as features of browsers were the main differentiator and companies protected their USPs.

IE was never and will never be just a browser: it is an integral part of the operating system itself. For better or worse, Microsoft chose to make the web consumption tool also the file browsing and document display tool. Many of the very – at that time – futuristic features of IE6 were in there as they were needed for Powerpoint-style presentations.

That’s why the end of XP is a light at the end of the tunnel for all those suffering the curse that is IE6. Many users just didn’t bother upgrading their browser as what the OS came with was good enough.

A cracker’s paradise

Of course we now have a security problem: not all XP installs will be replaced and the lack of security patches will result in many a hacked server. Which is scary seeing that many ATMs run on XP and lots of government computers (the UK government alone spent 5.5m GBP on getting extended support for XP as moving on seems to be hard to do with that many machines and that much red tape). XP and IE6 weren’t a nuisance for web developers – they are a real threat to internet security and people’s online identity for a long time now.

The fast innovator in a closed environment dilemma

You can say what you want about IE6 - and it has been a running joke for a long time – having it and having it as the nemesis of web standards based browsers (Opera, Netscape6 and subsequently Firefox) taught us a lot. Having a browser that dared to dabble with applications in HTML years before the W3C widget spec or Adobe Air was interesting. Having a browser in the operating system that naturally was the first thing people clicked to go online helped the internet’s popularity. It didn’t help the internet as a whole though.

The big issue of course was that people didn’t upgrade and the OS didn’t force-upgrade the browser. This meant that companies had a fixed goal to train people on: if it works in IE6, it is good enough for us. That’s why we have hundreds of large systems that only work in IE. Many of those are enterprise systems: CRM, Asset management, Ticketing, CMS, Document management – all these fun things with lots of menus and trees and forms with lots of rules.

Nobody likes using these things. People don’t care for them, they just see them as a necessary thing to do their job and something created by magical hairy pixies called the IT department. When you don’t like something but need to use it any change in it is scary, which is why a lot of attempts to replace these systems with more user-friendly and cross-platform systems is met with murmurings or open revolt. I call this the Stockholm syndrome of interfaces: I suffered it for years, so I must like it, right? All the other stuff means more work.

Back to the browser thing though: The issue wasn’t IE6, the issues were its ubiquity, an audience that wasn’t quite web savvy yet and didn’t crave choice but instead used what was there, and Microsoft’s tooling centering around creating amazing things for IE first and foremost and maybe a fallback for other browsers. The tools locked into IE6 were most of the time not created by web developers, but by developers of .NET, classic ASP, Sharepoint and many other – great – tools for the job at hand. Everything seemed easy, the tools seemed far superior to those that cover several targets and when you stayed inside the ecosystem, things were a breeze. You didn’t even have to innovate yourself – you just waited until the platform added the next amazing feature as part of the build process (this even happened at awesome events that only cost your employer and means you can get an awesome T-Shirt to boot). Sound eerily familiar to what’s happening now in closed platforms and abstracted developer tools, doesn’t it? Look – it’s the future, now – if you use platform x or browser y.

What should we take away from this?

Which brings me to the learning we should take away from these years of building things for a doomed environment: browsers change, operating systems change, form factors change. What we think is state-of-the-art and the most amazing thing right now will be laughable at best or destructive to innovation at worst just a year ahead.

And it is not Microsoft’s fault alone. Microsoft have seen the folly of their ways (OK, with some lawsuits as extra encouragement) and did a great job telling people to upgrade their systems and stop targeting OldIE. They understand that not every developer uses Windows and made testing with virtualisation much easier. They are also much more open in their messaging about what standards new IE supports. If they understand this, we should, too.

Here are the points we should keep in our heads:

  • Bolting a browser into an operating system makes it harder to upgrade it – you see this now in Android stock browsers or iOS. Many of the amazing features of HTML5 need to be poly-filled, not for old IE, but for relatively new browsers that will not get upgraded because the OS can’t get updated (at times on hardware that was $500 just a few months ago)
  • Building software for the current state of the browser is dangerous – especially when you can’t trust the current state to even be stable. Many solutions relying on the webkit prefix functionality already look as silly as a “if (document.layers || document.all) {}” does.
  • Stop pretending you can tell end users what browser to use – this is sheer arrogance. Writing software means dealing with the unknown and preparing for it. Error handling is more important than the success case. Great UX is invisible – the thing just works. Bad error handling creates unhappy users and there is nothing more annoying than being on a pay-by-the-minute connection in a hotel to be told I need to use another browser or update mine. Stop pretending your work is so important people have to change for you if all you need to do is being more creative in your approach.

There are only a few of us unlucky enough to have to support IE6 in a pixel-perfect manner right now. The death of XP wasn’t the big liberation we really needed. And by all means it should not mean that you write web apps and web sites now that rely on bleeding edge technology in newer browsers without testing for it. This will never go away, and it shouldn’t. It makes us craftsmen, it keeps us on the ball. We need to think before we code, and – to me – that is never a bad idea.

The rules did not change:

  • HTML is king – it will display when everything else fails, it will perform amazingly well.
  • Progressive Enhancement means you write for now and for tomorrow – expect things to break, and plan for it, and you can never be surprised.
  • Browser stats are fool’s gold – who cares how many people in Northern America who have a certain statistics package installed use browser x or browser y. What do your end-users use? Optimise for form factors and interaction, not for browsers. These will always change.
  • Writing for one browser helps that one in the competition with others, but it hurts the web as a whole – we’re right now in a breakneck speed rat-race about browser innovation. This yields a lot of great data but doesn’t help developers if the innovations vanish a few versions later. We have jobs to do and projects to deliver. There is not much time to be guinea pigs
  • Real innovation happens when we enhance the platform – we need WebComponents in the browsers, we need WebRTC in browsers, we need a more stable Offline and Local Storage solution. What we don’t need is more polyfills as these tend to become liabilities.

So, RIP XP, thanks for all the hardship and confusion that made us analyse what we do and learn from mistakes. Let’s crack on with it and not build the next XP/IE6 scenario because we like our new shiny toys.

Steve Faulkner et alTPG Sessions and Speakers at CSUN 2014

Here’s a list of the TPG schedule of sessions, themes, and speakers during the 2014 CSUN Conference:

Tuesday: Pre-Conference Workshop

  • Time: 1:30 PM
  • Workshop Title: Implementing ARIA and HTML5 into Modern Web Applications (Part Two)
  • Speakers; Hans Hillen, Steve Faulkner, Billy Gregory, Karl Groves

Wednesday Sessions

  • Time: 9:20 AM
  • Session Theme: Things I Wish I Knew When I Started Working in Digital Accessibility
  • Speaker: Billy Gregory
  • Room Location: Gaslamp A, 2nd Floor Seaport Tower

Thursday Sessions

  • Time:  3:10 PM
  • Session Theme: Oh, Canada? An Overview of Accessibility in the Great White North
  • Speaker: Billy Gregory (with Denis Boudreau Patrick Dunphy
  • Room Location: Gaslamp A, 2nd Floor Seaport Tower
  • Time: 3:10 PM
  • Session Theme: Roadmap For Making WordPress Accessible
  • Speaker: Karl Groves
  • Room Location: Balboa B 2nd Floor Seaport Tower
  • Time: 3:10 PM
  • Session Theme: Adapting to New Trends: Section 508 Refresh, HTML 5 and Mobile
  • Speaker: Charlie Pike (with Sarita of CA Technologies)
  • Room Location: Cortez Hill B 3rd Floor Seaport Tower
  • Time: 4:20 PM
  • Session Theme: Lessons Learned: Accessibility Theory vs. Implementation Reality
  • Speaker: Hans Hillen (w/ Jennifer Gauvreau of CGI Federal)
  • Room Location: Gaslamp A 2nd Floor Seaport Tower

Friday Sessions

  • Time: 9:20 AM
  • Session Theme:  Crowdsourcing The Accessibility Awareness Problem
  • Speaker:     Billy Gregory
  • Room Location: Mission Beach AB 3rd Floor Harbor Tower
  • Time: 10:40 AM
  • Session Theme: How to Win the Accessibility 3-Legged Race
  • Speaker: Billy Gregory
  • Room Location: Balboa B 2nd Floor Seaport Tower
  • Time: 1:50 PM
  • Session Theme: No Beard Required. Mobile Testing With the Viking & the Lumberjack
  • Speakers: Billy Gregory, Karl Groves
  • Room Location: Balboa A 2nd Floor Seaport Tower

The post TPG Sessions and Speakers at CSUN 2014 appeared first on The Paciello Group Blog.

Steve Faulkner et alUsability and accessibility opportunities in a web component world

A discussion on the WHATWG list about the limitations/issues with the current design of the summary and details elements, brought forth the following comment:

[me: ] in the absence of browser making “clicks on (non-interactive) parts of the summary defer to the disclosure triangle.” how is  an author supposed to do this?

[hixie:] The author isn’t supposed to do this. The whole point of semantic controls like this [details/summary] is that the user agent is the one that picks the user interface.

Once we start talking about custom widgets, we’re in the space of Web components, at which point the author can do whatever the author wants. [emphasis mine]

source: http://lists.w3.org/Archives/Public/www-archive/2014Apr/0012.html

Don’t fear – embrace

Which got me to thinking that we should be embracing web components as an opportunity to improve the usability and accessibility of native HTML controls and content. It’s a little sad that the way to fix accessibility and usability in a native UI is to create a custom UI, rather than ensuring by design of the HTML feature that usability and accessibility are built in, but if it is to be, lets embrace it.

A simple demo

To this end, I have made a simple demo using the flipbox web component, to illustrate use of a web component to provide easy display of rich text alternatives for images using a natty interaction pattern:
Default state with images displayed.
Rich text alternatives displayed after pressing flip button.

The post Usability and accessibility opportunities in a web component world appeared first on The Paciello Group Blog.

Planet Mozillawebpd: a Polymer-based web UI for the beets music library manager

beets webpd filtered artists list

beets is the extensible music database tool every programmer with a music collection has dreamed of writing.  At its simplest it’s a clever tagger that can normalize your music against the MusicBrainz database and then store the results in a searchable SQLite database.  But with plugins it can fetch album art, use the Discogs music database for tagging too, calculate ReplayGain values for all your music, integrate meta-data from The Echo Nest, etc.  It even has a Music Player Daemon server-mode (bpd) and a simple HTML interface (web) that lets you search for tracks and play them in your browse using the HTML5 audio tag.

I’ve tried a lot of music players through the years (alphabetically: amarok, banshee, exaile, quodlibetrhythmbox).  They all are great music players and (at least!) satisfy the traditional Artist/Album/Track hierarchy use-case, but when you exceed 20,000 tracks and you have a lot of compilation cd’s, that frequently ends up not being enough. Extending them usually turned out to be too hard / not fun enough, although sometimes it was just a question of time and seeking greener pastures.

But enough context; if you’re reading my blog you probably are on board with the web platform being the greatest platform ever.  The notable bits of the implementation are:

  • Server-wise, it’s a mash-up of beets’ MPD-alike plugin bpd and its web plugin.  Rather than needing to speak the MPD protocol over TCP to get your server to play music, you can just hit it with an HTTP POST and it will enqueue and play the song.  Server-sent events/EventSource are used to let the web UI hypothetically update as things happen on the server.  Right now the client can indeed tell the server to play a song and hear an update via the EventSource channel, but there’s almost certainly a resource leak on the server-side and there’s a lot more web/bpd interlinking required to get it reliable.  (Python’s Flask is neat, but I’m not yet clear on how to properly manage the life-cycle of a long-lived request that only dies when the connection dies since I’m seeing the appcontext get torn down even before the generator starts running.)
  • The client is implemented in Polymer on top of some simple backbone.js collections that build on the existing logic from the beets web plugin.
    • The artist list uses the polymer-virtual-list element which is important if you’re going to be scrolling through a ton of artists.  The implementation is page-based; you tell it how many pages you want and how many items are on each page.  As you scroll it fires events that compel you to generate the appropriate page.  It’s an interesting implementation:
      • Pages are allowed to be variable height and therefore their contents are too, although a fixedHeight mode is also supported.
      • In variable-height mode, scroll offsets are translated to page positions by guessing the page based on the height of the first page and then walking up/down from there based on cached page-sizes until the right page size is found.  If there is missing information because the user managed to trigger a huge jump, extrapolation is performed based on the average item size from the first page.
      • Any changes to the contents of the list regrettably require discarding all existing pages/bindings.  At this time there is no way to indicate a splice at a certain point that should simply result in a displacement of the existing items.
    • Albums are loaded in batches from the server and artists dynamically derived from them.  Although this would allow for the UI to update as things are retrieved, the virtual-list invalidation issue concerned me enough to have the artist-list defer initialization until all albums are loaded.  On my machine a couple thousand albums load pretty quickly, so this isn’t a huge deal.
    • There’s filtering by artist name and number of albums in the database by that artist built on backbone-filtered-collection.  The latter one is important to me because scrolling through hundreds of artists where I might only own one cd or not even one whole cd is annoying.  (Although the latter is somewhat addressed currently by only using the albumartist for the artist generation so various artists compilations don’t clutter things up.)
    • If you click on an artist it plays the first track (numerically) from the first album (alphabetically) associated with the artist.  This does limit the songs you can listen to somewhat…
    • visualizations are done using d3.js; one svg per visualization

beets webpd madonna and morrissey

“What’s with all those tastefully chosen colors?” is what you are probably asking yourself.  The answer?  Two things!

  1. A visualization of albums/releases in the database by time, heat-map style.
    • We bin all of the albums that beets knows about by year.  In this case we assume that 1980 is the first interesting year and so put 1979 and everything before it (including albums without a year) in the very first bin on the left.  The current year is the rightmost bucket.
    • We vertically divide the albums into “albums” (red), “singles” (green), and “compilations” (blue).  This is accomplished by taking the MusicBrainz Release Group / Types and mapping them down to our smaller space.
    • The more albums in a bin, the stronger the color.
  2. A scatter-plot using the echo nest‘s acoustic attributes for the tracks where:
    • the x-axis is “danceability”.  Things to the left are less danceable.  Things to the right are more danceable.
    • the y-axis is “valence” which they define as “the musical positiveness conveyed by a track”.  Things near the top are sadder, things near the bottom are happier.
    • the colors are based on the type of album the track is from.  The idea was that singles tend to have remixes on them, so it’s interesting if we always see a big cluster of green remixes to the right.
    • tracks without the relevant data all end up in the upper-left corner.  There are a lot of these.  The echo nest is extremely generous in allowing non-commercial use of their API, but they limit you to 20 requests per minute and at this point the beets echonest plugin needs to upload (transcoded) versions of all my tracks since my music collection is apparently more esoteric than what the servers already have fingerprints for.

Together these visualizations let us infer:

  • Madonna is more dancey than Morrissey!  Shocking, right?
  • I bought the Morrissey singles box sets. And I got ripped off because there’s a distinct lack of green dots over on the right side.

Code is currently in the webpd branch of my beets fork although I should probably try and split it out into a separate repo.  You need to enable the webpd plugin like you would any other plugin for it to work.  There’s still a lot lot lot more work to be done for it to be usable, but I think it’s neat already.  It definitely works in Firefox and Chrome.

W3C Team blogThis week: W3C Annotations Workshop, WebRTC Summit, Net Neutrality in Europe, etc.

This is the 28 March – 4 April 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

Nothing stood out particularly this week; I noted a few mentions of:

Net Neutrality & Open Web

W3C in the Press (or blogs)

6 articles this week. A selection follows. Read more and find keywords on our Press clippings.

Planet MozillaHTML5 sur les stéroïdes à HTML5mtl

Creative Commons: http://j.mp/1mD8erV

Creative Commons: http://j.mp/1mD8erV

C’est avec un immense plaisir que je présenterais pour la troisième fois au groupe d’utilisateurs HTML5mtl le 22 avril prochain. Disons que j’ai une petite faiblesse pour ce groupe consacré à HTML pour la grande région de Montréal: j’en suis l’un des fondateurs avec Mathieu Chartier et Benoît Piette. Lors de cette soirée, je parlerais de Firefox OS, mon sujet de prédilection, mais aussi mon principal focus en tant qu’évangéliste chez Mozilla. Pour moi, Firefox OS, c’est HTML5 sur les stéroïdes: c’est un avancé d’HTML incluant les WebAPI qui nous permettent enfin de rivaliser avec les applications natives. Voici donc le résumé de ma présentation:

HTML5 est un pas de géant dans la bonne direction: il apporte plusieurs fonctionnalités dont les développeurs avaient besoin pour créer plus facilement de meilleures expériences web. Il a aussi fait naitre un débat sans fin: applications natives ou applications web! Lors de cette présentation, Frédéric Harper vous montrera comment le web ouvert peut vous aider à créer des applications mobiles de qualités. Vous en apprendrez plus sur des technologies telles que les WebAPIs, ainsi que les outils qui vous permettront de viser un nouveau marché avec Firefox OS et le web d’aujourd’hui.

C’est d’autant plus un plaisir pour moi que de me joindre au groupe ce mois-ci, car j’affectionne particulièrement ma ville où je ne présente plus assez. Pas que je me plaigne des pays où je partage ma passion avec d’autres développeurs, mais c’est plaisant de pouvoir le faire en français et d’avoir l’opportunité de réseauter avec des gens de chez nous. C’est donc un rendez-vous, le 22 avril prochain à 18:30 (ouverture des portes à 18:00 – si vous arrivez en retard, je vais vous faire chanter!) au bureau de Microsoft Montréal, que je remercie, situé au 2000 McGill College suite 450. Réservez votre place rapidement! Au plaisir de vous voir au HTML5mtl.


--
HTML5 sur les stéroïdes à HTML5mtl is a post on Out of Comfort Zone from Frédéric Harper

IEBlogStay up to date with Enterprise Mode for Internet Explorer 11

Microsoft is taking an important step towards helping businesses stay up to date with the latest software, services, and devices. Enterprise Mode for Internet Explorer 11, announced today as an update for Windows 7 and Windows 8.1, provides better compatibility for older versions of Internet Explorer and tools to manage which Web apps use it.

Businesses can benefit from the modern web standards, better performance, and increased security of our latest browser, while extending existing investments in legacy web apps.  And by decreasing dependencies on older versions, Internet Explorer is helping customers stay up-to-date with Windows 8.1, services like Office 365, and devices like the Surface Pro 2.

Businesses can benefit from the modern Web standards, better performance, and increased security of our latest browser, while extending existing investments in legacy Web apps. And by decreasing dependencies on older versions, Internet Explorer is helping customers stay up-to-date with Windows 8.1, services like Office 365, and devices like the Surface Pro 2.

How does Enterprise Mode help you stay up-to-date?

Many businesses are experiencing tension between today’s Web apps and services—which may require modern standards like HTML5 and CSS3—and older Web apps and services, designed for older versions of Internet Explorer. Legacy apps often represent a significant investment and have long, multi-year lifecycles, effectively making these customers dependent on an older version of Internet Explorer until they can upgrade these Web apps to modern Web standards.

Introduced in 2009, Internet Explorer 8 was the first browser available on Windows 7 and included innovative features like Compatibility View for older Web sites. Because it also ran on Windows XP, many customers and developers chose to standardize on Internet Explorer 8 to help ease the migration to Windows 7. According to Net Applications, Internet Explorer 8 still has more than 20% of the desktop browser market share; despite the fact that IE9, IE10, and IE11 have superseded IE8, many customers still rely on Internet Explorer 8 to run their business.

By providing better backward compatibility for Internet Explorer 8, Internet Explorer 11 with Enterprise Mode is intended to help break this dependency and provide the best of both worlds: A modern, up-to-date browser that helps customers extend their existing investments in older Web apps.

How does Enterprise Mode provide better compatibility?

In designing Enterprise Mode for Internet Explorer 11, engineering reviewed compatibility problems reported by customers and found clusters of similar issues. Some of the areas targeted by Enterprise Mode include:

  • User agent string differences. Many legacy Web apps use browser detection, not today’s best practice of feature detection. By replicating the original Internet Explorer 8 user agent string, Enterprise Mode works for sites that fail if they can’t recognize IE8 as the browser.
  • ActiveX controls and other binaries. Some ActiveX controls silently fail if they query the browser version and get a response they don’t expect, so Enterprise Mode appeases these by mimicking IE8’s responses. In testing, customers report that many of these ActiveX controls “just work” in Enterprise Mode.
  • Deprecated functionality. Internet Explorer 8 still contained some vestiges of proprietary functionality, such as CSS Expressions which was used to place objects dynamically on a page. This functionality was removed in later versions of Internet Explorer, but some legacy Web apps used this to place buttons and other elements. Enterprise Mode brings back some deprecated features, including CSS Expressions.

Before and after with Enterprise Mode IE
A Web app works properly when viewed in Internet Explorer 11 with Enterprise Mode on the right. Note the Enterprise Mode icon, circled in the address bar.

  • Pre-caching and pre-rendering. Many modern browsers like Internet Explorer 11 pre-cache and pre-render pages, to make browsing more fluid. When you click on a pre-cached link, one tab disappears while the pre-rendered content tab appears in its place. To a legacy navigation controls, this behavior is confusing—so Enterprise Mode turns it off.

When Internet Explorer 11 renders a page in Enterprise Mode, numerous configuration and code changes eliminate common compatibility issues in these and other areas. Also, by targeting Internet Explorer 8—and IE8’s Compatibility View—Enterprise Mode also provides some benefit for sites designed for even older versions, such as Internet Explorer 7. This is emulation, not virtualization; Enterprise Mode provides a better emulation of IE8 within IE11, while avoiding many performance, security, and other problems associated with running older Internet Explorer 8 binaries.

Speaking of performance, we’ve made a lot of browser improvements in the last five years; Internet Explorer 11 is dramatically faster than Internet Explorer 8. Web apps load twice as fast, and Enterprise Mode takes advantage of network improvements, redesigned script and layout engines, and hardware-accelerated graphics. While we believe that real-world performance matters when evaluating a browser, the JavaScript benchmark results below highlight the significant difference between Internet Explorer 11 with Enterprise Mode and the original Internet Explorer 8. Try it with your own apps, and see for yourself.

JavaScript performance in enterprise mode is slightly slower than IE11 but still much faster than IE8.

Enterprise Mode for Internet Explorer 11 may not fix all compatibility problems, but does work for many of the most common issues. Most importantly, this is an area of continued investment for Microsoft and is a significant step towards helping customers stay up-to-date with the latest version of Internet Explorer.

How is Enterprise Mode managed?

Enterprise Mode for Internet Explorer 11 is turned off by default. When configured with a list of legacy Web apps, IE11 will switch in and out of Enterprise Mode dynamically as users surf the Web. Internet Explorer provides a seamless browsing experience, so users don’t have to worry about which browser to use for which sites.

Corporate IT controls which sites and paths are rendered in Enterprise Mode via a centrally-managed XML list or group of lists. For example, www.contoso.com/travel can be set to use Enterprise Mode, while www.contoso.com/erp may be set to use modern “Edge” standards mode. A new Enterprise Mode Site List Manager tool is available for managing lists, as shown below.

Enterprise Mode IE site list manager
Enterprise Mode Site List Manager, showing CRM and ERP systems with new (Default) and legacy (Enterprise) paths.

Two registry keys, which can be set via new Group Policies, enable/disable Enterprise Mode and provide a local link or URL path to the XML list. Different divisions or locations, for example, can be configured to use different lists.

  • Registry Key
  • Function

[HKEY_LOCAL_MACHINE\SOFTWARE\ Policies\Microsoft\Internet Explorer\Main\EnterpriseMode] “Enable” = “” | {URL:port}

  • This setting lets you decide whether users can turn on Enterprise Mode for Web sites with compatibility issues. Optionally, this policy also lets you specify where to get reports (through POST messages) whenever a user turns on or off Enterprise Mode.

[HKEY_LOCAL_MACHINE\SOFTWARE\ Policies\Microsoft\Internet Explorer\Main\EnterpriseMode]

“SiteList” = {File or URL}

  • This setting lets you specify where to find the list of Web sites you want opened using Enterprise Mode. This list can be maintained using the new Enterprise Mode Site List Manager tool.

Registry location showing enterprise mode configuration.
Registry keys for enabling Enterprise Mode and pointing to the managed site list.

When enabled, a tool menu option enables end-users to force a page into Enterprise Mode. This can be made available to all users, or select users for testing purposes. This same registry key can be used to collect manual overrides. By configuring the “Enable” key with a valid URL and port, Internet Explorer will initiate a simple POST to the supplied address whenever a user enables or disables Enterprise Mode. This effectively helps customers crowd-source lists of compatible Web apps from their own users, which may decrease triage and testing costs.

To learn more about Enterprise Mode

To learn more about Enterprise Mode for Internet Explorer 11, visit the Internet Explorer TechNet site and view the Build session, Better App Compat with Enterprise Mode for Internet Explorer 11.

Documentation and Other Resources

Enterprise Mode Site List Manager

Windows 7 and Windows Server 2008 R2

Windows 8.1 and Windows Server 2012 R2

Internet Explorer 11 provides increased performance, improved security, and support for the modern technologies like HTML5 and CSS3 that power today’s Web sites and services. By adding better backward compatibility with Enterprise Mode, Internet Explorer 11 now helps customers stay up to date with the latest browser—and facilitates using the latest software, services, and devices.

— Kevin Miller, Program Manager Lead, Internet Explorer

— Fred Pullen, Product Marketing Manager, Internet Explorer

IEBlogAnnouncing an updated version of Internet Explorer 11 - available on Windows 8.1, Windows 7, and Windows Phone 8.1

Today we’re excited to announce an updated version of Internet Explorer 11 available with the Windows 8.1 Update and for our Windows 7 customers as well as the debut of Internet Explorer 11 for Windows Phone 8.1. The Windows 8.1 Update will be available for download today on MSDN and TechNet, with automatic updates beginning April 8th for both Windows 7 and Windows 8.1 customers. We are also launching two new experiences today – 22Tracks and FishGL – so you can explore what’s new with IE11 across Windows and Windows Phone.

We've heard that people browse the Web on many devices, switching between their laptop, tablet, and phone throughout the day. Today’s update to IE11 means that whatever device you pick-up, your tabs and favorites are there for you, right where you left off. Windows 8.1 and Windows Phone 8.1 share the same experience and underlying Web standards that help developers build interoperable sites and apps that just work across many browsers and devices. That includes updates to the latest specs for hardware-accelerated (and stable) WebGL as well as professional quality rich media like HTML5 video including closed captioning, adaptive streaming, and rights management.

Internet Explorer works seamlessly across phones, tablets and PCs
Internet Explorer 11 works seamlessly across phone, laptop, and small and large tablets

Introducing IE11 for Windows Phone 8.1

With Windows Phone 8.1 you now have access to the most modern and full-featured phone browser ever with IE11. In addition to the same underlying engine across device experiences, and roaming your favorites and tabs between devices, Windows Phone now offers many of the same features as the modern IE you experience on Windows. With IE11 for Windows Phone and Live Sites you can now pin your favorite sites directly to your Start Screen for information from the Web at a glance. Reading Mode helps you optimize the view of articles like you were reading a digital book on your phone. Voice Commands get you quickly to your favorite Web sites by speaking naturally to your device. IE11 for Windows Phone also includes InPrivate to keep your browsing private. And to help you better manage your phone’s data usage, the new High Savings Mode can be enabled to reduce data consumption by 60-80% through reducing image downloads and only loading elements of the page relevant to the content you want to view.

Updated IE11 for Windows 8.1

With today’s update, IE11 adapts your browsing experience by detecting your Windows device and input type – whether an 8 inch tablet in portrait mode or a 24 inch desktop with mouse and keyboard. The Web is still front-and-center but new design enhancements make your browsing experience feel like it was made just for your device – like the number of tabs on-screen and the size of the fonts and menus. You can also now control when the browser remains on-screen or hides away for full-screen browsing depending on the type of device you use.

Internet Explorer responds to the size of your device
Internet Explorer 11 adjusts responsively, adapting to your device

New enhancements to the F12 Developer Tools

IE11 comes with a completely redesigned and enhanced suite of in-browser developer tools that help developers build, diagnose, and optimize modern Web sites and apps. We heard from developers – you want shortcuts that are more common across the many tools you use and more flexibility to emulate various versions of IE. Today’s update includes enhancements to both of those requests as well as improved UI and Memory tools. The Debugger tools make it easier to identify, detect, and isolate code that is transcompiled, minified, or part of 3rd party libraries like jQuery.

A complete set of enhancements is available on MSDN here.

Enterprise Mode helps organizations progress toward modern browsers

Available for both Windows 8.1 and Windows 7, Enterprise Mode for Internet Explorer 11 provides improved Internet Explorer 8 compatibility for specified sites. Enabling enterprises to safely update to Internet Explorer 11 while maintaining great backwards compatibility for specific sites that were developed for Internet Explorer 8 or below. Organizations can designate that Enterprise Mode be enabled for specific sites so they can benefit from modern Web standards, better performance, and increased security of a modern Web browser, while reducing upgrade costs and extending legacy Web app investments. By improving backward compatibility for older versions of Internet Explorer, this also helps organization stay up-to-date with services such as Office 365 and deploy devices like the Surface Pro 2.

For IT professionals, you can learn more about the benefits of Enterprise Mode for Internet Explorer 11 from the IE engineering blog and the Internet Explorer TechNet page.

Enterprise Mode Internet Explorer

22tracks and FishGL: Fast, beautiful, and perfect for touch

In January, we invited developers and enthusiasts alike to help us rethink what’s possible on the Web. With today’s updates to IE11, we take another step toward that vision by releasing two new experiences. We remain committed to building an open and interoperable Web – while these experiences are perfect for touch-browsing, they work well in any modern browser.

22tracks: http://t.22tracks.com

We’ve teamed-up with the team at 22tracks to bring you a completely new touch-first music experience. 22tracks is all about finding new, emerging music – featuring top DJs from across Europe: Amsterdam, London, Paris, Brussels, and they are expanding. The site shows that with a single line of code, developers can create responsive sites that look great across many screen sizes, by automatically detecting the device you’re using and adjusting the experience accordingly. And with the power of WebGL, an interactive audio visualizer adapts to your music and responds to your touch – tap and hold, swipe, and drag as your listen and see what happens. The site also takes advantage of many features in Windows that make it feel like an app: you can pin your favorite tracks to the Windows Start Screen, share tracks using the Charm Bar, or save and listen to a track later using the Reading List app in Windows. A few more details about the folks at 22Tracks and their site are available on their blog.

22 Tracks web site
22tracks helps you find emerging music...across any device

FishGL: http://fishGL.com

WebGL and the 3D JavaScript library three.JS bring the browser to life in a way that no other technology can. And since Internet Explorer has a fun history with fish aquariums, we felt this update shouldn’t be any different. Enter FishGL – an interactive, touch-friendly 3D graphics benchmark. Rotate around the tank of colorful fish. Crank up the fish count, see how many your browser can run. While you are there tap the glass to scatter the fish or tap and hold for more one-on-one interaction. Swipe your finger across the screen to rotate the room or pinch to zoom. Use the control panel to toggle to fish view – insider the aquarium. Power users can adjust the aquarium physics too.

Fish GL web site
Can you find the light switch to the aquarium?

Looking Ahead

While we are excited about today's announcement we're even more excited about the future. As we begin working on the next generation of Internet Explorer for all of our devices we want to build a deeper partnership with users and Web developers. We want to hear more from you and starting today we are launching a beta site to help foster a two-way dialog between the IE team at Microsoft and the community. At status.modern.IE you can see what is supported in IE and standards we are evaluating for future versions. We’ll be listening to your feedback, via @IEDevChat, conferences and online forums, and we want to hear even more from the community about what you want to see in the next versions of IE.

status.modern.ie
status.modern.IE (beta) – At a glance information on what’s available in IE and across browsers, and what’s coming next!

Be sure to download today’s Windows update via MSDN or TechNet for the very latest, install the Windows Phone 8.1 update to start using IE11 today on your Phone and check-out our new experiences: 22Tracks and FishGL. On April 8 the Windows 8.1 update and IE11 update for Windows 7 will be available for all customers via Windows Update.

We look forward to hearing your feedback @IEDevChat or via Connect, to help us move the industry forward and continue to enhance the browser.

— Sam George, Partner Group Program Manager, Internet Explorer

Bruce LawsonNotes on accessibility of Web Components

At Edge Conference on Friday, Peter Gasston unmasked me as a secret accessibility wanker by saying “For a proper in-depth look at a11y in web components, see @brucel – he’s just spent weeks researching it for a talk next week.”

Well, not weeks, but I confess to reading around the subject (A lesson on rendering trees, emerging technologies and tacos), and had some chats with the ever-helpful Addy Osmani and The Mighty Steve Faulkner as well as (gasp) thinking a bit.

(If you plan to attend my talk at Funka conference in Stockholm on April 8, please stop reading now. Or read on, and go to someone else’s talk.)

If you don’t know what Web Components are, I recommend starting with Peter Gasston’s A Detailed Introduction To Custom Elements or his excellent introduction to web components at Edge Conference.

Very, very crudely: Web Components will allow us to extend existing HTML elements, and create our very own not-HTML-but-they-look-like-it elements with JavaScript.

“Real” HTML elements have built-in behaviours. Something like a <button>, for example, can be focussed; it can be activated by the keyboard, and when it’s activated it does something. Developers don’t need to add anything to the button element to get these behaviours; they’re given to us.

However, some developers love wheel-reinvention (it can make a diverting break from yak-shaving). So we get vile messes like this, that emulate <button> but which aren’t <button>. Therefore, to make it accessible, it requires tabIndex to make it focussable, JavaScript to listen for clicks and needs ARIA roles to let assistive technology know what this tag bukkake is supposed to be:

<DIV id=:rk class="J-K-I J-J5-Ji L3 J-K-I-JO" tabIndex=0
unselectable="on" closure_hashCode_l16mgm="182" act="">
<DIV class="J-J5-Ji J-K-I-Kv-H" unselectable="on">
<DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
<DIV class=J-K-I-KC unselectable="on">
<DIV class=J-K-I-K9-KP unselectable="on">&nbsp;</DIV>
<DIV class=J-K-I-Jz unselectable="on">Search Mail</DIV>
</DIV></DIV></DIV></DIV>

(The example is from Steve Faulkner’s 2010 article HTML5 and the myth of WAI-ARIA redundance. “Tag bukkake” is defined as “nastier than tag soup, and far more in your face”.)

In The Future™, you’d be able to extend <button>, so add all kinds of extra <div>s for hanging styles off etc, but without having to reinvent the base element. You’d need JavaScript, to define and register your omg-look-at-my-sexy-button element of course, but your basic markup would be

<button is="omg-look-at-my-sexy-button">

and User Agents that didn’t support JavaScript would fallback to showing a <button>.

You can also make your own custom elements with no fallback, too. But whichever way you choose, you need to add all the ARIA information and tabindex yourself. I don’t think this is misuse of ARIA; the ARIA spec says

WAI-ARIA is intended to augment semantics in supporting languages like HTML and SVG… It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages.

Given that the whole point of Web Components is to add “new types of objects, via style and script, that are not yet directly supported by the language of the page”, this seems to me a pretty good fit.

But enough theorising – how well are Web Components supported in assistive technology?

The answer is, pretty well (although Some stuff that doesn’t work between the DOM and Shadow DOM).

That’s actually not too surprising; although Web Components and Shadow DOM can hide things from the “real” DOM of the page (by design), the browser mashes them all together to render them, and assistive technologies sit on top of browsers. Of course, if the developer couldn’t be bothered to add ARIA information etcetera, they may not be accessible – but the fact they’re encapsulated in a component doesn’t make it better or worse than if they’re in the page in the traditional way.

The primary impediment to accessibility on the Web isn’t technical, it’s social. It’s that many (most?) developers don’t give a toss. One aspect of Web Components is that they can be shared and imported into the HTML – think of server-side includes, but client-side.

<head>
  <link rel="import" href="/path/to/imports/stuff.html">
</head>

(More at HTML Imports #include for the web.)

I had a vision of a big CDN (like Google’s Web Fonts or hosting of jQuery) but Addy Osmani told me that including from third party CDNs could be a performance problem. Nevertheless, we can expect lots of Web Component libraries to spring up, and people saving them locally, using their build processes to check they have the latest versions in their directories for inclusion at run time.

I don’t think it’s necessary for me to urge developers to put the source code of the Web Components they write onto Github for forking and collaboration. Please do that, and make it easy for people to contribute, so that people who notice accessibility holes can send pull requests.

A while ago, on this blog, I got an email from a screenreader user telling me that the live comment preview below the comments box needed an ARIA live region to be accessible. It was a WordPress plugin, with the source code on Github. I sent a pull request and, a couple of days later, the developer merged my one-line change latest version of the plugin. That’s my site, and 43,410 others, made more accessible through one pull request.

Christian Heilmann recently wrote that we need more “passion” in accessibility, “Not another library to add ARIA to badly thought-out HTML“.

I disagree. If passionate evangelism were enough, the web would be perfectly accessible now. My message to accessibility advocates is “passion – great. But with pull requests, please.”

Also

  • Web Components and the Three Unsexy Pillars by Paul “it’s not my round” Lewis. “I believe we need some open and community-driven way of vetting and ensuring Web Components are accessible, secure and performant. While we figure out what that means, let’s not be fooled into thinking that Web Components can fix bad development”
  • webcomponents.github.io “document[s] web components best practices so that others can follow the same path”
  • The golden path announcing “A community upvoting platform that lets us collaborate on best practise in front end code” by Mairead Buchan
  • Plans for repo of good web components: “Section for peer-reviewed Custom Elements” by Addy Osmani

Planet MozillaBugzilla 5.0 moved to Python (bye bye Perl!)

This discussion took place three years ago, and we have been working very hard to make it happen. But we are now done: Bugzilla 5.0, the next major release of Bugzilla which will be released later this month on April 31, will be based on Python 3.4, meaning that Bugzilla 4.4 was the last major release to be based on Perl. We hope this migration to Python will trigger more contributors and will increase the development rate of Bugzilla.

Bugzilla 5.0 comes with many major changes. Just to name a few:

  • Support for Internet Explorer (including IE 11) and less known browsers has been removed. You must now run Firefox, Google Chrome or Safari, which fully support HTML5, else an error message will be displayed asking you to use one of these browsers.
  • You must have Java 8 installed and enabled in your browser in order to upload new attachments. This way, sanity checks can be done client-side before the attachment is uploaded to Bugzilla. If you don’t have Java installed or enabled, you can still view existing attachments, though, but you won’t be able to upload new ones.
  • The version 5.0 of Bugzilla can be downloaded for free, but security fixes (5.0.1, 5.0.2, …) require that you register to our server to be able to download them. The fee isn’t expensive: $20 per security release for installations with less than 10 users. $200 between 10 and 50 users. $1000 above 50 users. As we do security releases only once every 4 months or so, this means that you can keep your installation safe for only $60 per year (or $3000 for larger installations).
  • For other changes, please read the Bugzilla 5.0 release notes.

Enjoy!

Note: For the ones who didn’t notice when I wrote this post (April 1): yes, it was an April fool!


IEBlogBuilding Better Input Experience for East Asian Users with the IME API in IE11

During the development of Internet Explorer 11, we proposed and implemented a new set of IME APIs to the Web Applications Working Group for a better input experience for East Asian users. These discussions resulted in changes to the Editor’s Draft of the W3C IME API. This API enables developers to build a tightly integrated experience between the IME that East Asian users rely on to type in their local languages and the UI that developers create to assist input, for example a search suggestion list that dynamically updates based on the keywords that the user has typed.

Avoid UI Occlusion

With IE11, developers can avoid the IME window occluding the part of the UI that is expected to be fully visible while the user is typing.

IME converts Roman alphabets into local characters. There are thousands of characters in East Asian languages. Often the same Roman input maps to several different East Asian words, in which case the user could choose from a list of candidates provided by the IME. The candidates UI is usually a floating window positioned close to the input box, and is not part of the DOM tree, thus JavaScript code doesn’t have a direct access to its size and position.

Candidate window in Chinese

Example of the IME candidate window when typing Simplified Chinese

Many Web sites show a custom UI below the input box as a form of auto-complete. For example, a list of city names that continues narrowing down based on what the user has typed.

Candidate window in English

Example of an input suggestion UI

Since the IME candidate window is also below the input box by default, the two UIs overlap with each other, making it difficult for the user to see or interact with them.

Candidate window in Chinese

Input suggestion UI occluded by the IME candidate window UI

Using the new IME API in IE11, developers can detect the opening of the IME candidate window by listening to MSCandidateWindowShow event, then call getCandidateWindowClientRect() function to find out where the candidate window is and position the suggestion UI away from it:

var context = document.getElementById("mySearchBox").msGetInputContext();
context.addEventListener("MSCandidateWindowShow", candidateWindowShowHandler);

function candidateWindowShowHandler(e) {
   var imeRect = context.getCandidateWindowClientRect();
   var suggestionRect = document.getElementById("mySuggestionList").getBoundingClientRect();
   // Check if the two rects intersect, and position them away from each other.
}

When the IME candidate window changes position or closes, it fires MSCandidateWindowUpdate or MSCandidateWindowHide events. Developers could listen to them and shift the suggestion UI accordingly.

For a more integrated look, developers can apply the new -ms-ime-align: after CSS property on the textbox to tell the IME to adjust its width and dock below the textbox.

IME API demo on IE Test Drive

The IME API Test Drive where the IME candidate window doesn’t occlude the Web site’s suggestion UI

Earlier Suggestions

Before IE11, developers had to wait until the user finished composing an East Asian character inside the IME to know what the new character would be. In IE11, the list of candidates inside the IME is also exposed to developers while the user is composing, allowing the site to generate suggestions much earlier.

For example, to type the city name of Shanghai in Chinese (“上海”), the user has to type “shang” and hit the space key to get the first Chinese character “上” into the textbox. The suggestion logic of the site couldn’t begin until this sequence was complete. Using the new IME API in IE11, the site gets the list of IME candidates by calling the new getCompositionAlternatives() function as soon as the user has typed the first “s” character; the character “上” is returned among several other candidates. By matching the IME candidate list to the list of city names, the site can find out that the user may be looking for “上海,” and show that in the suggestion UI, so the user could finish the input by only typing “s” and tapping on the suggestion, saving many keystrokes.

var searchBox = document.getElementById("mySearchBox");
var context = searchBox.msGetInputContext();
var compositionAlternates = context.getCompositionAlternatives();
var searchStrings = new Array();

// Add the user’s raw input as one search string.
searchStrings.push( searchBox.value.toLowerCase().trim() );
for (var i = 0; i < compositionAlternates.length; i ++)
{
    // Merge the alternate with the string that is already in the search box.
    var searchString = searchBox.value.substr(0, context.compositionStartOffset);
    searchString += compositionAlternates[i];
    searchString += searchBox.value.substr(context.compositionEndOffset);
    searchStrings.push(searchString);
}

// Find out which string matches the beginning of a city name, and put that city name into the suggestion UI.
matchToCityNames(searchStrings);

Comparison with and without use of get composition alternatives.

Using getCompositionAlternatives() in IME API to provide earlier suggestions

Summary

With Internet Explorer 11, developers can enable an IME-aware input experience in their Web-based applications and sites where the IME collaborates tightly with the rest of the page and provides East Asian users a fast and fluid experience, especially in typing suggestion scenarios.

Please note that this API relies on some Windows 8.1 features of the Text Services Framework Interfaces so it is not fully functional with IE11 on Windows 7. It also requires support from the IME. At the time of writing this blog, only the in-box Chinese Simplified/Traditional IMEs in the desktop, and the in-box Chinese Simplified/Chinese Traditional/Japanese/Korean IMEs in the Modern UI environment have a full support of this API.

Please try out the IME API Test Drive on Windows 8.1 and start using the new APIs in your sites to support these scenarios for East Asian users. We look forward to your feedback through Connect.

Jianfeng Lin
Program Manager, Internet Explorer

Planet MozillaEmpower Mobile Web Developers with JavaScript & WebAPI at PragueJS

Copyright Honza Černý: http://j.mp/QydiDK

Copyright Honza Černý: http://j.mp/QydiDK

HTML5 is a giant step in the right direction: it gives a lot more tools that developers need to create better experiences for users. The problem? It’s not there yet when it comes to web development for mobile devices. In this talk, Frédéric Harper will show you how you can use HTML, and JavaScript to build amazing mobile applications, and brush up what you published before. You’ll learn about the open web technologies, including WebAPIs, and tools designed to get you started developing HTML apps for Firefox OS, and the web.

That was the abstract of the presentation I did on Thursday at PragueJS. My goal was to show JavaScript developers that the eternal question between native versus mobile web application can be answered differently. We, Mozilla, created Firefox OS to open the web to more people, and give a real web platform to users as to developers. By doing so, we created what we call the WebAPIs: those APIs give you the control over the hardware with HTML5. Here are the slides from my presentation. The recording of my presentation has been made by Node5 and will be available soon.

With that in mind, I cannot see anything else than a bright future for the web…


--
Empower Mobile Web Developers with JavaScript & WebAPI at PragueJS is a post on Out of Comfort Zone from Frédéric Harper

Steve Faulkner et alHTML5Accessibility.com updated

HTML5Since October 2010 I have been testing and recording information on HTML5Accessibility.com about the implementation of accessibility support in browsers for new HTML5 features. I had let the updates to the site slide, but have made a concerted effort in 2014 to provide the information on the latest browsers. For now only windows browsers are covered. Support information for Mac browsers (Safari, Chrome, Firefox) will be coming soon.

Overview of HTML5 accessibility support in Windows browsers

HTML5 Accessibility Support Score

Firefox <meter max="100" min="0" value="88.5"></meter>
88.5/100

Chrome + Opera<meter max="100" min="0" value="47"></meter>
47/100

Internet Explorer<meter max="100" min="0" value="37"></meter>
37/100

Firefox  have consistently lead the pack in providing accessibility support for new features as they are implemented. This is a great achievement by the Mozilla Accessibility Engineers and really important work, as it allows user with disabilities, who require assistive technology to participate on the web, the opportunity to do so.

Chrome (+Opera) and Internet Explorer continue to perform poorly in implementing accessibility support. Chrome has many unfinished/partial implementations, while Internet Explorer is particularly poor in providing accessibility support for non interactive HTML elements.

Browser implementation bugs have been filed where applicable and are listed in the ‘notes’ column of the HTML5 accessibility support tables.

Detailed accessibility support information is available at HTML5Accessibility.com

The post HTML5Accessibility.com updated appeared first on The Paciello Group Blog.

Planet MozillaLantea Maps conversion to WebGL

I blogged about Lantea Maps 18 months ago. As its marketplace listing describes, the app's purpose is displaying maps as well as recording and displaying GPS tracks.

I wrote this app both to scratch an itch (I wanted an OpenStreetMap-based app to record GPS tracks) and to learn a bit more of JavaScript and web app development. As maps are a 2D problem and the track display requires drawing various lines and possibly other location indicators, I wrote this app based on 2D canvas. I started off with some base code on drawing bitmap tile maps to canvas, and wrote the app around that, doing quite some rewriting on the little bit of code I started from. I also ended up splitting map and track into separate canvases so I wouldn't need to redraw everything when deleting the track or when moving the indicator of the last location or similar. Over time, I did a lot of improvements in various areas of the app, from the tile cache in IndexedDB via OpenStreetMap upload of tracks to pinch zooming on touch screens.

Still, performance of the map canvas was not good - on phones (esp. the small 320x480 screens like the ZTE Open), where you only have a handful of 256x256 map tiles to draw, panning was slightly chunky, but on larger screens, like my Android tablet or even my pretty fast desktop, it ranged from bad to awful (like, noticeably waiting from any movement until you saw any drawing of a move map). Also, as it takes until images are loaded (cached from IndexedDB or out from the web) and that's all called asynchronously, the positions the images ended up being drawn often weren't completely correct any more at the time of drawing them. I tried some optimizations with actually grepping the pixels from the canvas, setting them in the new positions and only actually redrawing the images on the borders, but that only helped slightly on small screens while making large ones even worse in performance.

Given what I read and heard about how today's graphics chips and pipelines work, I figured that the problem was with the drawImage() calls to draw the tiles to the canvas as well as the getImageData()/putImageData() calls to move the pixels in the optimizations. All those copy image data between JS and graphics memory, which is slow, and doing it a lot doesn't really fit well with how graphics stacks work nowadays. The only way I heard that should improve that a lot would be to switch from 2D canvas to WebGL (or go to the image-based tile maps that many others are using, but that wouldn't be as much fun). I don't remember all sources for that, but just did get another pointer to a Mozilla Hacks post that explains some of it. And as Google also seems to being moving their Maps site to WebGL (from image-based tiles, mind you), it can't be a really wrong move. :)

So, I set out to try and learn the pieces of WebGL I needed for this app. You'd guess that Mozilla, who invented that API together with Khronos, would have ample docs on it, but the WebGL MDN page does only have one tutorial for an animated 3D cube and a list of external links. I meanwhile have filed a bug on a WebGL reference so may improve this further in the future, but I started off first trying with the tutorial that MDN has. I didn't get a lot to work there except some basics, and a lot of the commands in there were not very well explained, but the html5rocks tutorial helped me to get things into a better shape, and some amount of trying around and the MSDN WebGL reference helped to understand more and get things actually right.
One thing that was pretty useful there as well was separating the determination of what tiles should be visible and loading them into textures from the actual drawing of the textures to the canvas. By doing the drawing itself on requestAnimationFrame and this being the only thing done when we pan as long as I have all tiles loaded into textures, I save work and should improve performance.

Image No. 23214 Image No. 23213
2D Canvas (left) and WebGL (right) version of Lantea Maps on the ZTE Open

As you can see from the images, the 2D canvas and WebGL versions of Lantea Maps do not look different - but then, that was not intended, as the map is the map after all. Right now, you can actually test both versions, though: I have not moved the WebGL to production yet, so lantea.kairo.at still uses 2D canvas, while the staging version lantea-dev.kairo.at already is WebGL. You'll notice that panning the map is way more fluid in the new version and the tile distortions that could happen with delayed loading in the old one do not happen. I still wonder though why it sometimes happens that you have to wait very long for tiles to load, esp. after zooming. I still need to figure that out at some point, but things render after waiting, so I found it OK for now. Also, I found the WebGL app to work fine on Firefox desktop (Linux), Firefox for Android, as well as Firefox OS (1.1, 1.2, and 1.5/Nightly).

So, I'm happy I did manage the conversion and learn some WebGL, though there's still a lot to be done. And as always, the code to Lantea Maps is available in my public git as well as GitHub if you want to learn or help. ;-)

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>