Re: [css3] [css21] browser specific CSS

On 19/04/2011 23:59, Glenn Linderman wrote:
> On 4/2/2011 4:42 AM, Anton Prowse wrote:
>> Glenn Linderman wrote:
>>> So that leave site authors to avoid new features in which they find
>>> bugs or inconsistent implementations.
>>
>> Precisely. I agree that this is the price of not condoning browser
>> sniffing.
>>
>> [...]
>>
>> More interesting is the case where things are undefined. Often it's
>> undefined because the problem of deciding what the "best" thing to
>> mandate is *hard*. Allowing browsers to experiment here can provide
>> valuable empirical data to help make a decision in future.
>
> The logical flaw in your reasoning is that if site authors avoid new
> features in which they find bugs or inconsistent implementations, even
> if the inconsistencies are due to undefined features of the standard,
> then there will be no empirical data to help make future decisions.

It may seem like there's a flaw/inconsistency in my reasoning.  There 
isn't one though; the choice between receiving empirical data on 
implementation-specific behaviours and not encouraging any and all 
authors to work with/around all such behaviours is not, in fact, binary.

Firstly, it's important to distinguish between bugs, undefined behaviour 
and experimental features.  There's not much we can do about bugs if 
there's no browser sniffing, so we just have to avoid the buggy 
behaviour (or put up with it, if it doesn't overly harm the user 
experience).  Undefined behaviour is similar, except that it's expected 
that browsers do something sensible even if it isn't interoperable, so 
it's likely more palatable to put up with the cross-browser differences. 
  Experimental features, however, can be played with through the use of 
vendor prefixes.  (Caution: vendor prefixes are not a silver bullet, and 
it's essential that authors are aware of their limitations and 
consequences.  The factors that come into play are: the experience and 
knowledge of the author; the purpose and intended audience of the 
website; the type of behaviour being experimented with; and the ability 
or willingness of the author to revisit his work.  There are probably 
others too.)

> With scrollable <tbody>, I was providing a better experience for Firefox
> users than for users of other browsers. Leaving aside the ease or
> difficulty of sniffing, and the fact that it was an extension to the
> standard, now that it is removed, I cannot (I still can for users of old
> versions of Firefox, of course). Now that I cannot, what empirical
> benefit can be gained?

That's unrelated to the topic in hand, since you successfully delivered 
scrollable tbody to Firefox without sniffing for that browser.  I note 
with interest, however, Boris's comment in the Bugzilla bug that he 
cites in a later post in this thread: he points out that the scrollable 
tbody behaviour should have been implemented in Firefox with a vendor 
prefix, and that he hopes that no new feature will be released to 
authors in the way that scrollable tbody was.

>>>> Making browser sniffing easy is just begging for less knowledgeable
>>>> authors to "fix up" Browser X instead of reviewing their understanding
>>>> of the language (eg via tutorials, books) and switching to different
>>>> CSS
>>>> which does render the same cross-browser. This is a problem, because
>>>> unbeknown to the author, Browser Q also (legitimately) renders the page
>>>> in the same way as Browser X... but the author didn't test in Browser Q
>>>> so they didn't notice. Users of Browser Q now see broken pages.
>>>
>>> Users of Browser Q should report the problem to the site author. He can
>>> choose to support Browser Q or not. Whether he makes good or bad coding
>>> decisions along the way will determine how easy or hard it is for him to
>>> support Browser Q in addition to the others.
>>
>> This is exactly what many of us opposed to browser sniffing want to
>> discourage. We don't want authors choosing whether or not to support
>> Browser Q. We want authors to choose to support all browsers, and don't
>> feel comfortable with providing ways to make it easy for an author to
>> choose to support Browsers X, Y and Z and ignore Browser Q, even if that
>> comes at the expense of not being able to give Browser Y a new feature.
>> (Note that often it *is* possible to give Browser Y a new feature
>> anyway, since CSS is designed in such a way that existing browsers will
>> ignore new features (properties, values, @-rules, etc) if they don't
>> understand them. I accept that this only works when there is sensible
>> fallback, which is not the case for all new features, especially
>> high-level layout features.)
>
> Authors that support all browsers, coding and recoding and rerecoding
> until they find some bland technique that works identically in all
> browsers, and avoiding anything that is complex or interesting that
> doesn't, will not provide the empirical data that is helpful to enhance
> future specifications.

Secondly, whether or not finding something that works in all browsers 
involves coding and recoding and recoding depends on the cause of the 
problem and the choice of how to deal with it.

If the spec says that the feature that the author is trying to use is 
undefined or left to browser choice, then the answer is either (i) to 
accept (and understand) the consequence that different browsers may 
behave differently on that feature, or else (ii) to think about a way of 
achieving the same or similar effect (recoding and testing).

If the spec says that the feature is supposed to work in a certain way 
but a browser has a bug or a non-standard implementation of that 
feature, then (iii) thinking of an alternative (recoding and testing) is 
preferred.

If the feature is achievable through the use of vendor prefixes, then 
(iv) the author is free to use those prefixes to target certain browsers 
(though he ought to understand the responsibilities and consequences 
that result from the use of vendor prefixes).

The desired empirical data will come from (i) and (iv), in addition to 
dedicated test cases.


> If there were an easy way of browser sniffing, then authors may
> choose to leverage these discovered differences, and provide
> different experiences for users of different browsers.

Condoning sniffing to achieve something desirable in one place 
unfortunately makes it impossible to discourage people from sniffing in 
other places where it potentially causes more harm, hence I don't 
support it.

> Encouraging browsers to add experimental functionality, with a way to
> sniff out the browser that has the functionality, would provide such data.

Indeed, but it has the potential to greatly harm Web usability and 
openness.  A less costly approach in many cases is the use of vendor 
prefixes or (in the case of deliberately undefined behaviour) simply 
allowing each browser to do what it wants.

[I plan to follow-up on your later posts in due course.]

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 21 April 2011 08:39:55 UTC