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/
