Re: [css3] [css21] browser specific CSS

On 4/19/2011 11:50 PM, Alan Gresley wrote:
> On 20/04/2011 7:59 AM, Glenn Linderman wrote:
>
>> 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
>
>
> To get the columns from shrink wrapping.
>
>
> .mh5>div
> {
> width:100%;
> margin-right: 20px;
> }


I've read the box model spec quite a few times, and never figured this 
out.  From CSS2.1 PR Section 10.2:
<percentage>
     Specifies a percentage width. The percentage is calculated with 
respect to the width of the generated box's containing block. If the 
containing block's width depends on this element's width, then the 
resulting layout is undefined in CSS 2.1.

it seems that this is quite unspecified by CSS 2.1, but testing your 
suggestion proves that the browsers I can test with do, in fact, produce 
a consistent result, BUT ARE NOT REQUIRED TO. So from other comments 
made here, I shouldn't use this feature, because there might be a 
browser somewhere that acts different.


> All browsers are showing correctly that I can test (FF version 3.6.16
> has been gobbled by FF4) apart from Safari which does not clip the
> margin-right in a overflowing container. To fix that change this CSS,


So this Safari behavior seems to be a non-conformance to CSS2.1 PR, 
correct?  Section 10.3.3, correct?


> .mh5
> {
> overflow: auto;
> height: 100px;
> width: auto;
> float: left;
> }
>
>
> to this.
>
>
> .mh5
> {
> overflow-y: auto;
> overflow-x: hidden;
> height: 100px;
> width: auto;
> float: left;
> }
>
>
> Does this help?


Sure, it helps.  But it seems to be replacing an undefined, inconsistent 
behavior with an undefined, 
somewhat-consistent-among-some-number-of-tested-browsers behavior: do I 
understand that correctly?

So the recommendation is to never depend on non-standard features, 
except if you can test enough browsers and decide you can?  So then 
after deployment, someone comes along with a different or upgraded 
browser that acts different, and then what?  Sniff the browser? 
Redesign the web site?


> I should add that floats (or tables) with auto width and cases involving
> overflow use to be very buggy in 2008.


Well on this machine, I'm running 4 browsers released in 2011, happily. 
  For some applications, this one in particular, I know that the users 
are only using Chrome and Firefox (and sadly they are the two that 
produced stupid-looking results without your tweak), and upgrade 
reasonably often.  So this helps to make an icky fallback case work by 
depending on a non-standard feature of current versions of these browsers.

I have no particular desire to test this on older versions of browsers, 
because they don't apply to this application, but from what you say, 
this technique wouldn't likely work well on them.


By the way, I did peruse your CSS Test site, and the CSS discussion 
group and wiki you pointed me at.

I was a bit disappointed to find your samples that render in all known 
browsers using all sorts of browser-specific CSS rules, apparently as 
fallbacks for (older?) versions of browsers during their development 
paths towards standardization... I don't find that significantly less 
complex to create or understand than browser/version sniffing.  I expect 
to hear about "CSS bloat" in the future, if that sort of technique is 
the wave of the future. It seems that the arguments about how complex 
browser sniffing is to get right and how people misuse it, will simply 
be replaced by arguments about how people misuse and over-constrain 
browser-prefixed CSS, and what a nightmarish mess they have with 6 
(different, at least because of different prefixes) fallback techniques 
for 6 different browsers, and how difficult it is to maintain the same 
code 6 different ways, and how the real functionality of the CSS is 
obscured by the necessity to express it many ways to support multiple 
versions of multiple browsers.

As an experiment, I tried to extract the techniques of your menu system 
from your CSS file, and remove all the fallbacks, and I did succeed, 
after some hours, in making a similar system that looks similarly nice, 
and works in _today's_ browsers, but likely not the older ones for which 
you have all the fallbacks in place to support.

And it seems that the CSS discussion group and wiki are populated by 
many people that are sniffing and hacking their way to solutions -- 
depending more on actual behaviors of the varied browsers than the 
standards.  It only confirms my view that some here have tried to 
dispute, that sniffing and hacking are the only way to achieve 
reasonable web sites with yesterday's browsers, that are still widely in 
use.

There is pent-up demand for more sophisticated web applications, 
otherwise libraries like jquery, which have hundreds of thousands of 
lines of code to try to provide uniform services across diverse versions 
of browsers, would not have been invented nor be maintained.  So the 
line I hear here, about "just don't use the new features that aren't 
consistently implemented across browsers or have a bug or 
non-conformance in some implementation" isn't going to be 
well-received... it'll be ignored, and more lines of code added to 
jquery to support new and future browsers... likely including more lines 
of code to do more complex browser sniffing if browser vendors attempt 
to make sniffing harder, as has been stated here.  Sad.

Received on Wednesday, 20 April 2011 08:18:23 UTC