<Glazblog/>

The Open Web Platform is a careful and fragile construction billions of people, including millions of implementors rely on. HTML, CSS, JavaScript, the Document Object Model, the Web API and more are all standardized one way or another; that means vendors and stakeholders gather around a table to discuss all changes and that these changes must pass quality and/or availability criteria to be considered "shippable".

One notable absent from the list of Web Standards is WebExtensions. WebExtensions are the generalized name of Google Chrome Extensions that became mainstream when Google achieved dominance over the desktop browser market and when Mozilla abandoned its own, and much more powerful, addons system based on XUL and privileged scripts.

As a reminder, the WebExtension API allows coders to implement extensions to the browser based on:

• HTML/CSS/JS for each and every dialog created by the extension, including the ones "integrated" into the browser's UI
• a dual model with "background scripts" with more privileges than "content scripts" that get added to visited web pages
• a new API (the WebExtension API) that offers - and rather strictly controls - access to information that is not otherwise reachable from JavaScript
• a permissions model that declare what part of the aforementioned API the extension uses and which remote URLs the embedded scripts can access
• a URL model that puts everything in the extension under a chrome-extension:// URL
• a review process (on the Google Chrome Extension store) supposed to block harmful codes and more

A while ago, at a time Microsoft still had its own rendering engine, it initiated a Community Group on WebExtensions at the World Wide Web Consortium (W3C). With members from most browser vendors plus a few others, this seemed to be a very positive move not only for implementors but also for users.

But unfortunately, that effort went nowhere. Lack of commitment from other browser vendors and in particular Google, Microsoft abandoning its own rendering engine, lax Community Group instead of a formal W3C Working Group, the WebExtension draft specification has been in limbos for a while now and WebExtensions clearly remain the poor parent of Web Standards even if most people have at least one browser extension installed (usually some sort of ad-blocker).

Today, Google is impulsing a deep change in its WebExtension model:

• Background HTML pages will be deprecated in favor of ServiceWorkers. That change alone will imply a complete rearchitecture of existing extensions and will also impact their ability to create and deal with the dialogs their UX model requires.
• The webRequest API that billions of users activate on a daily basis to block advertisement, trackers or undesirable content, is at stake and should be replaced by a declarartive new API that will not allow to monitor the requested resources any more. At a time the advertisement model on the Web is harmed by ad blockers, one can only wonder if this change is triggered only by technical considerations or if ad strategy is also behind it... Furthermore, it will be limited to a few dozens of thousands of declarations, which is far below the number of trackers and advertisement scripts available in the wild today.
• Some heavily used API will be removed, without consideration for usage metrics or change cost to implementors
• Even the description of the top level of an extension (aka the "browser action" and the "page action") will change and impact extension vendors
• All of that is for the time being decided on the Google side alone, with little or no visible contact with the other WebExtension host (Mozilla) or the thousands of WebExtension (free or commercial) providers. There is even a "migration plans" document but it's not publicly available, the link being access-restricted

On the webRequest part specifically, all major actors of the ad-blocking and security landscape are screaming (see also the chromium-extensions Google group). Us at Privowny are also deeply concerned by the v3 proposed changes. Even Amnesty International complained in a recent message! To me, the most important message posted in reply to the proposed changes is the following one:

Hi, we are the developer of a child-protection add-on, which strives to make the Internet safer for minors. This change would cripple our efforts on Chrome.

Talk about "don't be evil"...

All of that gives a set of very bad signals to third-party implementors, including us at Privowny:

1. WebExtensions are not a mature part of the Open Web Platform. It completely lacks stability, and software vendors willing to use it must be ready to life-threatening (for them) changes at any time
2. WebExtensions are fully in the hands of Google, that can and will change it any time based on its own interests only. It is not a Web Standard.
3. Google is ready to make WebExtensions diverge from cross-browser interoperability at any time, killing precisely what brought vendors like us at Privowny to WebExtensions.
4. Google Chrome is not what it seems to be, a browser based on an Open Source project that protects users, promotes openness and can serve as a basis tool for webcitizen's protection.

Reading the above, and given the fact Google is able to impulse changes of such magnitudes with little or no impact study on vendors like us, we consider that WebExtensions are not a safe development platform any more. We will probably study soon an extraction of most of our code into a native desktop application, leaving only the minimum minimorum in the browser extension to communicate with web pages and of course with our native app.

After Mozilla that severely harmed its amazing addons ecosystem (remember it triggered the success of Firefox), after Apple that partly went away from JavaScript-based Safari extensions jeopardizing its addons ecosystem so much it's anemic (I could even say dying), Google is taking a move that is harmful to Chrome extensions vendors. What is striking here is that Google is making the very same mistake Mozilla did: no prior discussion with stakeholders (hear extension implementors), release of a draft spec that was obviously going to trigger strong reactions, unmeasured impact (complexity, time and finances) on implementors, more and more restrictions on what it is possible to do but a too limited set of new features.

On the legal side of things, this unilateral change could probably even qualify as "Abuse of dominant position" under European Union's article 102 TFUE, and could then cost Google a lot, really a lot...

The Open Web Platform is alive and vibrant. The Browser Extension ecosystem is in jail, subject to unpredictable harmful changes decided by one single actor. This must change, it's not viable any more.

TL;DR: the title says it all, and it's available there.

Eons ago, at a time BlueGriffon was only a Wysiwyg editor for the Web, my friend Mohamed Zergaoui asked why I was not turning BlueGriffon into an EPUB editor... I had been observing the electronic book market since the early days of Cytale and its Cybook but I was not involved into it on a daily basis. That seemed not only an excellent idea, but also a fairly workable one. EPUB is based on flavors of HTML so I would not have to reinvent the wheel.

I started diving into the EPUB specs the very same day, EPUB 2.0.1 (released in 2009) at that time. I immediately discovered a technology that was not far away from the Web but that was also clearly not the Web. In particular, I immediately saw that two crucial features were missing: it was impossible to aggregate a set of Web pages into a EPUB book through a trivial zip, and it was impossible to unzip a EPUB book and make it trivially readable inside a Web browser even with graceful degradation.

When the IDPF started working on EPUB 3.0 (with its 3.0.1 revision) and 3.1, I said this was coming too fast, and that the lack of Test Suites with interoperable implementations as we often have in W3C exit criteria was a critical issue. More importantly, the market was, in my opinion, not ready to absorb so quickly two major and one minor revisions of EPUB given the huge cost on both publishing chains and existing ebook bases. I also thought - and said - the EPUB 3.x specifications were suffering from clear technical issues, including the two missing features quoted above.

Today, times have changed and the Standards Committee that oversaw the future of EPUB, the IDPF, has now merged with the World Wide Web Consortium (W3C). As Jeff Jaffe, CEO of the W3C, said at that time,

Working together, Publishing@W3C will bring exciting new capabilities and features to the future of publishing, authoring and reading using Web technologies

Since the beginning of 2017, and with a steep acceleration during spring 2017, the Publishing@W3C activity has restarted work on the EPUB 3.x line and the future EPUB 4 line, creating a EPUB 3 Community Group (CG) for the former and a Publishing Working Group (WG) for the latter. If I had some reservations about the work division between these two entities, the whole thing seemed to be a very good idea. In fact, I started advocating for the merger between IDPF and W3C back in 2012, at a moment only a handful of people were willing to listen. It seemed to me that Publishing was a underrated first-class user of Web technologies and EPUB's growth was suffering from two critical ailments:

