Re: [css3] [css21] browser specific CSS

On 4/1/2011 4:32 PM, "Gérard Talbot" wrote:


Thanks for your response, Gérard.


> Le Ven 1 avril 2011 2:04, Brian Manthos a écrit :
>> Alan hits on a good point here.  IMO, one of the weakest points in the
>> interoperability story right now is the lack of tests.
>
> Hello all,
>
> There is right now 9418 testcases in the latest version of CSS 2.1 test
> suite [RC6]. I would not say that the weakest point of CSS 2.1 test suite
> is the lack of tests.


That seems like a large number of tests, but CSS has a large number of 
features, so it is hard to know how complete the coverage is, just from 
the number.  Do you have statistics about feature coverage, percentage-wise?


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


>> If it gets accepted, that re-enforces the case as a correct interpretation
>> of the specification and puts pressure on vendors aiming for compliance to
>> fix the issue.
>
> This simple thing is not mentioned anywhere in Glenn Linderman's initial
> post. Glenn states things about browsers - without substantiating them,
> nothing solid, concrete whatsoever - as if browsers are not improved, as
> if new versions are not released and as if people do not upgrade. It just
> is not so. Microsoft has been now for the past 4 years focusing on spec
> conformance (eg CSS 2.1) like never before; Mozilla, Opera, Apple (since
> Safari), Google and KDE have always been focusing on spec conformance.
> And today there are clearly and undisputably more people using IE8+ than
> people using IE6 and IE7 combined.


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.

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

The internet isn't full (yet) of discussion about all the variations in 
the current crop of browsers, which may be fewer than prior browser 
versions... but the prior browser versions haven't gone away yet, 
either, and given time and testing, some discussion will no doubt 
appear, unless the browsers are all bug-free and fully conformant.


>> If it gets rejected, you'll learn something in the "why".
>>
>> -Brian
>
>
> To Glenn,
>
> 1-
> Each and all of your webpages from your website
> http://nevcal.com/nevcal/index.html
> uses a doctype declaration which triggers backward-compatible "quirks"
> rendering mode. All of them.


Clever of you to look there.  Just as the cobbler's children wear no 
shoes, my personal web site was created some years ago, and hasn't 
gotten much of a facelift in recent years, too busy with other things, 
and it is a very simple design, and seems to render pretty well in all 
the browsers, old and new, except the browser sniffer hasn't been 
updated for IE9 (but it realizes it doesn't understand it, and produces 
a warning).  So why update the framework (other than to support IE9)? 
Particular page content has been updated from time to time, although 
some of that is also quite outdated, and should be removed.

I'll beg to differ regarding all of them being in "quirks" mode... but 
most, and perhaps all, the public ones that you can see are in "HTML 
4.01 Transitional" mode, and at least many of them at least used to 
validate.

Most of my work is done behind firewalls and/or with login security, so 
I will have to make and expose specific cases for concrete discussions 
and submissions.


> backward-compatible "quirks" rendering mode is by definition a bugward
> mode of IE5 rendering engine. backward-compatible "quirks" rendering mode
> has nothing *_ absolutely nothing_* to do with complying with CSS
> conformance rules.
>
> "
> There is no authoritative specification of what happens in Quirks Mode.
> After all, the mode is, by essence, an inten­tional violation of CSS and
> HTML specifications.
> "
> What happens in Quirks Mode?
> http://www.cs.tut.fi/~jkorpela/quirks-mode.html


That page refers to quirks mode as pages without a DOCTYPE.  My pages 
use the "HTML 4.01 Transitional" DOCTYPE, which is actually defined in 
W3 standards documents.  I even validated quite a number of them as 4.01 
Transitional.  There may be no difference between IE Quirks mode (no 
DOCTYPE) and IE's treatment of 4.01 Transitional DOCTYPE, I couldn't say 
for sure.

Except for an irrelevant character encoding mismatch, the HTML at 
http://nevcal.com/glenn/ still validates with that DOCTYPE.  The 
mismatch is irrelevant, because the page is fully ASCII... I've been 
gradually transitioning from ISO-8859-1 to UTF-8 for all my pages. 
Likely the others mostly do also.


> 2-
> Your website stylesheet uses unitless values for its CSS rules: that
> includes width and height:
> http://nevcal.com/style.css
>
> http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fnevcal.com%2Fstyle.css&profile=css21&usermedium=all&warning=2&lang=en
>
> And, here, I'm not even referring to other blatant problems with your
> stylesheet: over-declaring CSS declarations, over-defining, redefining CSS
> declarations, over-constraining CSS declarations. There is such a thing as
> over-CSS-coding, bloated CSS code and over-constraining CSS code (width:
> 100%;).
>
> Even use of<font>, undisputable misuse and overuse of<br>, etc.. can be
> found on your site.


Heh heh... no doubt I'm an ignorant coder.  While I ran the HTML through 
a conformance checker, I don't recall ever running the CSS through a 
conformance checker.  I found about 12 unitless non-zero values, out of 
130, not sure which ones I copied from other people's code, but I'll 
admit to adding at least a few of those by myself.  Will update in due 
time, now that I'm aware of the omission.


> 3-
> Your initial post had http://nevcal.com/cssrequest.js but it was 404 not
> found back then and still today.


Oops.  My apologies, and thanks for pointing it out. That should have 
been http://nevcal.com/cssbrowser.js  Happily my link to Rafael's code 
from which I started was correct, so the idea was there.  I just tweaked 
his code to add a few things.


