July 17, 2014

Reinventing Fire

You’re drunk FCC, go home

I just chimed in to the FCC to request that they stop the merger of Comcast and Time-Warner Cable. I don’t know if my voice will make a difference, but I do know that saying nothing will definitely not make a difference.

Here was my statement to the FCC (flawed, I’m sure, but I hope the intent and sentiment is conveyed):

Allowing the merger of Comcast and Time-Warner Cable will dramatically decrease consumer benefits and choice.

Some mergers can be good, allowing struggling companies to reduce losses; in this case, neither Comcast nor Time-Warner Cable is in a situation that needs this merger for financial stability; both companies are currently thriving in the marketplace.

Innovation and an open market for goods and services is in the best interest of the American people. This was clearly shown when the Bell System was broken up January 8, leading to the emergence of advanced competitive services, including cellular phone service, and lower prices. The FCC should take that as a model, and decrease the monopolistic merger of competitors, which decreases this innovation, price competition, and customer choice. Customer service is already notoriously poor at both companies, and decreasing customer choice is likely to make it harder for customers to receive adequate service.

Without competition, Internet providers have little incentive to provide either improved service or lower prices. The US is already widely regarded as having relatively expensive and slow Internet service compared to other industrial nations, and this merger threatens to make that worse.

In addition to the loss of benefits to the consumer, this merger threatens American jobs. When a merger occurs, service departments also merge, and workers lose their jobs. This is especially true when the mergers are in similar industries; some studies have shown an average of 19% job loss, far above the norm of 7.9% when the industries are unrelated. Comcast currently employs 136,000 people; Time-Warner Cable currently employs 51,600 people; if the average job loss takes place, that could mean approximately 35,644 jobs lost, or more conservatively 14,820 jobs, in a still-struggling employment market; many of these will be unskilled labor, which is even harder to resolve. While no laws in the US take into account the effect of job loss on mergers, this is still a factor that can be taken into account by the FCC; laws are only necessary when systemic problems arise in the behavior of key industry players and regulators, and allowing this merger could necessitate the creation of a law that would otherwise be avoided.

Please take the necessary steps to block this merger.

If you are a US citizen, you have until August 25th, 2014 to file a comment. The FCC seems to have gone out of its way to make this difficult, so here are some step-by-step instructions:

  1. Fill out the Free Press petition first just in case. Then, if you want to register your opposition independently…
  2. Go to the FCC  Electronic Comment Filing System page
  3. Enter “14-57” in the Proceeding Number field; you’ll get no immediate confirmation, but this is the code for the “Applications of Comcast Corporation and Time Warner Cable Inc. for Consent to Assign or Transfer Control of Licenses and Applications”. (Note: this is not arcane at all. That’s just an illusion.)
  4. Fill in all required personal information
  5. Ensure that the Type of Filing field is set to “Comment” (the default)
  6. Write a text document explaining why this is such a bad idea; crib mine if you like, or find a much better rationale, but be sure to be clear in your opposition (or support, if you’re a masochist).
  7. Upload your document using the Choose File button. (That’s right, you can’t just leave a comment in a text area, you have to write a separate document. The FCC seems to accept at least .txt and .doc files.) Add your optional description of the file in the Custom Description, so they know your sentiment even if they don’t open your file (which is pretty likely); I labeled mine “Block Comcast-TWC merger”.

Yay! You live in an arguably democratic country!

by Magister at July 17, 2014 07:56 AM

July 16, 2014

Reinventing Fire

A Life in a Day, in 2024

I woke up startled; my glasses were ringing. I was late for a telcon… again. I’d stayed up working too late last night.

I slipped on my glasses and answered the call. Several faces popped up a few feet in front of my eyes. Okay, so it was a videocon… sigh. I muted and blanked my glasses, switched them to speakerphone, and placed them on the table, the lenses vibrating as speakers. I pulled on some clothes and rubbed my face awake, trotting into the bathroom with my glasses in my left hand. As I splashed some water on my face, I heard my name called from my glasses on the counter; “Doug, did you get in contact with them?”

“Specs, delay,” I told my glasses, and my phone agent told the other participants, politely, “Please wait for 10 seconds for a response.”

Drying my face quickly on a towel, I put my glasses back on, looked into the mirror, unblanked the camera and unmuted the mic, and replied, “Hey, folks, yes, sorry about that. I did talk to them, and they are pretty receptive to the idea. They have their own requirements, of course, but I’m confident that we can fold those into our own.” I noticed my own face in the display, broadcast from my camera’s view of my reflection in the mirror, and hastily straightened out my sleepy hair.

A few minutes later, when the topic had changed, I opened a link that someone dropped into the call, and started reading the document in the glasses’ display. With the limited space available, I scanned it in RSVP (rapid serial visual presentation) mode, but quickly found it too distracting from the simultaneous conversation, requiring too much concentration. So I muted and blanked again, and walked down the hall to my office. Ensconced in front of my big screen, I re-routed the call to use the screen’s videocamera and display.

On the screen, it was easier to scan the document at my leisure. I could easily shift my focus back to the conversation when needed, without losing my place in the document. I casually highlighted a few passages to follow up on later, and made a few notes. I did the same with another document linked from the telcon, and my browser told me that this page was linked to from a document I’d annotated several months before. I marked it to read and correlate my notes in depth after the call. One thing that stood out immediately was that both documents mentioned a particular book; I was pretty sure I’d bought a physical copy a couple of years before, and I stepped over to my bookshelves. I set my glasses camera on auto-scan, looking for the title via OCR, and on the third set of shelves, my glasses blinked on a particular book; sure enough, I had a copy. I guess I could have simply ordered a digital version, but I already the physical edition handy, and sometimes I preferred having a real book in my hands.