1. IDPF members were not at W3C so they could not confront their technical choices to browser vendors and the Web industry. It also meant they were inventing new solutions in a silo without bringing them to W3C standardization tables and too often without even knowing if the rendering engine vendors would implement them.
2. on another hand, W3C members had too little knowledge of the Publishing activity, that was historically quite skeptical about the Web... Working Groups at W3C were lacking ebook expertise and were therefore designing things without having ebooks in mind.

I was then particularly happy when the merger I advocated for was announced.

As I recently wrote on Medium, I am not any more. I am not convinced by the current approach implemented by Publishing@W3C on many counts:

• the organization of the Publishing@W3C activity, with a Publishing Business Group (BG) formally ruling (see Process section, second paragraph) the EPUB3 CG and a Steering Committee (see Process section, first paragraph) recreated the former IDPF structure inside W3C.  The BG Charter even says that it « advises W3C on the direction of current and future publishing activity work » as if the IDPF and W3C did not merge and as if W3C was still only a Liaison. It also says « the initial members of the Steering Committee shall be the individuals who served on IDPF’s Board of Directors immediately prior to the effective date of the Combination of IDPF with W3C », maintaining the silo we wanted to eliminate.
• the EPUB3 Community Group faces a major technical challenge, recently highlighted by representatives of the Japanese Publishing Industry: EPUB 3.1 represents too much of a technical change compared to EPUB 3.0.1 and is not implementable at a reasonable cost in a reasonable timeframe for them. Since EPUB 3 is recommended by the Japanese Government as the official ebook format in Japan, that's a bit of a blocker for EPUB 3.1 and its successors. The EPUB3 CG is then actively discussing a potential rescindment of EPUB 3.1, an extraction of the good bits we want to preserve, and the release of a EPUB 3.0.2 specification based on 3.0.1 plus those good bits. In short, the EPUB 3.1 line, that saw important clarifying changes from 3.0.1, is dead.
• the Publishing Working Group is working on a collection of specifications known as Web Publications (WP), Packaged Web Publications (PWP), and EPUB 4. What these specifications represent is extremely complicated to describe. With a daily observation of the activities of the Working Group, I still can't firmly say what they're up to, even if I am already convinced that some technological choices (for instance JSON-LD for manifests) are highly questionable and do not « lead Publishing to its full Web potential », to paraphrase the famous W3C motto. It must also be said that the EPUB 3.1 hiatus in the EPUB3 CG shakes the EPUB 4 plan to the ground, since it's now extremely clear the ebook market is not ready at all to move to yet another EPUB version, potentially incompatible with EPUB 3.x (for the record, backwards-compatibility in the EPUB world is a myth).
• the original sins of EPUB quoted above, including the two missing major features quoted in the second paragraph of the present article, are a minor requirement only. Editability of EPUB, one of the greatest flaws of that ecosystem, is still not a first-class requirement if not a requirement at all. Convergence with the Web is severely encumbered by personal agendas and technical choices made by one implementation vendor for its own sake; the whole W3C process based on consensus is worked around not because there is no consensus (the WG minutes show consensus all the time) but mostly beacause the rendering engine vendors are still not in the loop and their potential crucial contributions are sadly missed. And they are not in the loop because they don't understand a strategy that seems decorrelated from the Web; the financial impact of any commitment to the Publishing@W3C is then a understandable no-go.
• the original design choices of EPUB, using painful-to-edit-or-render XML dialects, were also an original sin. We're about to make the same mistake, again and again, either retaining things that partly block the software ecosystem or imagining new silos that won't be editable nor grokable by a Web Browser. Simplicity, Web-centricity and mainstream implementations are not in sight.

Since the whole organization of Publishing @W3C is governed by the merger agreement between IDPF and W3C, I do not expect to change anyone's mind with the present article. I only felt the need to express my opinion, in both public and private fora. Unsurprisingly, the feedback to my private warnings was fairly negative. In short, it works as expected and I should stop spitting in the soup. Well, if that works as expected, the expectations were pretty low, sorry to say, and were not worth a merger between two Standard Bodies.

I have then decided to work on a different format for electronic books, called WebBook. A format strictly based on Web technologies and when I say "Web technologies", I mean the most basic ones: html, CSS, JavaScript, SVG and friends; the class of specifications all Web authors use and master on a daily basis. Not all details are decided or even ironed, the proposal is still a work in progress at this point, but I know where I want to go to.

I will of course happily accept all feedback. If people like my idea, great! If people disagree with it, too bad for me but fine! At least during the early moments of my proposal, and because my guts tell me my goals are A Good Thing™️, I'm running this as a Benevolent Dictator, not as a consensus-based effort. Convince me and your suggestions will make it in.

I have started from a list of requirements, something that was never done that way in the EPUB world:

1. one URL is enough to retrieve a remote WebBook instance, there is no need to download every resource composing that instance

2. the contents of a WebBook instance can be placed inside a Web site’s directory and are directly readable by a Web browser using the URL for that directory

3. the contents of a WebBook instance can be placed inside a local directory and are directly readable by a Web browser opening its index.html or index.xhtml topmost file

4. each individual resource in a WebBook instance, on a Web site or on a local disk, is directly readable by a Web browser

5. any html document can be used as content document inside a WebBook instance, without restriction

6. any stylesheet, replaced resource (images, audio, video, etc.) or additional resource useable by a html document (JavaScript, manifests, etc.) can be used inside the navigation document or the content documents of a WebBook instance, without restriction

7. the navigation document and the content documents inside a WebBook instance can be created and edited by any html editor

8. the metadata, table of contents contained in the navigation document of a WebBook instance can be created and edited by any html editor

9. the WebBook specification is backwards-compatible

10. the WebBook specification is forwards-compatible, at the potential cost of graceful degradation of some content

11. WebBook instances can be recognized without having to detect their MIME type

12. it’s possible to deliver electronic books in a form that is compatible with both WebBook and EPUB 3.0.1

I also made a strong design choice: the Level 1 of the specification will not be a fit-all-cases document. WebBook will start small, simple and extensible, and each use case will be evaluated individually, sequentially and will result in light extensions at a speed the Publishing industry can bear with. So don't tell me WebBook Level 1 doesn't support a given type of ebook or is not at parity level with EPUB 3.x. It's on purpose.

With that said, the WebBook Level 1 is available here and, again, I am happily accepting Issues and PR on github. You'll find in the spec references to:

• « Moby Dick » released as a WebBook instance
• « Moby Dick » released as a EPUB3-compatible WebBook instance
• a script usable with Node.js to automagically convert a EPUB3 package into a EPUB3-compatible WebBook

My EPUB Editor BlueGriffon is already modified to deal with WebBook. The next public version will allow users to create EPUB3-compatible WebBooks.

I hope this proposal will show stakeholders of the Publishing@W3C activity another path to greater convergence with the Web is possible. Should this proposal be considered by them, I will of course happily contribute to the debate, and hopefully the solution.

Cash Investigation vient d'interviewer le Vice-Amiral Coustillière. Je passe sur le fait qu'il parle de « blackdoor » pour revenir sur ses propos expliquant son choix. Ce type est totalement à côté de la plaque et a démontré en vingt secondes son incompétence totale en la matière. Il a raconté n'importe quoi et ne mesure absolument pas la portée de ses propos, de ses choix, de ses faiblesses mais surtout des faiblesses qu'il vient d'introduire dans la Défense Nationale française. Monsieur Le Drian, vous êtes là ?

