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.
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:
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.
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.
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.
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.
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.
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.
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:
We have an ongoing project to change the legal structure of the W3C
from the complex cooperation between universities it has been from the start,
to a more conventional non-profit legal entity,
and reinventing its governance along the way,
while ensuring sure that the finances are solid.
Partly overlapping with that,
is figuring out what to do with the role of the Director,
in anticipation that the founding Director and inventor of the web, Tim Berners-Lee,
may sooner or later retire.
The current model puts of lot of power and responsibility in the role of the Director,
so we need to be careful about how we reassign them.
After many years of strife between the W3C and the WHATWG
about the handling of HTML,
DOM,
and a few other specifications,
there’s finally a cooperative way forward emerging.
We now have the agreement over which this peace is supposed to be built,
but we’ve still got to make it work.
As we’re trying to make the process by which specifications are developed
more agile and in line with the needs of our time,
several approaches are being proposed:
improving the REC track which W3C has been using so far,
creating a new parallel “evergreen” track,
combining both…
This is at the core of what W3C does,
so we’d better get this right.
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:
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.
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.
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.
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.
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:
Réformes institutionnelles (entité légale, évolution du rôle du directeur, du TAG et de l’AB)
Insister sur une gestion irréprochable : transparence, respect des règles (on les applique ou on les change, mais pas de bricolage), clarifier et assumer les responsabilités…
Établir enfin des relations normales avec le WHATWG
Permettre à plus de membres actuels, en particulier hors des USA ou de l’UE, de participer pleinement et de ne pas être cantonnés à un rôle trop souvent passif
Trouver un modèle permettant de financer certains Experts Invités cruciaux sur lesquels les Working Groups s’appuient lourdement
Améliorer encore le Process et les outils associés. Par exemple:
Automatisation (éventuellement partielle) des Transition Calls sur la base de check-lists préétablies, afin de réduire les délais.
Investir plus de temps et d’argent à améliorer, débugguer, ou mettre hors service les validateurs qui bloquent abusivement les publications automatisées.
Mettre en place une procédure d’appel, jugée par l’AB, pour traiter les objections sur la forme et les violations du Process.
Mieux définir comment et quand les spécifications doivent sortir de la phase d’incubation, afin d’être sûr que cette transition ne se fasse pas trop tard (ou jamais), et que les mêmes critères soient appliqués à tous et dans tous les groupes.
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.
W3C는 곧 자문 위원회 구성원 9명 중 5명을 새로 선출하는 선거를 실시합니다. 해당 선거에 W3C 회원의 추천(Daniel께 감사드립니다)을 통하여 후보로 나서게 됨을 알려드립니다.
해당 선거를 위해 W3C에 제출한 내용은 다음과 같습니다:
여러 면에서 W3C는 표준 작업을 위한 핵심적인 역할을 해왔지만 현재의 영광에 안주하지 않아야 합니다. 세상은 계속 변하고 있고, 이에 발 맞추어 우리는 지속적으로 W3C를 더 발전시켜, 기존 프로젝트와 작업 그룹(WG)들에게 최상의 업무 환경을 제공해야 합니다. 그로 인해 표준화 추진을 위한 가장 최적의 장소로 W3C를 선택한 새로운 프로젝트들이 활발히 유입될 수 있습니다.
저에게는 그동안 W3C에서 다양한 역할을 하는 기회가 있었습니다. CSS 작업 그룹 내 브라우저 벤더인 오페라(Opera)의 대표, CSS 작업 그룹 및 다른 작업 그룹 내에서의 초청 전문가(Invited Expert), 중소기업 비빌로스타일(Vivliostyle)의 AC, 관심 그룹의 의장 등을 맡아왔습니다. 작업 그룹 및 웹 플랫폼 인큐베이터 관심 그룹(WICG) 안에서 인큐베이션부터 REC 단계에 이르기까지의 전체 진행 단계를 거치며 표준 문서를 편집해왔습니다. 이를 통해 W3C의 다양한 사업 운영과 더불어 원활히 운영되지 않는 부분이 무엇인지 잘 알고 있습니다.
프랑스인인 저는 노르웨이와 중국에 살았던 적이 있고, 현재 일본에 거주 중이며 한국 및 미국 기업과 협력하고 있습니다. 이러한 저에게 다양성과 국제 협력은 중요합니다. 특히 저는 아시아 회원사들의 생각과 관심사가 W3C 경영진에게 전달될 수 있도록 적극 지원할 것입니다. 또한 모든 분들이 W3C에 참여하기 수월하도록 노력할 것입니다.
AB로써 제가 관심있는 항목들은 다음과 같습니다:
제도 개혁 (법인 설립, 회장 / TAG / AB의 역할)
올바른 관리, 투명성, 그리고 규칙 준수
WHATWG와의 관계 정상화
기존의 회원사, 특히 미국 및 유럽 이외 회원사들의 적극적인 참여 지원
작업 그룹 내에서 핵심적인 역할을 하는 초청 전문가 지원을 위한 재정적 모델 도출
절차 및 관련 도구의 추가적인 개선.
예:
지연을 줄이기 위한 방법으로 미리 정해진 체크리스트를 사용하여 표준 단계 전환 요청 자동화 혹은 부분 자동화
표준 문서 발행 자동화에 방해가 되는 유효성 검사도구의 수정, 개선, 제거에 시간 및 비용 투자
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.
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:
Institutional reform (legal entity, role of the director / TAG / AB)
Good governance, transparency, and adhering to the rules (or changing them, but not working around)
Normalizing the relation with the WHATWG
Allow more existing members, especially outside of US/EU, to switch from “followers” to “contributors”
Find a financial model allowing to sponsor some crucial Invited Experts when working groups deeply rely on them
Further improvements to the process and related tools. Examples:
Automate or semi-automate transition calls using pre-determined check-lists to reduce delays
Spend more time and money on fixing / improving / getting rid of validators that block automated publication
Set up a light-weight appeal process handled by the AB, for process-based objections
Better define how and when specs should graduate from incubation, to make sure the transition does not happen too late (or never), and the same rules apply in all groups.
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.
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 ?
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.
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 locauxprivé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.
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.
Whole books could probably be written about this,
but here’s a little primer about
how things are today, why it is a hard problem,
and how there’s hope that it is going to get better.
TL;DR: If you want to use contenteditable now,
don’t do it directly and instead use a pre-made javascript editor,
such as CKEditor,
tiny MCE, and the like.
If they don’t do what you want,
and you need to do this yourself now,
be prepared for a lot of pain,
or for waiting for newer standards to stabilise, or both.
Now let’s dive in.
Contenteditable is an attempt at having a high level construct
that would enable rich text editing in web pages,
letting browsers do all the heavy lifting,
and letting the user (via typing, keyboard shortcuts, contextual menus…)
or the javascript (via invocations of execCommand) just ask for these things to happen.
There are a ton of entangled reasons why this is complex,
but just to get a sense of it,
here is a contrived example.
You can try playing with it here but I encourage you to think through it before trying:
Got that?
Now the user creates a selection that goes from
the last cell of the last row of the first table
to the second cell in the first row of the second table.
Then they press “a” on the keyboard.
Generally, selecting something and then typing means
replacing the selection with what was typed,
but in this case, what does that mean?
Should the browser merge the two tables?
If not, which of the two tables does the “a” go into,
and which of the table cells?
What happens to the other cells?
Are they deleted,
or do they still exist but their content is deleted?
Or do they get merged using colspan?
If you do merge the two tables, how do you do that?
Naively remove the markup that corresponds to the selection?
Make it into a 5 column table?
8 columns?
What happens to the alternating background color?
Does anything depends on whether the tables were laid out
below each other (display: table)
or besides each other (display: inline-table)?
What happens to the borders?
Did it make a difference if the first cell of the second table
was styled with user-select: none?
What about if were contenteditable=false instead?
What font and font-weight shall the inserted “a” use?
What if instead of typing “a” you try and paste from the clipboard
after copying the 3rd to 7th items of the list?
Does it affect whether the tables get merged?
Do you preserve the numbering?
What background do you get?
Do you get a border?
How about the font?
Does the same thing happen if you copy it from one browser (e.g. Firefox)
and paste into another one (e.g. Chrome)?
Would it make a difference if the styles were inline instead of cascaded?
…
There’s a million subtleties like this,
many of which don’t have an obvious correct answer,
as it depends what you’re trying to do.
The end result is that browsers are full of bugs
and are inconsistent with each other,
that the specs (ContentEditableTrue
and execCommand)
don’t cover all the cases and aren’t followed particularly closely by the browsers anyway.
Even if that was solved and everybody harmonised on one behaviour
(which isn’t happening, as browsers have mostly given up),
it still wouldn’t be good enough,
because as a user maybe that harmonised behaviour is not the one you wanted,
and now you want a separate method
or way to opt into that alternative behavior.
So web-based editors (CKEditor, TinyMCE, google docs…) go to great lengths
to work around contenteditable,
instead of using it.
For example they do live DOM diffing,
to try and figure out what contenteditable did to the document and for what reason,
undo it, and do it again in a different way.
What people are working on now
(with Johannes as a spec editor)
is a completely different approach,
where the browser does not do the heavy lifting,
and instead, just provides events to inform a javascript based editor
about what it is that the user is trying to do,
and APIs to facilitate doing that.
Step 1 in that story (which is reasonably far along)
is to make sure that everything that would cause a change in a contenteditable element
fires a Javascript event before that change occurs, which:
informs the javascript about the user intent
allows the javascript to cancel the behavior the browser was about to provide,
ensuring that nothing is changed in the contenteditable
Step 2 in that story is to provide multiple modes of contenteditable,
where contenteditable=true is the one we know today, kept for legacy reasons,
but other contenteditable=[something else than true or false] provide modes
where all the events described in step 1 still fire,
the insertion caret is still drawn,
but depending on the mode,
some of the events do not have a default action provided by the browser,
and unless js reacts to them, nothing happens at all.
contentEditable=false:
the element is not editable
contentEditable=events:
the caret is drawn
the events fire
nothing happens unless js reacts to the events
contentEditable=caret:
the caret is drawn
the caret can be moved by the user
the events fire
nothing else happens unless js reacts to the events
contentEditable=typing:
the caret is drawn
the caret can be moved by the user
the events fire
the user typing something when nothing is selected will insert text
the user attempting to move the caret will move the caret
IME-based composition of text works
nothing else happens unless js reacts to the events:
deletion (including the cut part of cut and paste) does nothing but fire an event
the paste part of cut/copy and paste does nothing but fire an event
replacement (select something then type) does nothing but fire an event
formatting commands (Ctrl+B to make something bold) does nothing but fire an event
…
contentEditable=true:
the caret is drawn
the caret can be moved by the user
the events fire
the browser has—and unless cancelled, applies—a default behaviour for all events