Florian’s Blog

Running Bikeshed on Termux

I like treating my phone like the general purpose computer that it is, so I’m a big fan of Termux, which lets you have a full blown Linux environment on your Android device.

Since my work involves writing and editing specs, one tool I use a lot is Bikeshed, a spec-generating tool that takes in lightly-decorated Markdown and spits out a full spec, with cross-spec auto-linking, automatic generation of indexes/ToC/etc, and many other features.

Put the two together, and you can build specifications right on your phone, which I find a lot of fun.

Here’s how to get it to work.

Installing Dependencies

# get yourself a compiler
pkg install clang
# dependencies of later stages
pkg install libxml2 libxslt libjpeg-turbo
# bikeshed is a python program
pkg install python

Installing Bikeshed

pip install bikeshed

If that works, you’re done. Go bikeshed away to your heart’s delight.


Unfortunately, it might not work. lxml is a dependency of Bikeshed which will get pulled in by pip when trying to install Bikeshed. However, it is very demanding to compile, and many android devices will run out of memory and crash when trying. This is a known issue, and Termux normally lets you work around that by providing a precompiled version. Unfortunately, that doesn’t help us because Termux’s pkg tool only keeps track of a single version of each package, and the one it has for python-lxml isn’t the one Bikeshed wants.

Instead, do this:

CFLAGS="-O0" pip install lxml==5.1.0

Compiling with optimizations turned off significantly reduces how much memory it takes to successfully compile lxml, making it work on many more devices. I presume that makes it slower too, but I haven’t found that to make an obvious difference when using Bikeshed.

Once that goes through, have another shot at installing Bikeshed:

pip install bikeshed

Now you should be good.

Accessing your built specs

One small annoyance is that your home folder in termux is not readable by other applications on the phone/tablet, so you need to put your specs under ~/storage/shared/<whatever-you-like> if you want to be able to reach them via file://sdcard/<whatever-you-like> in the browser. Not a blocker, but annoying. Conveniently, Bikeshed can build your specification and serve it from a local web server:

bikeshed serve

You can then point your browser to http://localhost:8000 and view the specification you just built. Bikeshed will also rebuild and serve an updated copy everytime the source changes.

REC Track Transitions Are Too Heavy

One of the things that takes a lot of time on the W3C REC track, and make people wish for some more agile way such as evergreen or living standards is the act of publishing itself.

Thanks to Echidna, publishing a Working Draft is fine, but otherwise it takes a lot of time. Here are a few recent examples, from the W3C’s Github repository for handling transitions, about specifications I had been following or been involved in one way or another:

My point here isn’t to put blame on anyone, but to highlight that we have a major bottleneck that introduces weeks of latency into the pipeline. This is something we badly need to improve on. Incidentally, this isn’t something that would automatically be improved by the tooling changes that have been discussed for evergreen. In addition to being a regular source of frustration in Working Groups, this puts the REC track at an unnecessary disadvantage compared to the WHATWG process, the proposed evergreen track, or even to keeping things in incubation forever.

The checks that occur at transitions are nonetheless valuable. This is where we verify and enforce the criteria — such as wide review, or implementation experience — that we have collectively deemed necessary for that specific level of maturity. Even if individual specification writers could follow the same practices on their own without the Process forcing them to, these institutional checks are what makes specifications be Standards, and not just someone or some company’s possibly good idea. Nonetheless, the way we currently do these checks is heavy, and that must improve, lest we tempt people into doing away with the checks entirely.

I don’t mean we should try and go from an average 19 days (or whatever the average is now) to 11 days (or some similar better but similar figure) by nagging the W3C Team more insistently. I mean to try and go from many days to 0 days most of the time, by changing the way we approach the problem. I think we can fix this without any change to the Process.