Several painful things happened to bluegriffon.org yesterday... In chronological order:

1. during my morning, two users reported that their browser did not let them reach the downloads section of bluegriffon.org without a security warning. I could not see it myself from here, whatever the browser or the platform.
2. during the evening, I could see the warning using Chrome on OS X
3. apparently, and if I believe the "Search Console", Google thought two files in my web repository of releases are infected. I launched a complete verification of the whole web site and ran all the software releases through three anti-virus systems (Sophos, Avast and AVG) and an anti-adware system. Nothing at all to report. No infection, no malware, no adware, nothing.
4. since this was my only option, I deleted the two reported files from my server. Just for the record, the timestamps were unchanged, and I even verified the files were precisely the ones I uploaded in january and april 2012. Yes, 2012... Yesterday, without being touched/modified in any manner during the last four years, they were erroneously reported infected.
5. this morning, Firefox also reports a security warning on most large sections of BlueGriffon.org and its Downloads section. I guess Firefox is also using the Google blacklist. Just for the record, both Spamhaus and CBL have nothing to say about bluegriffon.org...
6. the Google Search Console now reports my site is ok but Firefox still reports it unsecure, ahem.

I need to draw a few conclusions here:

• Google does not tell you how the reported files are unsecure, which is really lame. The online tool they provide to "analyze" a web site did not help at all.
• Since all my antivir/antiadware declared all files in my repo clean, I had absolutely no option but to delete the files that are now missing from my repo
• two reported files in bluegriffon.org/freshmeat/1.4/ and bluegriffon.org/freshmeat/1.5.1/ led to blacklisting of all of bluegriffon.org/freshmeat and that's hundreds of files... Hey guys, we are and you are programmers, right? Sure you can do better than that?
• during more than one day, customers fled from bluegriffon.org because of these security warnings, security warnings I consider as fake reports. Since no public antimalware app could find anything to say about my files, I am suspecting a fake report of human origin. How such a report can reach the blacklist when files are reported safe by four up-to-date antimalware apps and w/o infection information reported to the webmaster is far beyond my understanding.
• blacklists are a tool that can be harmful to businesses if they're not well managed.

Update: oh I and forgot one thing: during the evening, Earthlink.net blacklisted one of the Mail Transport Agents of Dreamhost. Not, my email address, that whole SMTP gateway at Dreamhost... So all my emails to one of my customers bounced and I can't even let her know some crucial information. I suppose thousands at Dreamhost are impacted. I reported the issue to both Earthlink and DH, of course.

Long ago, there was Cnet's Paul Festa. When Festa went (finally) away, I thought we could take tech journalism practices back to normal. Seems I was wrong. Here's a summary of things that happened to me in the last months:

The unpolite

• (someone to me) Hello Daniel, I am forwarding below an interview request from a journalist who says he misses your email to ping you
• (me to that someone) thanks, will reply.
• (me to journalist) got your request, expect answer to all questions soon
• (me to journalist) here are the replies. Best regards.
• ...
• ...

No ACK, no thanks, no reply, no notification the article will be published, no notification the article was published. In short, the journalist never said me a single word directly. That person is now blacklisted. Can still leave that black list if there are some sort of apologies.

The impatient

• (journalist to me at 7pm PST) hello M. Glazman, I'm writing an article about blah, I know you're based in Europe but could I call you on the phone in the next half hour?
• ...

7pm PST is 4am here. I was of course in front of my computer at 4am waiting for a journalist's email and ready to take a call from the US at 4:30am. Of course.

The painful

• (journalist to me) so what's your activity/title at W3C?
• (me to journalist) I am co-chairing the CSS Working Group

Article is published, of course w/o notification. I am listed there as "W3C Chairman". Obviously.

The bastard

• (me to journalist) hello, you interviewed me a few weeks ago and now that the article is published (you did not notify me, did you?), I discover at least one paragraph with quotes from me completely opposite to what I precisely said. What I precisely said is « blah », and you can see it's totally different from the contents of the article so could you please fix this in your article?
• (journalist to me) this is not my recollection of the interview
• (me to journalist) well, you recorded the interview so you can check ; please check.
• (journalist to me) sorry but I don't have time for that
• (me to journalist) again, the words put in my mouth by your article are absolutely not the ones I said, will you fix them yes or no?
• ...

No answer, article unfixed. Journalist permanently blacklisted.

The ghost

• (very polite journalist to me) hello Daniel, first let me introduce myself blah blah if you have some time to answer some questions, I'd be happy to blah blah and best regards looking forward to blah blah
• (me to journalist) sure, no problem ! send me your questions and I'll reply immediately !
• (me to journalist) hello, did you send your questions?
• (me to journalist) hello, I still haven't received your questions...
• ...

Strange, to say the least.

The rough

• (journalist to me, precise words, only translated from french) hello, I am a journalist at blah, here are 5 questions. Please answer.
• ...

In one word only: no. I was polite enough to reply "No, thanks".

The out-of-scope

• (journalist to me) hello, would you answer a few questions about the future of PHP?

Do I really need to explain?

A large part of the current CSS Object Model sucks. More specifically, the CSSValue, CSSPrimitiveValue, CSSValueList, RGBColor, Rect and Counter interfaces are so poorly designed they're not implemented. I just tried to implement them for a project of mine and I must say the model is so weak and incoherent it cannot be implemented as is.

I have then tried to refine what's in the 2000-nov-13 spec of DOM Level 2 Style to reach something workable. I am NOT saying this has to be done or implemented. Call it a mental exercise I did just for fun, w/o caring about performance.

Let's first look at what's wrong:

Interface CSSValue

      interface CSSValue {
      
        // UnitTypes
        const unsigned short      CSS_INHERIT                    = 0;
        const unsigned short      CSS_PRIMITIVE_VALUE            = 1;
        const unsigned short      CSS_VALUE_LIST                 = 2;
        const unsigned short      CSS_CUSTOM                     = 3;
      
                 attribute DOMString        cssText;
                                              // raises(DOMException) on setting
      
        readonly attribute unsigned short   cssValueType;
      };

"inherit" is here considered as a special identifier despite of the fact a CSSPrimitiveValue can be a CSS_IDENT. There is no UnitType for "initial". A CSS_CUSTOM is, according to the spec, a "custom value"; but a custom value still has to be valid per CSS syntax so it should be representable with CSS_VALUE_LISTs and CSS_VALUEs.

Interface CSSValueList

interface CSSValueList : CSSValue {
  readonly attribute unsigned long    length;
  CSSValue           item(in unsigned long index);
};

All in all, this one is simple and should be quite ok. But one thing is missing: a property can accept a comma-separated list of whitespace-separated values. The current CSSValueList cannot express if the serialization of a CSSValueList should be whitespace- or comma-separated.

Interface CSSPrimitiveValue

interface CSSPrimitiveValue : CSSValue {

