Re: [css3] [css21] browser specific CSS

On 22/04/2011 05:28, Glenn Linderman wrote:
> On 4/21/2011 1:39 AM, Anton Prowse wrote:
>> 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.)
>
> I agree there are distinguishable cases of behavioral differences in
> browsers, and you've classified them reasonably.
>
> However, bugs are widespread.  Not having a workaround for them is
> foolishness.

Frustrating, maybe.  Foolish?  Certainly not if the workaround is damaging.

> Experimental features are great ways to experiment, and vendor prefixes
> are great for that, but Alan's site full of vendor prefix alternatives
> has demonstrated to me that it is not appropriate for general use, or
> released sites.

That largely depends on whether the author can commit to maintaining the 
stylesheet.  If he is likely to, then they can be used effectively.

> Sadly, I can envision a future where browser sniffing
> is sometimes done via vendor prefix misuse.

Yes, unfortunately it's likely that this could be achieved.

> Having a demonstration site of recommended, standard, cross-browser
> techniques for various use cases would go a long ways toward helping
> people pick good techniques for various common "widgets".  Such a set of
> use cases probably could have helped reduce the number of such use cases
> that accidentally wander into non-defined territory in the standard, had
> development of the standard centered around providing generalized
> facilities that solve such use cases.

That's a great idea.  But I don't think that that falls to the CSS WG to 
create.

> Scrollable tbody, and auto width
> tables have discussions on the web from 10 years ago, and the hacks
> people have done to get pleasing results from various browsers that were
> much less standard than today's (mostly requiring Javascript, sadly,
> because neither the CSS standard nor the conformance level of browsers,
> was anywhere as good as the current crop of browsers).  It would have
> been great if such common cases, along with drop-down menus, and tabbed
> interfaces, would have been addressed by the standards committee, so
> that the only people hitting undefined areas would be those pushing the
> state of the art, not just trying to do simple stuff.

Many, many websites are dedicated to providing such information, 
although they vary widely in quality, accuracy and understanding.  It's 
a dangerous game to promote certain techniques as "authorized" or 
"official", and I don't think that the WG should go down that route.  It 
would be fantastic if WG members, as experts in the field, were to offer 
this kind of resource in a personal capacity though.


>>>>>> 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.
>
> Well, that's an interesting theory, but I can't say that I can agree
> with it.
>
> First, when coding CSS, after getting a basic understanding of it,
> most people are going to "just try things" using their favorite
> browser. After they get something working there (which may or may not
> require resorting to the spec) they will either try it in other
> browsers, or not.  If it works the same, they will be happy, and
> probably not refer to the spec again, until someone reports a problem
> in some untested browser(s).  By then, they would likely be married
> to the technique, and try to hack the other browsers into submission
> :)  If they find a difference in testing other browsers, then they
> would probably resort to the spec to figure out why, and come up with
> an alternative technique, if possible.
>
> When the authors have to resort to alternative techniques, that is
> when you lose the empirical data you desire... because when they find
> one, you don't learn their original thought processes and desires and
> goals, unless they happen to report it as an issue or feature
> enhancement request.

Indeed, but that's precisely (ii) and (iii) above, isn't it?  We agree 
that you don't get empirical data that way.

The author could alternatively have decided to (i) live with the 
difference or (iv) used vendor prefixes if the rendering differences are 
related to experimental features.

> And when they put up with differences, you don't know whether they
> understand them, or simply didn't test all the browsers... again, you
> have no understanding of the data you see.

Indeed, but quite possibly that doesn't matter.

> If they do browser sniffing reasonably correctly, and code for the
> various browsers to achieve the affects that they want to see, then is
> when you learn what their goals are, and what features would be good to
> standardize, clarify, or enhance.

That's not the only way (nor the best way) to express those desires, 
though.  Some specific examples would help here, since it's getting 
rather abstract at this point!

> I could see authors, clients, and corporations more willing to use
> vendor prefixes, if they can also do browser sniffing.  While vendor
> prefixes provide a very small amount of browser sniffing, its use
> depends on their effect being limited to small variations in
> appearance... something like rounded box borders.  But broader issues
> are much harder to deal with using localized vendor prefixes with
> standard fallbacks.

I agree with the latter, but I don't see how browser sniffing affects 
corporate willingness to use vendor prefixes.

>>> 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.
>
> Yep, you've stated that before, and I think you are throwing out the
> baby with the bathwater.  It is great -- nay, imperative -- to have a
> base level of standardization among browsers, so that the web can have a
> foundation to build on.  But also having a way to use specific browser
> feature extensions will help with the ability to innovate on the web,
> and keep it growing and thriving.  CSS vendor prefixes are much too
> limited for more than decorative twiddles.
>
> A lot can be done with "feature sniffing" too, be they standard or
> vendor-specific features.  But these forward-looking,
> not-always-standards-committee-sanctioned, vendor extensions, while they
> should be codified in some manner, are also likely where there are the
> most bugs and variations between browsers, and an overall browser
> sniffing required to deal with different browsers differently, until the
> day comes that the extension becomes standard and uniform.

I don't think that the typical web developer ought to be in the game of 
using vendor extensions and then browser sniffing to work around bugs in 
said extensions.  If the implementation is buggy then it should be 
avoided, and bug reports filed.  Only experts should be trying to fix up 
buggy implementations... and experts are probably capable of doing 
browser sniffing by the back door anyhow (and hopefully sensible enough 
to assess the risk and margin for error in what they're doing, and 
understand the responsibilities and consequences that come with it).

I don't believe that it's a case of throwing the baby out with the 
bathwater, which seems to imply that you think the needs of the experts 
outweigh the dangers lurking for the non-experts (and the resulting poor 
user experience of their users).  I fundamentally disagree on that 
point.  At the heart of the issue is whether the WG should be seen as 
_condoning_ an approach that would lead to a less usable or less open 
Web due to its misuse by authors (and I *guarantee* that it would be 
widely misused).  I strongly feel that it shouldn't.


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

Received on Thursday, 28 April 2011 17:37:49 UTC