> So unless you're targeting a very specific market, like iPhone users (where yes, WebKit's share is 100% due to Apple's monopoly), it's very hard to find any demographic in which there is such a strong dominance as IE had back in the day.
As you hint towards later in your own post, WebKit/Blink are in many markets there on mobile/tablet: in Europe, WebkIt/Blink are over 90%. For many of my customers, they could make a quite sensible business decision to not support other browsers with the same level of testing. This still causes problems—we have Edge implementing large numbers of WebKit prefixed properties, Opera abandoning Presto in large part due to the WebKit domination of mobile (where, at the time, bug compatibility was necessary on several major sites), leaving Firefox as the last hold-out from supporting WebKit prefixes (and if they wish to make inroads on mobile, they'll have to).
> CSS got a bit mired in CSS 2, but CSS 2.1 allowed them to slim down the specification and get out something working, while CSS 3 allowed them to work on individual features separately, and thus be able to make progress without having to wait for everything in the world to be ready.
I'm relative certain CSS 2.1 is actually longer: it defines much of what's in CSS 2 in far more detail, with much less left undefined and fewer contradictions. What little that was dropped was dropped because it didn't meet the modern (post-2003 or so) requirements for specs to advance to REC at the W3C, namely the requirement for two interoperable implementations of each feature (technically, requirements to advance beyond Candidate Recommendation to Proposed Recommendation, whereupon the Members of the W3C vote (one vote per member) and the Director has a final say, thereafter being published as a Recommendation).
CSS 2.1 laid a lot of groundwork that's been vital for more recent modules: without a clear definition of many of the underlying layout primitives in CSS 2.1, it would be hard to define the new features in reasonable detail. That's not to say CSS 2.1 is perfect—there's work happening on CSS 2.2, primarily just integrating the current errata, and the test suite could certainly be better (Mozilla Research are paying me to work on that in the coming months, as Servo doesn't have the user base that would show many of the site compatibility bugs that arise as a result of their bugs, leaving them disproportionately reliant upon the test suite).
> Now, you want to make some cool new device that needs web rendering support? You want to experiment with interesting new ways to present web content? You now have several high-quality, open source options to choose from, which have enough market share that most sites have done the compatibility work to make sure they are compatible.
A lot of that depends on how "standard" your device is—if you're running Android, it's "relatively" straight forward. (I think Opera's recent rewrite of their browser, basing it on top of the Chromium Content API, shows that even implementing the UI is hardly a small effort.) If you're running everything statically linked, using DirectFB to write to screen (this is how many embedded browsers work), it is substantially more work, especially if you are concerned with minimising binary size. I think it's easy to underestimate how much work is involved in porting the open-source browsers to new platforms, yet alone keeping them up to date and providing security fixes (which given the short support period of each release, depends upon the former).