  // UnitTypes
  const unsigned short      CSS_UNKNOWN                    = 0;
  const unsigned short      CSS_NUMBER                     = 1;
  const unsigned short      CSS_PERCENTAGE                 = 2;
  const unsigned short      CSS_EMS                        = 3;
  const unsigned short      CSS_EXS                        = 4;
  const unsigned short      CSS_PX                         = 5;
  const unsigned short      CSS_CM                         = 6;
  const unsigned short      CSS_MM                         = 7;
  const unsigned short      CSS_IN                         = 8;
  const unsigned short      CSS_PT                         = 9;
  const unsigned short      CSS_PC                         = 10;
  const unsigned short      CSS_DEG                        = 11;
  const unsigned short      CSS_RAD                        = 12;
  const unsigned short      CSS_GRAD                       = 13;
  const unsigned short      CSS_MS                         = 14;
  const unsigned short      CSS_S                          = 15;
  const unsigned short      CSS_HZ                         = 16;
  const unsigned short      CSS_KHZ                        = 17;
  const unsigned short      CSS_DIMENSION                  = 18;
  const unsigned short      CSS_STRING                     = 19;
  const unsigned short      CSS_URI                        = 20;
  const unsigned short      CSS_IDENT                      = 21;
  const unsigned short      CSS_ATTR                       = 22;
  const unsigned short      CSS_COUNTER                    = 23;
  const unsigned short      CSS_RECT                       = 24;
  const unsigned short      CSS_RGBCOLOR                   = 25;

  readonly attribute unsigned short   primitiveType;
  void               setFloatValue(in unsigned short unitType, 
                                   in float floatValue)
                                        raises(DOMException);
  float              getFloatValue(in unsigned short unitType)
                                        raises(DOMException);
  void               setStringValue(in unsigned short stringType, 
                                    in DOMString stringValue)
                                        raises(DOMException);
  DOMString          getStringValue()
                                        raises(DOMException);
  Counter            getCounterValue()
                                        raises(DOMException);
  Rect               getRectValue()
                                        raises(DOMException);
  RGBColor           getRGBColorValue()
                                        raises(DOMException);
};

This is so completely crazy I don't know where to start...

• CSS_UNKNOWN is supposed to represent a "value that is not a recognized CSS2 value". Then it should be thrown away by the parser as invalid and never reach the OM, right?
• the list of units is long and not easily extensible
• attr(), counter(), counters(), rect() and the more recent gradients or var() calls are all functions; adding a new setter and a new getter for each new type is overkill
• attr() was extended by recent specs and can now take more than one argument. The above does not allow to individually modify those arguments.
• "initial" and "inherit" are, as I already said above, covered by both CSSValue and CSS_IDENT here
• let's suppose we have a CSSValue that is a CSSPrimitiveValue. Setting its cssText to "10px 10px" will then trigger an exception since a CSSPrimitiveValue cannot transmute magically into a CSSValueList...
• I love how the spec prose says setStringValue() has "No Parameters"...

Interface Rect

interface Rect {
  readonly attribute CSSPrimitiveValue  top;
  readonly attribute CSSPrimitiveValue  right;
  readonly attribute CSSPrimitiveValue  bottom;
  readonly attribute CSSPrimitiveValue  left;
};

This looks and smells like a CSSValueList far too much.

Interface RGBColor

interface RGBColor {
  readonly attribute CSSPrimitiveValue  red;
  readonly attribute CSSPrimitiveValue  green;
  readonly attribute CSSPrimitiveValue  blue;
};

This cannot represent rgba(), hsl() and hsla() colors. We also have to use three CSSPrimitiveValue for the three color components because they can be a percentage or an integer...

Interface Counter

interface Counter {
  readonly attribute DOMString        identifier;
  readonly attribute DOMString        listStyle;
  readonly attribute DOMString        separator;
};

Again, something is missing here: nothing says if it's supposed to be a counter() or a counters() value. And no, the separator could not do the trick since it can be the empty string.

Requirements

To have a better OM for Values, i.e. an extensible OM that allows an application to deal with parsed values of all kinds, we need to change of perspective. First, the list of reserved idents, the list of units and the list of functions are not extensible. Secondly, we have cast issues between PrimitiveValues and ValueLists and we need a single interface. We can deal with all the issues with a single CSSValue interface:

New interface CSSValue

interface CSSValue {

  // ValueTypes
  const unsigned short      CSS_SYMBOL                     = 0;
  const unsigned short      CSS_NUMBER                     = 1;
  const unsigned short      CSS_UNIT                       = 2;
  const unsigned short      CSS_STRING                     = 3;
  const unsigned short      CSS_URI                        = 4;
  const unsigned short      CSS_IDENT                      = 5;
  const unsigned short      CSS_VALUE_LIST                 = 6;


  readonly attribute unsigned short   type;
           attribute boolean          commaSeparated;
  readonly attribute unsigned long    length;

  CSSValue           item(in unsigned long index);
                                        raises(DOMException);

  void               setFloatValue(in float floatValue)
                                        raises(DOMException);
  float              getFloatValue()
                                        raises(DOMException);

  void               setStringValue(in DOMString stringValue)
                                        raises(DOMException);
  DOMString          getStringValue()
                                        raises(DOMException);
};

Definition group ValueTypes

An integer indicating the type of the Value

CSS_SYMBOL

The value is a single character than cannot be interpreted otherwise. For instance the / character in the font shorthand property. The value can be obtained by the getStringValue() and set by the setStringValue() method.

CSS_NUMBER

The value is a simple number. The value can be obtained by using the getFloatValue() method and set through by setFloatValue() method.

CSS_UNIT

The value is a number followed by a unit. The number part of the value can be obtained by using the getFloatValue() method and set through by setFloatValue() method. The unit part of the value can be obtained by using the getUnit() method and set through by setUnit() method

CSS_STRING

The value is a string. The value can be obtained by the getStringValue() and set by the setStringValue() method.

CSS_URI

The value is a URI. The parameter of the url() function can be obtained by the getStringValue() and set by the setStringValue() method.

CSS_IDENT

The value is a CSS identifier. The value can be obtained by the getStringValue() and set by the setStringValue() method.

CSS_VALUE_LIST

The value is a list of values or a function. It is a function if the getStringValue() method does not reply the empty string. The list of values is whitespace-separated if the commaSeparated attribute is false and comma-separated otherwise.

Attributes

type of type unsigned short, readonly

The type of the value as defined by the constants specified above.

commaSeparated of type boolean

The separation type of the list of values. Meaningful only if the type attribute is CSS_VALUE_LIST. The list is whitespace-separated if the attribute is false and comma-separated otherwise.

length of type unsigned long, readonly

The number of CSSValue in the list. The range of valid values of the indices is 0 to length-1 inclusive.

Exceptions

INVALID_ACCESS_ERR: Raised if the CSS value is a not a CSS_VALUE_LIST.

Methods

getFloatValue

Retrieves the value of a CSS_NUMBER or the number part of the value of a CSS_UNIT. If this CSS value is not a CSS_NUMBER or a CSS_UNIT, a DOMException is raised.

Return Value

float The float value of this CSS_NUMBER or CSS_UNIT

Exceptions

INVALID_ACCESS_ERR: Raised if the CSS value isn't a CSS_NUMBER nor a CSS_UNIT.

getStringValue

For a CSS_SYMBOL, retrieves the single character used as a symbol.

For a CSS_STRING, retrieves the string. Enclosing quotes or double-quotes are NOT included.

For a CSS_UNIT, retrieves the unit of the value.

For a CSS_URI, retrieves the argument of the url(...) notation. Enclosing quotes or double-quotes are NOT includedt.

For a CSS_IDENT, retrieves the identifier.

For a CSS_VALUE_LIST and if that list of values is passed as the parameters of a function, retrieves the function name. Retrieves the empty string otherwise.

For a CSS_NUMBER and CSS_UNIT, a DOMException is raised.

No Parameters

Return Value