My stomach started grumbling before the call ended. I decided to go out to lunch. Throwing the book and one of my tablets into my bag, I asked my glasses to pick a restaurant for me. It scanned the list of my favorites, and looked also for new restaurants with vegetarian food, looking for a nice balance between distance, ratings, and number of current patrons. “I’ve found a new food truck, with Indian-Mexican fusion. It’s rated 4.5, and there are several vegetarian options. Dave Cowles is eating there now. It’s a 7-minute drive. Is that okay, or should I keep looking?”

“Nope, sounds great. Call Dave, would you?” A map popped up, giving me an overview of the location, then faded away until it was needed. A symbol also popped up, indicating that my call to Dave had connected, on a private peer session.

“Hey, Doug, what’s up?”

“I was thinking of going to that food truck…”, I glanced up and to the right, and my glasses interpreted my eye gesture as a request for more context information, displaying the name of the restaurant, “… Curry Favor. You’re there now, right? Any good?”

“I just got here myself. Want me to stick around?”

“Yeah, I’ll be there in about 10 minutes.” I headed out the door, and unhooked my car’s charger before I jumped in. My glasses showed the next upcoming direction, and the car infographics; the car had a full charge. “Music”, I said, as I drove off; my car interface picked a playlist for me, a mix of my favorites I hadn’t heard in a while, and some new streaming stuff my music service thought I would like. As I got out of range of my house’s wifi, my glasses switched seamlessly to the car’s wifi. It was an easy drive, with my glasses displaying the optimal route and anticipating shifting traffic patterns and lights, but I still thought how nice it would be to buy one of the self-piloted cars. My car knew my destination from my glasses, and it alerted me that a parking spot had just opened up very near the food truck, so I confirmed and it reserved the spot; I’d pay an extra 50¢ to hold the spot until I arrived, but it was well worth it. My glasses read out the veggie menu options out loud on demand, and I chose the naan burrito with palak paneer and chick peas; my glasses placed my order in advance via text.

I pulled into my parking space, and my glasses blinked an icon telling me the sub-street sensor had registered my car’s presence. Great parking spot… I was right across the street from the food truck. I walked over to the benches where Dave sat. “Hey, Dave.”

We exchanged a few words, but my glasses told me my order was ready in a flash. I went to the window, and picked up my burrito; the account total came up in my view, and I picked a currency to pay it; I preferred to use my credit union’s digital currency, and was glad when the food truck’s agent accepted it. “Thanks, man,” I smiled at the cashier.

Dave and I hadn’t seen each other in a while, and we caught up over lunch. It turned out he was working on a cool new mapping project, and I drilled him for some details; it wasn’t my field, but it was interesting, and you never knew when a passing familiarity might come in handy. With his okay, my glasses recorded part of our conversation so I could make more detailed notes, and his glasses sent me some links to look at later. We finished our food quickly –it was tasty, so I left a quick positive review– and walked to a nearby coffee shop to continue the conversation. While we were talking, Dave recommended an app that I bought, and I also bought a song from the coffee shop that caught my ear from their in-house audio stream; Dave and the coffee shop each got a percentage of the sale. I learned that the coffee shop got an even bigger share of the song, because the musician had played at their shop and they’d negotiated a private contract, in exchange for promotion of her tour, which popped up in my display; that was okay, I liked supporting local businesses, and I filed away the tour dates in my calendar in case it was convenient for me to go to the show.

Dave went back to work, and I settled into the coffee shop to do some reading. First I read some of the book I’d brought, making sure to quickly glasses-scan the barcode first so I could keep a log; I found several good pieces of information, which I highlighted and commented on; my glasses tracked my gaze to OCR the text for storage and anchoring, and I subvocalized the notes. I then followed up on the links from earlier; my agent had earned its rate, having found several important correlations between the documents and my notes, as well as highly-reputed annotations from others on various annotation repos, and I thought more about next steps. I followed a few quick links to solidify my intuition, but on one link, I got stopped abruptly at an ad-wall; for whatever reason, this site insisted I watch a 15-second video rather than just opting-in to a deci-cent micropayment, as I usually did when browsing. I tolerated the video –unfortunately, if I took my glasses off while it played, the ad would know– only to find that the whole site was ad-based… intolerable, so I did some keyword searching to find an alternate site for the information.

Light reading and browsing was fine in a public place, but to get any real work done, I needed privacy. I strolled back to my car –my glasses reminding me where I’d parked– and I returned home. Back in my office, I put on some light music, and started coding. I started with a classic HTML-CSS-SVG-JS doc-app component framework on my local box, because I was old-school, and went mobile from there, adding annotated categories to words and phrases for meaning-extraction, customizing the triple-referenced structured API, dragging in a knowledge-base and vocabulary for the speech interface and translation engine, and establishing variable-usage contract terms with service providers (trying to optimize for low-cost usage when possible, and tweaking so the app would automatically switch service providers before it hit the next payment threshold… I’m cheap, and most of my users are too). I didn’t worry much about tweaking the good-enough library-default UI, since most users would barely or rarely see any layout, but rather would interact with the app through voice commands and questions, and see only microviews; I paid more attention to making sure that the agents would be able to correctly index and correlate the features and facts. Just as I was careful to separate style from content, I was careful to separate semantics from content. At some point, I reflected, AIs would get powerful enough so that information workers wouldn’t have such an easy time making a living; I wondered if we’d even need markup or APIs or standards at all, or if the whole infrastructure would be dynamic and ad-hoc. Maybe the work I was doing was making me obsolete. “‘Tis a consummation devoutly to be wished,” I thought to myself wryly.

