- From: Gérard Talbot <www-style@gtalbot.org>
- Date: Sat, 2 Apr 2011 16:22:33 -0700
- To: "Glenn Linderman" <v+html@g.nevcal.com>
- Cc: "www-style mailing list" <www-style@w3.org>
Le Sam 2 avril 2011 0:44, Glenn Linderman a écrit :
> On 4/1/2011 4:32 PM, "Gérard Talbot" wrote:
>
>
>> 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).
Inconsistence does not necessarly mean browser bug or spec violation.
> I have code that proves
> that, not yet provided here. I haven't yet determined if they all fall
> in the "undefined" areas mentioned.
Add to this, searching for these strings in CSS 2.1 spec:
"free to",
"interpret",
"approximate",
"may apply", "may add", "may have",
"may",
"define",
"user agent-dependent", etc.
> 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
Those variations can be caused by conditional comments (
http://msdn.microsoft.com/en-us/library/ms537512(v=vs.85).aspx ) , or by
javascript forks, or by compatibility list maintained by Microsoft, or by
meta X-UA-Compatible, etc.. We do not know. No clue. No specifics. No
details.
Have you ever read/seen/examine this page:
http://hsivonen.iki.fi/doctype/#ie8modes
or
http://hsivonen.iki.fi/doctype/ie8-mode.png
Before you view a webpage in IE8 or IE9, such page goes through a
labyrinth of possibilities in those browsers.
> 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?
Both.
In many of your posts, you say "IE" but we do not know which version.
There is a huge difference between IE6 and IE8 (and IE9) if/when we're
talking about CSS 2.1 bugs. But your posts do not distinguish any of this.
In many of your posts, you say "bugs" or "CSS bugs" but we see 0 testcase,
0 link, 0 webpage url, 0 explanation, 0 detailed description, 0 bug
report. Sometimes, we can not be sure if you're referring to HTML4 bugs or
CSS 2.1 bugs.
In many of your posts, you say "browsers" or "different browsers" but we
do not know which browsers specifically and which versions.
In many of your posts, you say "CSS" but we do not know which spec and/or
which section or module of which spec you're talking about.
And, at least, the code of your stylesheet suggested that IE6 is a browser
worth supporting.
> 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.
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)
> 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 intentional 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.
This looks like an omission on Korpela's article; you have a good point here.
> My pages
> use the "HTML 4.01 Transitional" DOCTYPE,
Your pages use the "HTML 4.01 Transitional" DOCTYPE without system
identifier, without an url.
http://en.wikipedia.org/wiki/Quirks_mode
http://hsivonen.iki.fi/doctype/
http://www.opera.com/docs/specs/doctype/
http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html
https://developer.mozilla.org/en/docs/Mozilla_Quirks_Mode_Behavior
etc.
Some of these documents are no longer maintained too; so, they are not
100% reliable.
> 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.
> 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.
> 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.
>
>>
>> 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.
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.
>
>
>>
>> 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..
>
>
>> 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
Gérard Talbot
--
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html
Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/
Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Saturday, 2 April 2011 23:23:16 UTC