DOMString The float value of this CSS_NUMBER or CSS_UNIT

Exceptions

INVALID_ACCESS_ERR: Raised if the CSS value is a CSS_NUMBER or a CSS_UNIT.

item

For a CSS_VALUE_LIST, Used to retrieve a CSSValue by ordinal index. The order in this collection represents the order of thevalues in the CSS style property. If index is greater than or equal to the number of values in the list, this returnsnull.

For all other value types, a DOMException is raised.

Parameter

index of type unsigned long: index into the collection.

Return value

CSSValue The CSSValue at the index position in the CSSValueList, or null if that is not a valid index.

Exceptions

INVALID_ACCESS_ERR: Raised if the CSS value is a not a CSS_VALUE_LIST.

setFloatValue

Sets the value of a CSS_NUMBER or the number part of the value of a CSS_UNIT. If this CSS value is not a CSS_NUMBER or a CSS_UNIT, a DOMException is raised.

Parameter

floatValue of type float;

No Return Value

Exceptions

INVALID_ACCESS_ERR: Raised if the CSS value isn't a CSS_NUMBER nor a CSS_UNIT or if the attached property doesn't support the float value or the unit type.

NO_MODIFICATION_ALLOWED_ERR: Raised if this property is readonly.

setStringValue

For a CSS_SYMBOL, sets the single character used as a symbol.

For a CSS_STRING, sets the string.

For a CSS_UNIT, sets the unit of the value.

For a CSS_URI, sets the argument of the url(...) notation.

For a CSS_IDENT, sets the identifier.

For a CSS_VALUE_LIST and if the parameter is not the empty string, make the list of values become a function and sets the function name. Make the list become a plain list of values if the parameter is the empty string.

For a CSS_NUMBER and CSS_UNIT, a DOMException is raised.

Parameter

stringValue of type DOMString

No Return Value

Exceptions

INVALID_ACCESS_ERR: Raised if the CSS value is a CSS_NUMBER or a CSS_UNIT, if the type of the value is CSS_SYMBOL and the string can be parsed as an other type of value, if the type of the value is CSS_UNIT and the string is not a valid CSS unit, if the type of the value is CSS_URI and the string is not a valid URI, if the type of the value is CSS_IDENT and the string is not a valid CSS identifier, if the type of the value is CSS_VALUE_LIST and the string is not a valid CSS identifier or the empty string.

NO_MODIFICATION_ALLOWED_ERR: Raised if this property is readonly.

Conclusion

The above should be enough to describe any CSS value, specified or computed. The model will become a bit complex for complex values but it ensures any web application can have access to parsed values, deal with their types and modify them. Let's take an example:

background-image: linear-gradient(to bottom, yellow 0%, blue 100%), url(foo.png);

This will result in the following OM (click on the image to enlarge it):

Again, I'm not saying the above is the thing to do or implement. It can certainly be improved, for instance for colors. A totally different perspective is also perfectly possible. I am only saying that making a better CSS OM allowing a full representation of parsed values in stylesheets and computed values is feasible. I hope the CSS OM will offer such power in the future.

UPDATE: the new CSSValue interface above lacks one thing, the ubiquitous cssText for parsing and serialization. Sorry for that.

Brendan, I have the highest respect for you and you do know it. But I cannot let you affirm in public the current situation about prefixes was caused first by the CSS Working Group.

