Re: [css3] [css21] browser specific CSS

On 4/1/2011 1:29 AM, Alan Gresley wrote:
> On 1/04/2011 5:38 PM, Glenn Linderman wrote:
>> On 3/31/2011 10:53 PM, Alan Gresley wrote:
>>>> 1) Not all browsers can be easily differentiated with the various known
>>>> hacks. Searching for and/or inventing such hacks may bring a feeling of
>>>> accomplishment, but are largely a waste of programming resources. Some
>>>> of the hack sites I've visited point out that certain browsers
>>>> cannot be
>>>> easily differentiated, but do have variant CSS implementations.
>>>
>>>
>>> I strongly disagree with the use of any browser hacks. From all my
>>> experience with coding CSS and HTML, any browser bugs relating to CSS
>>> implementation that do occur can not be fixed with hacks. The only fix
>>> is the rearrange the HTML or try simpler CSS styling.


Note the immediately prior sentence, which is a quote from your earlier 
email.  The way I interpret it, is that you are suggesting, as a fix for 
inconsistent and buggy CSS features in various browsers, to avoid 
triggering the inconsistent and buggy CSS features by avoiding them... 
using the subset of CSS that works consistently.  This is the fix that I 
referred to later.  Sadly that subset of CSS, while useful for some 
things, is pretty limited compared to what CSS 2 claims to be capable of.


>> Hi Alan,
>>
>> Thanks for your response. I too dislike browser hacks
>
> :-)
>
> Let me re-clarify, I strongly disagree with the use of any browser hacks
> that are targeting or filtering the latest versions of rendering engines
> (Gecko, Presto, Trident and WebKit). Please don't take to mean that I
> don't support CSS hacks but any CSS hacks should be those well known
> hacks aimed at browser likes IE7-.


Certainly the limitations of existing deployed browsers cannot be 
overcome by any means except hacks or conditional CSS based on user 
Agent detection in Javascript or CGI, because none of them implemented a 
version of CSS that supported determination of browser brand and version 
in CSS.  And until and unless a technique for doing so is added to CSS, 
that current hack mentality, or conditional coding, will persist.  It is 
only after there is CSS support for browser brand and version 
determination, and that all browsers not supporting that feature have 
died, that CSS hacks or conditional CSS without Javascript or CGI User 
Agent parsing will go away.  Having pure CSS-only conditionals would be 
way better.

Or, I suppose, if you believe there will be a day when all the browser 
implement CSS without bugs, that could also be a solution.  LOL

I agree IE has the most obvious problems.

I agree that some hacks are almost imperative, until there is a better 
solution.  I think that a better solution is being able to have a CSS 
selector that chooses a browser brand and version (or better, a range of 
versions), so that conditional CSS can be written without hacks.  As 
browsers fix some of the bugs that allow the hacks to be useful, it 
makes hack creation harder, going forward, and if you can't create a 
hack, and not all browsers properly implement a feature, it basically 
means the feature might as well not exist, because it can't be used, 
with your "fix".


>> , but with the
>> state of the browser art today, and the limitation of being unable to
>> detect a browser in CSS [snip]
>
>
> Lets take Gecko 1.9 for instance. All versions between Firefox 3.0.1 to
> Firefox 3.6.16 has undergone major modification in how it implement the
> specs and the specs that were gradually implemented.


I agree with this statement, but I'm not sure what the point of it is.


>> Your suggested fix works for simple things, but today's web sites want
>> to be complex things, and what can be done with CSS is way easier than
>> coding everything in Javascript (which is often disabled anyway), so the
>> limits of the extant CSS implementations are being pushed... if they
>> weren't, all you fine folks wouldn't be working on newer versions of CSS!
>
>
> CSS2.1 is still being worked on. I didn't suggest any fix. I will
> suggest that seeking these complex things will lead you no where fast if
> you don't understand how CSS works.


See above, where you suggest a fix.  I agree that you were not 
suggesting a change to CSS as part of the fix... that's me doing that.

