On 10/22/12 4:10 AM, Philip TAYLOR wrote:
We, and the stakeholders for whom we work, have expectations founded on
solving real-world problems. Some of those problems are more imagined
than others, depending upon the actor who presents them.
The standing and immediate requirements faced by browser product teams
and W3C Group participants are rarely so tangible, or so relevant to the
problems that we solve day-in-day-out.
If an implementation chooses to ignore the wording of the current
specification, which according to :
http://www.w3.org/Style/CSS/Overview.en.html
is CSS 2.1 as amended by CSS Color Level 3, CSS Namespaces and
Selectors Level 3, and implements a behaviour that directly
contradicts that specification, how can that be classified as
anything other than a bug ?
...On account of three points of logic:
1. Reccos are not binding, no matter how passionately
we might wish otherwise.
2. "Bugs" lead to completely unintended behavior or,
in a specification, unintended consequences.
3. CSS 2.1 and especially CSS 3 are in a number of
areas well ahead of the state of the art. In most
test results I see many given features labelled
"Partial" or "Experimental" - and unless someone
claims to have built a reference implementation,
it's hard to call the contradictory behavior a
bug.
...Better to call it a "misimplementation." So goes the rationale for
duplicative -vendor property prefixes; the implication is "until we meet
the spec and/or the typical behavior, we're keeping this in our own
little sandbox."
In my view (which I do not think is heretical), an author should be
able to /rely/ on a W3C specification, not have to test his/her work
against every extant browser -- would you not agree ?
I do agree in principle, starting from the premise that the Reccos etc.
define the not-broken behavior, and then researching real-world
deviation from that expected result.
I would even carry my sentiment to the point of stating that if it's
contradicting the spec, then it needs to live in a -vendor prefix,
preferably one that includes consistent (or at least well-documented)
major version information.
So many times over the years I've wished that a vendor would relegate to
nightlies, or omit entirely, property and selector support that's
off-the-rez.
However, product team dynamics, release schedules, and vendors' grasp of
our priorities rarely have very little to do with the standards-adoption
process. That's why the Acid tests were so important: they provided
batteries of sub-tests that provided concrete support goals and
illuminated implementation challenges that once met would lead to better
browsing software.
--
Ben Henick lurker...@henick.net
Sitebuilder At-Large t:@bhenick
+1 785 856 1863
______________________________________________________________________
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/