Here’s one possible approach:

  1. For each type of transition, document the criteria for automatic approval. This is expected to be stricter than the criteria defined by the Process: there are cases where a judgement call is needed, and where the Director and his delegates will want to exercise judgement as to whether the criteria are fulfilled (e.g. “we don’t have two implementations, but in this case, it’s ok because…”). However, there should be a large enough subset publications that are routine, and that can be approved on the basis of a check-list.

  2. Turn the check-lists for each transition into online forms. For each criteria, there should be a checkbox, and a freeform text field to register (for the record) evidence in support of the criteria being fulfilled.

  3. Hook these forms into Echidna, so that when you try to publish something that involves a transition, Echidna gives you a link to the relevant form. Some of the criteria (e.g. passes Pubrules) can be determined automatically, so they should be, but the result should still be indicated in the form, with a text field to give an opportunity to explain any anomaly. For the rest, the person requesting the transition ticks the boxes and fills in explanations and supporting evidence.

  4. If they cannot tick all the boxes, they can still push a “request evaluation by the Director/Team” button, and we fall back to the same approval process as today, except everything is in structured data fields instead of freeform Github issues, and Echidna is still in the loop to publish instantly if the Director approves, instead of a manual handoff to Team contacts who may not always be instantly available.

  5. If the they are able to tick all the boxes, all the information provided is archived somewhere public, and they get to bypass the Director, and publish directly. Possibly, if we want a little bit of verification, we could send automated notifications to the chairs and team contacts of the relevant WG and ask any of them for approval, but the question would merely be to verify that the information is truthful, it wouldn’t need to be the kind of judgement call that the Director makes on actual transition calls.

  6. Done! Echidna automatically handles the rest.

For sure, this description is insufficient, and to implement a system along these lines, we’d need to be a lot more specific about what the requirements are; but hopefully the general intent of such a system is clear.

W3C Advisory Board Election

It’s that time of the year again: the W3C is running the annual election cycle to renew about half of its Advisory Board, which I have the privilege to serve on for a two-year term as a result of last year’s election.

I think this is no ordinary time in W3C history; there always are many important topics on the AB’s radar, but several current ones raise to the level of existential questions for the W3C:

To fill the 7 seats open on the AB this year, 12 candidates are running. This is an impressive list of highly qualified and motivated people, which makes me optimistic about our prospects at tackling the challenges outlined above regardless of the outcome of this election.

However, not all 12 can be elected, so AC representatives will have to vote. With the current voting system, that means ranking candidates by order of preference. I think these are all great people, and I look forward to working with those who will be elected. At the same time, there are some I am particularly excited about, and would like to encourage voters to rank them high. Here’s my top four:

  1. Elika Etemad has been a leading figure in our community for years, excelling both on technical topics as well as on governance and process questions. She is largely responsible for the success of the CSS-WG over the last 10 years, and is uniquely positioned to drive reforms at the W3C while preserving its core values.

  2. Eric Siow has been a very reasonable voice in the AC, and his strong senior management experience will be particularly valuable given the topics at hand.

  3. Although I only know him by reputation rather than personally, I am particularly impressed with the strong and relevant mix of skills and perspectives Avneesh Singh brings to the table.

  4. In addition to having views well-aligned with mine, Alan Stearns is a master consensus builder, which will come in handy as the AB can be an unwieldy group at times.

I could also say good things about many other candidates, but only the top positions in the ranking have a meaningful impact in the results of the vote. For better or worse, this is my pick.

You can also read Elika’s commentary on some of the other candidates on her blog.

If you are an AC-Rep, please vote here. If you're not but work for a W3C member, please remind your AC-Rep to vote.

Candidat à l’AB

This is the French translation of my previous post about running for the W3C AB.

Le W3C organise une élection pour renouveler 5 des 9 membres de son Advisory Board. Ayant eu l’honneur d’être nominé par l’inimitable Daniel Glazman, j’ai le plaisir d’annoncer ma candidature.

Voici la version française de la profession de foi que j’ai déposée au W3C pour cette élection :

Pour de nombreuses raisons, le W3C s’est imposé comme un acteur incontournable de la standardisation, mais il ne faut pas pour autant nous endormir sur nos lauriers. Si nous voulons offrir les meilleures conditions de travail aux projets et groupes existants, et nous assurer que les nouveaux projets ayant besoin de standardisation continuent de choisir de le faire au W3C, il faut sans arrêt sur le métier remettre notre ouvrage et travailler à l’amélioration de cette institution, sans quoi elle ne manquerait pas de perdre du terrain.

J’ai eu l’occasion de porter diverses casquettes au W3C : représentant d’un fournisseur de navigateur (Opera) au CSS-WG, Expert Invité au même CSS-WG et dans quelques autres Working Groups, AC-Rep d’une petite entreprise (Vivliostyle), co-chair d’un Community Group… J’ai édité des spécifications depuis la phase d’incubation (dans un WG aussi bien qu’au WICG) jusqu’à la publication finale sous forme de REC. Bref, je sais comment les shadoks pompent par ici, et pourquoi ils risquent de continuer longtemps à pomper si on ne s’en mêle pas un peu.