1. the CSS Working Group gathers you guys, browsers vendors. The Working Group decides nothing "by itself", it's an empty shell where browser vendors discuss, sometimes fight, and reach consensus. If a consensus was reached about introducing vendor prefixes in the past, the MEMBERSHIP of the Group is fully responsible for it and that DOES include Mozilla, or more probably Netscape at that time but eh we were all there at that time.
2. even the W3C Process is decided by the W3C Members. The CSS WG is totally out of scope here. It's like saying you blame an airport because you don't like showing an ID at the airport, the airport being bound by national and international regulations. Nothing it can do about it. Have someone at the W3C Advisory Board (you used to have Arun) or call for Process changes in a constructive way. But please, tell Mozilla reps to stop asking for Process changes in the CSS WG when the bits to change are NOT in our hands. That too sucks our time.
3. the CSS Working group kept drafts under its wings too often not because of pains caused by the W3C Process but because of the perfectionism of the WG Members. And they include Mozilla. People who criticize W3C say it lacks pragmatism, but trust me on that please, I too often said "perfectionism on CSS 2.1 sucks our time for CSS 3". CSS 2.1 took too many years to emerge also because you browser vendors wanted the most perfect spec and could never end the loop.
4. let's take CSS Variables, a top request by the whole CSS Community since 1997. Dave Hyatt and I had a complete, simple, nice, understandable, easily implementable proposal, Dave even implemented it in WebKit and shipped it. Finally removed it because other browser vendors ended up in endless discussions on the feature itself. The CSS WG is not guilty here. The browser vendors are. They argued and argued and argued ad nauseum, for something that could have hit browsers FOUR YEARS AGO and we still don't even have an alternative. Don't blame the CSS WG, blame your representatives to the CSS WG. Where is the lack of pragmatism and the lack of speed?
5. when the whole mobile Web is full of a feature implemented by WebKit, documented by Apple in two lines only on their developer's web site, protected by IPRs owned by Apple, never submitted by any browser vendor to the Working Group, and when Microsoft, Mozilla and Opera want to implement that super feature because lack of it harms their market share, don't blame the CSS WG. Fight the legal issue about IPR, implement a counter-measure legally feasible we could rapidly standardize or get Apple to submit their feature to the WG. But you just cannot tell the WG is guilty in any way here.
6. I have said dozens and dozens of times in the CSS WG that prefixes are a terrible burden on Web Authors' shoulders. It's only recently (relatively to the age of the WG) that we adopted a rule allowing us to get rid of prefixes when we think a feature is stable enough. But this rule comes, again, from CONSENSUS AMONG BROWSER VENDORS. The Working Group here is nothing more but a meeting room. Each time a new proposal to simplify (or get rid of) prefixes was submitted in the past, one browser vendor at least objected. So what should we do? Break consensus? On what basis? My chair's hat?!? Playing Heads or Tails? Even with the new rule, discussions about the stabilization of a given feature and removal of prefixes always lead to one browser vendor objecting to the proposal supported by the others. And it's not always the same browser vendor. How can you say here the WG is first guilty?
7. as far as I know, the list of prefixed (and even sometimes unprefixed while they should be prefixed!) properties implemented by WebKit is the following one:

   -epub-caption-side
   -epub-hyphens
   -epub-text-combine
   -epub-text-emphasis
   -epub-text-emphasis-color
   -epub-text-emphasis-style
   -epub-text-orientation
   -epub-text-transform
   -epub-word-break
   -epub-writing-mode
   -webkit-animation
   -webkit-animation-delay
   -webkit-animation-direction
   -webkit-animation-duration
   -webkit-animation-fill-mode
   -webkit-animation-iteration-count
   -webkit-animation-name
   -webkit-animation-play-state
   -webkit-animation-timing-function
   -webkit-appearance
   -webkit-aspect-ratio
   -webkit-backface-visibility
   -webkit-background-clip
   -webkit-background-composite
   -webkit-background-origin
   -webkit-background-size
   -webkit-border-after
   -webkit-border-after-color
   -webkit-border-after-style
   -webkit-border-after-width
   -webkit-border-before
   -webkit-border-before-color
   -webkit-border-before-style
   -webkit-border-before-width
   -webkit-border-bottom-left-radius
   -webkit-border-bottom-right-radius
   -webkit-border-end
   -webkit-border-end-color
   -webkit-border-end-style
   -webkit-border-end-width
   -webkit-border-fit
   -webkit-border-horizontal-spacing
   -webkit-border-image
   -webkit-border-radius
   -webkit-border-start
   -webkit-border-start-color
   -webkit-border-start-style
   -webkit-border-start-width
   -webkit-border-top-left-radius
   -webkit-border-top-right-radius
   -webkit-border-vertical-spacing
   -webkit-box-align
   -webkit-box-direction
   -webkit-box-flex
   -webkit-box-flex-group
   -webkit-box-lines
   -webkit-box-ordinal-group
   -webkit-box-orient
   -webkit-box-pack
   -webkit-box-reflect
   -webkit-box-shadow
   -webkit-box-sizing
   -webkit-color-correction
   -webkit-column-axis
   -webkit-column-break-after
   -webkit-column-break-before
   -webkit-column-break-inside
   -webkit-column-count
   -webkit-column-gap
   -webkit-column-rule
   -webkit-column-rule-color
   -webkit-column-rule-style
   -webkit-column-rule-width
   -webkit-column-span
   -webkit-column-width
   -webkit-columns
   -webkit-dashboard-region
   -webkit-filter
   -webkit-flex-align
   -webkit-flex-direction
   -webkit-flex-flow
   -webkit-flex-item-align
   -webkit-flex-order
   -webkit-flex-pack
   -webkit-flex-wrap
   -webkit-flow-from
   -webkit-flow-into
   -webkit-font-feature-settings
   -webkit-font-kerning
   -webkit-font-size-delta
   -webkit-font-smoothing
   -webkit-font-variant-ligatures
   -webkit-grid-columns
   -webkit-grid-rows
   -webkit-highlight
   -webkit-hyphenate-character
   -webkit-hyphenate-limit-after
   -webkit-hyphenate-limit-before
   -webkit-hyphenate-limit-lines
   -webkit-line-box-contain
   -webkit-line-break
   -webkit-line-clamp
   -webkit-line-grid
   -webkit-line-grid-snap
   -webkit-locale
   -webkit-logical-height
   -webkit-logical-width
   -webkit-margin-after
   -webkit-margin-after-collapse
   -webkit-margin-before
   -webkit-margin-before-collapse
   -webkit-margin-bottom-collapse
   -webkit-margin-collapse
   -webkit-margin-end
   -webkit-margin-start
   -webkit-margin-top-collapse
   -webkit-marquee
   -webkit-marquee-direction
   -webkit-marquee-increment
   -webkit-marquee-repetition
   -webkit-marquee-speed
   -webkit-marquee-style
   -webkit-mask
   -webkit-mask-attachment
   -webkit-mask-box-image
   -webkit-mask-box-image-outset
   -webkit-mask-box-image-repeat
   -webkit-mask-box-image-slice
   -webkit-mask-box-image-source
   -webkit-mask-box-image-width
   -webkit-mask-clip
   -webkit-mask-composite
   -webkit-mask-image
   -webkit-mask-origin
   -webkit-mask-position
   -webkit-mask-position-x
   -webkit-mask-position-y
   -webkit-mask-repeat
   -webkit-mask-repeat-x
   -webkit-mask-repeat-y
   -webkit-mask-size
   -webkit-match-nearest-mail-blockquote-color
   -webkit-max-logical-height
   -webkit-max-logical-width
   -webkit-min-logical-height
   -webkit-min-logical-width
   -webkit-nbsp-mode
   -webkit-opacity
   -webkit-padding-after
   -webkit-padding-before
   -webkit-padding-end
   -webkit-padding-start
   -webkit-perspective
   -webkit-perspective-origin
   -webkit-perspective-origin-x
   -webkit-perspective-origin-y
   -webkit-print-color-adjust
   -webkit-region-break-after
   -webkit-region-break-before
   -webkit-region-break-inside
   -webkit-region-overflow
   -webkit-rtl-ordering
   -webkit-svg-shadow
   -webkit-tap-highlight-color
   -webkit-text-decorations-in-effect
   -webkit-text-emphasis-position
   -webkit-text-fill-color
   -webkit-text-security
   -webkit-text-size-adjust
   -webkit-text-stroke
   -webkit-text-stroke-color
   -webkit-text-stroke-width
   -webkit-touch-callout
   -webkit-transform
   -webkit-transform-origin
   -webkit-transform-origin-x
   -webkit-transform-origin-y
   -webkit-transform-origin-z
   -webkit-transform-style
   -webkit-transition
   -webkit-transition-delay
   -webkit-transition-duration
   -webkit-transition-property
   -webkit-transition-timing-function
   -webkit-user-drag
   -webkit-user-modify
   -webkit-user-select
   -webkit-wrap
   -webkit-wrap-flow
   -webkit-wrap-margin
   -webkit-wrap-padding
   -webkit-wrap-shape-inside
   -webkit-wrap-shape-outside
   -webkit-wrap-through
   background-position-x
   background-position-y
   border-image-outset
   border-image-repeat
   border-image-slice
   border-image-source
   border-image-width
   overflow-x
   overflow-y
   text-overflow
   word-wrap
   zoom
   

   many of them being "documented" by Apple. Some are well known, come from a CSS WG spec/draft/document, and have their counterparts in Gecko, Presto and Trident. Some are totally unknown to us and were never submitted for standardization. So again, don't blame the CSS WG for prefixed properties that NEVER reached us. They are going to hit the market and spread because of a company, not because of a standards body. For the ones you implement and people don't use, well, Apple has nice editing tools, nice IDEs. I told you a loooong time ago that a browser is only the top of the ecosystem's iceberg and that editing is still a major part of it.

8. we already have an existing case with extremely ugly de facto standardization coming from WebKit mobile market dominance, and that's the infamous meta viewport tag. I heard myself some Apple engineers acknowledge it was a rather big mistake. We have CSS equivalents for this on our radar, submitted by Opera. We could have moved towards a de jure solution faster here but apparently there is little interest shown by browser vendors if you except of course Opera. Blame again the CSS WG for that? Not you, Brendan, please. You know too well standardization for that.
9. all of that said, please tell me how you are going to get rid of the -webkit-* prefix (or even implement the prefixed version in Moz) for -webkit-text-size-adjust given the IPRs?

It is too easy to always beat the CSS WG or the W3C. If you recall correctly, I have been one of the first ones to shout at the W3C in the XHTML2 fiasco. It was so early that Netscape still existed. I am still the first one to say it when they mess things up. But here, that's just unfair. I only agree that the CSS Working Group could have done better but hey, the Working Group members - hear YOU BROWSER VENDORS - decided there. So putting that organization at the top of your recriminations just carries a false message and hides an inconvenient truth.

Mozilla and Opera gave hand to Apple to create the WHAT-WG. You guys can speak together, for instance when your high-level representatives had a private secret meeting at Apple while the CSS WG was by pure coincidence in the meeting room on the other side of the corridor, was it november 2010. Meet again and let Apple know it must submit to the corresponding WGs technical proposals for the features that hit the Web and spread too wide to remain proprietary. Apple too must preserve the Open Web. So it says for HTML and APIs, so why not for CSS?

2011 just came to an end and it's time to look back and report. For Disruptive Innovations, things are simple:

