Re: [css3] [css21] browser specific CSS

On 4/1/2011 6:24 PM, "Gérard Talbot" wrote:
>
> Le Ven 1 avril 2011 10:51, Glenn Linderman a écrit :
>> On 4/1/2011 9:43 AM, Tab Atkins Jr. wrote:
>>> On Thu, Mar 31, 2011 at 8:20 PM, Glenn Linderman<v+html@g.nevcal.com>
>>> wrote:
>
>>
>> Sorry, you didn't explain it, and Boris didn't explain... you only
>> stated that there were such reasons.
>>
>> If browser sniffing and resultant workarounds are implemented poorly,
>> that either means that
>>
>> 1) it is hard to implement them well, given the available facilities for
>> doing sniffing... this could certainly be improved, with boilerplate
>> Javascript or CSS features to assist.
>>
>> 2) some web site authors are bad coders.  This is certainly true...
>> there are many web sites that suffer from bad coder syndrome.  Lots of
>> sites are authored by people by just whacking at the HTML until it works
>> for them in one browser, one screen size, and then they claim it is
>> done.  Others may do bad browser detection, and support two browsers,
>> and make things worse for the third, and not care.
>>
>> 3) If a single browser is used for web site development, and it has
>> bugs, the site may depend on those bugs, and no other browser may even
>> want to display that site properly, because to do so would require
>> implementing bugs instead of standards.
>>
>> Problem 1 could be cured, eventually, with appropriate features in the
>> specifications.  Problems 2 and 3 will never go away, but if browser
>> detection were easier/standardized, and available in CSS without
>> resorting to Javascript (and in Javascript in an easier manner, and to
>> CGI scripts in an easier manner), then it would be lots easier to test
>> with multiple browsers, and good web site coders could benefit.
>>
>> Don't cater to the bad coders, but rather make it easy for good coders
>> to do useful things in easy and effective ways, and provide
>> documentation for doing it right.  If it is easy enough, even the bad
>> coders might learn how.  But right now there is a huge barrier to using
>> CSS: it doesn't work cross-browser, without heavy investment in learning
>> arcane browser hacks.
>
> Glenn,
>
> Your last sentence is stunning. First and again, you do not specify what
> you mean with "CSS". Is it CSS 2.1? Is it CSS 3 modules and, if so, which
> modules? There are some CSS 3 modules which are Candidate Recommendation
> but there are others which are not remotedly close to CR status.


The web is full of this.  Search for "CSS hacks"... 217,000 hits.  The 
first page from google is all on topic, I didn't examine all 217,000 
hits for relevance.  The relevant version of CSS is the one claimed to 
be implemented by each of the currently used browsers seen on the web... 
from no support at all, to at least CSS2.  I don't think CSS has reached 
standardization past CSS2.  Isn't CSS2.1 still being discussed here as a 
working document, not a published spec?

Search for "ie6 css bugs" - 42,400 hits.
Search for "ie7 css bugs" - 20,000 hits.
Search for "ie8 css bugs" - 12,400 hits.
Search for "ie9 css bugs" - 114 hits.  I don't see any on the first page 
that look like actual bugs, though, mostly trolls.  I'm not trying to 
claim that there are this many bugs, but just that there are bugs.

Search for  Firefox "css bugs" - 57,400 hits.
Search for  Opera "css bugs" - 30,900 hits.
Search for  Chrome "css bugs" - 25,200 hits.

I already stated that I need to analyze some of the discrepancies I've 
found in the new set of browsers, and see if I can figure out if any of 
the discrepancies are bugs, and if so, in which browsers.  But that 
doesn't mean there aren't CSS bugs in older browsers that visit my sites.

I don't expect the CSS committee to help me debug my websites, or to 
help me properly implement them, so it is not clear that the specific 
bugs should be reported here; it seems that this is the wrong forum for 
browser implementation bugs, and the right forum for issues with the 
standards under development.

My issue with the standards under development is that because of the 
past bugs, and because of the potential for future bugs, I believe, even 
still after the current discussions I've read in these responses to my 
postings, that CSS would be a better standard if it provided an easy way 
to sniff browser brands and versions. Tighter definitions in the 
standards, and more interest in conforming to standards on the part of 
browser vendors, both of which seem to be in the pipeline, will help, 
but I doubt it will eliminate the problems of browser differences, 
either due to undefined aspects of the standard as Anton and you have 
pointed out, or to bugs.


> You do not provide a single example of what you call a "browser bug". No
> testcase. No example. No demonstration. No url. Nothing concrete. Just a
> sweeping statement on browsers (no version specified) regarding
> unspecified chunks of an unidentified CSS level. We have no idea, no clue.


You have no clue, and how long have you been using CSS?  That's a pretty 
stunning statement too.  I'd think you folks on the CSS committee would 
be well aware of the variations and/or deficiencies in the various 
browsers with respect to CSS.  The number of bugs in various CSS 
implementations that are leveraged as CSS browser detection hacks alone 
is significant.  Yes, many of the bugs are in older browers, but they 
are browsers that are still being used.

You made the statement "as if browsers are not improved" and talked 
about new versions being released, etc.  All this adds variation, and 
browser sniffing is the only solution I've seen discussed to handle the 
variation.  Bugs are another reason to do sniffing.


>> Until you show me the mile high picture, what I'm hearing is that in the
>> future, it will be more difficult to do browser detection, and therefore
>> the barrier to using advanced CSS will be even higher.  The perception
>> will be that the spec has lots of nice features, but because there is no
>> way to work around browser bugs (which will exist), the payback for
>> learning a new feature will be to rip out uses of it, if not all
>> browsers support it correctly.
>
> Not once, so far, have I read you say that people can and should report
> bugs to browser manufacturers when they believe they see one. Isn't that
> what should be happening in the first place when people think/believe they
> see a bug?


Why should I say that?  I totally agree with your statement "... people 
can and should report bugs to browser manufacturers when they believe 
they see one. Isn't that what should be happening in the first place 
when people think/believe they see a bug?".  I have reported bugs to 
Mozilla.org, Google, and Opera regarding some of the bugs I have found, 
not all are CSS bugs.  Yes, it is a given that they should be reported. 
  But sadly, reporting the bug, and even having the bug be fixed in a 
newer version, doesn't remove the buggy version from the WWW... so it 
must still be detected and dealt with in some manner.


> In your initial post, you wrote "But just as Microsoft is attempting to
> make IE6 die" . Even such claim is questionable. I would say that
> Microsoft has done very little to make IE6 die.


Every claim is questionable, Gérard. All of mine, and all of yours.

I would agree with you, though, that until recently, Microsoft has done 
very little to make IE6 die.  http://www.ie6countdown.com/ certainly 
makes it seem to me like they are now trying to make ie6 die.  Is it 
convincing to you?

Received on Saturday, 2 April 2011 10:03:06 UTC