Bruce LawsonReading List

W3C Team blogThis week: #HTML5 Proposed Recommendation, After HTML5, #W3C20, etc.

This is the 12-19 September 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

[What was tweeted frequently, or caught my attention. Most recent first]

Open Web & net neutrality

W3C in the Press (or blogs)

6 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.

Planet MozillaExtensible Web Summit Berlin 2014: my lightning talk on Web Components

I was invited to join and give a lightning talk at the Extensible Web Summit that was held in Berlin past week, as part of the whole JSFest.berlin series of events.

The structure of the event consisted in having a series of introductory lightning talks to “set the tone” and then the rest would be a sort of unconference where people would suggest topics to talk about and then we would build a timetable collaboratively.

My lightning talk

The topic for my talk was… Web Components. Which was quite interesting because I have been working/fighting with them and various implementations in various levels of completeness at the same time lately, so I definitely had some things to add!

I didn’t want people to get distracted by slides (including myself) so I didn’t have any. Exciting! Also challenging.

These are the notes I more or less followed for my minitalk:

When I speak to the average developer they often cannot see any reason to use Web Components

The question I’m asked 99% of the time is “why, when I can do the same with divs? with jQuery even? what is the point?”

And that’s probably because they are SO hard to understand

  • The specs–the four of them– are really confusing / dense. Four specs you need to understand to totally grasp how everything works together.
  • Explainer articles too often drink the Kool Aid, so readers are like: fine, this seems amazing, but what can it do for me and why should I use any of this in my projects?
  • Libraries/frameworks built on top of Web Components hide too much of their complexity by adding more complexity, further confusing matters (perhaps they are trying to do too many things at the same time?). Often, people cannot even distinguish between Polymer and Web Components: are they the same? which one does what? do I need Polymer? or only some parts?
  • Are we supposed to use Web Components for visual AND non visual components? Where do you draw the line? How can you explain to people that they let you write your own HTML elements, and next thing you do is use an invisible tag that has no visual output but performs some ~~~encapsulated magic~~~?

And if they are supposed to be a new encapsulation method, they don’t play nicely with established workflows–they are highly disruptive both for humans and computers:

  • It’s really hard to parse in our minds what the dependencies of a component (described in an HTML import) and all its dependencies (described in possibly multiple nested HTML imports) are. Taking over a component based project can easily get horrible.
  • HTML imports totally break existing CSS/JS compression/linting chains and workflows.
  • Yes, there is Vulcaniser, a tool from Polymer that amalgamates all the imports into a couple of files, but it still doesn’t feel quite there: we get an HTML and a CSS file that still need a polyfill to be loaded.
  • We need this polyfill for using HTML imports, and we will need it for a while, and it doesn’t work with file:/// urls because it makes a hidden XMLHttpRequest that no one expects. In contrast, we don’t need one for loading JS and CSS locally.
  • HTML Imports generate a need for tools that parse the imports and identify the dependencies and essentially… pretend to be a browser? Doesn’t this smell like duplication of efforts? And why two dependency loading systems? (ES6 require and HTML imports)

There’s also a problem with hiding too much complexity and encapsulating too much:

  • Users of “third party” Web Components might not be aware of the “hell” they are conjuring in the DOM when said components are “heavyweight” but also encapsulated, so it’s hard to figure out what is going on.
  • It might also make components hard to extend: you might have a widget that almost does all you need except for one thing, but it’s all encapsulated and ooh you can’t hook on any of the things it does so you have to rewrite it all.
  • Perhaps we need to discuss more about use cases and patterns for writing modular components and extending them.

It’s hard to make some things degrade nicely or even just make them work at all when the specs are not fully implemented in a platform–specially the CSS side of the spec

  • For example, the Shadow DOM selectors are not implemented in Firefox OS yet, so a component that uses Shadow DOM needs double styling selectors and some weird tricks to work in Gaia (Firefox OS’ UI layer) and platforms that do have support for Shadow DOM

And not directly related to Web Components, but in relation to spec work and disruptive browser support for new features:

  • Spec and browser people live in a different bubble where you can totally rewrite things from one day to the other. Throw everything away! Change the rules! No backwards compatibility? No problem!
  • But we need to be considerate with “normal” developers.
  • We need to understand that most of the people cannot afford to totally change their chain or workflows, or they just do not understand what we are getting at (reasons above)
  • Then if they try to understand, they go to mailing lists and they see those fights and all the politics and… they step back, or disappear for good. It’s just not a healthy environment. I am subscribed to several API lists and I only read them when I’m on a plane so I can’t go and immediately reply.
  • If the W3C, or any other standardisation organisation wants to attract “normal” developers to get more diverse inputs, they/we should start by being respectful to everyone. Don’t try to show everyone how superclever you are. Don’t be a jerk. Don’t scare people away, because then only the loud ones stay, and the quieter shy people, or people who have more urgent matters to attend (such as, you know, having a working business website even if it’s not using the latest and greatest API) will just leave.
  • So I want to remind everyone that we need to be considerate of each others’ problems and needs. We need to make an effort to speak other people’s language–and specially technical people need to do that. Confusing or opaque specs only lead to errors and misinterpretations.
  • We all want to make the web better, but we need to work on this together!

Thanks

With thanks to all the people whose brain I’ve been picking lately on the subject of Web Components: Angelina, Wilson, Francisco, Les, Potch, Fred and Christian.

flattr this!

IEBlogUpdates to our platform roadmap

Continuing our commitment to openly sharing our platform roadmap via status.modern.IE, today we’re announcing another round of updates to our plan. These updates include new ECMAScript, Networking, Performance, Media, CSS, and DOM features under consideration and in development:

Feature Status
Math Built-ins (ES6) In Development
Number Built-ins (ES6) In Development
String Built-ins (ES6) In Development
Object Built-ins (ES6) In Development
RegExp Built-ins (ES6) In Development
Classes (ES6) In Development
Template Strings (ES6) In Development
dppx Unit for resolution Media Query In Development
DOM Event Constructors In Development
WAV Audio Support In Development
Meta Referrer In Development
WeakSet (ES6) Under Consideration
Spread (ES6) Under Consideration
Tail Calls (ES6) Under Consideration
Subclassing (ES6) Under Consideration
Modules (ES6) Under Consideration
SIMD (ES7) Under Consideration
ASM.js Under Consideration
Clipboard API Under Consideration

Follow status.modern.IE for continual updates as our plans evolve for the Web platform in IE. Additionally, IE feature statuses are also integrated into caniuse.com via our open data feed. You can also help us make this a valuable resource for developers by contributing to the open source project. As always, ask us questions and give us feedback via @IEDevChat.

Jacob Rossi

Senior Program Manager

 


Update 9/18/14 - Added Clipboard API as Under Consideration

WHATWG blogRolling out TLS and HSTS

All whatwg.org and html5.org domains, including subdomains, are now available over TLS. We are also enabling HSTS though this is not done everywhere just yet. If you find Mixed Content issues be sure to let us know or provide a pull request on GitHub.

Update: TLS and HSTS are now deployed everywhere on both domains. We also submitted the domains to the HSTS preload list.

WHATWG blogThe Future of the Web: My Vision (May 1, 2012)

Like probably many others who read this blog, I am a web design enthusiast, web standards advocate, and web designer by trade. I have been working with HTML since the early 2000s, and have enjoyed it ever since.

Over the years, the web has evolved around me. I have watched it grow and adapt. And now, as a newly started professional web designer, I wish to contribute.

From this week forward, I will be writing and sharing both opinions and tutorials on my opinions of the web, where it’s gone, and most importantly, where it’s going.



<section>

Article 1: Websites and Sectioning
Part 1: The Basics


