- From: Glenn Linderman <v+html@g.nevcal.com>
- Date: Sun, 03 Apr 2011 21:14:00 -0700
- To: www-style@gtalbot.org
- CC: www-style mailing list <www-style@w3.org>
On 4/2/2011 4:22 PM, "Gérard Talbot" wrote:
> Have you ever read/seen/examine this page:
>
> http://hsivonen.iki.fi/doctype/#ie8modes
>
> or
>
> http://hsivonen.iki.fi/doctype/ie8-mode.png
I have now, thanks. Things are way more complex than I was aware of,
although I knew they were more complex than back when I wrote my
publicly visible web site that has been commented on, and which I've
done minimal maintenance to for several years.
So what is the best CSS-only way of conditionally displaying a "you
should upgrade your browser" message to visitors to my web site that use
versions of IE < 8, Firefox < 3.6, Opera < 9? And a message to users of
browsers other than IE, Firefox, Opera, and Chrome that I haven't tested
my site with their browsers, but rather only with browsers/versions
blah, blah, blah (whatever I actually test with, over time)?
>> 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?
>
> Both.
OK, so please disprove the ones you dispute. :)
I will admit to not substantiating them, but I think you are
knowledgeable enough about browsers that you should own up to the fact
that there are many non-conformances to the standard known to be in all
of the older browsers, and still variations in conformance to the
standards in current browsers, which is the general statement I've made,
and which is admitted to in the pages you link to above.
I'm not yet sure if the differences in behavior that I've recently
experienced are due to "undefined" parts of the standards, I need to
research that. If I think it is bugs, I'll report them; if I think it
is "undefined", in either case, I'll be convinced that the CSS standard
should include browser discrimination features, so that I can deal with
the discrepancies.
> And, at least, the code of your stylesheet suggested that IE6 is a browser
> worth supporting.
And I've already responded that those comments were likely pasted in
from some place where I found an interesting technique.
> Glenn,
>
> I am telling you that your doctype declaration triggers
> backward-compatible "quirks" rendering mode in *_all of your webpages
> website_* and in all browsers released after 2002.
>
> In Firefox 2+ : Tools/Page Information ... Ctrl+I
> In Opera 9+: View/Panels ... F4/Info
> In other browsers (eg Chrome 10): javascript:document.compatMode in
> address bar or javascript:alert(document.compatMode)
The chart you pointed to seems to confirm your statement. Sad that old
versions of standards are now considered "quirks". But those pages are
very simple, render properly (perhaps only because they are rendered in
"quirks" mode), and are very old. While I will put test cases showing
bugs or discrepancies on that web site, it will be in "hidden" URLs,
findable only if you get them from me or someone that I've told about
them, as they will not be an interesting part of the web site for casual
passersby. As I said below.
>> 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.
>> 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.
>
>
> Well, then, start reading and testing a bit. You have been complaining,
> reporting about *unknown*, *undescribed* browser bugs in *undefined*
> browsers happening in *unspecified* webpages in this mailing list and now,
> you are not sure how exactly backward-compatible "quirks" rendering mode
> is triggered in 2002+ browsers.
>
> I'm telling you again: backward-compatible "quirks" rendering mode is the
> whatever-you-code-is-ok rendering mode; backward-compatible "quirks"
> rendering mode is an IE bugward rendering mode where there is no "law", no
> rules, even for valid CSS code and valid HTML code.
Yep, have been reading and testing. Reading is how I found this list,
testing is how I discovered variations in rendering behavior between
browsers. There's lots to read, I appreciate pointers being given from
folks on this list that are no doubt way more advanced than me. But:
lots of what I read has confirmed my reports about unknown, undescribed
bugs in undefined browsers that I see in my unspecified web pages, and
I'm seriously surprised that you wouldn't be aware that such exist.
>> 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,
>
>
> "
> Unit-less numbers in CSS (e.g. width: 300) are interpreted as pixels in
> Quirks Mode and ignored in Standards Mode.
> "
> http://www.opera.com/docs/specs/doctype/
>
> Unitless values was identified as parsing error in CSS 1 (section 7.1).
>
>
>> 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.
>
>
> The CSS validator is about validating CSS code and will not report such
> kind of issues (applicability of declaration). It will check grammar,
> syntax and doing verifications that can be checked automatically by a
> software. There are parts of checking an HTML document which can not be
> checked by software. Compliance with the spec is ideally what you want to
> do. And realistically speaking, you want to avoid declarations which do
> not apply or which should not apply.
>
> e.g. overflow does not apply to table-row-groups objects. Mozilla may
> support scrollable tbody (with overflow and a set height) but the CSS 2.1
> spec *_does not require_* conforming user agents to do so. So, in such
> precise issue, you can not claim a bug in non-Gecko browsers when the CSS
> 2.1 spec is clear on this:
>
> 'overflow'
> Applies to: non-replaced block-level elements, table cells,
> inline-table, and inline-block elements
> http://www.w3.org/TR/CSS21/visufx.html#overflow
>
> There are lots of examples of this sort on the web. With more time, I
> could find more (issues, problems) in your stylesheet.
Indeed, scrollable tbody is a great feature in Gecko. It is an example
of something that can be leveraged usefully in a web site when Gecko of
appropriate versions can be detected. Yet the other browsers can have a
fallback that works adequately, but not as nice as scrollable tbody.
This is yet another reason why it would be nice to have browser
discrimination available via CSS. Right now I do that detection on the
server side, and generate different HTML. I'd much rather do it in CSS.
>> 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?
>
>
> Unitless non-zero values *_may be_* rendered differently in
> backward-compatible "quirks" rendering mode in different browsers. Not in
> web standards compliant rendering mode in browsers released after 2002.
>
>
>> And why does the
>> validator not report it?
>
>
> The HTML validator will report validation markup errors, not CSS code
> (syntax, grammar, lexical, etc) errors.
I was talking about the CSS validator here.
And unitless values were defined in old, pre-CSS HTML tag attributes to
be pixels, right there in the HTML 4.01 standard. So I'd be a bit
surprised to find a browser that interprets unitless dimensions as
anything else, and haven't yet, but will nonetheless be more careful to
1) specify units in the future (I usually have anyway)
2) run the CSS validator more often
>>> 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.
>
>
> I still am convinced your stylesheet does not use/does not rely on
> inheritance, does not use default values (in fact, it often resets them
> unneedlessly), over-qualify, over-declares, over-defines, redefines,
> over-codes unneedlessly, could be optimized.
It may. Such issues shouldn't prevent a conformant browser from
rendering properly.
>>> 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.
>
>
> We do not know for sure about this. Fractional values are not rounded up
> the same in browsers; rounding issues affect browsers differently,
> depending on browser versions, bug fixes, property involved. E.g.
>
> http://www.w3.org/Style/CSS/Test/CSS2.1/20100127/html4/margin-006.htm
>
> was originally (january 2010) rendered in 3 different ways by 6 browsers
> and is a good example of fractional values and rounding issues: view that
> test in Firefox 3.6.16, IE8, Opera 11.01, Chrome 10.0.648.204, Konqueror
> 4.6.1, Safari 5.0.4 and you will get 3 different renderings. The bottom
> line is rounding of fractional pixels is not covered by CSS 2.1 spec: so,
> all 3 renderings are okay and the test had to be reworked.
>
> If you take into consideration the gap at the bottom of the testpage, then
> this makes 5 different renderings and they are all okay according to spec.
>
>
> All this to say that I know that your stylesheet has over 25 length values
> that have fractional values or can lead to fractional used values; add to
> this a constrained page layout, quirks mode, etc..
Well, I told you it hasn't been a problem so far. So while it is nice
to be reminded that fractional values are not rounded the same in every
browser, and that CSS permits that, none of the issues I'm dealing with
have been tracked back to floating point rounding errors.
>>> 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.
>
> Method support detection; object feature detection.
> http://www.jibbering.com/faq/#detectBrowser
That's not a better technique. That's an opinion statement that happens
to agree with yours.
Further, it is not a CSS technique. To me, using Javascript to detect
browsers or methods or objects or properties to be able to adjust CSS is
inappropriate. Would be much better have a CSS technique to adjust CSS
per browser. I use Javascript to detect browsers, because there seems
to be nothing better, the CSS hacks are limited in their detection
abilities, but when Javascript is turned off, it doesn't help.
> Gérard Talbot
Received on Monday, 4 April 2011 04:14:31 UTC