Je suis français, j’habite au Japon, j’ai vécu en Norvège et en Chine, j’ai des relations commerciales avec des entreprises américaines et coréennes… La diversité et la participation internationale sont des sujets qui me tiennent à cœur. Je tiens en particulier à permettre aux entreprises membres des pays d’Asie de se faire entendre et d’avoir leurs intérêts pris au sérieux. Les autres aspects de la question de la diversité ne m’échappent pas, et j’apporterai mon soutien à tous les efforts cherchant à rendre le W3C plus inclusif et accueillant à toutes et à tous.

Voici quelques sujets qui m’intéressent tout particulièrement:

PS: Je suis candidat indépendant, mais Kōdansha (une des plus grandes maisons d’édition du Japon) m’apporte son soutien et financera ma participation à l’AB.

PPS: Au fait, je ne suis pas seulement un geek des standards, j’ai aussi un MBA de l’INSEAD (souvent classé premier MBA au monde); mon cv complet est disponible en ligne.

Si vous êtes l’AC-Rep d’un membre du W3C, vous pouvez votez ici. Si vous n’êtes pas AC-Rep, mais que votre employeur est membre du W3C, merci d’en parler avec votre AC-Rep.

Ab 출마

This is the Korean translation of my previous post about running for the W3C AB. I would like to thank Jihye Hong (from LG Electronics) for the translation.

W3C는 곧 자문 위원회 구성원 9명 중 5명을 새로 선출하는 선거를 실시합니다. 해당 선거에 W3C 회원의 추천(Daniel께 감사드립니다)을 통하여 후보로 나서게 됨을 알려드립니다.

해당 선거를 위해 W3C에 제출한 내용은 다음과 같습니다:

여러 면에서 W3C는 표준 작업을 위한 핵심적인 역할을 해왔지만 현재의 영광에 안주하지 않아야 합니다. 세상은 계속 변하고 있고, 이에 발 맞추어 우리는 지속적으로 W3C를 더 발전시켜, 기존 프로젝트와 작업 그룹(WG)들에게 최상의 업무 환경을 제공해야 합니다. 그로 인해 표준화 추진을 위한 가장 최적의 장소로 W3C를 선택한 새로운 프로젝트들이 활발히 유입될 수 있습니다.

저에게는 그동안 W3C에서 다양한 역할을 하는 기회가 있었습니다. CSS 작업 그룹 내 브라우저 벤더인 오페라(Opera)의 대표, CSS 작업 그룹 및 다른 작업 그룹 내에서의 초청 전문가(Invited Expert), 중소기업 비빌로스타일(Vivliostyle)의 AC, 관심 그룹의 의장 등을 맡아왔습니다. 작업 그룹 및 웹 플랫폼 인큐베이터 관심 그룹(WICG) 안에서 인큐베이션부터 REC 단계에 이르기까지의 전체 진행 단계를 거치며 표준 문서를 편집해왔습니다. 이를 통해 W3C의 다양한 사업 운영과 더불어 원활히 운영되지 않는 부분이 무엇인지 잘 알고 있습니다.

프랑스인인 저는 노르웨이와 중국에 살았던 적이 있고, 현재 일본에 거주 중이며 한국 및 미국 기업과 협력하고 있습니다. 이러한 저에게 다양성과 국제 협력은 중요합니다. 특히 저는 아시아 회원사들의 생각과 관심사가 W3C 경영진에게 전달될 수 있도록 적극 지원할 것입니다. 또한 모든 분들이 W3C에 참여하기 수월하도록 노력할 것입니다.

AB로써 제가 관심있는 항목들은 다음과 같습니다:

참고 사항: 무소속으로 출마하지만, 본 직책에 대해 Kodansha(일본에서 가장 큰 출판사 중 하나)에서 지원을 받습니다. 참고로, 저는 기술 분야 이외에도 INSEAD(세계 MBA 랭킹에서 1위를 차지한 바 있는 경영대학원)의 MBA를 소지하고 있습니다. 자세한 내용은 이력서를 참고해주세요.

AC 대표분께는 여기에서 투표 참여해주시길 부탁드립니다. 이에 해당되지 않는 분께는 귀사의 AC 대표께 투표 참여 안내 부탁드립니다.


This is the Chinese translation of my previous post about running for the W3C AB. I would like to thank Bobby Tung (Co-chair of the Chinese Layout Requirement Task Force) for the translation.

W3C即将进行顾问委员会理事会的选举,这次将改选出五名新理事。我受到一名W3C会员的提名(谢谢Daniel Glazman),在此高兴地宣布参选。








如果你是AC Rep,请投票。不然请告诉你的AC Rep。


This is the Japanese translation of my previous post about running for the W3C AB.