I put the finishing touches on the app prototype, wrote some final tests, and ran through a manual scenario walk-through to pass the time while the test framework really put the app through its paces, spawning a few hundred thousand virtual unique concurrent users. Other than a few glitches to be polished up, it seemed to work well. I was pretty proud of this work; the app gave me real-time civic feedback, including drill-down visualization, on public policy statements, trawling news sites, social networks, and annotation servers for sentiment and fact-checking; it balanced opinion with cost-benefit risk-scenarios weighted by credibility and likelihood, and managed it all with voting records of representatives. It also tracked influence, either by lobbying or donations or inferred connections, and correlated company ownership chains and investments, to give a picture on who was pushing who’s buttons, and it would work equally well for boycotting products based on company profiles as it would on holding politicians accountable. As part of the ClearGov Foundation’s online voting system, it stood a chance of reforming government, though it was getting more adoption in South America and Africa than it was in the US so far. Patience, patience…

Megan came home from work with dinner from a locavore kitchen; the front door camera alerted me to her approach, and I saw she had her hands full. “Open front door,” I told the house as I rose to help her. We ate in front of the wallscreen, watching some static, non-interactive comedy streams; we were both too tired to “play-along” with plots, character POV, or camera angles, and it wasn’t really our style anyway. I hadn’t gotten enough rest the night before, so I turned in early to read; the mattress turned off the bedside light when it sensed my heart-rate and breathing slow into sleep.

Note: This story of the Web and life in 2024 is clearly fictional; nobody would hire someone who’d worked in web standards to do real programming work.

by Magister at July 16, 2014 02:03 AM

July 11, 2014

W3C Blog

This week: #i18n Personal names around the world, #HTML elements, #Web2024, etc.

