W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [css3] [css21] browser specific CSS

From: Glenn Linderman <v+html@g.nevcal.com>
Date: Sat, 02 Apr 2011 14:10:47 -0700
Message-ID: <4D9790D7.3030603@g.nevcal.com>
To: Alan Gresley <alan@css-class.com>
CC: www-style@gtalbot.org, Brian Manthos <brianman@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org" <www-style@w3.org>
On 4/2/2011 11:24 AM, Alan Gresley wrote:
> Snipped a fare bit.

Thanks for your response, Alan, you snipped a fair bit, for sure, making 
it hard to tell who and what you are responding to.  You seem to be 
responding not only to my comments but also to others, and that is fine, 
but seems a bit confused below.

> On 2/04/2011 6:44 PM, Glenn Linderman wrote:
>> On 4/1/2011 4:32 PM, "Gérard Talbot" wrote:
>>>> If one or more browsers appear to be wrong, make a test case that
>>>> captures
>>>> the specific issue succinctly and submit it for consideration to the
>>>> test
>>>> suite.
>>> Web authors' contributions to the CSS 2.1 test suite
>>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
>>> Contributions to the CSS 2.1 test suite
>>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/
>> Thanks for those links. I'll try to find time to figure out what I have
>> to do to produce a test case.
> I was the one that mention a test case. I didn't say to produce test
> cases for the testsuite. Somehow that was inferred indirectly in Brian's
> reply to me. This is what you wrote.
>>> 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.
> This was my reply.
>> 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.
> Do you understand what I write above?

I believe I have an understanding of your statement, but I've been too 
busy writing emails in this thread to do the analysis of the variations 
I've recently found, and isolate the test cases.

However, if a specification provides freedom for implementations to "do 
their own thing", it is very reasonable for the specification to also 
provide a way to determine which implementation is in use, so that 
"their own thing" can be leveraged or avoided, depending on the goals of 
the site.  Otherwise, the only way to have a consistent site is to avoid 
all the behaviors for which such freedom is given.  If the behaviors are 
all avoided, then the freedom given to the implementations is useless.

> Currently there are implementations that do not follow the CSS specs
> correctly or the spec fails to expressed the desired behavior (some
> behavior is not defined). This is not the fault of the implementers or
> the specs writers but the nature of developing CSS which is only a
> decade old.

Absolutely.  Implementations vary.  Bugs exist.  Not all the bugs are 
because of intentional violations of the spec (probably some are, 
though), but some are historical in nature, and some due to 
misinterpretations of the spec, and probably some that are due to 
ambiguities in the spec.  All these are, nonetheless, either bugs, or 
areas where there is freedom of implementation choice.  But these are 
all reasons it would be helpful to have a reasonable way to determine 
which implementation is in use.

> By not doing proper testing and being able to isolate a problematic part
> in a test case, many authors have hacked browsers into submission
> (mainly due to ignorance) and this has resulted in what I think Tab
> means as anti-patterns. Please read this.
> <http://dbaron.org/log/2005-12#e20051228a>

I will do this.  Looks interesting.

>> It is true that not all _current_ browsers render all HTML/CSS
>> consistently, and it is well known that the old ones don't (I wish I
>> could say didn't, but they are still in use). I have code that proves
>> that, not yet provided here. I haven't yet determined if they all fall
>> in the "undefined" areas mentioned. I've recently updated to the latest
>> browser releases (I stated that as the first sentence in the thread, if
>> you look back) so clearly I understand that browsers do change. And, the
>> variations I encounter and am abstractly discussing are regarding these
>> latest releases, although I have experience previous releases also, and
>> variations there.
> See below.
>> No one has yet disputed any of my unsubstantiated claims, and the
>> internet is full of similar claims, many of which are substantiated with
>> code samples; it didn't seem necessary to substantiate things which seem
>> to be common knowledge.
> What claims are made on the internet is a lot of misinformation.

Surely there is a lot of misinformation on the internet.  But amidst all 
the smoke, there are clearly many demonstrated variations in 
functionality of browsers with respect to CSS.  I haven't analyzed all 
the cases to determine if they fall into the category of bugs or freedom 
of implementation choice... I haven't even had time yet to analyze the 
cases I've specifically encountered to make that determination.

But it is very clear to me from the research that I have done, that when 
implementations vary, it is important to be able to discriminate among 
the implementations.  Because that is presently hard, it is not done 
well, and causes problems for users, site authors, and vendors alike. 
Because I don't believe that there will ever be a time reached when all 
in-use implementations do not vary, I do believe that it is important to 
have an easy method to discriminate among implementations, and 
guidelines for the benefits and pitfalls of doing so.

The statement has been made here, and attempts have been made to justify 
it, that such a method will make the problems worse, but no compelling 
proof of that has been offered... it seems to be based on opinion and 
speculation, derived from particular experiences of members of the 
group.  While I cannot dispute the experiences, I can point out that 
since a simple, standard method of browser discrimination has not been 
available, the actuality of what would have happened had it been 
available, or the actuality of what would happen should it become 
available, has not and cannot be determined... and so statements about 
"it would be worse" or "it would be better" are truly just speculative 
predictions based on opinions.