W3Cで間もなくAB(Advisory Board)の選挙があります。ABW3Cで取締役会の一番近い役割を担っているグループです。メンバー会社に選出され、任期は2年間となります。今回は9人のうち、5人が任期満了のため、新しく5人を選出することになります。元CSS-WG議長のダニエル・グラズマンにノミネートされ、ここに立候補をしたことをお知らせ申し上げます。


様々な面から、W3Cは標準化を推し進めるための重要な場所になっていますが、安泰と思ってはいけません。世の中は色々進化していますから、 既存のプロジェクトやワーキンググループを最良の状態にするために、 そしてW3Cをベストな標準化団体として選ぶ新プロジェクトの健全な流れを維持できるように、 W3Cをより良くする継続した努力が必要です。

W3Cで多種な役割を経験して参りました:CSSワーキンググループのブラウザー会社(オペラ)の代表、CSS-WGを含む様々なWGへの無所属専門家(Invited Expert)、小企業(株式会社ビブリオスタイル)の代表(AC Rep)、 コミュニティグループの共同議長……最初のコミュニティグループ及びワーキンググループでのインキュベーションから、完成したレコメンデーション(REC)まで仕様書の担当を経験しています。これらの経験より、W3Cの様々な事業運営に精通しており、同時に円滑に進まないところも意識しています。



追記:無所属として立候補しますが、 出張費等は講談社から支援していただきます。


AC Repである方、こちらで投票ください。そうでない方、御社のAC Repに連絡してください。

Running for the AB

This post is also available in 日本語, 中文, 한국어, and français.

The W3C will soon run an election to renew 5 of the 9 members of its Advisory Board. As I have been nominated by a member of W3C (thank you Daniel), it is my pleasure to announce my candidacy.

Here is the statement I have provided to W3C for this election:

Many aspects contribute to making W3C a great venue to work on standardisation, but we should not rest on our laurels. The world does not sit still, and we need to constantly work at making W3C better, so that existing projects and working groups have the best working conditions possible, and so that we get a healthy inflow of new projects choosing the W3C as the best host for their standardization efforts.

I have had the opportunity to wear many hats at the W3C: representative of a browser vendor (Opera) to the CSS working group, invited expert to the same CSS-WG and a few other, AC representative of a small company (Vivliostyle), co-chair of a Community Group… I have edited specifications through the whole life cycle, from incubation (in a WG & in WICG) to REC. All that to say that I know how things work at W3C, and also how they sometimes don’t.

I’m from France, live in Japan, lived in Norway and China before, have business relations with Korea and the US… Diversity and global participation are important to me. In particular, I intend to make sure that Asian members get their voices and concerns heard. Other aspects of diversity are not lost on me, and I will support all efforts to make W3C an inclusive and welcoming place to all.

Topics I am particularly interested in for the AB:

PS: I am independent, but my expenses for this role will be covered by Kodansha (one of the largest Japanese publishing companies).