• BlueGriffon released; BlueGriffon is our Wysiwyg content editor for the Web, powered by Gecko. It's the only editor of its kind offering support for html5, css3 and svg, all builtin. Version 1.4 to be released in january 2012.
• many addons to BlueGriffon released. Our best-seller is clearly the CSS Pro Editor. A CSS 3 Animations Editor is on its way.
• an EPUB version of BlueGriffon is also on its way. It takes more time than previously expected because of interpretation issues in the spec. But stay tuned, it's alive.

On the CSS WG front:

• many new RECs, including CSS 2.1. The CSS WG is going very well, and we have a lot of new cool stuff on the radar. The Working Group is larger than ever, with an impressive number of active contributors.
• the CSS Test Suite harness developed by Peter Linss is a major achievement, that helped us managing thousands of CSS 2.1 tests and delivering implementation reports.
• CSS prefixes are a larger and larger problem every day. Even if we have different opinions on "why" and on "what instead", we almost all agree on part of the diagnosis: prefixes harm the Authoring community.
• The current CSS OM is a pile of crap we unfortunately all have to rely on; and I do mean it: ALL. Web authors, game implementors, app developers, we all suffer from the weaknesses of the CSS OM. This should become a high priority, it's highly time to make the CSS OM evolve to support the new web apps ecosystem.

On the Mozilla front:

• Mozilla appears to be in great shape, recruiting more than ever and diving into new market areas. Only stupid journalists and trolls jumped on the Mozilla-Google-deal-is-no-more bandwagon and the figures recently reported are excellent news.
• this major direction shift did not happen at no cost, and the way Enterprises' needs were dealt with is still one of the largest and hardest hickups in Mozilla's history. From my perspective and reading the Moz Enterprise mailing-list, it's still largely unresolved. While things that many people (including yours truly) were waiting for reach finally the launchpad, some others are still the poor parent in the organization. The ecosystem (third-party Gecko-based apps) for instance is still undervalued and undersupported and a builtin system that would allow a real add-on marketplace is still not in sight. The debugging environment (call it Venkman or Firebug or whatever) focuses more than ever on content and chrome is forgotten, very strongly impacting add-on and apps developers; I just can't believe some of us had to rely on alert() or dump() in 2011... Surprisingly, Mozilla's CEO almost does not communicate at all (outside of MoCo), a drastic change in MoCo's 8 years of existence. Thunderbird came back to the nest after a few years of semi-independent life and it does not appear to be able to fly alone.
• a few years ago, development tools were officially called "bloat" and the trend was to get rid (hear turn them into add-ons) of all of them to make the browser lighter. We were a few to fight that and it's good to discover now we were right: web development tools distributed with the browser itself and immediately available are a major attractor.
• XUL's fate is still a matter of concern to many add-on and 3rd-party implementors, and we heard just nothing here. That's unusual in the Mozilla world, and very embarassing because people (our customers) don't bet on a technology if they feel if it could be on the extinction slope.
• I think Mozilla has to reorganize the way it - as an organization and a community - communicates. Planet.mozilla.org became a good example for "unmanageable logorrhea", sorry to say. If by pure lack of chance you're away from a computer during one day, you may have missed extremely important technical information hidden between flows and flows of blog articles, information that you will NOT find again because you don't even know on which blog they're posted. Leave for a summer break and you're doomed. "Hey, that was posted on a blog entry two weeks ago, you missed it?" Hell, YES, I missed it, I also have a private life, and I missed it because it was on a blog and not on a persistent easy-to-find web site owned by MoCo. That is now a rather severe issue. Most of that information should only be LINKED on blogs and their primary host should be MDN or the wiki, both sites automatically sending to planet a weekly links-only digest of all new documents.

On the Web front:

• the numberless html is a failure at least from one point of view. There is not a single journalist or commenter not using the "5" digit mentioning the "new" html language. I still remember TimBL looong ago, probably during the Web Conference in Paris, saying something like "unfortunately, human beings need meaningful identifiers". He was speaking of addresses, and the topic was of course URLs vs. URNs. For html version numbers, it's about the same. A "Living Standard" will never be meaningful to people who are not implementors and will always harm third-party vendors or even corporate users who need to match an implementation against a given snapshot of a spec. Don't misunderstand me, I see good bits in the "Living Standards" process. I see also unrecoverable bad bits.
• that "Living Standard" frenzy is a bit like the soviet revolution - if you can pardon that weird analogy - it tries to expand and reach all standardization areas related to the Web, even the ones that work pretty well with another system. Like the soviet revolution's proselitism, it uses sometimes unexpected ways. And it also suffers epic failures like the Websocket hickup at IETF that triggered extremely harsh words, almost never seen before in that organization. But unlike the soviet revolution that was highly centralized, it's more an organized chaos.
• html still poses major issues in terms of unified look&feel, localization, internationalization for web-based apps, not even mentioning "standalone" (hear chromeless) web-based apps. It really seems we're reinventing the wheel, as if XUL XAML and other solutions never existed. We're not there yet. Again. In terms of accessibility, I won't even tell you here my gut feeling, I want to remain polite at least the first day of this new year...

On the personal front:

• 44 and counting :-)

Wishing you a very happy 2012 !

Disclaimer: I'm one of the two co-chairmen of the CSS Working Group and the opinions below reflect exactly what I think of the CSS process not only as an individual contributor but also with my co-chair hat on.

The ineffable Henri Sivonen has contributed a long, a very long, a probably too long post about CSS Vendor Prefixes. In short, he thinks they are harmful and should be dropped. I tend to totally disagree and will explain why below. In bold, Henri's words. Indented and normal, my responses.

vendor prefixes are hurting the Web

No. Said like that without justification and as a first sentence in Henri's prose, no. They are not. Vendor prefixes allow vendors to implement experimental CSS features without harming the namespace of unprefixed properties.

They are hurting Web authors

Here, I agree. As they are now, vendor prefixes are hurting Web authors because a) the browser market does not evolve that fast, in particular on mobile devices b) some browser vendors never get rid of prefixed properties. As a result, Web authors have to maintain several prefixes properties per feature.

They are hurting competition in the Web browser space

I totally fail understand why, maybe the rest of Henri's article will explain why.

It would also make sense for browsers to implement other browsers’ prefixed features to the extent existing content uses prefixed features

This is non-sense. There are only two cases : first case, the prefixed property was proposed for standardization and then all browser vendors will probably implement it ; second case, it was not proposed, probably because it's too proprietary or badly spec'd, and no other browser vendor will implement it because it lacks a good definition or use case.

Why do we have vendor prefixes?

Henri says the discussion is Member-confidential. It is only because that discussion is super old, long before the CSS WG decided to go public. There is nothing secret here : we have vendor prefixes because vendors needed a way to start implementing new features w/o saying their implementation was the official final CSS property.

there is no clear rule for using vendor prefixes in the DOM

That's correct and that is hurting the Web. Mozilla does it right: when it implements a new API these days, everything is prefixed with moz. That way, if the final standardized API differs from the experimental implementation, it's easy to get rid of the moz-prefixed version, tell authors hey guys this was experimenal anyway, and finally switch to the stable standardized version.

Vendor Prefixes are “Hell” for Web Authors and Authoring Tool Vendors

That is 100% true, as I detailed above for Web authors. For Authoring tool vendors, it's a nightmare. But let me tell you one thing: the "HTML live standard" of the WHAT-WG is a nightmare of a MUCH greater magnitude than this one. In comparison with the fact what the whole world has now to call "HTML" can change overnight, CSS vendor prefixes are a sweet, predictable, simple candy.