It seems that people that have responded here are in the "it would be 
worse" camp, no doubt triggered by my "it would be better" claim, and 
associated request for a feature to do easy browser discrimination.  I 
have no idea (but see my quote from Microsoft's web site below) if that 
is either a majority or universal opinion among the voting members of 
the committee, but I'll guess it is at least a majority since it has 
been stated that the issue has come up before, but that the draft 
documents do not include such discrimination capabilities.

>> Are you disputing any of my claims, or just
>> pointing out that I haven't substantiated them? If the former, which
>> unsubstantiated item(s) that I have stated do you dispute, so that I can
>> substantiate them?
> I have substantiated my claims. On a previous message you have this.

You have stated that implementations vary.  You have stated that the 
Gecko implementation has been much improved in various versions 
associated with various versions of Firefox.  I don't see where you 
substatiated these claims, but I do believe them.

The point where you and I seem to disagree, is that you have stated that:

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

That is an unsubstantiated opinion, based on your experience.  While I 
agree that bugs cannot be fixed with hacks, I claim that bugs (or other 
variations between implementations) can be avoided if the implementation 
can be determined: right now, the only way to somewhat determine the 
implementation is with hacks, and I think that is a sad state of 
affairs, and leads to poorly coded hacks and poorly coded web sites as a 
result.  That's my unsubstatiated opinion, based on my experience.

So I'm requesting a simple, standard way to discriminate among the 
browser implementations of the future, like the C language (and many 
other) implementations have a simple (not sure it is standard, though) 
way to discriminate among implementations.

[moved this from below]
 > Anyway, why do you think this is the appropriate list to discuss all
 > this? This one may help you more.

I think this is the appropriate forum to request that CSS add a feature 
to do browser sniffing easily.  That's the reason I joined the forum, to 
make the request.

Microsoft has implemented conditional comments and suggests using 
independent CSS files for each version of IE.  While I understand that 
Microsoft doesn't speak for the while industry, it is pretty clear they 
understand that their variant implementations are better dealt with by 
being able to discriminate among versions.

 From their site I quote:
> One of the most common operations performed in a Web page is to
> detect the browser type and version. Browser detection is performed to ensure
 > that the content presented to the browser is compatible and renders 
> The browser type can be detected using many different
> techniques. Most methods of browser detection make use of script on the
> server or client.
 From <http://msdn.microsoft.com/en-us/librar/ms537512%28v=vs.85%29.aspx>

>>> If one or more browsers appear to be wrong, make a test case that
>>> captures the specific issue succinctly and submit it for consideration
>>> to the test suite.
>> How? Where?
>> In general, I can only tell that the browsers differ in their behavior,
>> not which one is wrong. But still, that makes it appropriate for a test
>> case, and the CSS enforcement police can decide which browsers are
>> guilty, and of what.
> Police.... where?

Just slang terminology, Alan, sorry to confuse you with it.  I assumed 
that since you were participating in a standards group you would have 
heard such terminology in the past.  I'll reword:

In general, I can only tell that the browsers differ in their behavior,
not which one is wrong. But still, that makes it appropriate for a test
case.  I may have my own opinion about which browser most closely 
following my understanding of the CSS specification, but the most 
enlightened determination of conformance can probably be done by the 
various members of the CSS standards committee.

> Please view this page (also take a look around).
> <http://css-class.com/test/>
> The page layout of this page has appeared identical in every browser
> that I can possibly test since April 2008. The only difference is the
> CSS3 enchantments. Only IE6- has the wobbles.

No doubt I can learn some things there, Alan, thanks.  Whether you have 
examples of each kind of functionality I wish to achieve in my own 
cross-platform web sites remains to be determined.

> <http://www.css-discuss.org/>
> You will get plenty of help there. You may even see me there. Can you
> please begin a 'browser specific CSS' discussion there since you are
> taking much time away from people here who could be doing other things
> like perhaps fixing buggy browsers (as you so claim).

This looks like it could be another useful resource.  I do appreciate 
these references to resources that you can recommend, as it is hard 
evaluate the quality of the many sites found by random searching.

I must point out, though, that it wasn't my goal to spend man-days of my 
time or other people's time on this discussion.  It seemed like an 
obvious thing to request: implementations of the most portable 
programming language in the world have ways to do easy discrimination of 
implementations and versions, and the present experience with CSS is 
full of these hacks to do such discrimination, and a major browser 
vendor has a documented way of discrimination among versions of their 

The fact that I have gotten (after some days) such voluminous and 
vehement response implies to me that this is a subject that has, indeed, 
been hashed over a number of times, and that there is only an uneasy 
truce at the experiment of making it harder, rather than easier, to do 
browser discrimination, with strong opinions at both ends of the 
spectrum, but a majority holding sway with the "no sniffing" opinion. 
Yes, this is speculation on my part.

Code in that most portable of programming languages does not generally 
have #if scattered all over it, to make platform selection abstractions, 
but instead is limited to a few places where types are defined, and a 
few places where implementation bugs are worked around.  It hasn't 
proven to be a problem, in general.

If the emperor had clothes, the committee would quickly and gladly 
implement a version discrimination feature, and if the opinions stated 
in response to my request turn out to be factual, then the 
discrimination feature would not be much used, nor much misused, because 
the specification and implementations would be so adequate that people 
would not need to resort to browser sniffing, other than perhaps for 
decorative purposes, or to workaround the occasional bug in a particular 
version, as is done in C code.

There are other response pending, but I'm going to have to slow down the 
rate of my responses to get other things done, and to be able to read 
some on the sites that you have linked me to.  Thanks.
Received on Saturday, 2 April 2011 21:11:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:58 UTC