PPS: By the way, I’m not only a techie, I also hold a MBA from INSEAD (often ranked #1 MBA world-wide); you can read my full resume.

If you are an AC-Rep, please vote here. If you're not but work for a W3C member, please remind your AC-Rep to vote.

Moralisation de la vie publique

Note to my non-French speaking readers: This blog post is about questionable campaign practices by a candidate during the 2017 French legislative election

Le président de la république et son premier ministre ont nommé garde des sceaux M. Bayrou, avec comme premier chantier la moralisation de la vie publique, sujet qui lui tient à cœur, puisque la lutte contre les conflits d’intérêts et contre l’influence de l’argent privé dans la vie politique sont sa priorité depuis des années. Voici donc un message fort en ce début de quinquennat, et dont je me félicite.

Que faut il donc penser du fait que des évènements de la campagne électorale de Mme. Anne Genetet, candidate La République En Marche  ! dans la 11ème circonscription des français de l’étranger aux élections législatives, aient été sponsorisés ou organisées par des sociétés privées ?

Prospectus annonçant une réunion de campagne pour Mme Genetet co-organisée par la société Publicis Prospectus annonçant une réunion de campagne pour Mme Genetet co-organisée par la société BNP Paribas

L’article 11-4 de la Loi n° 88-227 du 11 mars 1988 relative à la transparence financière de la vie politique nous offre une piste de réflexion :

Les personnes morales à l’exception des partis ou groupements politiques ne peuvent contribuer au financement des partis ou groupements politiques, ni en consentant des dons, sous quelque forme que ce soit, à leurs associations de financement ou à leurs mandataires financiers, ni en leur fournissant des biens, services ou autres avantages directs ou indirects à des prix inférieurs à ceux qui sont habituellement pratiqués.

L’article L52-8 du code électoral est d’accord, et ajoute que la même chose s’applique aux candidats en campagne.

Les personnes morales, à l’exception des partis ou groupements politiques, ne peuvent participer au financement de la campagne électorale d’un candidat, ni en lui consentant des dons sous quelque forme que ce soit, ni en lui fournissant des biens, services ou autres avantages directs ou indirects à des prix inférieurs à ceux qui sont habituellement pratiqués.

Mme. Genetet a expliqué qu’elle n’a fait que participer à ces rencontres sans en être organisatrice, et qu’il ne s’agirait d’ailleurs pas des évènements politiques, mais simplement de communication d’entreprises envers les jeunes.

Les jeunes en question sont les Jeunes avec Macron. Il est tout à fait louable de participer à la vie politique et de s’engager, mais il n’en reste pas mois qu’il s’agit là d’un groupement politique. Vu que les prospectus respectent la charte graphique des Jeunes avec Macron et non celles des entreprises, il serait surprenant qu’ils ne soient pas impliqués dans l’organisation de cette rencontre. Si il est tout à fait possible que la candidate n’ai pas été elle à l’origine de cette réunion, il n’en reste pas moins qu’elle y a participé.

Quoi qu’il en soit, les lois ci-dessus interdisent qu’un service soit rendu à un parti, groupement politique, ou un candidat en campagne par une personne morale autre qu’un parti ou groupement politique sans s’intéresser à savoir qui d’entre eux est l’organisateur. Même s’il semble probable que cet incident relève plus de la négligence que de quoi que ce soit d’autre de plus sinistre, je vois néanmoins difficilement comment la mise à disposition de locaux privés pour un évènement s’inscrivant dans une campagne électorale échapperait à cette définition. Le renouveau politique n’exonère pas du respect de la loi.

Divers autres candidats[1][2][3] à la même élection semblent pour le moins dubitatifs.

Modernizing the Disposition of Comments

I’ve just produced the Disposition of Comments for the Media Queries Level 4 specification. A DoC is a W3C document whose goal is to represent that a work-in-progress specification has been widely reviewed, not only by members of the working group who writes it, but also by other relevant working groups as well as by the general public, and that these comments have all been formally addressed. Having received many comments from a diverse audience, and having addressed them, is a a key part of going from an interesting idea to a world wide standard.

Just as when I prepared the last DoC for CSS-UI-3, or the one before, or the DoC for CSS-CONTAIN, it proved to be a useful exercise, beyond merely demonstrating wide review. Every time, I find relevant comments that had been made a long time ago, but had been forgotten before reaching a conclusion, sometimes after having been discussed for a while, sometime never having been noticed at all. Preparing a DoC gives us a chance to find and address these comments.

However, every time, one aspect of the DoC strikes me as odd and outdated.

The DoC is for a specific draft, traditionally a LCWD, the last one before publication as a Candidate Recommendation. This makes a lot of sense when drafts are made in private then revealed to the world, then we get comments and address them, and repeat.

However, we do all our work in public, and continuously take in comments from both members and the general public. We no longer have an LCWD under the new process. We are increasingly in a process where we publish early publish often.

Under such a process, the last draft before CR is likely to be barely different from the one before it, which will also be similar to the one before it, etc. Showing wide review of the last draft is not very useful. A well managed document will have received wide review spread over many iterations, but the last draft will most likely not have received a lot of comments, even if many people read it, since the issues will have been ironed out before we decide we’re ready to transition to CR.

Actually, if a document has been well handled under the new process, the last draft before CR should barely receive any comment, since everything that can reasonably be discovered other than by trying to implement and pass a test suite should have been addressed already.

In practice, I believe that most recent DoCs have integrated that, and often cover a period longer than just the last draft before CR. However, partly because of habits, and partly because of the tooling used to prepare these documents, they all claim to be about a particular draft.

That’s not helpful, and I think we should change that. Going forward, DoC should declare not which draft it covers, but which period of time, and give a short justification for the starting point.

I do not think it is particularly useful for the DoC to cover the early stages of a specification when the overall design is still in flux, as many comments are invalidated by large rewrites of important parts. Different specifications mature at different speeds, so I do not think there will be a universal answer for when DoCs should start. The FPWD is probably a good guideline, as it typically signals the point where there’s agreement in the Working Group about the general design and where we start ironing out the details.

As the W3C Process does not impose any particular form for these DoC, all we need to start is to agree to start writing DoC that way, and for tools like bikeshed and Lea’s (unnamed?) tool to support this new style.