> 4-
> According to your stylesheet
> http://nevcal.com/style.css (see lines 80 and 375), IE6 is a browser worth
> supporting.
>
> Right now, according to Microsoft
> http://ie6countdown.com/
> , about 3% of web browser users in North America are still using IE6...


Nope, I barely thought IE6 was worth supporting in those days: I 
produced messages (still visible at http://nevcal.com/glenn/ when viewed 
with IE6, IE7 or IE8, and certainly it is hardly worth supporting now. 
Those comments came along for the ride, when I borrowed that CSS from 
some example somewhere.

Sadly, a fair number of business users are still using Windows 2000, 
which cannot be upgraded to IE > 6.  Happily, most of them can use 
alternate browsers successfully, and need not resort to IE6.


> 5-
> Some declarations in your stylesheet are not supposed to apply to begin
> with. That's given by the spec.


This is vague.  I guess I should run a validator.  OK, the validator 
only reported on the unitless numbers, it found 15 of them, I must have 
miscounted.  No other errors were reported.  So what are you talking 
about here, that some are not supposed to apply?  And why does the 
validator not report it?


>
> 6-
>> While I would be delighted if all browsers actually did implement all
> CSS>  in the same standard-conforming way, omissions, bugs, and
> extensions all
>> exist, and have
>> for many years now, and likely will continue to exist.
>
> We don't know what "all CSS" means actually in your writing. Is it CSS 3
> modules still in working draft? Is it CSS 2.1? Does it include CSS 4
> selectors too?


I'm mostly talking about the current CSS 2 here.  I look forward to some 
of the new HTML 5 features and CSS 2.1 and CSS 3 features, but so far 
I've been sticking to HTML 4 and CSS 2 for real web sites, with an 
occasional chance to experiment.  <IFRAME SANDBOX> is one HTML 5 feature 
that sounds interesting, but the experiments indicate that its effect in 
current browsers is quite variant, but that is HTML not CSS, so I won't 
go further on this list.


> A wide majority (over 80%) of all browsers in use today on the web pass
> the acid2 test.
> All of tested graphical browsers on the CSS 2.1 test suite achieved a
> score of over 85% in october 2010. Today, their score is undisputably
> higher than 6 months ago.


Glad to hear it.  While I'm aware of the acid and acid2 tests, I'm 
unaware of exactly what % feature coverage they provide.  I have heard 
that many browsers struggled to pass them, in their early days.


> 7-
> Your stylesheet has more lines of code (398 lines) than the HTML documents
> that are supposed to be styled by it. Out of this, well over 150 class
> declarations! Some people refer this as classitis.


That style sheet is used for a lot of pages you can't see, as well as 
the ones you have looked at.  My understanding is that it is better to 
have one stylesheet that can be cached than attempt to have bunches of 
little stylesheets with repeated subsets scattered all over.  And some 
of the pages on my site are quite small, so of course the style sheet is 
bigger than them.


>
> 8-
> Many (well over 25) length values in your stylesheet have fractional
> values or can lead to fractional used values:
> e.g. width: 10%;, margin-left: .1em;
> and there will be rounding issues affecting browsers differently because
> of this.


Hasn't been a problem so far.


> 9-
> A lot of what you do in your nav.js is also debattable. E.g.
>
>        objHTML = document.createElement('p');
>        objHTML.setAttribute('name', 'mylogdata');
>        objHTML.setAttribute('id', 'mylogdata');
>
> These 3 lines above are questionable.


Oh, my ancient nav.js.  Well, what is questionable about those lines? 
That function is just a debugging hack that isn't even referenced 
anymore.  Looks like it was intended to append data to a document to 
help debug javascript back before there was a decent javascript debugger...

That nav.js also contains an older browser sniffer that my new one you 
couldn't see will replace.  It is much less functional the new one.

I see it doesn't detect IE9 very well :) But it does detect it as IE, of 
an unknown version, to remind me to add a detection check for IE9.

Maybe the new crop of browsers will handle my iframe navigation bar 
better... the only reason I wrote nav.js and that older browser sniffer 
was because links in iframes didn't work the same in all browsers. 
Seems to me like a basic repetitive navigation bar (as opposed to a more 
sophisticated highlighted menu system) should be in a separate document 
to avoid duplication... so that's why it is in an iframe.  But the links 
inside the iframe escaped the iframe on some browsers but not others. 
Not sure what the current behaviour will be.  If you do look at 
http://nevcal.com/glenn with IE9, the content explains the era in which 
this stuff was originally coded.  And as long as it works, it doesn't 
get much attention.  Will have to update a few things there.


>
> 10-
> You seem to assume that
> this.agent=navigator.userAgent;
> is a trustworthy piece of info on which your function lib_bwcheck() can
> rely on, if javascript support is enabled.


Please point me at a better technique for browser detection.  I'll swap 
in my new one from the link above if you don't have a better one.  I'll 
have to test to see if IE9 works without the Javascript.  Surely it 
should by now.

Please implement a better technique for browser detection in CSS 2.1 and 
CSS 3, so I don't even need the Javascript.

Not sure why IE9 gives such a narrow navigation bar... Opera, Firefox, 
and Chrome all work fine.  Note that Chrome didn't even exist when I 
wrote the code, but I did write it to detect and fix known problems with 
particular browsers, as Tab or was it Boris, has been recommending, and 
assume that unknown browsers work until bugs are found.  And such 
happened.  Happily, Chrome works fine with the site, although the site 
long predates Chrome.  I've just tested IE9 in a local copy of my site, 
and it is functional without the weird "deframe()" hack which I will be 
glad to get rid of when earlier versions of IE go away.

>
> Gérard Talbot

Received on Saturday, 2 April 2011 07:44:59 UTC