Web authors have to say the same thing in a different way to each browser

Only because browser vendors are shipping "experimental features" in non-experimental versions! Experimental features should be available only in "technology previews" of the browsers, not in stable versions. That way, everyone could still test the experimental features according to the W3C rules BUT Web authors would not use prefixed versions in production. Since almost all browser vendors switched to a fast release process, I don't see the problem here. A feature would move from prefixed to unprefixed as soon as the spec reaches stability, ie CR status.

pure hell

I have the feeling Henri is using my opinion here to tell the world a "Live CSS Standard" would be better. I have the gut feeling he's advocating for a WHATWG way of doing in the CSS Working Group. I think this is totally wrong. I think this would make CSS collapse and trigger the hatred of CSS Authors because they will be totally unable to say what is CSS at a given point.

When the possibility of using engine-specific prefixes exists, engine-specific Web content follows.

This is just false. CSS stylesheets are full of CSS hacks because the different browsers don't evolve at the same speed, because they don't all offer the same feature set at the same time. Even if prefixes are removed, that will persist and therefore engine-specific Web content will persist.

Thus, a Web author who does not want to poison the standard namespace will only use the prefixed CSS keywords or DOM APIs

NO. Henri just doesn't understand Web authoring here. The only way to stop harming a stylesheet with different prefixes for the same property is to stop using prefixed properties. EXPERIMENTAL features are experimental, and Web authors are using them because browser vendors are shipping these features as if they could be used in production. They cannot. They're subject to change or even disappear at any time.

If a site uses CSS with the -webkit- prefix, users of Firefox, Opera or IE get a worse experience even if they implemented the same feature with their own prefix or without a prefix

It's only because browser vendors are dumb. And I do mean it. The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web. Of course, if -webkit-foo and -moz-foo are not based on the same version of the spec - and that happens all the time - that will be helpless.

Back in the old days when Internet Explorer introduced a feature that they just made up, they did not make their mark on it by baking their name into the identifier

Totally false for CSS. Microsoft Word is full of totally proprietary -ms-* properties since the first version of Word based on XML and CSS, in the "old days".

Last week, insertAdjacentHTML finally shipped to the Firefox release channel.

Unprefixed, yes. But that's normal, we have here a de facto standard, IE and its online doc, where we usually have a de jure standard, a W3C specification. That IE feature is more than ten years old and the IE-specific Web is full of it. It is totally out of question to do something even lightly different from what IE does. So prefixes are not needed. We already have the standard!

The situation is harmful for Firefox for mobile, Opera Mobile and IE on Windows Phone.

That's possible and I don't care. What I see is that your proposal to get rid of prefixes will be even more harmful to non-browsing tool vendors, Web authors who will never know if a feature is experimental (and then subject to changes) or not, and finally Web users.

In a word: No.

No only because at the time a standard is published, the Web is already full of prefixed properties. And the Web is full of prefixed properties because browser vendors ship experimental features to all final users, allowing Web Authors to use these experimental features in production Web sites. Even telling them "go ahead, it's tagged experimental but it's shipped to everyone anyway".

Lea Verou's prefix free...

...is in my opinion dangerous. It tells Web authors that a prefixed version of a property equals another prefixed version of the same property. And that is just false. Lea's prefix-free tool is FAR from enough. Trust me on that please, I had to implement a few thousand lines to start working around the problem and I only have a partial solution... This is MUCH MORE complex than what Lea's tool lets Web Authors think it is.

In practice, vendor prefixes don’t prevent legacy from accumulating ahead of CR. It’s not useful to pretend that they do.

Again, only because of browser vendors themselves. They wanted CSS prefixes but don't use them according to their original wishes. Experimental is experimental, ie "should not be used in production". Since whatever you ship will ALWAYS be used and abused, shipping experimental features to the masses could only lead to legacy prefixes accumulating in the wild. This is browser vendors' fault.

If -webkit-CSS meets the client requirement within budget today, -webkit-CSS is used.

Exactly what I said above. So don't make -webkit-CSS available to the masses. Make it available in tech previews, beta channels, etc. But not stable versions.

browser vendors should stop adding more prefixed CSS features and DOM APIs

Basically, it says CSS should become a Live Standard. I totally disagree and will do all I can to avoid that.

For CSS, features like this include at least Transitions, Animations, 2D Transforms and 3D Transforms

That opinion would be hilarious if it was not tragic... These features are almost similarly implemented but there are still stuff discussed in the spec itself. The standardization is NOT done yet, and the features are complex enough a new painful hole could emerge in the coming weeks.

I also think that it would make sense to unprefix single-vendor features

Ah, that I could agree with IF there is some sort of formal environment here : a) the vendor must consider its implementation is frozen b) it was shipped for the first time more than a year ago, so this implementation is now a de facto standard because Web sites are using it.

In these cases (flexbox, gradients), I think it would make sense to stop changing the spec, to unprefix the features in browsers that are closest to the current drafts and then prioritize work to match the spec in other browsers

Clearly no. That's what the WHATWG does, only implementations matter and specs don't, as Hixie told me during TPAC. I don't want to see that happen in CSS, ever. Furthermore, it would trigger an absolute nightmare for Web Authors and Web Authoring Tool vendors.

I think when browser vendors implement a feature experimentally, the feature should stay in experimental builds (nightly builds, “labs” builds or similar) until it is close enough to a “final” design that it can be taken as a constraint for future changes to the feature.

AAAAAH FINALLY. Here we agree entirely. Just what I said above.

I think the system where a WG can change anything until Candidate Recommendation (...) is fundamentally broken. I think decisions whether a feature can be changed should be depend on deployment.

I totally disagree. It's broken because browser vendors break it shipping experimental features in non-experimental versions. Basing prefix removal strictly on deployment is the most harmful decision to Web Authors and Web Authoring Tools that you could take. Only stability matters, not deployment.

Update: now it's clearer. One of Henri's goal is to make CSS adopt the Living Standards way of doing things. My opinion is that it would kill CSS or at least be incredibly harmful to it. So I will fight that. And to reply to Rik in that IRC log, no, I don't always mention my co-chair role when I discuss CSS. I even mention "hat on" or "hat off" when I do.

I had an interesting online chat with a friend in the US this morning (well, this night for him...). The topic was HTML and the recent Microsoft announcements. While we see HTML reach a next level with desktop apps, the lingua franca of the web is still far, really far away from having all what's needed for desktop apps or even web-based desktop-alike apps. If form controls improved a lot between html4 and html5, a wide range of UI elements are still out of reach. Well. Let me explain before shouting : they are codable but each and every site has to reinvent the wheel with lots of UI theming and JavaScript-based controls. That's bad because that's incoherent and expensive. HTML+CSS still lacks major, really major stuff like:

• real menus
• tabboxes
• pop-ins and more powerful tooltips
• trees (and when I mean trees, I mean tree-like widgets like the XUL <tree> able to render tens of thousands of lines w/o making the user experience awful)
• better integration with the OS/WindowManager
• etc.

While we're (the Standards Community) now focusing on super-mega-hyper-useful stuff like an API to get the battery status (sic...), we're still unable to include in a web- or desktop app such widgets with a native look&feel. There are zillions of frameworks to ease the pain, but none of them is ready for desktop apps, and HTML+CSS+JS desktop apps need them to become mainstream AND cross-platform.