<warning>Warning: This article discusses the topic of <semantics>semantics</semantics></warning>

As a researcher by hobby, I often find myself reading through various encyclopedic websites. Whether it be a wiki, or a single purpose website devoted specifically to that aim, I spend countless hours of my time using them.

With the new work on HTML to semantically markup a website, I am rather excited to see what the future may hold for such informational websites. The concepts written in the specifications and drafts are very intriguing, and will hopefully someday improve the semantic importance of the web. Combine this with the ability for future screen readers, search engines, etc. to extract such data, the possibilities are near endless.

However, as I have read around, I have noticed that not all things are as clear as they should be. Although it has been several years since the formerly labeled HTML5 specification has come into the light, I can still see these arguments floating about.

In this specific case, I am referring to the use of the semantic elements such as <article>, <section>, and so-forth, as well as their relationship to the <h1>-<h6> elements.

Because it seems that many are in disagreement about the matter, I felt I should share my opinions as to what they mean, and how they could be used.

Below, you will see the method I have devised for sectioning out content.


(Note: All information is of my personal opinion, and may not reflect the views of other web designers, the WHATWG, or the W3C.)


Firstly, let us imagine the idea of a web page, likely encyclopedic in content. This page has a single focus, a single section, and a single paragraph.

At the very basic, it would be marked up as follows:


<article>
<section>
<p>Hello, World!</p>
</section>
</article>

<figure> Figure 1 <figcaption>Output of Example 1</figcaption> </figure>

As we can see, this bare minimum design utilizes three elements: <article>, <section>, and <p>. These elements, as can be semantically understood, represent the start of the article, the internal section, and the paragraph within the section.

Fairly simple, right?

Well, let’s take this a step further. What if you were to want to add a title to the article?

This is how it would be done.


<article>
<header><h1>Hello, World!</h1></header>
<section>
<p>Hello, World!</p>
</section>
</article>

<figure> Figure 2 <figcaption>Output of Example 2</figcaption> </figure>

Now, we see the addition of two new elements: <header> and <h1>. The <header> element designates this region of the document as the header of the article. The <h1> element designates this line of text as the title, or heading of the article.

Still, this seems simple, doesn’t it?

For our next step, let’s say that we wish to increase the scope of this article, from Hello, World! to Hello, World! and Foobar.


<article>
<header><h1>Hello, World! and Foobar</h1></header>
<section>
<h1>Hello, World!</h1>
<p>Hello, World!</p>
</section>
<section>
<h1>Foobar</h1>
<p>Foo</p>
<p>Bar</p>
</section>
</article>

<figure> Figure 3 <figcaption>Output of Example 3</figcaption> </figure>

Now we have an article which is both titled, and has two titled sections, each containing a heading within an <h1> element. We also have the article itself, headed within both an <h1> and <header> element.

This concept, though simplistic, is easy to read by humans, and holds semantic value to machines and scripts.


In conclusion, this is the way that I view the new method of sectioning content in HTML. Using this method, we come up with a quick, easy method to divide a document, and even a website, into logical sections which can be easily read by both humans and machines.

Next time, we will be discussing part two of this topic: Styling.

Until then,

-Christopher Bright

</section>

Bruce LawsonReflections on Extensible Web Summit, Berlin

I was lucky enough to visit Berlin very briefly for the Extensible Web Summit. It was organised, it seems, by members of W3C (but was not an officially branded W3C) and hosted by Beuth University, Berlin. Lunch was provided by Google, beers afterwards by Yandex (although I missed those as I’d taken the inexplicable decision to fly back straight after rather than hobnob with the great, the good, and Chaals.) Thanks to all organisations.

This isn’t a record of the day; the event notes were crowd-scribed. It’s my preliminary thoughts about the concept of the “extensible web”.

As far as I can deduce – because the term “extensible web” wasn’t actually defined on the day – it’s about giving/ exposing primitives so developers can extend various parts of the platform. (Read The Extensible Web Manifesto for a longer description and statement of intent.)

In the current world, we wait for something like Appcache to be specified, then implemented and then scoffed at. This can take a long time, and we might not get what we want; Hixie told me “The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution … Appcache works great if you want to do what it was designed for, but it turns out most people want to do something different enough that appcache feels horrible to them”.

So, an example of Extensible Web practices/ methodology is Service Worker – it allows you to control how websites fetch and store information across the network (and when there is no network) but it’s very low-level; you have to do everything yourself in JavaScript – but that gives you great power and flexibility.

One of the tests of Service Worker is: can we explain how AppCache works by coding it via Service Worker in JavaScript? Yes, we can. Similarly, Chrome’s Chris Wilson said how he hopes to be able to explain how the <audio> element works in terms of the Web Audio spec. Explaining how things work and giving us hooks in is a good idea, it seems to me. For example, in a sane, Extensible Web-world, we’d never have had the <canvas> element, but instead would have extended <img> with a scriptable API.

But while it’s good to explain magic, I feel we need to be careful about using the word “magic” pejoratively. A lot of the success of the Web was that simple HTML tags (<a>, <input>) made magic happen. You write <img src=”vomiting-otter.jpg”> and a vomiting otter appears; you don’t need to worry about how it gets there over the network, its caching, its format, etc. Similar with <input> – you just code a reasonably obvious word in angle brackets and it works.

As Steve Faulkner notes, a lot of the success of accessibility on the Web is/was that simple HTML elements makes accessibility happen.

Service Workers, and the spec that I’ve been closer to, <picture>, are great examples of listening to developers (partnership). Service Worker came out of a meeting between Opera, Mozilla, Google, BBC, Financial Times etc and was specified by Google, Mozilla and Samsung (and many others). <picture> came about because developers demanded it, even when the browser vendors and standards bodies didn’t care.

The Extensible Web Manifesto says “We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization”. I hope the end result is standardisation of a canon of best practice and then native implementation. Although JavaScript and C++ performance are (allegedly) very close now, I’d still rather see Sexy Feature implemented in 20K of C++ in a one-time download of a browser than loads of devs use a different Sexy Feature polyfill that gets downloaded squilions of times by billions of users of millions of sites.

But I’ve already heard potentially good ideas for extensions to core HTML handwaved away with “oh, that’s a job for Web Components”. So I’m not yet entirely convinced that we’re not heralding a new era of JavaScript-only web development. I don’t want to see the fossilisation of the declarative web and a new Programmer Priesthood (re-)emerge.

How can developers make their voices heard? It’s true that browser vendors are OBSESSED with solving developer’s problems. If we don’t, you’ll make native apps, and then browsers disappear, we default on our mortgages, our partners leave us for Apple employees and our hamsters starve. None of us want this to happen. So we try to listen.

Then there is the question of how developers can participate. The bravery barrier to entry for many of the mailing lists is already too high – I periodically get emails from people asking me to propose a feature or ask a question on a list as a proxy because lists are scary places.

W3C has set up a Specification forum where you can ask questions about specs/ propose a feature. Read around it to see if anyone else has a similar proposal, and if appropriate, add comments to that before you set up a new thread. Use Mozilla’s guidelines WebAPI Design Guidelines and please remember that use-cases are much better than a fully-worked out proposed syntax.

I’m enthused about the Extensible Web manifesto and the progress we’ve already made, eg baking popular jQuery-like syntax into browser engines via the Selectors API, getting our hands on the network with Service Worker, and the heady new world of Web Components. We need to ensure that all devs who want to can participate by allowing ease of collaboration, courteous discourse. And it would be perilous to forget that the declarative web reduces the barrier to entry and enhances accessibility.

Anne van KesterenTLS: issues with StartSSL

