Re: [css3] [css21] browser specific CSS

(I too am concatenating various responses.)

On 02/04/2011 10:59, Glenn Linderman wrote:
> So far I've not gotten any responses about how to work around the
> problems, other than "recode to use different CSS", which either
> indicates that there is a lot of redundant features, or forces a site
> redesign because the features needed aren't uniformly available.

Usually the latter.  I think most of not all of the people opposed to 
browser sniffing recognize that there are benefits that it could bring 
to some authors.

> It is pretty clear that site authors are going to do browser sniffing
> as a workaround to the problems of buggy browsers.  Making it easier
> to do correct browser sniffing would be helpful to avoid sites being
> created with bad detection checks

It's a good argument.  Some arguments against browser sniffing are 
countered by an API which makes it easier to do correct sniffing.

As others have already pointed out, though, doing correct sniffing is 
still hard, even when it's made more reliable at detecting metadata 
about the browser.  This is because the thing that you need to sniff for 
varies subtly depending on the problem.  Hence I don't find this 
argument too compelling, because I think a significant number of authors 
would still do it wrongly, even with an easier "API" or whatever.


> On 4/1/2011 9:15 PM, Boris Zbarsky wrote:
>> On 4/1/11 8:25 PM, Glenn Linderman wrote:
>>> Any attempts to predict the future are foolishness. Bug workarounds
>>> should be applied to versions known to have the bugs, no more, no less.
>>
>> This is _very_ rarely done.
>
> I posit this is _very_ rarely done because browser brand detection is
> hard enough without having to code version detection too. "Oh well,
> browser Q is screwed up anyway, just screw the users that use it"
> probably seems like an adequate justification to avoid the added
> complexities of a more precise detection. Making sniffing hard
> encourages this sort of attitude. "Our site works best in browser R. If
> browser Q can't hack the code, screw it, just use the fallback solution
> we use for the handhelds."

I don't see that as an argument in favour of easier browser sniffing. 
Currently, CSS doesn't condone browser sniffing at all, and I don't see 
that paving the cowpaths is a good thing here.  "You don't want me to do 
X because it hurts people, but I'm doing it anyway and it hurts 
people... so make it easier for me to do X because I'll hurt fewer 
people" doesn't work for me, because it still hurts /some/ people.


> if it wasn't so hard to figure out how to detect the browser, the
> site coders would have more brainpower left to figure out the best
> way range of versions for which to use a fallback CSS

Again, I don't see that as an argument in favour.  It's not for those 
who create the CSS specs to be telling authors where to spend their 
time, but I suspect that many feel that authors who are spending their 
time on browser sniffing are mis-prioritizing their work.  Making it 
easier for authors to sniff so that they can have more time to work 
around the negative consequences of sniffing (such as preventing a 
capable browser from using code they can handle merely because it wasn't 
on the author's list of browsers to test) just shifts the problem.  It 
doesn't remove it.

> The state of the art today, is that there is a jumbled mass of sites
> trying to explain all the issues, each of which starts from a
> different browser being declared "correct", each of which uses
> different detection mechanisms to sniff the browser, each of which
> proclaims their own practices as best practices, none of which (that
> I have found) that mention how best to code the appropriate range of
> versions.

I agree with that.  But your argument behind it seems to be that if it 
were easier to browser sniff then the lives of authors who want to 
browser sniff would be easier.  That's true.  But that doesn't 
contribute anything to the question of whether we should condone browser 
sniffing or not, so it's a red herring.

> And if you decide not to browser sniff, or if it becomes impossible
> to browser sniff, then web authors simply aren't going to use
> features that don't work in any one of the browsers they have chosen
> to support.

> blindfolding the users and the site authors isn't going to promote
> use of CSS in general or new features of CSS.

> you have as yet offered nothing as an alternative for working around
> the bugs that are to be expected in new features in future browsers.
>
> 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.


> On 4/1/2011 11:27 AM, Tab Atkins Jr. wrote:
>> We don't want to offer features that let bad coders do
>> things that hurt users.
>
> That's a very laudable goal.  But I'm not sure it is achievable,
> except by throwing out the baby with the bathwater.

I agree that it's not achievable in an absolute sense.  But adopting 
positions that make it harder for bad coders to hurt some users may well 
be viewed as an preferable, even if that makes it harder for good coders 
to be able to offer newer features to some users.  It's important to 
realize that this is a spectrum not a binary choice.


> On 4/1/2011 12:39 PM, Anton Prowse wrote:
>> Most authors also tend to assume that when their page looks wrong in
>> Browser X it's because Browser X is wrong.  Often, however, Browser X
>> isn't wrong; instead Browser X is exercising free choice given to it via
>> the CSS spec, either granted explicitly or more usually through making
>> the rendering undefined when certain conditions are satisfied.  (Search
>> for the string "define" in CSS21 to catch the instances of "is not
>> defined", "does not define", "undefined" etc to see just how many there
>> are!)
>
> In the standards committees I've been involved in, such
> specifications of "free choice" were usually ways to paper over
> preexisting variations in extant implementations so that variant
> implementations could all conform to the standard.
>
> I'm unaware of any case where that actually benefits users, except
> for backward compatibility with a particular vendors proprietary
> features.

This is sometimes true in CSS too.  But more often that you might 
imagine, the choice is given so that browsers can assist users without 
mandating one particular solution out of several available.

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.

>> 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.)

