Re: [css3] [css21] browser specific CSS

On Fri, Apr 1, 2011 at 5:25 PM, Glenn Linderman <v+html@g.nevcal.com> wrote:
>> Every feature has a tension here, because
>> everything can be misused.  Every feature, then, has to be evaluated
>> separately, to see if the gain from exposing it is worth the harm from
>> it being misused.
>
>
> So, your statement "everything can be misused" is in direct conflict to "We
> don't want to offer features that let bad coders do things that hurt users".
>  Can't do both.  Just withdraw the CSS spec, it can't meet its goals!  :)

No.  I specifically said, *in the quote you are directly responding
to*, that there is always a tension between usefulness and misuse
potential, and each feature must be evaluated separately to balance
the two.  It's clearly ridiculous to try and find absolutes in this
area, and it's not useful to imply that I'm trying to do so,
particularly when I'm explicitly doing the opposite.

For example, it's useful to be able to tell what sites a user has
recently visited, so you can present, for example, sharing links
specific to the sharing services the user has recently visited.  But
this is also a privacy violation, and has security implications in
that it makes it easier to do much more targeted phishing attacks (you
can, for example, figure out what banking website the user has
recently visited, and present a fake UI for that bank specifically).
It turns out that this is sufficiently bad that we shouldn't make this
very easy, so you can no longer use JS to read styles that were
applied by a :visited rule.


>> Browser detection has a long history of being very
>> bad, and there's no reason to think that the parts we can solve in the
>> browser will offset the parts that are still dependent on people
>> always doing the right thing, because doing the "right thing" is *very
>> hard*.
>
>
> The above paragraph highlights the thing that is still missing from your
> "long form" explanation... while browser detection has a long history of
> being very misused, 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.

Uh, yes.  They *should* avoid buggy and inconsistent implementations,
and bug the browsers to fix them.  Putting pressure on browses to fix
their bugs is the correct solution to *every* problem in this area.

Unfortunately, not every problem has a silver bullet.


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

Yup, but we've learned from experience that the harm done to users by
badly-done browser-sniffing is greater than the gain that good
browser-sniffing can bring, in general.

Thus, it's best for users if it's difficult, but not impossible, to
browser-sniff.  If you have the intelligence and resources to
browser-sniff, you're more likely to have the intelligence and
resources to fix your browser-sniffing when it inevitably breaks for
some users.  Making browser-sniffing easier wouldn't significantly
increase the number of people doing good browser-sniffing (they're
already doing it), but it *would* increase the likelihood that people
with lesser intelligence and resources start browser-sniffing, and
doing it wrong, and when things break they won't be fixed.

> Making it hard to leverage the good browsers is not going to advance the
> state of the art in site development.  Why would anyone bust their butt to
> implement some new CSS feature, only to discover that (1) it doesn't work on
> the 10th of 10 browsers in the required compatibility list, so they have to
> discard it completely because they can't differentiate that browser from the
> others?

Authors with the resources to do browser sniffing will still do so;
the fact that they actually have a "required compatibility" list means
that they'll probably keep up with bug reports and fix things when
they break.  Those who don't will just skip the feature for now, and
use it later when it works more widely.  This is the best outcome we
can reasonably hope for.

~TJ

Received on Saturday, 2 April 2011 01:07:12 UTC