On the upside, they basic offer certificates that are free for non-commercial usage and help out quickly. If you have a more complicated domain setup (e.g. whatwg.org requires both *.whatwg.org and *.spec.whatwg.org, html5.org requires *.html5.org), you have to get validated for USD 60. That validation then allows you to issue as many non-commercial certificates as you want for domains you own for about a year. If you pay, the certificates last for two years, otherwise one.

Now the downside:

  • Revoking a certificate costs USD 25, even though it should be easy to automate.
  • Does not allow setting the Common Name on a certificate. E.g. if you have both example.com and sub.example.com it will likely pick the latter, even though that might not at all be the most common name.
  • Provided intermediate certificate uses SHA-1 rather than SHA-256.
  • The user interface is really quite bad and not forgiving. You have to carefully follow the steps and not make mistakes.
  • They spelled my name with an uppercase “v”. Very sad. This ends up on every certificate. Not sure how to resolve this.

Anne van KesterenTLS: issues with DreamHost

There are numerous issues with TLS on DreamHost in a shared hosting setup unfortunately.

  • Does not support TLS 1.2.
  • Does not support forward secrecy.
  • Has SSL 3.0 enabled (even when no unique IP is acquired for the domain and SNI is required, which SSL 3.0 does not support).
  • Uses RC4 which has known weaknesses and fails on initial attempt in Internet Explorer 11.
  • Provides no convenient way to add certificates. When a certificate is valid for a domain and its subdomains (e.g. both html5.org and *.html5.org), you have to configure it for each of them separately. For html5.org I have twelve domain entries in my control panel. Having to copy and paste the key, certificate, and intermediate certificate, as well as clicking through several screens for each of those entries, is very time consuming. The situation for whatwg.org is even worse.
  • Has no built-in support for HSTS and therefore requires configuration for each domain.

To be honest, if I did not have this legacy and started looking for a solution today for twenty-thirty domains and as many subdomains, I would likely not pick DreamHost and try to figure out setting up something myself on a VPS. DreamHost is great value, but it does not offer perfection and that is irking.

Reportedly DreamHost will be improving this as they switch their server OS. Once they do I will update this post.

Planet Mozilla IndieWebCampUK 2014 Hack Day Demos: HTTPS, #webactions, new & improved #indieweb sites

One weekend ago, 18 IndieWebCampUK participants (including 2 remote) showed 25 demos in just under 75 minutes of what they designed and built that weekend in 19 different interoperable projects. Every single demo exemplified an indieweb community member scratching their own personal site itch(es), helping each other do so, and together advancing the state of the indieweb. We can all say:

I'm building Indie Web Camp.

During the demos I took realtime notes in IRC, with some help from Barnaby Walters. Archived on the IndieWebCamp wiki, here's a summary of what each of us got working.

Glenn Jones

Glenn Jones built improvements to Transmat. (IRC notes)

He built a map view that shows the venues nearest to his current location (via GeoLocation API).

He also found an open source HTML5 JS open source pedometer and repurposed it into Transmat so that when running on his Android as a web app, it can detect when he's walking, and only do GPS lookups when he's walking, so it saves battery.

Now he has an HTML5 JS app that can auto-checkin for him while he's walking.

Barnaby and Pelle

Barnaby WaltersPelle Wessman Barnaby Walters and Pelle Wessman built cross-site reply webactions that work purely via their websites - no browser extension needed! This is the first time this has been done. (IRC notes)

Barnaby has setup registerProtocolHandler on Taproot to register a handler for the "web+indie:" (since updated to "web+action:") protocol when he loads a particular page on his website so that his website is registered to handle webactions via the <indie-action> tag.

Barnaby demonstrates loading the page that calls registerProtocolHandler. The browser asks to confirm that he wants waterpigs.co.uk to handle "web+indie" URLs.

Then Barnaby goes to Pelle's website home page where he has a list of posts that he's written, now with "Reply", "Like", and "Tip" webactions next to each post, each webaction represented and wrapped by <indie-action> tags in the markup.

Pelle's site also has a web component ([https://github.com/voxpelli/indie-action-component open sourced on github]) to handle his <indie-action> tags, which creates an iframe that uses that same protocol handler using a Promise, which connects the iframe to calling the handler that Taproot registered.

Thus without anything installed in the browser, Barnaby can go to Pelle's site, click the "Reply" button next to a post which automatically goes to Barnaby's site's Taproot UI to post a reply!

Barnaby Walters

Barnaby Walters also built a map-view post aggregator that shows icons for people at the locations embedded in their recent posts. (IRC notes)

The map-view aggregator is at a self-standing demo URL for now, but Barnaby plans to include this view as another column type in Shrewdness, so you can have a map view of recent posts from people you're following.

Grant Richmond

Grant Richmond got a fancy new domain (grant.codes) and setup Glenn Jones's Transmat on it - which makes it the second installation of Transmat! (IRC notes)

Grant also built a contact page: grant.codes/contact that has links for various methods of communication:

All of the links are text links for now, no icons yet.

Grant has implemented a people focused communication UI on his site!

Jeremy Keith

Jeremy Keith added https on adactio.com, and implemented <indie-action> tag webactions. (IRC notes)

adactio https

Jeremy took his site adactio.com from no https support to https Level 4. All adactio.com URLs redirect to https. However subdomains (e.g. austin.adactio.com) are still http.

adactio webactions

Jeremy's also implemented the new <indie-action> tag for webactions around his existing Tweet action links, both on his post permalinks, and on his posts in-stream (e.g. on his home page or when paginated).

Shane Hudson