> So is there a list of which CSS is expected to be cross-platform and
> which is not?

The spec itself.  As for browser support lists, there are several 
popular and seemingly reliable ones out there.

>> Alternatively, perhaps Browser X is correct and in fact it's Browsers W,
>> Y and Z that are wrong.  This doesn't happen so often any more, but back
>> in the era of Firefox 2, for example, IE6 got some common aspect of
>> stacking contexts correct when other major browsers all got it wrong.
>> Most authors assumed it was IE6 up to its usual tricks, and hacked to
>> "fix" that browser.  They were pretty mystified when the other browsers
>> updated their rendering in later versions, resulting in page breakage in
>> all modern non-IE browsers!  Again, if the author had researched the
>> problem instead of opting for a quick fix for Browser X, they would have
>> realized that their chosen technique isn't yet reliable and would have
>> changed to a different one.
>
> So they had to recode.  Since the discrepancy existed, they had to
> code two ways anyway.

Or avoid the feature.

>> Hence browser sniffing makes it really easy for authors to
>> unintentionally give certain users a bad experience.
>
> It also makes it really easy for authors to intentionally give
> certain users a better experience, if they are using a decent browser
> brand and version.

The view of most of us who are opposed to browser sniffing is that that 
is not an acceptable trade-off.

>> It also makes CSS much more difficult to maintain because the CSS is
>> forked; the consequence of some later change elsewhere in the stylesheet
>> has to evaluated in multiple ways, once for each fork.  Even at the best
>> of times authors seem to find it rather hard to understand from a global
>> perspective the many many interactions going on inside their CSS.  I'm
>> not hopeful that expecting them to hold /multiple/ global perspectives,
>> one of each fork, is realistic.
>
> Every conditional does, indeed, make for harder understanding.  So,
> like Tab, you don't offer an alternative to achieve the desired
> functionality in the presence of some browsers that act differently
> than others.

No.  I'm not sure that there is one which doesn't suffer from drawbacks 
that many find unacceptable.  No-one's come up with one so far, despite 
this problem having a long history.


> Particularly problematical are older
> browsers that implement a new feature with a bug. That feature becomes
> dead until that browser is dead. Feature detection can help some, if all
> the browsers get it right the first time (ROFL).

Yes, this is one of the biggest frustrations of not having browser 
sniffing.  Bugs should be filed to the browser manufacturer, but that 
doesn't help the author right now.  However, although using browser 
sniffing allows the author to fix the bug for a specific browser, it 
comes at the cost of the negative consequences that browser sniffing 
has.  Many participants on this mailing list feel that the negatives 
outweigh the positives.


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

Received on Saturday, 2 April 2011 11:43:18 UTC