This is the 4-11 July 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 (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

And, on the lighter side

Open Web & net neutrality

W3C in the Press (or blogs)

5 articles since the 4-Jul Digest; a selection follows. You may read all articles in our Press Clippings page.

by Coralie Mercier at July 11, 2014 04:11 PM

July 10, 2014

ishida >> blog

Typography questions for HTML & CSS: Korean justification

The editors of the CSS3 Text module specification are currently trying to get more information about how to handle Korean justification, particularly when hanja (chinese ideographic characters) are mixed with Korean hangul.

Should the hanja be stretched with inter-character spacing at the same time as the Korean inter-word spaces are stretched? What if only a single word fits on a line, should it be stretched using inter-character spacing? Are there more sophisticated rules involving choices of justification location, as there are in Japanese where you adjust punctuation first and do inter-character spacing later? What if the whole text is hanja, such as for an ancient document?

If you are able to provide information, take a look at what’s in the CSS3 Text module and follow the thread on public-i18n-cjk@w3.org (subscribe).

by r12a at July 10, 2014 04:35 PM

July 09, 2014

W3C Blog

W3C Highlights (June 2014) and Webizen Next Steps

Last month the W3C Membership gathered in Cambridge for one of our bi-annual meetings. At these meetings we discuss recent and upcoming work, the health and evolution of the organization, and new imperatives driven by changes around us. I invite you to read W3C Highlights - June 2014, which the W3C staff prepared for the participants.

Those who come to the meeting are passionate about the Open Web. Though the critiques at these meetings can be sharp, the attendees all want to work together to Lead the Web to its Full Potential. Outside of big group discussions, at meals and in hallways we give ourselves the time to listen.

Here’s an example. In the months leading up to the June meeting, I chaired a public task force to develop a proposal that gives individual developers a greater voice within W3C. I presented the draft “Webizen” proposal to the Membership who had concerns about its current form. Fortunately, during the meeting and then by email, a number of people volunteered to help us turn the idea into a successful program.

We have launched a new task force with solid Member participation to determine next steps. That task force remains open to the public; our discussions take place on public-webizen@w3.org (archive). Our next face-to-face opportunity to share a proposal with the Membership will be during TPAC 2014 in October.

by Jeff Jaffe at July 09, 2014 07:11 PM

July 04, 2014

W3C Blog

This week: input APIs collaborations, W3C TAG by-election, etc.

This is the 27 June – 4 July 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 (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

And, on the lighter side

  • Markup pun galore in Twitter thread (via @tenderlove)
  • “In W3C, browser devs consult the reference copy of the CSS spec that’s kept in a humidity-controlled glass case” [image (via @brucel)]

Open Web & net neutrality

W3C in the Press (or blogs)

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

by Coralie Mercier at July 04, 2014 05:59 PM

Books in Browsers event in San Francisco, 23-25 October

The goal of the W3C’s Digital Publishing Activity is to help make the Open Web Platform perfectly suitable for the needs of the Publishing industry, which also means helping to build the necessary bridges between that community and the Web Community at large. As such, the call for papers for the “Books in Browsers: Advancing Open Web Standards and Digital Publishing” event has a great interest for W3C.

Books in Browsers is a summit for the new generation of internet publishing companies, focusing on developers and designers who are building and launching tools for online storytelling, expression, and art. From the announcement:

Over the last four years, Books in Browsers has advanced from a discussion of how startups might optimize existing publisher workflows to an exploration of the concept of “craft” in digital-native authoring and reading environments. This focus is bumping up squarely against the current limitations of web browsers to author, display, and link page elements together in ways that liberate the next generation of digital publishing.

Simultaneously, there is a burst of interest in how evolving web standards can advance publishing, and reciprocally how the frontiers of design, user interaction, and narrative can inform the objectives for web standards, common open source tools, and widely deployed services. One of the most obvious signposts of this engagement is the emergence of the W3C Digital Publishing Interest Group (DigPub IG).

The event will take place in San Francisco, on the 23-25 October, at the Gray Area Foundation for the Arts. W3C is pleased to contribute to the event, co-hosted by by the Hypothes.is Project and the Frankfurt Book Fair (FBF).

by Ivan Herman at July 04, 2014 07:41 AM

June 30, 2014

Decentralyze - Programming the Data Cloud


I have an idea that I think is very important but I haven’t yet polished to the point where I’m comfortable sharing it. I’m going to share it anyway, unpolished, because I think it’s that useful.

So here I am, handing you a dull, gray stone, and I’m saying there’s a diamond inside. Maybe even a dilithium crystal. My hope is that a few experts will see what I see and help me safely extract it. Or maybe someone has already extracted it, and they can just show me.

The problem I’m trying to solve is at the core of decentralized (or loosely-coupled) systems. When you have an overall system (like the Web) composed of many subsystems which are managed on their own authority (websites), how can you add new features to the system without someone coordinating the changes?

RDF offers a solution to this, but it turns out to be pretty hard to put into practice. As I was thinking about how to make that easier, I realized my solution works independently of the rest of RDF. It can be applied to JSON, XML, or whatever. For now, I’m going to start with JSON.

Consider two on-the-web temperature sensors:

 > GET /temp HTTP/1.1
> Host: paris.example.org
> Accept: text/json
< HTTP/1.1 200 OK
< Content-Type: text/json
 > GET /temp HTTP/1.1
> Host: berkeley.example.org
> Accept: text/json
< HTTP/1.1 200 OK
< Content-Type: text/json

The careful human reader will immediately wonder whether these temperatures are in Celcius or Fahrenheit, or if maybe the first is in Celcius and the second Fahrenheit. This is a trivial example of a much deeper problem.

Here’s the first sketch of my solution:

 > GET /temp HTTP/1.1
> Host: paris.example.org
> Accept: text/json
< HTTP/1.1 200 OK
< Content-Type: text/json
{"GrowJSONVersion": 0.1,
"defs": {
"temp": "The temperature in degrees Fahrenheit as measured by a sensor and expressed as a JSON number"

> GET /temp HTTP/1.1
> Host: berkeley.example.org
> Accept: text/json
< HTTP/1.1 200 OK
< Content-Type: text/json
{"GrowJSONVersion": 0.1,
"defs": {
"temp": "The temperature in degrees Fahrenheit as measured by a sensor and expressed as a JSON number"

I know it looks ugly, but now it’s clear that both readings are in Fahrenheit.

My proposal is that much like some data-consuming systems do schema validation now, GrowJSON data-consuming systems would actually look for that exact definition string.

This way, if a third sensor came on line:

 > GET /temp HTTP/1.1
> Host: doha.example.org
> Accept: text/json
< HTTP/1.1 200 OK
< Content-Type: text/json
{"GrowJSONVersion": 0.1,
"defs": {
"temp": "The temperature in degrees Celcius as measured by a sensor and expressed as a JSON number"

the software could automatically determine that it does not contain data in the format it was expecting. In this case, a human could easily read the definition and make the software handle both formats.

That’s the essence of the idea. Any place you might have ambiguity or a naming collision in your JSON, instead use natural language definitions that are detailed enough that (1) two people are very unlikely to chose the same text, and (2) if they did, they’re extremely likely to have meant the same thing, and while we’re at it (3) will help people implement code to handle it.

I see you shaking your head in disbelief, confusion, or possibly disgust. Let me try answering a few questions:

Question: Are you really suggesting every JSON document would include complete documentation of all the fields used in that JSON document?

Conceptually, yes, but in practice we’d want to have an “import” mechanism, allowing those definitions to be in another file or Web Resource. That might look something like:

 > GET /temp HTTP/1.1
> Host: paris.example.org
> Accept: text/json
< HTTP/1.1 200 OK
< Content-Type: text/json
{"GrowJSONVersion": 0.1}
{"import": "http://example.org/schema",
"requireSHA256": "7998bb7d2ff3cfa2666016ea0cd7a379b42eb5b0cebbb1142d8f086efaccfbc6",
 > GET /schema HTTP/1.1
> Host: example.org
> Accept: text/json
< HTTP/1.1 200 OK
< Content-Type: text/json
{"GrowJSONVersion": 0.1,
"defs": {
"temp": "The temperature in degrees Fahrenheit as measured by a sensor and expressed as a JSON number"

Question: Would that break if you didn’t have a working Internet connection?

No, by including the SHA we make it clear the bytes aren’t allowed to change. So the data-consumer can actually hard-code the results of retrieval obtained at build time.

Question: Would the data-consumer have to copy the definition without changing one letter?

Yes, because the machines don’t know which letters might be important. In practice the person programming the data-consumer could do the same kind of import, referring to the same frozen schema on the Web, if they want to. Or they can just cut-and-paste the definitions they are using.

Question: Would the object keys still have to match?

No, only the definitions. If the Berkeley sensor used tmp instead of temp, the consumer would still be able to understand it just the same.

Question: Is that documentation string just plaintext?

I’m not sure yet. I wish markdown were properly standardized, but it’s not. The main kind of formatting I want in the definitions is links to other terms defined in the same document. Something like these [[term]] expressions:

{"GrowJSONVersion": 0.1,
"defs": {
"temp": "The temperature in degrees Fahrenheit as measured by a sensor at the current [[location]] and expressed as a JSON number"
"location": "The place where the temperature reading [[temp]] was taken, expressed as a JSON array of two JSON numbers, being the longitude and latitude respectively, expressed as per GRS80 (as adopted by the IUGG in Canberra, December 1979)"

As I’ve been playing around with this, I keep finding good documentation strings include links to related object keys (properties), and I want to move the names of the keys outside the normal text, since they’re supposed to be able to change without changing the meaning.

Question: Can I fix the wording in some definition I wrote?

Yes, clearly that has to be supported. It would be done by keeping around the older text as an old version. As long as the meaning didn’t change, that’s okay.

Question: Does this have to be in English?

No. There can be multiple languages available, just like having old versions available. If any one of them matches, it counts as a match.


by sandhawke at June 30, 2014 09:17 PM

June 27, 2014

W3C Blog

This week: #663399, W3C comma tools, Firefox WebIDE, etc.

This is the 20-27 June 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 (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

Open Web & net neutrality

W3C in the Press (or blogs)

8 articles since the 20-Jun Digest; a selection follows. You may read all articles in our Press Clippings page.

by Coralie Mercier at June 27, 2014 04:27 PM

June 20, 2014

W3C Blog

This week: Picture Element, #HTML5 Last Call, #W3C20 Symposium, Tim Berners-Lee celebrated #web25 at #FENS2014, #663399becca, etc.

This is the 13-20 June 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 (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

Open Web & net neutrality

W3C in the Press (or blogs)

22 articles since the 2-Jun Digest; a selection follows. You may read all articles in our Press Clippings page.

by Coralie Mercier at June 20, 2014 03:04 PM

June 18, 2014

koalie’s contemplations in markup


— Arrête de crapoter ! s’exclame-t-il, passablement excédé.

C’est un jeune garçon, il semble, dont la voix n’a pas mué. Il s’adresse à un autre garçon, dont la voix est encore plus enfantine.

Il y a un collège pas loin d’ici, alors ils se planquent sur le terrain vague de l’ancienne laiterie, à l’ombre des chênes, pour partager un clope. Ils sont juste derrière l’épaisse haie au fond du jardin.

J’aimerais apparaître devant eux et leur dire de crapoter –mieux, de jeter leur mégot, leur paquet de clope et leur briquet, et d’aller se démarquer différemment. Faites du hip-hop si c’est votre truc, les gars !

Alors qu’ils se demandent à quelle heure ils vont se lever et comment s’habiller pour un événement lambda, je songe à mes années collège.

Si un adulte est apparu alors que je clopais dans l’allée contiguë à la sortie de l’école, je l’ai oublié. S’il a parlé, j’ai oublié ce qu’il a dit. J’ai même oublié avec qui j’ai commencé à cloper.

by koalie at June 18, 2014 10:49 AM

June 17, 2014

W3C Blog

HTML5: On Our Way to Recommendation

In 2012, the HTML Working Group Chairs came up with a plan to progress HTML, aka “Plan 2014“. The plan has several objectives:

  • Produce a W3C Recommendation for HTML 5.0 before the end of 2014, as well as a W3C Recommendation for HTML 5.1 before the end of 2016;
  • Use the Candidate Recommendation of HTML5, which started in December 2012, to focus the testing effort where it is appropriate;
  • Use modularity to manage the size and complexity of the specifications.

Over the past 2 years, we have continued to refine and improve the HTML 5.0 specification. The HTML Working Group receives and tracks proposals from a variety of people in the community, most prominently from the WHATWG. During the past 2 years, the HTML5 editors have worked with the community to exchange ideas and thus avoid divergence among specifications. The HTML Landscape lists the differences between various HTML specifications.

The HTML Working Group today has 97,000 tests for HTML5. As part of satisfying the W3C process requirements for Candidate Recommendation, we have tracked implementations of HTML5 features, and test results today show that there are at least 2 implementations for 96.7% of the available tests. What about the other 3.3%? Those failures arise from how different browsers handle errors, and the Working Group has concluded that these failures do not reflect differences in implementations that will significantly affect interoperability of real-world running code. Following the test results, we removed several features from HTML 5.0 due to their lack of implementations and stability, including the dialog element and scoped style sheet. Those features remain in the draft HTML 5.1 specification for the time being.

W3C would like to thank the community for helping to build this valuable test suite. The tests come from the Test the Web Forward community effort and the contributors to the web-platform-tests github repository, and we strongly encourage Web developers to continue to contribute to the testing effort and help make the Open Web Platform reliable. At the moment, the HTML Working Group is specifically looking for additional HTML 5.0 tests related to media elements and page navigation.

As planned, given the substantive changes made to the document, we’re returning HTML 5.0 to Last Call. The scope of the expected feedback at this point is limited to changes that have taken place during the Candidate Recommendation phase and the deadline is 15 July 2014. Once we have addressed the Last Call comments and finalize the test suite, we expect to move the document to Proposed Recommendation in the fall. A few features may be removed from HTML 5.0 but kept in HTML 5.1 if we can’t get enough implementations: the DataCue interface, <input type=time>, drag and drop, and the new ruby model.

Advancing HTML 5.0 towards Recommendation status is just one step in advancing the Open Web Platform, a full-fledged programming environment for rich, interactive, cross-platform applications, with HTML5 at its core. Several Groups are extending the HTML markup language, including for responsive design, performance, accessibility or additional security purposes. The HTML Working Group, the W3C Technical Architecture Group and the Web Applications Working Group, are looking to have an Extensible Web Summit in the middle of September where we will discuss the future of HTML. We expect a formal announcement in early July.

by Philippe le Hegaret at June 17, 2014 03:07 PM

June 14, 2014

koalie’s contemplations in markup

Hiroshige's Dragon In Clouds, 1830-1839

I drew Hiroshige’s “Dragon In Clouds, 1830-1839″ on iPad mini, using ArtRage. I started it last month flying back from San Francisco and finished it last week (again in planes!) during my trip to Boston.

I’m not overly happy with it. I struggled with the tools, unable to find the right brush, the right setting; even with the colours I struggled! I’m posting it for closure. There.

Hiroshige's Dragon In Clouds, 1830-1839

by koalie at June 14, 2014 09:13 PM

June 02, 2014

W3C Blog

Last week: WebRTC, Net Neutrality, HTML5 advertising defeats Flash, etc.

This is the 26 May – 2 June 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 (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

Open Web & net neutrality

W3C in the Press (or blogs)

7 articles since the 26-May Digest; a selection follows. You may read all articles in our Press Clippings page.

by Coralie Mercier at June 02, 2014 05:34 PM

May 28, 2014

ishida >> blog

Universal Access discussions in Oman

Factoids listed at the start of the EURid/UNESCO World Report on IDN Deployment 2013

5.1 million IDN domain names

Only 2% of the world’s domain names are in non-Latin script

The 5 most popular browsers have strong support for IDNs in their latest versions

Poor support for IDNs in mobile devices

92% of the world’s most popular websites do not recognise IDNs as URLs in links

0% of the world’s most popular websites allow IDN email addresses as user accounts

99% correlation between IDN scripts and language of websites (Han, Hangkuk, Hiragana, Katakana)

About two weeks ago I attended the part of a 3-day Asia Pacific Top Level Domain Association (APTLD) meeting in Oman related to ‘Universal Acceptance’ of Internationalized Domain Names (IDNs), ie. domain names using non-ASCII characters. This refers to the fact that, although IDNs work reasonably well in the browser context, they are problematic when people try to use them in the wider world for things such as email and social media ids, etc. The meeting was facilitated by Don Hollander, GM of APTLD.

Here’s a summary of information from the presentations and discussions.

(By the way, Don Hollander and Dennis Tan Tanaka, Verisign, each gave talks about this during the MultilingualWeb workshop in Madrid the week before. You can find links to their slides from the event program.)

Basic proposition

International Domain Names (IDNs) provide much improved accessibility to the web for local communities using non-Latin scripts, and are expected to particularly smooth entry for the 3 billion people not yet web-enabled. For example, in advertising (such as on the side of a bus) they are easier and much faster to recognise and remember, they are also easier to note down and type into a browser.

The biggest collection of IDNs is under .com and .net, but there are new Brand TLDs emerging as well as IDN country codes. On the Web there is a near-perfect correlation between use of IDNs and the language of a web site.

The problems tend to arise where IDNs are used across cultural/script boundaries. These cross-cultural boundaries are encountered not just by users but by implementers/companies that create tools, such as email clients, that are deployed across multilingual regions.

It seems to be accepted that there is a case for IDNs, and that they already work pretty well in the context of the browser, but problems in widespread usage of internationalized domain names beyond the browser are delaying demand, and this apparently slow demand doesn’t convince implementers to make changes – it’s a chicken and egg situation.

The main question asked at the meeting was how to break the vicious cycle. The general opinion seemed to lean to getting major players like Google, Microsoft and Apple to provide end-to-end support for IDNs throughout their produce range, to encourage adoption by others.


Domain names are used beyond the browser context. Problem areas include:

  • email
    • email clients generally don’t support use of non-ascii email addresses
    • standards don’t address the username part of email addresses as well as domain
    • there’s an issue to do with smptutf8 not being visible in all the right places
    • you can’t be sure that your email will get through, it may be dropped on the floor even if only one cc is IDN
  • applications that accept email IDs or IDNs
    • even Russian PayPal IDs fail for the .рф domain
    • things to be considered include:
      • plain text detection: you currently need http or www at start in google docs to detect that something is a domain name
      • input validation: no central validation repository of TLDs
      • rendering: what if the user doesn’t have a font?
      • storage & normalization: ids that exist as either IDN or punycode are not unique ids
      • security and spam controls: Google won’t launch a solution without resolving phishing issues; some spam filters or anti-virus scanners think IDNs are dangerous abnormalities
      • other integrations: add contact, create mail and send mail all show different views of IDN email address
  • search: how do you search for IDNs in contacts list?
    • search in general already works pretty well on Google
    • I wasn’t clear about how equivalent IDN and Latin domain names will be treated
  • mobile devices: surprisingly for the APTLD folks, it’s harder to find the needed fonts and input mechanisms to allow typing IDNs in mobile devices
  • consistent rendering:
    • some browsers display as punycode in some circumstances – not very user friendly
    • there are typically differences between full and hybrid (ie. partial) int. domain names
    • IDNs typed in twitter are sent as punycode (mouse over the link in the tweet on a twitter page)


Google are working on enabling IDN’s throughout their application space, including Gmail but also many other applications – they pulled back from fixing many small, unconnected bugs to develop a company wide strategy and roll out fixes across all engineering teams. The Microsoft speaker echoed the same concerns and approaches.

In my talk, I expressed the hope that Google and MS and others would collaborate to develop synergies and standards wherever feasible. Microsoft, also called for a standard approach rather than in-house, proprietary solutions, to ensure interoperability.

However, progress is slow because changes need to be made in so many places, not just the email client.

Google expects to have some support for international email addresses this summer. You won’t be able to sign up for Arabic/Chinese/etc email addresses yet, but you will be able to use Gmail to communicate with users on other providers who have internationalized addresses. Full implementation will take a little longer because there’s no real way to test things without raising inappropriate user expectations if the system is live.

SaudiNIC has been running Arabic emails for some time, but it’s a home-grown and closed system – they created their own protocols, because there were no IETF protocols at the time – the addresses are actually converted to punycode for transmission, but displayed as Arabic to the user (http://nic.sa).

Google uses system information about language preferences of the user to determine whether or not to display the IDN rather than punycode in Chrome’s address bar, but this could cause problems for people using a shared computer, for example in an internet café, a conference laptop etc. They are still worrying about users’ reactions if they can’t read/display an email address in non-ASCII script. For email, currently they’re leaning towards just always showing the Unicode version, with the caveat that they will take a hard line on mixed script (other than something mixed with ASCII) where they may just reject the mail.

A trend to note is a growing number of redirects from IDN to ASCII, eg. http://правительство.рф page shows http://government.ru in the address bar when you reach the site.

Other observations

All the Arabic email addresses I saw were shown fully right to left, ie. <tld><domain>@<username>. I wonder whether this may dislodge some of the hesitation in the IETF about the direction in which web addresses should be displayed – perhaps they should therefore also flow right-to-left?? (especially if people write domain names without http://, which these guys seem to think they will).

Many of the people in the room wanted to dispense with the http:// for display of web addresses, to eliminate the ASCII altogether, also get rid of www. – problem is, how to identify the string as a domain name – is the dot sufficient?? We saw some examples of this, but they had something like “see this link” alongside.

By the way, Google is exploring the idea of showing the user, by default, only the domain name of a URL in future versions of the Chrome browser address bar. A Google employee at the workshop said “I think URLs are going away as far as something to be displayed to users – the only thing that matters is the domain name … users don’t understand the rest of the URL”. I personally don’t agree with this.

One participant proposed that government mandates could be very helpful in encouraging adaptation of technologies to support international domain names.

My comments

I gave a talk and was on a panel. Basically my message was:

Most of the technical developments for IDN and IRIs were developed at the IETF and the Unicode Consortium, but with significant support by people involved in the W3C Internationalization Working Group. Although the W3C hasn’t been leading this work, it is interested in understanding the issues and providing support where appropriate. We are, however, also interested in wider issues surrounding the full path name of the URL (not just the domain name), 3rd level domain labels, frag ids, IRI vs punycode for domain name escaping, etc. We also view domain names as general resource identifiers (eg. for use in linked data), not just for a web presence and marketing.

I passed on a message that groups such as the Wikimedia folks I met with in Madrid the week before are developing a very wide range of fonts and input mechanisms that may help users input non-Latin IDs on terminals, mobile devices and such like, especially when travelling abroad. It’s something to look into. (For more information about Wikimedia’s jQuery extensions, see here and here.)

I mentioned the idea of bidi issues related to both the overall direction of Arabic/Hebrew/etc URLs/domain names, and the more difficult question about to handle mixed direction text that can make the logical http://www.oman/muscat render to the user as http://www.muscat/oman when ‘muscat’ and ‘oman’ are in Arabic, due to the default properties of the Unicode bidi algorithm. Community guidance would be a help in resolving this issue.

I said that the W3C is all about getting people together to find interoperable solutions via consensus, and that we could help with networking to bring the right people together. I’m not proposing that we should take on ownership of the general problem of Universal Acceptance, but I did suggest that if they can develop specific objectives for a given aspect of the problem, and identify a natural community of stakeholders for that issue, then they could use our Community Groups to give some structure to and facilitate discussions.

I also suggested that we all engage in grass-roots lobbying, requesting that service/tool providers allow us to use IDNs.


At the end of the first day, Don Hollander summed up what he had gathered from the presentations and discussions as follows:

People want IDNs to work, they are out there, and they are not going away. Things don’t appear quite so dire as he had previously thought, given that browser support is generally good, closed email communities are developing, and search and indexing works reasonably well. Also Google and Microsoft are working on it, albeit perhaps slower than people would like (but that’s because of the complexity involved). There are, however, still issues.

The question is how to go forward from here. He asked whether APTLD should coordinate all communities at a high level with a global alliance. After comments from panelists and participants, he concluded that APTLD should hold regular meetings to assess and monitor the situation, but should focus on advocacy. The objective would be to raise visibility of the issues and solutions. “The greatest contribution from Google and Microsoft may be to raise the awareness of their thousands of geeks.” ICANN offered to play a facilitation role and to generate more publicity.

One participant warned that we need a platform for forward motion, rather than just endless talking. I also said that in my panel contributions. I was a little disappointed (though not particularly surprised) that APTLD didn’t try to grasp the nettle and set up subcommittees to bring players together to take practical steps to address interoperable solutions, but hopefully the advocacy will help move things forward and developments by companies such as Google and Microsoft will help start a ball rolling that will eventually break the deadlock.

by r12a at May 28, 2014 10:01 AM

W3C Blog

Last week: EmotionML is a Recommendation, Specifiction, TimBL at the Webbys, Web Cryptography, etc.

This is the 19-26 May 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 (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

Open Web & net neutrality

  • Webby Awards 2014: Sir Tim Berners-Lee’s remarks on the history and the future of the Web, including “Up to us.”, a plea for Net Neutrality (21 May 2014)

W3C in the Press (or blogs)

1 article since the 19-May Digest. You may read all articles in our Press Clippings page.

by Coralie Mercier at May 28, 2014 07:51 AM

May 23, 2014

ishida >> blog

Typography questions for HTML & CSS:Arabic justification

I’ve been trying to understand how web pages need to support justification of Arabic text, so that there are straight lines down both left and right margins.

The following is an extract from a talk I gave at the MultilingualWeb workshop in Madrid at the beginning of May. (See the whole talk.) It’s very high level, and basically just draws out some of the uncertainties that seem to surround the topic.

Let’s suppose that we want to justify the following Arabic text, so that there are straight lines at both left and right margins.

Unjustified Arabic text

Arabic justification #1

Generally speaking, received wisdom says that Arabic does this by stretching the baseline inside words, rather than stretching the inter-word spacing (as would be the case in English text).

To keep it simple, lets just focus on the top two lines.

One way you may hear that this can be done is by using a special baseline extension character in Unicode, U+0640 ARABIC TATWEEL.

Justification using tatweels

Arabic justification #2

The picture above shows Arabic text from a newspaper where we have justified the first two lines using tatweels in exactly the same way it was done in the newspaper.

Apart from the fact that this looks ugly, one of the big problems with this approach is that there are complex rules for the placement of baseline extensions. These include:

  • extensions can only appear between certain characters, and are forbidden around other characters
  • the number of allowable extensions per word and per line is usually kept to a minimum
  • words vary in appropriateness for extension, depending on word length
  • there are rules about where in the line extensions can appear – usually not at the beginning
  • different font styles have different rules

An ordinary web author who is trying to add tatweels to manually justify the text may not know how to apply these rules.

A fundamental problem on the Web is that when text size or font is changed, or a window is stretched, etc, the tatweels will end up in the wrong place and cause problems. The tatweel approach is of no use for paragraphs of text that will be resized as the user stretches the window of a web page.

In the next picture we have simply switched to a font in the Naskh style. You can see that the tatweels applied to the word that was previously at the end of the first line now make the word to long to fit there. The word has wrapped to the beginning of the next line, and we have a large gap at the end of the first line.

Tatweels in the wrong place due to just a font change

Arabic justification #3

To further compound the difficulties mentioned above regarding the rules of placement for extensions, each different style of Arabic font has different rules. For example, the rules for where and how words are elongated are different in the Nastaliq version of the same text which you can see below. (All the characters are exactly the same, only the font has changed.) (See a description of how to justify Urdu text in the Nastaliq style.)

Same text in the Nastaliq font style

Arabic justification #4: Nastaliq

And fonts in the Ruqah style never use elongation at all. (We’ll come back to how you justify text using Ruqah-style fonts in a moment.)

Same text in the Ruqah font style

Arabic justification #5: Ruqah

In the next picture we have removed all the tatweel characters, and we are showing the text using a Naskh-style font. Note that this text has more ligatures on the first line, so it is able to fit in more of the text on that line than the first font we saw. We’ll again focus on the first two lines, and consider how to justify them.

Same text in the Naskh font style

Arabic justification #6: Naskh

High end systems have the ability to allow relevant characters to be elongated by working with the font glyphs themselves, rather than requiring additional baseline extension characters.

Justification using letter elongation (kashida)

Arabic justification #7: kashida elongation

In principle, if you are going to elongate words, this is a better solution for a dynamic environment. It means, however, that:

  1. the rules for applying the right-sized elongations to the right characters has to be applied at runtime by the application and font working together, and as the user or author stretches the window, changes font size, adds text, etc, the location and size of elongations needs to be reconfigured
  2. there needs to be some agreement about what those rules are, or at least a workable set of rules for an off-the-shelf, one-size-fits-all solution.

The latter is the fundamental issue we face. There is very little, high-quality information available about how to do this, and a lack of consensus about, not only what the rules are, but how justification should be done.

Some experts will tell you that text elongation is the primary method for justifying Arabic text (for example), while others will tell you that inter-word and intra-word spacing (where there are gaps in the letter-joins within a single word) should be the primary approach, and kashida elongation may or may not be used in addition where the space method is strained.

Justification using inter-word spacing

Arabic justification #8: space based

The space-based approach, of course, makes a lot of sense if you are dealing with fonts of the Ruqah style, which do not accept elongation. However, the fact that the rules for justification need to change according to the font that is used presents a new challenge for a browser that wants to implement justification for Arabic. How does the browser know the characteristics of the font being used and apply different rules as the font is changed? Fonts don’t currently indicate this information.

Looking at magazines and books on a recent trip to Oman I found lots of justification. Sometimes the justification was done using spaces, other times using elongations, and sometimes there was a mixture of both. In a later post I’ll show some examples.

By the way, for all the complexity so far described this is all quite a simplistic overview of what’s involved in Arabic justification. For example, high end systems that justify Arabic text also allow the typesetter to adjust the length of a line of text by manual adjustments that tweak such things as alternate letter shapes, various joining styles, different lengths of elongation, and discretionary ligation forms.

The key messages:

  1. We need an Arabic Layout Requirements document to capture the script needs.
  2. Then we need to figure out how to adapt Open Web Platform technologies to implement the requirements.
  3. To start all this, we need experts to provide information and develop consensus.

Any volunteers to create an Arabic Layout Requirements document? The W3C would like to hear from you!

by r12a at May 23, 2014 07:32 PM

Typography questions for HTML & CSS:Korean line breaking rules

When it comes to wrapping text at the end of a line in a web page, there are some special rules that should be applied if you know the language of the text is either Chinese or Japanese (ie. if the markup contains a lang attribute to that effect).

The CSS3 Text module attempts to describe these rules, and we have some tests to check what browsers currently do for Japanese and Chinese.

There’s an open question in the editor’s draft about whether Korean has any special behaviours that need to be documented in the spec, when the markup uses lang to identify the content as Korean.

If you want to provide information, take a look at what’s in the CSS3 Text module and write to www-international@w3.org and copy public-i18n-cjk@w3.org.

by r12a at May 23, 2014 02:18 PM

Typography questions for HTML & CSS:Effect of markup and styling on cursive script (eg. Arabic)

If you put a span tag around one or two letters in an Arabic word, say to change the colour, it breaks the cursiveness in WebKit and Blink browsers. You can change things like colour in Mozilla and IE, but changing the font breaks the connection.

Breaking on colour change makes it hard to represent educational texts and things such as the Omantel logo, which I saw all over Muscat recently. (Omantel is the largest internet provider in Oman.) Note how, despite the colour change, the Arabic letters in the logo below (on the left) still join.

Picture of the Omantel logo. Multi-coloured Omantel logo on a building in Muscat.

Here’s an example of an educational page that colours parts of words. You currently have to use Firefox or IE to get the desired effect.

This lead to questions about what to do if you convert block elements, such as li, into inline elements that sit side by side. You probably don’t want the character at the end of one li tag to join with the next one. What if there is padding or margins between them, should this cause bidi isolation as well as preventing joining behaviour?

See a related thread on the W3C Internationalization and CSS lists.

by r12a at May 23, 2014 12:35 PM

May 22, 2014

koalie’s contemplations in markup


– “Drôle de temps,” dit mon voisin. Il se parle souvent à voix haute.

Chacun sur sa terrasse, séparés par l’épaisse haie de thuyas, nous nous faisons la même réflexion sur le temps.

Le ciel est gris, très gris, et le vent souffle. Par moment, la lumière semble émaner du sol et se reflète sur les nuages. C’est assez beau.

by koalie at May 22, 2014 08:27 AM