Re: [css3] [css21] browser specific CSS

On 4/2/2011 4:42 AM, Anton Prowse wrote:
> (I too am concatenating various responses.)


Thanks for a very thoughtful response, Anton.  It is clear you presently 
fall into the camp of "make browser sniffing hard", which is not the 
camp I am in, obviously, but in spite of the thoughtfulness of your 
arguments there is a logical inconsistency in them.  I will attempt to 
point it out now.  I have been quiet for a time because of several reasons:

1) I've been busy, and no doubt everyone here has been too. I now have a 
specific demonstration of inconsistency in rendering among current 
browsers, using the not-yet-standardized HTML5 doctype.

2) Pushback from various people that I haven't done my homework to 
demonstrate an inconsistency among modern conformant browsers, and that 
they are too busy, so I should go away and make noise on other forums.

Although, since the spec isn't final, it is unclear how they can be 
conformant; a careful coder would want to code only to final 
specifications, not drafts; sadly the past history is that none of the

browsers fully conformed to past final specifications, so there were few 
usable features from those specifications.  Happily, there is better 
conformance among current browsers to the current draft, than there ever 
was among older browser to older drafts.  Sadly, older browsers still 
exist, and have no support for easy sniffing.  Sadly, newer browsers 
still have variations, still have no support for easy sniffing, are 
making it harder to do sniffing at all, and because the spec isn't 
final, no one knows whether the code they write today will have any 
chance of standing the test of time.  It does seem that by using the 
HTML5 doctype, that most new version browsers now at least conform to 
the old specs that use other doctypes, so perhaps now in 2011 we are now 
achieving conformance with the 1998 specification: If CSS 2.1 and HTML5 
were to reach final form this month, I wonder how long it would be 
before the features would be usable?

3) Discovering the Firefox 4 has removed the useful feature of 
scrollable <tbody> that someone here pointed out has never been 
standard, and trying in vain to find a decent workaround. It is in the 
process of testing that that I developed a test case outside of private 
environments that demonstrates one of the variations among today's browsers.

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.


On 4/2/2011 4:42 AM, Anton Prowse wrote:
 > Glenn Linderman wrote:
>> 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.


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

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?


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

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


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


For older browsers, yes, along with corresponding UA sniffing techniques 
and hacks.  For newer ones, I haven't found such.

=======================

OK, here is a demonstration of a difference between current browser 
versions using the HTML5 doctype to attempt to get all browsers to act 
the same, in conformance to the current not-yet-standard.  I don't know 
if this is a bug in some of the browsers, or an area where the standard 
is not silent on how it should be handled.  My interpretation of what is 
useful would be that Firefox and Chrome have a bug.  I wouldn't be at 
all surprised to be told that IE and Opera have a bug, and that the 
"overflow" feature should not consume additional space when overflow 
occurs than when it didn't... if the space were truly constrained, I 
would even agree with that.

Once upon a time in a browser named Firefox, one could, in CSS, make 
scrollable <tbody>, and the header row cells would have the same widths 
as the body row cells.  The only little glitch was that when the 
vertical scrollbar appeared, it would take space from the last column of 
cells, so providing a blank column at the right, the same width as the 
scrollbar, was the workaround.

However, Firefox 4.0 has explicitly removed this capability, per its 
release notes, without a stated reason.

The data I display in my tables is variable width: for some data sets, 
some columns are wider or narrower than for other data sets, so it is 
not possible to predict the widths without wasting significant space. 
Hence I've been using the auto layout for column widths.

Now I cannot figure out a CSS only way to get the <thead> to stay 
visible while scrolling the <tbody> when it exceeds the vertical size 
allocated to the table.  This is true whether the table is coded with 
<table>, <thead>, <tbody>, <tr>, and <td> tags, or if coded with <div> 
tags, and styled with the corresponding display: modes.

Is there a pure CSS solution for this, like was available in Firefox 3.x?

This seems to be a giant step backwards, unless I'm missing something. 
Constraining the overall table within a block of fixed height causes 
scrolling, but while the table may be only 300px wide, the containing 
block winds up being the full width of the viewport, and the scrollbar 
over at the right margin of the page, far away from the right edge of 
the table, rather bizarrely.  Because the whole table is within the 
constraints, headers and footers also are scrolled, leaving the middle 
of the table with no visible captions.

Then, if float: left; is added to the style of the containing block, it 
not only brings the scrollbar next to the table, it shrinks the table, 
forcing some cells to have multiple lines, rather unnecessarily (this 
behavior happens in Firefox and Chrome; Opera and IE leave the table at 
its natural width, with one line of text per cell (appropriate, in my 
opinion, until the total widths of cells exceeds the width of the viewport).

I see several problems here:
1) no CSS technique for scrolling table body rows.
2) without a float, directive, the scrollbar is far away from the data 
being scrolled.
3) with a float, different browsers render the table differently, even 
though there is no width constraint.

Demonstration page: http://nevcal.com/test/testtab3.html

Received on Tuesday, 19 April 2011 22:00:21 UTC