Shane Hudson went from no SSL and no comments yesterday to https level 5! He also imported the contents of all his old comments from his WordPress blog to his Craft install (the CMS he's dogfooding, contributing plugins to, selfdogfooding). (IRC notes)

He was able to get SSL setup on his site with an A rating, and forward secrecy, and is thus https level 5.

Shane also wrote a script to do the import of comments from WordPress to Craft. It's "a bit crude, dealing with XML to CSV a few times".

Nat Welch

Nat Welch (AKA icco on IRC) got his blog running (his own software) in Go (language) hosted on AppEngine with SSL, achieving https level 4! (IRC notes)

AppEngine does SSL for free if you're ok with SNI.

So now Nat has SSL Labs rating A- on writing.natwelch.com! And also automatic redirect works from http to https. Thus he has also achieved https Level 4!

Right now he's using AppEngine default auth, using his Google account. Eventually he wants to use indieauth to auth into his site.

Tim Retout

Tim Retout got pump.io running on his site and added support to it for POSSEing to Twitter. (IRC notes)

His goal is to add all the indieweb feature support too like webmentions, microformats etc. He has to run off to catch a train.

He is also too humble, as he helped numerous people in person at the camp get on SSL, https level 4 or 5 at that. A round of applause for Tim!

Tom Morris

Tom Morris added https to his site, made it responsive, and setup mf2py as a service. (IRC notes)

responsive tommorris.org

Tom showed his current site tommorris.org with different window sizes. His CSS is now "less sucky" and he has made his site more responsive on mobile / small display etc.

mf2py as a service

Tom also got the Python microformats2 parser (mf2py) running as a service that you can submit your URLs to and get back pretty-printed JSON.

tommorris https

Tom got his main site tommorris.org up to https Level 4 with an A- rating, but has not yet done so with *.tommorris.org (e.g. wiki.tommorris.org).

During the next demo, Tom got his SSL Labs rating from A- to A with some help from Aral. And during the demo after that took his rating up to A+ thanks to this blog post.

Kevin Beynon

Kevin Beynon got IndieAuth login to his own site working! (IRC notes)

Kevin started by showing us his site home page kevinbeynon.com using a tablet. We projected it by holding up to the Talky HD camera.

He pointed out that there is no admin link on the home page then went to his "secret" URL at /admin/ which has an IndieAuth login screen. He entered his own URL, and chose to RelMeAuth authenticate using Twitter which redirected to it and back and came back with the message "Log-in Successful".

Kevin went to his home page again, and showed that it now has visible links to "admin" and "log out". Next he plans to bring his post creating and editing interface into his home page front end, so that he can do inline editing and post notes from his home page.

Joschi Kuphal

Joschi Kuphal got his site's https support to SSL rating A+, fixed his webmention implementation, and implemented webactions on permalinks. (IRC notes)

jkphl https A+

Joschi noted that his site was running with SSL before but had some flaws. He worked on it and improved his site's rating from F to A+.

jkphl webmentions fixed

He also fixed some flaws with his webmention implementation thanks to feedback from Ryan Barrett online.

jkphl permalinks webactions

Third, Joschi implemented webactions on permalinks, in particular he added <indie-action> markup around his default Twitter, G+, Facebook "share" links. He then demonstrated his site working with Barnaby Walters's Web Action Hero Toolkit browser extension.

Chris Asteriou

Chris Asteriou is fairly new to the IndieWeb and started with going through IndieMark, adding h-entry and h-card markup, and a notes section to his site.(IRC notes)

digitalbliss microformats

Chris showed digitalbliss.uk.com, noted that he added h-entry on his page with entries. He clicked the "Play" link at top to show this. And then he marked up the info at bottom of his home page with h-card.

digitalbliss notes

Chris added a notes section and used the verification tools on indiewebify.me to check it and verify that he reached IndieMark Level 2.

Tantek

Tantek Çelik switched his permalink webactions from <action> tags to <indie-action> tags and researched the UX of webactions on posts in a stream (e.g. a home page).

tantek indie-action

Based on the webactions discussion session in the first day with Tantek, Jeremy, and Pelle, they concluded that the <indie-action> tag was more appropriate than the <action> tag.

Tantek initially publicly proposed the <action> tag for consideration in a session on Web Actions at Open Source Bridge 2012, and then later implemented them at last year's IndieWebcampUK 2013 which were then demonstrated working with Barnaby Walters's browser extension.

Changing from <action> to <indie-action> at a minimum better fits with the web component model. Jeremy Keith pointed out that an <indie-action> tag in particular would be a good example of a web component, worthy as a case-study for web components.

Tantek updated his permalink webactions to use <indie-action> tags and Barnaby updated his browser extension to support them as well.

in-stream webactions

Tantek analyzed the UI of various silos, in particular Instagram and Twitter.

Instagram has a very minimal simple webaction UI, with just "Like", "Comment", and "..." (more) buttons, the first two with both icon and text labels, which makes sense since their primary content is large (relative to the UI) images/video (visual media). Instagram's webactions are identical on photos viewed on their own screen, and when in a stream of media. Deliberately designed consistency.

Twitter on the other hand is horribly inconsistent between different views of tweets, and even different streams, sometimes their webactions are:

  • on the right with text labels
  • on the left with text labels
  • on the left without text labels

Their trend seems to be icon only, likely because the text label distracts from the tweet text content around it, especially in a stream of tweets that are primarily (nearly all) just text.

Tantek walked through comparisons of Twitter's different webactions button icon/text usage/placements with Aral, who came to the same conclusions from the data.

It may be ok to use both icon and text labels on note/post permalink pages, as there is more distinction between the (single) content area, and the footer of webactions.

However, the conclusions is that in-stream webactions should use just icons (clear ones at that) when among posts that are primarily, mostly, or perhaps even often just text.

Next Tantek is working on implementing icon-only webactions on his home page posts stream. He made some progress but realized it will require him to rework some storage code first.

Aral Balkan

Aral Balkan upgraded his site's https support to SSL rating A+ and https Level 5, and his how-to blog post about it! (IRC notes)

Aral already supported https on his site aralbalkan.com beforehand. On IndieWebCampUK hack day he added support for forward secrecy, which raised its SSL rating from A- to A+ and thus he achieved https Level 5!

Apparently it took him only 2 lines of code to implement that change on nginx, and noted that it's a bit harder on Apache.

After his demo, Aral also updated his blog post about SSL setup with nginx with what he learned and how to get to SSL rating A+.

Rosa Fox

Rosa Fox created a UI on her site for CRUD posting of projects. (IRC notes)

Rosa wanted to make her own CMS with support for posting images and tags. She demonstrated her local dev install of her new CMS with the following new features she built at Hack Day:

  • a UI for creating a new project
  • CRUD posting interface for projects
  • using Postgres to store data

Aaron Parecki

Aaron Parecki participated remotely, added support for posting bookmarks to his site, and added bookmarks posting via micropub to his Quill app! (IRC notes)

Aaron has been publishing bookmarks to another place for a long time in a WordPress install at aaron.pk/bookmarks and he wanted to integrate them into his main site aaronparecki.com.

Once Aaron got the bookmark post type implemented in his publishing software p3k and deployed to his site, he did a mass import from the aaron.pk/bookmarks WordPress XML export.

That was the last thing aaronpk was using WordPress for, so he's no longer using WordPress to publish any of his own content.

Now all of Aaron's bookmarks are at aaronparecki.com/bookmarks all marked up with microformats. Each bookmark is an h-entry, and embedded inside is an h-cite of the bookmark itself.

This also means you can comment, bookmark, and like his bookmarks themselves!

During later demos, Aaron also updated his Quill app with a bookmark posting interface, as well as a bookmarklet so you can quickly open the Quill UI to make a bookmark.

Kevin Marks

Kevin Marks built a feed coverter that takes legacy RSS/Atom feeds and produces modern readable and usable h-entry page, including such niceties as inline playable audio elements in converted podcasts. (IRC notes)

Kevin noticed that people are building h-feed readers, so he built a tool that takes legacy RSS Atom feeds and unmunges them and produces nice clean h-entry feeds.

The converter is at feed.unmung.com/. Unmung.com is a URL he bought ages ago, and set it up on Google AppEngine.

E.g. if you put in xkcd.com/rss.xml into it, it generates a nice readable HTML page with h-entry, which you can then subscribe to in an indie reader like Barnaby's Shrewdness.

Kevin demonstrated using unmung to convert a podcast feed feeds.wnyc.org/onthemedia into an h-feed with embedded playable HTML5 <audio> elements, providing an actual useful interface, much better than the original feed.

Kevin made the point that no one wants to parse RSS or Atom any more. Now by parsing the microformats JSON representation, you can get any existing RSS or Atom etc.

You can now subscribe to iTunes podcasts etc. in your indieweb reader!

Robin Taylor

Robin Taylor added support for https (including forward secrecy, getting an SSL "A" rating) to his site robintaylor.uk and automatic redirects from http to https, achieving https Level 5! (IRC notes)

UK Homebrew Website Clubs

As we were wrapping up, Tom Morris asked openly if anyone would be interested in coming to a Homebrew Website Club in London. Jeremy Keith similarly asked the group for interest in a Homebrew Website Club Brighton.

Both had quite a bit of interest, so we can expect to start seeing more Homebrew Website Club meetups in more locations!

See also

Join Us At The Next IndieWebCamp In Cambridge

IndieWebCamp Cambridge is next month on the East Coast.

Join us. Share ideas. Come work on your personal web site. Help grow and evolve the independent web. Be the change you want to see in the world wide web.

"The people I met at @indiewebcamp are the A-Team of the Internet. Give them some tape and an oxy-acetalyne torch and they'll fix the web."

Anne van KesterenTLS: first steps

Given Pervasive Monitoring Is an Attack and the proposal to require TLS for new platform features I was ready to invest some time. Overall TLS advocacy is increasing. On IRC someone quipped “TLS is the new utf-8”.

TLS helps with protecting credentials, what content is being viewed, the path and query components of a URL, and provides an assurance you are actually getting content from the given domain rather than an attacker. Of course, if the given domain is compromised or talks to other domains in the backend without encryption, you are none the wiser. That relies on the user trusting the domain owner.

TLS used to not have an equivalent to the Host header, requiring a unique IP address for each domain you wanted to have TLS on. With the Server Name Indication (SNI) extension, TLS has become virtually free. The catch is that older Android and Internet Explorer on Windows XP will not be able to get to your domain. (Just as Internet Explorer 2 cannot get to your domain now as it likely requires a Host header.) Python 2 is being patched.

Mathias already has TLS deployed and asked if html5.org could follow. I use DreamHost. DreamHost supports “Secure Hosting” though does not use it much itself yet unfortunately and has ample room for improvement. Their support team claims they are working on it as they are transitioning to a new OS for their servers.

DreamHost is also rather expensive for certificates. StartTLS is not, so I created an account there. Unfortunately html5.org has a number of subdomains so I had to pay USD 60 to get myself validated. That way I get access to more elaborate certificates. Lacking proof of my mobile phone number I am now waiting up to ten business days for a letter with a key to arrive that will get me said validation. Otherwise StartSSL has been excellent in support so far and although the UI leaves much to be desired, it is workable.

Another problem remaining with DreamHost (shared hosting) is that databases are on a different domain and the connection to it is not encrypted. Now they claim to have safety measures in place and generally only allow internal access to those databases, but that could be better still. (See To Celebrate Spying on Google Users, the NSA Drew a Smiley Face.)

Steve Faulkner et alWeb Components punch list

Considerations for web component and custom control design:

If your control has the stuff below covered, excellent! If not then please implement it before shouting to the world about it being the next big thing. Or at least document its deficits and provide a health warning that the control is incomplete and not fit to use in production.

design consideration description Yes/No
focusable Can you get to the control via the keyboard?
operable Can you use the control with the keyboard?
expected operation Can you use the standard keys for the control type to operate it.
clear indication of focus Can you easily see it when the control has focus?
label The control has a text label that is exposed as an accessible name in accessibility APIs
role The control has an appropriate role exposed in accessibility APIs
states and properties The control has any UI states and properties that it has exposed in accessibility APIs

Take note:

The ARIA design patterns provide a most excellent and comprehensive set of requirements, for expected keyboard interaction and what role, state and property information needs to be exposed, for a large variety of custom controls.

Accessibility APIs

If the term accessibility APIs has you scratching your head, read Why accessibility APIs matter by the one and only Marco Zehe.

The accessibility tree

Tree of accessible objects that represents the structure of the user interface (UI). Each node in the accessibility tree represents an element in the UI as exposed through the accessibility API; for example, a push button, a check box, or container.

Example baseline test using the native HTML button element

Most of the considerations listed below do not need to be checked for a native HTML button as you get them for free (thanks to the browser implementers). If you build a custom control (for example, a custom button web component) you need to add most of this stuff yourself.

design consideration description Yes/No
focusable Using a test file attempt to tab to the control. (except when it is disabled) yes
operable Using a test file attempt to make something happen (except when it is disabled) yes
expected operation Buttons have standard expected keystrokes (enter or space) that will make something happen. Using a test file ensure that controls works as expected. (except when it is disabled) yes
indication of focus Using a test file, can you see the control is focused? (except when it is disabled) yes
label Default method for providing an accessible name for button is via text content child of button element (there are others, whatever you use you you need to end up with an acc name exposed). You can check it using aViewer or other accessibility object inspection tool. yes
role Default role for <button> is already provided by browser (role:button). You can check it using aViewer or other accessibility object inspection tool yes
states and properties The control has any UI states and properties that it has exposed in accessibility APIs. Standard states and properties for <button> are already provided by browser (focusable, focused, unavailable [if disabled attribute used). You can check them using aViewer or other accessibility object inspection tool. yes

aViewer

Obect Inspection tools such as aViewer can be used to test that your custom controls are exposing the correct information via accessibility APIs.

aVIEWER UI displaying information about a button element. It shows that the button has a correct accessible name and role and state.

Some Other Object inspection tools:

A personal opinion

<script async="" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

Further reading

 

WHATWG blogThe Future of the Web: My Vision (May 23, 2012)

I apologize for the longer than expected wait for this article, but now, we may continue.

The article below will pick up where Part 1 left off.



<section>

Article 1: Websites and Sectioning
Part 2: Styling


<warning>Warning: This article discusses the topic of <semantics>semantics</semantics></warning>

As we began with previously, we now have the basics down as to how to properly divide information into sections. This time, we will be looking into the second aspect of sectioning: Styling.

When a search engine or screen reader scans a website, it does so by evaluating the markup of the page. Humans however, view by way of sight. If we were to use absolutely no form of styling, it would be difficult, if not impossible, to logically divide an article into sections.

</section><section>

When we read through a webpage, several common features are used to guide us in logically separating it out:

<figure class="list">
  • Bolded text defining headings.
  • Heading text larger than the content below it.
  • Logical heading levels which decrease in size as it gets deeper.
  • Ocasionally indenting subsections and subheadings within their parents.
</figure>

Web browsers of today will often do much of this work for you, but this is not always enough. Below, I will show you at most basic, the heading layout I choose to use when building a website.


<article>
<header><h1>Main Heading</h1></header>
<section class="topsection">
<h1>Top Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
</section>
</section>
</section>
</section>
</section>
</section>
</article>

Now obviously, this is more compact than any site would naturally be, and wouldn't use such simplified text. However, this perfectly demonstrates the decreasing levels of the font size of the heading. With each level, it gradually scales downward, starting from nearly 3 times larger than the content at highest, to the same size as the content at lowest.

To achieve this, we use the following CSS Code.


header > h1 { font-size: 2.75em; }
section.topsection { font-size: 2em; }
section > section { font-size: 75%; }
section h1 { font-size: inherit; }
section * { font-size: 16px; }
section h1, section p { margin: 0; }

As you can see, the above code generates a much more aethetically pleasing, and far more understandable result than one without styling.

</section>

At this point, you are probably asking: How can this actually apply to real life?

Well, below this I will explain.


<section>

Use in Practical Design

As mentioned above, the true power of this method is revealed when used in practical application.

In the figure below, I will demonstrate said power by use of the first chapter of the book Alice's Adventures in Wonderland by Lewis Carroll.

<figure> 404 <figcaption>Styling used in Practical Application</figcaption> </figure>

In the above sample, you can easily see the logically broken down structure of the chapter. You have the main article with its heading, the major logical division (the chapter), and two minor logical divisions (the sections). Although the subsections lack heading text, you can still tell that they are seperated. Even if you were to remove the row of stars, the spacing alone would be able to divide them.

And now, to show the code that makes it work:

HTML:
<article>
<header>
<hgroup>
<h1>ALICE'S ADVENTURES IN WONDERLAND</h1>
<h2>By Lewis Carroll</h2>
<h3>THE MILLENNIUM FULCRUM EDITION 3.0</h3>
</hgroup>
</header>
<section class="topsection">
<h1>CHAPTER I. Down the Rabbit-Hole</h1>
<section class="subsection">
<p>...</p>
<p>...</p>
<p>...</p>
<p>...</p>
<p>...</p>
</section>
<div class="sep">* * * * * * * * * * * * * * * * * * * *</div>
<section class="subsection">
<p>...</p>
<p>...</p>
<p>...</p>
</section>
</section>
</article>
Note: Text removed to prevent overcluttering.


CSS:
hgroup * { margin: 0; }
hgroup h1 { font-size: 2em; }
hgroup h2 { font-size: 1.5em; }
hgroup h3 { font-size: 1em; }
section { margin-bottom: 2em; }
section h1 { margin: 0.5em 0; }
p { text-indent: 1em; margin: 1em 0; }
p:first-of-type { margin-top: 0; }
.sep { font-weight: bold; margin: 0 1em 2em; }
Note: To show the full extent of the sample, this example uses a multi-tier heading for the article. This will be explained further in Part 3.

And here we have it. Together, the markup and the styling provides a neat, clean look which greatly improves readability. As well, it is written in semantic code which allows computers to properly understand its meaning.

</section>

In conclusion of this section, we have now learned the importance of sectioning, as well as how to properly style sections. These two concepts, when applied properly, could help create a much richer and more consistantly appealing world wide web in the coming future.

Next time, we will be discussing more advanced ascpets of this layout principle, such as multi-tiered headings and asides.

Until then, I hope that you have learned something new from this subject.

-Christopher Bright

<section>

Notes

  • Starting from now, if this article does not thoroughly desribe something for you, please leave a comment detailing your problem. I will do my best to update it.
  • I will soon be working out a method to rate the usefulness of this article, for future reference.
  • Any comments made will be taken into consideration for the future. I intend to make this beneficial for everyone, so all comments are accepted.
  • Examples will now be made within iframes, due to the possible large size of the content.
</section> <section>

References

Alice's Adventures in Wonderland
Written by Lewis Carroll
Converted to ebook by David Widger of Project Gutenberg.
www.gutenberg.org/files/11/11-h/11-h.htm#2HCH0001
All rights go to their respective owners.
</section> <section>

Updates

  • I have made a fix to the specific coding of the CSS, condensing it as much as possible, I believe.
  • Although further feedback will be needed to make a final decision, this may be the final entry of this series at this time.
</section>

WHATWG blogCSS Books & CSS Figures

Today we're happy to add two more specs to the WHATWG stable, Books and Figures! These are specifications focused on CSS features. Books provides ways to turn HTML document into books, either on screen or on paper. Using Books, authors can style cross-references, footnotes, and most other things needed to present books on screen or paper. Figures are also based on traditional publishing — it provides ways to float elements with respect to columns and pages, and describes how to wrap text around them.

Printing was part of the first CSS proposal in 1994, and many of these CSS features have been in use since the first paper book written in HTML and CSS (CSS — Designing for the Web) was published in 2005. Now, a decade later, bestsellers are routinely produced with CSS. There are currently two implementations of these specifications that are able to produce books: AntennaHouse and Prince. We hope that our continued work on these specifications will help existing implementations converge, and also encourage browsers to present web content as pages. Pages can be printed, stored as PDF files, or shown on screens. Many users will prefer pages to scrollbars, and these specifications will help make it happen.

As an example of a feature from Books, consider footnotes. Turning an element into a footnote is easy:

span.footnote { float: footnote } 

This can, with a few more styles, be formatted as:

Body text, with a superscripted footnote saying '[1]' in red, and under the body, a short line delimiting the body from text in a smaller font size, with the same red '[1]' indicating the footnote.

In another example, common newspaper and magazine layouts can be achieved with just a 10-line style sheet. Here's what this could look like:

The page with five columns of body text, but with a paragraph in a larger font size spanning the first two columns to the upper left, an image with a caption spanning the last three columns at the top on the right, an image covering the second and third columns at the bottom, and a smaller image with a caption at the bottom right.

More screenshots and code examples are available.

Feedback on these specifications, like all our others, is most welcome, either on www-style, on WHATWG's mailing list, or as bugs in the bug database.

The features described by these specifications were previously published as part of a W3C CSS working group document that I wrote. Today we are moving the work to WHATWG, a W3C Community Group.

IEBlogMaking your WebGL code more flexible

The August update for Internet Explorer 11 includes new capabilities to help web developers detect when their WebGL application might encounter performance problems due to underlying hardware, including support for the failIfMajorPerformanceCaveat flag and WEBGL_debug_renderer_info extension. These can be added to other best practices to make your WebGL code more adaptable to the hardware that it is running on.

WebGL strategies for addressing hardware diversity

Web developers know that the world where we live is a complex one. The diversity of operating systems, hardware and browsers that our code can run on is huge. For example, to have your code work across diverse hardware means creating adaptable layouts or using graceful degradation. For a WebGL developer this means designing your code to run on high-end hardware that can render millions of triangles, or on a low-end device where 1000 triangles is the limit.

To allow your 3D scene to run on a small device, you can use some of these strategies to address this diversity:

  • Remove visual enhancements like shadows or particles
  • Reduce texture resolution
  • Reduce object complexity by using level of details
  • Change the resolution of your canvas and use hardware scaling
  • Reduce shader complexity (fewer lights, etc…)

Here's how I handled these differences in the WorldMonger demo on the www.babylonjs.com site:

Full version of WorldMonger demo

Here's the full version, complete with shadows, reflection, refraction, and post-process effects. The following steps outline how I reduced the complexity to accommodate less powerful devices.

 

Step 1 – The post-process is disabled, particles are disabled, shadows are disabled, and the texture resolution is reduced for reflection and refraction

Step 1 – The post-process is disabled, particles are disabled, shadows are disabled, and the texture resolution is reduced for reflection and refraction

 

Step 2 – The hardware scaling is now 2x, meaning the canvas resolution is the screen resolution / 2

Step 2 – The hardware scaling is now 2x, meaning the canvas resolution is the screen resolution / 2

 

Step 3 – The hardware scaling is now 4x and texture resolution is reduced again for reflection and refraction

Step 3 – The hardware scaling is now 4x and texture resolution is reduced again for reflection and refraction

 

To be able to apply these strategies to reduce scene complexity, you must figure out if the current device is powerful enough or not. To do so, let’s see together different options you have.

Benchmarking

The obvious option is benchmarking. One way is to render some scenes and measure the frames per second on a specific hardware to judge the overall performance. You can get more detail in an article I wrote about how to measure performance:

http://blogs.msdn.com/b/eternalcoding/archive/2013/05/21/benchmarking-a-html5-game-html5-potatoes-gaming-bench.aspx

The main idea in measuring performance is to compute the delta in time between two frames. If the delta time is lower than a given threshold, then you can consider taking actions to reduce your overall rendering complexity.

failIfMajorPerformanceCaveat

Because of the direct access to the GPU allowed by WebGL, browsers must ensure that running your code will not cause a major security issue. For some specific drivers that are not perfectly secure, the browser can prevent hardware acceleration in order to prevent security issues.

To enforce this, IE has a block-list of drivers that are not safe for use with hardware acceleration. On these devices, WebGL will software rendering instead, resulting in a slower but safer experience.

In the August update of Internet Explorer, we support a new flag that you can specify when getting your WebGL context: failIfMajorPerformanceCaveat.

The Khronos specification defines how this attribute works:

Context creation will fail if the implementation determines that the performance of the created WebGL context would be dramatically lower than that of a native application making equivalent OpenGL calls.

When a context is requested on a computer with a block-listed driver, the failIfMajorPerformanceCaveat flag prevents IE from returning a software context, and instead returns no context.

To use it you just have to add it as an option to the getContext function:

var canvas = document.getElementById('renderCanvas');
var context = canvas.getContext('webgl', 
{
failIfMajorPerformanceCaveat: true
});

Using this attribute, you can know that the current device isn't powerful or secure enough to run hardware accelerated 3D rendering. Then you can decide to use the software renderer, or if you prefer, let the user know their computer or graphics card aren't supported.

Identifying the renderer

Finally, in conjunction with the failIfMajorPerformanceCaveat attribute, IE also now supports the WEBGL_debug_renderer_info extension (Khronos specification).

The WEBGL_debug_renderer_info extension is a tool to get the renderer and vendor strings for the underlying graphics driver:

var gl = document.createElement('renderCanvas').getContext('experimental-webgl');
var extension = gl.getExtension('WEBGL_debug_renderer_info');
if (extension != undefined) {
    var renderer = gl.getParameter(extension.UNMASKED_RENDERER_WEBGL);
    console.log('UNMASKED_RENDERER_WEBGL = ' + renderer);
    var vendor = gl.getParameter(extension.UNMASKED_VENDOR_WEBGL);
    console.log('UNMASKED_VENDOR_WEBGL = ' + vendor);
}

For instance, here is the result I get on one of my computers:

UNMASKED_RENDERER_WEBGL = NVIDIA GeForce GTX 750 Series
UNMASKED_VENDOR_WEBGL = Microsoft

You can use this information to gather useful information for debugging; for example, if you detect using benchmarking that your code is running slowly, then you will be able to gather data for reproducing the issue.

But beware: Like user agent sniffing, using this feature to create a GPU “approved list” could result in a lot of other devices not being able to experience the best your app has to offer. Instead, I recommend targeting the broader audience by using it to only block specific devices that you've identified to perform poorly with your app.

Conclusion

Being able to create WebGL experiences that works seamlessly in all kinds of configurations is extremely hard. However, you can use these tools to have more control over the device and give more feedback to your users.

We will be sharing more details about WebGL support in the latest version of IE11 soon. In the meantime, we look forward to your feedback @IEDevChat or on Connect.

— David Catuhe, Principal Program Manager, Internet Explorer

Planet MozillaSnapping the puzzle together

I’ve had a picture in mind for a while: a vision of FirefoxOS + Appmaker + Webmaker mentor programs coming together to drive a new wave of creativity and content on the web. I believe this would be a way to really show what Mozilla stands for right now: putting access to the Internet in more hands and then helping people unlock the full potential of the web as a part of their lives and their livelihoods.

Puzzle pieces

The thing is: this picture has felt a bit like a puzzle until recently — I can see where it’s going, but we don’t have all the pieces. It’s like a vision or a theory more than a plan. However, over the past few months, things are getting clearer — feels like the puzzle pieces are becoming real and snapping together.

Bangladesh

Dinner w/ Mozilla Bangladesh

I had this ‘it’s coming together’ feeling in spades the other day as I had dinner w/ 20 members of the Mozilla community in Bangladesh. Across from me was a college student named Ani who was telling me about the Bengali keyboard he’d written for FirefoxOS. To his right was a woman named Maliha who was explaining how she’d helped the Mozilla Bangladesh community organize nearly 50 Webmaker workshops in the last two months. And then beside me, Mak was enthusiastically — and accurately — describing Mozilla’s new Mobile Webmaker to the rest of the group. I was rapt. And energized.

More importantly, I was struck by how the people around the table had nearly all the pieces of the puzzle amongst them. At a practical level, they are all actively working on the practicalities of localizing FirefoxOS and making it work on the ground in Bangladesh. They are finding people and places to teach Webmaker workshops. They have offered to help develop and test Appmaker to see if it can really work for users in Bangladesh. And, they see how these things fit together: people around the table talked about how all these things combined have the potential for huge impact. In particular, they talked about the role phones, skills and publishing tools built with Mozilla values could unleash a huge wave of Bengali language content onto the mobile internet. In a country where less than 10% of people speak English. This is a big deal.

The overall theory behind this puzzle is: open platforms + digital skills + local content = an opportunity to disrupt and open up the mobile Internet.

IMG_20140912_204932

Well, at least, that’s my theory. I see local platforms like Firefox OS — and HTML5 in general — as the baseline. They make it possible for anyone to create apps and content for the mobile web on their own terms — and they are easy to learn. In order to unlock the potential of these platforms, we also need large numbers of people to have the skills to create their own apps and content. Which is what we’re trying to tee up with our Webmaker program. Finally, we need a huge wave of local content that smartphone users make for each other — which both Webmaker and Appmaker are meant to fuel. These are the puzzle pieces I think we need.

On this last point: the content needn’t be local per se — but it does need to be something of value to users that the web / HTML5 can provide this better than existing mobile app stores and social networks. Local apps and content — and especially local language content — is a very likely sweet spot here. The Android Play Store and Facebook are bad — or at least limited — in how they support people creating content and apps. In languages like Bengali, the web — and Mozilla — have historically been much better.

But it’s a theory with enough promise — with enough pieces of the puzzle coming together — that we should get out there and test it out in practice. Doing this will require both discipline and people on the ground. Luckily, the Mozilla community has these things in spades.

India Community

Mozillians at Webmaker event in Pune

Talking with a bunch of people from the Mozilla India community underlined this part of things for me — and helped my thinking on how to test the local content theory. Vineel, Sayak and others told me about the recent launch of low cost Firefox OS smartphones in India — including a $33/R1999 phone from a company called Intex. As with Firefox releases in many other countries, the core launch team behind this effort were volunteer Mozilla contributors.
Working with Mozilla marketing staff from Taiwan, members of the Mozilla India community made a plan, trained Intex sales staff and promoted the phone. Early results: Intex sold 15,000 units in the first three days. And things have been picking up from there.

It’s exactly this kind of community driven plan and discipline that we will need to test out the Firefox OS + Appmaker + Webmaker theory. What we need is something like:

  1. Pick a couple of places to test out our theory — India and Bangladesh are likely options, maybe also Brazil and Kenya.
  2. Work with the community to test out the ‘everyone can author an app’ software first — find out what regular users want, adapt the software with them, test again.
  3. Make sure this test includes a strong Webmaker / training component — we should be testing how to teach skills at the same time as testing the software idea.
  4. Make sure we have both phones and a v1 of Mobile Webmaker in local languages
  5. Also, work with community to develop a set of basic app templates in local language — it’s important not to have an ‘empty shelf’ and also to build around things people actually want to make.
  6. Move from research to ‘market’ testing — put Mobile Webmaker on FirefoxOS phones and do a campaign of related Webmaker training sessions.
  7. Step back. See what worked. What didn’t. Iterate. In the market.

This sort of thing is doable in the next six months — but only if we get the right community teams behind us. I’m going to work on doing just that at ReMoCamp in Berlin this weekend. If there is interest and traction, we’ll start moving ahead quickly.

In the meantime, I’d be interested in comments on my theory above. We’re going to do something like this — we need everybody’s feedback and ideas to increase the likelihood of getting it right.


Filed under: mozilla, webmakers

W3C Team blogThis week: HTML5 video, #webizen survey, w3process raised issue-124, etc.

This is the 5-12 September 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

[What was tweeted frequently, or caught my attention. Most recent first]

Open Web & net neutrality

Bruce LawsonReading List

Standards smörgåsbord

Security Soufflé

Video Dessert

A Boy And His Atom: The World’s Smallest Movie, made by moving individual atoms at IBM, magnified 100 million times.

<style>.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; height: auto; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }</style>
<iframe allowfullscreen="allowfullscreen" frameborder="0" src="http://www.youtube.com/embed/oSCX78-8-q0"></iframe>

Planet MozillaHow to test new features in Firefox 34 Aurora

If you’re a fan of free and open source software and would like to contribute to Firefox, join me for some Firefox feature testing!

There are some nifty features under development right now for Firefox 34 including translation in the browser, making voice or video calls (a feature called “Hello” or “Loop”), debugging information for web developers in the Dev Tools Inspector, and recent improvements to HTML5 gaming.

I’ve written step by step instructions on these
ways to test Firefox 34. If you would like to see what it’s like to improve a popular open source project, trying out these tasks is a good introduction.

Aurora

First, Install the Aurora version of Firefox. It is best to set it up to use multiple profiles. That ensures you don’t use your everyday version of Firefox for testing, so you won’t risk losing your usual profile information. It also makes it easy to restart Firefox with a new, clean profile with all the default settings, very useful for testing. Sometimes I realize I’m running 5 different versions of Firefox at once!

To test “Hello”, try making some voice or video calls from Firefox Aurora. You will need a friend to test with. Or, use two computers that you control. This is a good task to try while joining our chat channels, #qa or #testday on irc.mozilla.org; ask if anyone there wants to test Hello with you. The goal here is mostly to find and report new bugs.

If you test the translation infobar in Aurora you may find some new bugs. This is a fun feature to test. I like trying it on Wikipedia in many different languages, and also looking at newspapers!

If you’re a web developer, you may use Developer Tools in Firefox. I’m asking Aurora users to go through some unconfirmed bug reports, to help improve the Developer Tools Inspector.

If you like games you can test HTML5 web-based games in Firefox Aurora. This helps us improve Firefox and also helps the independent game developers. We have a list of demo games so you can play them, report glitches, and feel like a virtuous open source citizen all at once. Along the way you have opportunities to learn some interesting stuff about how graphics on the web can work (or not work).

Monster madness

These testing tasks are all set up in One and Done, Mozilla QA’s site to start people along the path to joining our open source community. This site was developed with a lot of community contribution including the design and concept by long-time community member Parul and a lot of code by two interns this summer, Pankaj and Maja.

Testing gives a great view into the development process for people who may not (yet) be programmers. I especially love how transparent Mozilla’s process can be. Anyone can report a bug, visible to the entire world in bugzilla.mozilla.org. There are many people watching that incoming stream of bug reports, confirming them and routing them to developer teams, sometimes tagging them as good first bugs for new contributors. Developers who may or may not be Mozilla employees show up in the bugs, like magic . . . if you think of bugmail notifications as magic . . .

It is amazing to see this very public and somewhat anarchic collaboration process at work. Of course, it can also be extremely satisfying to see a bug you discovered and reported, your pet bug, finally get fixed.

Related posts:

Jeremy KeithWeb Components

The Extensible Web Summit is taking place in Berlin today because Web Components are that important. I wish I could be there, but I’ll make do with the live notes, the IRC channel, and the octothorpe tag.

I have conflicting feelings about Web Components. I am simultaneously very excited and very nervous. That’s probably a good sign.

Here’s what I wrote after the last TAG meetup in London:

This really is a radically new and different way of adding features to browsers. In theory, it shifts the balance of power much more to developers (who currently have to hack together everything using JavaScript). If it works, it will be A Good Thing and result in expanding HTML’s vocabulary with genuinely useful features. I fear there may be a rocky transition to this new way of thinking, and I worry about backwards compatibility, but I can’t help but admire the audacity of the plan.

And here’s what I wrote after the Edge conference:

If Web Components work out, and we get a kind emergent semantics of UI widgets, it’ll be a huge leap forward for the web. But if we end up with a Tower of Babel, things could get very messy indeed. We’ll probably get both at once.

To explain…

The exciting thing about Web Components is that they give developers as much power as browser makers.

The frightening thing about Web Components is that they give developers as much power as browser makers.

When browser makers—and other contributors to web standards—team up to hammer out new features in HTML, they have design principles to guide them …at least in theory. First and foremost—because this is the web, not some fly-by-night “platform”—is the issue of compatability:

Support existing content

Degrade gracefully

You can see those principles at work with newly-minted elements like canvas, audio, video where fallback content can be placed between the opening and closing tags so that older user agents aren’t left high and dry (which, in turn, encourages developers to start using these features long before they’re universally supported).

You can see those principles at work in the design of datalist.

You can see those principles at work in the design of new form features which make use of the fact that browsers treat unknown input types as type="text" (again, encouraging developers to start using the new input long before they’re supported in every browser).

When developers are creating new Web Components, they could apply that same amount of thought and care; Chris Scott has demonstrated just such a pattern. Switching to Web Components does not mean abandoning progressive enhancement. If anything they provide the opportunity to create whole new levels of experience.

Web developers could ensure that their Web Components degrade gracefully in older browsers that don’t support Web Components (and no, “just polyfill it” is not a sustainable solution) or, for that matter, situations where JavaScript—for whatever reason—is not available.

Web developers could ensure that their Web Components are accessible, using appropriate ARIA properties.

But I fear that Sturgeon’s Law is going to dominate Web Components. The comparison that’s often cited for Web Components is the creation of jQuery plug-ins. And let’s face it, 90% of jQuery plug-ins are crap.

This wouldn’t matter so much if developers were only shooting themselves in the foot, but because of the wonderful spirit of sharing on the web, we might well end up shooting others in the foot too:

  1. I make something (to solve a problem).
  2. I’m excited about it.
  3. I share it.
  4. Others copy and paste what I’ve made.

Most of the time, that’s absolutely fantastic. But if the copying and pasting happens without critical appraisal, a lot of questionable decisions can get propagated very quickly.

To give you an example…

When Apple introduced the iPhone, it provided a mechanism to specify that a web page shouldn’t be displayed in a zoomed-out view. That mechanism, which Apple pulled out of their ass without going through any kind of standardisation process, was to use the meta element with a name of “viewport”:

<meta name="viewport" value="...">

The value attribute of a meta element takes a comma-separated list of values (think of name="keywords": you provide a comma-separated list of keywords). But in an early tutorial about the viewport value, code was provided which showed values separated with semicolons (like CSS declarations). People copied and pasted that code (which actually did work in Mobile Safari) and so every browser must support that usage:

Many other mobile browsers now support this tag, although it is not part of any web standard. Apple’s documentation does a good job explaining how web developers can use this tag, but we had to do some detective work to figure out exactly how to implement it in Fennec. For example, Safari’s documentation says the content is a “comma-delimited list,” but existing browsers and web pages use any mix of commas, semicolons, and spaces as separators.

Anyway, that’s just one illustration of how code gets shared, copied and pasted. It’s especially crucial during the introduction of a new technology to try to make sure that the code getting passed around is of a high quality.

I feel kind of bad saying this because the introductory phase of any new technology should be a time to say “Hey, go crazy! Try stuff out! See what works and what doesn’t!” but because Web Components are so powerful I think that mindset could end up doing a lot of damage.

Web developers have been given powerful features in the past. Vendor prefixes in CSS were a powerful feature that allowed browsers to push the boundaries of CSS without creating a Tower of Babel of propietary properties. But because developers just copied and pasted code, browser makers are now having to support prefixes that were originally scoped to different rendering engines. That’s not the fault of the browser makers. That’s the fault of web developers.

With Web Components, we are being given a lot of rope. We can either hang ourselves with it, or we can make awesome …rope …structures …out of rope this analogy really isn’t working.

I’m not suggesting we have some kind of central authority that gets to sit in judgement on which Web Components pass muster (although Addy’s FIRST principles are a great starting point). Instead I think a web of trust will emerge.

If I see a Web Component published by somebody at Paciello Group, I can be pretty sure that it will be accessible. Likewise, if Christian publishes a Web Component, it’s a good bet that it will use progressive enhancement. And if any of the superhumans at Filament Group share a Web Component, it’s bound to be accessible, performant, and well thought-out.

Because—as is so often the case on the web—it’s not really about technologies at all. It’s about people.

And it’s precisely because it’s about people that I’m so excited about Web Components …and simultaneously so nervous about Web Components.

Footnotes

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