And I don't claim to be a CSS expert, but I do know how to read English, 
and the spec is written in English.  And I am a programmer, and can 
think logically, etc.  I'm willing to learn how CSS works.  But when it 
works differently in different browsers, it somewhat doesn't matter what 
the spec says, it matters what the implementations implement.  And 
understanding "how CSS works" (I think you mean understanding "what the 
specification prescribes") doesn't help in the understanding of buggy or 
variant implementations.

When you can guarantee that if I find a buggy implementation, I can 
report it, and the vendor will fix it, and update all the existing 
copies of the buggy implementation with the fixed implementaetion before 
the deadline for my site deployment, then I'll agree that that CSS 
doesn't need conditional syntax.  :)  And let's not forget handheld 
devices with the browser code in ROM (OK, most of them are flash these 
days...)


>> Hence, providing a quick and easy method of discriminating between
>> browser brands and versions in CSS would be a real service to web site
>> developers that want to push the state of the art, yet have no control
>> over their users' choices of browser brands and versions.
>
>
> See above concerning Gecko 1.9.


Rereading that sentence about Gecko 1.9 in this context, I still agree 
with it, but I still fail to understand how it is useful as a response 
to this issue, either.


>> For my personal web sites, I've chosen to mostly be bland, but that
>> doesn't appeal to customers. And even with blandness, I've discovered
>> enough differences in browsers, that I finally decided to code for
>> Firefox, use Javascript to detect which browser, and have a few tweaks
>> for (mostly) IE (and not just IE 6... some of the differences I've found
>> are still in IE9), but also Opera and Chrome. So if users of non-Firefox
>> browsers turn off Javascript, certain parts of my sites look terrible.
>> Firefox doesn't need Javascript at all to use my sites, but others do...
>> only so I can detect the browser and use different CSS rules.
>
>
> Do you have test cases? What you describe above does not reflect my
> views and my experience. What may be considered a CSS bug may be a
> browser attempting to follow two or more rules in the specs where part
> of the specs makes other parts of the specs break. Most of this was
> concerning interaction between floats and elements (inline-level and
> block-level) in normal flow.


I'm not a CSS expert on the committee... so I can't pronounce what is a 
bug or not a bug in a browser's implementation of CSS.  Sadly, I haven't 
found a chart listing which bugs are in which browsers either, nor of 
which CSS features to avoid if you want to work on all browsers (there 
are some incomplete lists here are there).  And the CSS tests that I've 
found mostly demonstrate some level of compliance by showing a picture 
that looks good or goofy depending on the correctness of the 
implementation... but reverse engineering the test and determining what 
makes the picture look different in the different browsers is hard work.

What I'm concerned about, as an implementer, is that my web sites look 
the same (or at least reasonably similar, and not stupid looking) in all 
the different browsers.  Sadly, I haven't figured out how to run Linux 
or Mac browsers on my Windows box, so I only test my sites using Windows 
browsers.  When I find something that works different on different 
browsers, I conclude that there is either a bug in one or more of the 
browsers (but which one?) or else there is a grey area in the spec which 
different browser authors have interpreted in different ways.  But I 
have little clue which is right and which is wrong.  So I pick the 
browser that does what I expected, and report bugs to the other browser 
vendors.  That might result in reporting correct behavior as a bug, in 
some cases.

Further, even though I report a problem, it will be 5-10 years before 
the browsers that have the problem will cease being used by various 
users... so I still need to write conditional code to have some sort of 
workaround, or avoid the feature altogether (per your fix :).



>> I'll be very surprised if this issue hasn't come up before within the
>> working group, but after recently discovering the technique I started
>> with thread by referencing, I realized how beneficial such would be (and
>> is, as I've applied it now to several sites), so wanted to be sure to
>> add my support for the concept, or, on the off chance that it hadn't
>> come up before, to bring it up.
>
>
> It has come up plenty of times.


Thanks for confirming that it keeps coming up.  Sometimes the customer 
is right, you know, and maybe the repeated requests indicate that this 
is one of those times.  I agree that if all the implementations 
conformed to the standard, you wouldn't need conditional CSS.  But they 
don't, and I don't expect them to conform in my lifetime.  Hence, a 
better way to detect differences when they are important to the 
functioning of the site, would be useful.


> The last things implementers need is to
> check what bugs happened in what version or ship builds so it can all
> fit nicely to some version bug tracking table.


Such a table sounds useful :)  In fact, I called something very similar 
to that a "chart" a few paragraphs back.

As an implementer, I read the CSS spec, discover how to do what I want, 
and then get disappointed over and over because things don't work the 
same from browser to browser.  So it would be nice to have a "real life" 
CSS table... where you can pick the feature you want, and see quickly 
what level of support it has in the browsers of interest for the client. 
  If there is not adequate support for that feature, you look for 
alternate ways of achieving the goals.

I guess there are various levels of support:
1) Implements CSS spec correctly for this feature.
2) Implements something that is somewhat wrong, but can be hacked to do 
something useful, using some workaround.
3) Unimplemented.

One can avoid using the hacks by treating #2 as unimplemented also, but 
that limits you to using a small subset of CSS, especially as long as 
IE6 is on the requirements list for the site.

Received on Friday, 1 April 2011 09:50:11 UTC