Boy, am I ever late to this party. Even so, my mind's been on these things today, so I'm writing.
Also, I apologize for the threading. I inadvertently sent this to Mr. Carroll rather than the list, and if T-Bird has a secret handshake for resolving that contingency, I don't know what it is.
TL;DR: It's all about good habits. Always was, always will be, and always leading to more site for less money when practiced by people whose skills are not in question. On 10/7/14, 6:23 AM, Barney Carroll wrote:
The obvious problem is that the W3C is too slow and cumbersome for many people's desires and expectations of the web. IE6 came with a
[...And IE5.x before it...]
suite of incredibly powerful functionality that the rest of browser-land is only now catching up to (filter: anyone?). The
Cf. alpha, animation, gradient &c. support per the CSS3 module specs. Many of these are actually well-supported in current-gen browsers. Alpha in basic forms has enjoyed reliable support for something close to ten years; I first used it in a production project during June 2006. The semanticians, and some few standardistas who don't participate here, are in the final stages of a quiet, intermittent battle over the proposition thatr filter:foo() and expression() are at all appropriate to include in the CSS context. To further confuse matters, jQuery and the various groups flogging their preferred preprocessors have jumped in with their own approaches to implementation.
problem then was that some of the earliest webapps were designed specifically for IE, back when there was no conceivable way of forking the code to achieve similar functionality in other browsers.
...It's been practical to fork JavaScript out to the barest limits from the moment both Netscape 4 and IE 3.01 came out. Having successfully met it, however, I would not wish on anyone the requirement to support IE 4-5 and Netscape 4 comparably. Among other things, the whack approach to the box model in all of them requires what we call a polyfill... these days.
VML was submitted 2 years before SVG started taking shape. IE6's lofty goals were almost reinstated in the "HTML5 in the broadest sense" that the W3 tried to make a PR splash about (embedded multimedia, file-system API, seamless vector graphics in HTML, CSS3 transforms & filters). But once again, people have come to expect awesome stuff that the W3C is too slow to ratify to a universal consensus.
People, for the most part, DO NOT CARE. They only care when something that works in {x} breaks in {y}, and damn the contract language, even if {y} happens to be a beige box PC from a practically anonymous vendor running Win98SE to a lousy display. (16-bit color spaces, anyone?) Salespeople and ubernerds care VERY, VERY MUCH. Of course, both of those groups tend to think of things like support gaps as obstacles to be scaled by McGyverish means if necessary, not as limitations that will work themselves out in the face of patience and persistence. I'd gander that one hour of thoughtful lobbying to (or chain-yanking of) someone in a position to Do Something is probably worth several THOUSAND hours of engineering workarounds. [Cf. the Browser Upgrade Campaign in 2005, for which the Web Standards Project set the stage - and in which, therefore, I played a VERY peripheral part - before the IE product team sent us word that they'd be willing to listen to us, but only if we divested the campaign.] Just don't tell that to the salespeople and ubernerds. ...And this is where I point out that I'm writing here because I was just thinking about this today: every HTML spec from 2.0 through to 4.01 was mostly retrospective. [CSS2, and ESPECIALLY CSS2.1, also shoulder this burden.] * 2.0 added forms and images; * 3.2 added anonymous elements (div, span), bidi links, and tables; and * 4.x added event handlers and the table extensions that had come about in the meantime. There *is* an HTML3.0, as well; that never made it past the Proposed milestone (if even that far) because its development was integral with backchannel discussions that involved Dave Raggett and commercial browser engineers, a fact that we could only apprehend in hindsight. HTML5 was developed on terms that reflected appreciation of the process mistakes committed with HTML3.0. To HTML4's credit, it turned a11y into an Official Thing with equally official API features, which it hadn't really been until then.
So the responsibility (which, I agree, ultimately rests on website authors) comes down to managing expectations. It's tough to say no, especially when there's a lot of money in it and many people in the trade of web development are inclined to exploratory hacking anyway.
Yes, that's a good deal more delicately put than my version.
It's becoming increasingly more difficult to tell people you can't, in good conscience, serve up code relying on unratified specifications, when implementation of such functionality is ubiquitous (and you know how to do it). A few years ago web development studios started finding the willpower to tell clients they wouldn't commit to like-for-like experiences in legacy Internet Explorer versions, and for a while standards-compliance seemed to be that bit more tenable – but recently I've come across numerous situations where people will say they only care about Chrome & iOS support.
Well, isn't that special? The trick is to bury the support matrix in the finer print, and deliver cross-browser assets as a matter of course. We too often look at this in terms of which browser will get the best experience; foresight and a firm hand with stakeholders can guarantee that each browser will get the best experience that the budget will allow. This is accomplished by: * Sticking to the features common to the various API implementations, ESPECIALLY those related to CSS; * Relying on native code to the greatest extent practicable, with particular emphasis on try() and catch() in JavaScript functions known to be fragile; * Using frameworks and polyfills to fill the gaps; * Throwing down for server-side processing in those cases that will be simplified accordingly; * Framing only the small shiny bits as platform- specific, if the need to discuss those particulars even arises; and * Testing. Test, test, test. What we have instead are professional managers managing teams of silo'd engineers and designers, with an emphasis on quicker shipping and lean processes. This looks terrific on somebody's bottom line, but it wrings more potential out of the medium than I care to contemplate in any detail. The goal is NOT to ask "how high?" when the stakeholders say "jump", but instead to put the stakeholders at ease and SOLVE THE PROBLEMS THE SITE IS MEANT TO SOLVE. Ahem. Sorry about that.
As regards the 'reasonableness' of these various expectations, I think W3C compliant validity is at its most applicable when it comes to web sites consisting of many documents: you want these documents to be consistent with each-other and marked up to universal standards for reasons of posterity & universal access. For my part,
...That's actually what a CMS is for, something that just came up at alistapart.com today, in fact. It's folly to insist on adherence to technical standards - which the Web platform suite is only in name, since there is no ENFORCEMENT mechanism - if you have not first set expectations of implementer knowledge and product quality that leave no PRACTICAL alternative to following those standards in spirit as well as name. As afflicted as we are by the race to the bottom, and as unlikely as we are to enter into a ubiquitous and effective professional organization, the opportunity to do that is restricted to a small elite of shops.
what I've been working on for the better part of the last year would be more accurately described as web apps: there's a single HTML document and it acts more as a wrapper for dynamic functionality. The term 'document' barely applies, and the use-cases are so esoteric and business-critical that the client will happily use a specific browser version in order to guarantee expected behaviour.
...Then you, sir, are a lucky man. May all your prospects be so accommodating. -- Ben Henick lurker...@henick.net Sitebuilder At-Large t:@bhenick ______________________________________________________________________ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/