Re: [css3] [css21] browser specific CSS

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.

Undefined behavior, expected to be sensible if not identical, may be 
palatable or may not, depending on the case.  Being able to deal with 
them via intelligent choice after understanding the behavior of 
particular browsers, by coding specific code for the specific browser 
would be useful, for the non-palatable cases.

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.  Sadly, I can envision a future where browser sniffing 
is sometimes done via vendor prefix misuse.

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

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

No, I did have to sniff Firefox to deliver scrollable tbody.  I sniffed 
it in CGI, though, not Javascript.

I don't know exactly when scrollable tbody was implemented in Firefox 
(or possibly its predecessors),  nor whether it preceded or succeeded 
the concept of CSS vendor prefixes.  Seems the bug he pointed to was 
several years old, so scrollable tbody would be older than that, likely.


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

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.

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.

I agree a small subset of that can come from (iv), if authors are 
willing (and allowed by their corporate or client rules) to use vendor 
prefixes.

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.

Scrollable tbody is an example of that, of sorts.  The code for Firefox 
3.x varied from the code for other browsers in manners other than the 
constrained height being provided to Firefox and not for Chrome.  The 
Firefox code also had to tweak the number of <th> and <td> items 
returned, which I can't imagine being doable using a vendor prefix in 
the CSS. I did it in CGI, it could have been done in Javascript, but not 
in CSS.  So the use of vendor prefixes alone as a technique for 
experimentation is very limited.


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


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

Thanks.  I understand time is limiting.  I'm rather sporadic in my own 
availability for this sort of discourse.  I wouldn't do it at all, 
except that I think it is an extremely important subject.  I see the 
lack of standardized browser sniffing as a huge burden on web authors 
that try to do innovation.  And I don't think use of Javascript should 
be required to compensate for the inability to do browser sniffing in 
CSS, as it presently is.