Re: active link in IE 6 and Opera 7

Alan J. Flavell wrote:
[snip]

So we have a shipwrecked 2.0, and a non-yet-finalised 2.1, and nothing
we can rely on, beyond studying what the developers of WWW-compatible
browsers have actually implemented. If the behaviours of (say)
Mozilla and Opera differ, then maybe one is right and one is wrong; or
maybe both are within the scope of the recommendations; or maybe
neither of them is right: but without a clear specification, it's
impossible to decide. Add to that the pressure on minority vendors to
emulate the behaviour of the Big One even when it's wrong, and the
mess is complete.

It is even worse than whether Mozilla & Opera differ, isn't it? What if Opera
7.7 differs from Opera 7.23, and Firefox 0.9 differs from Firefox 0.8? Won't
they all be out in the field?

I've stopped updating my testing browsers just because they are supposed to be
"better" in some way, eg. more compliant. I've realised that perhaps I need to
test in a range of the least compliant, not most compliant, browsers. (So IE 5
& IE 6 are both there, of course).

But, this thread has made me realise that I don't even know what "least
compliant" & "most compliant" actually mean. I have an O'Reilly CSS Reference
always available, (in a Dreamweaver panel), and keep checking it. Can I trust
it? Perhaps not.

Authors may say they want browsers to become more & more compliant. But it
that *really* what is best for authors? Doesn't it just generate more variety
to cater for? Wouldn't we actually be better off if browsers froze their
compliance at their current levels? (At least until Longhorn appears).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Rijk van Geijtenbeek / 2004-05-21 17:56:

On Thu, 20 May 2004 23:21:08 +0000 (UTC), Jukka K. Korpela
jkorpela (AT) cs (DOT) tut.fi> wrote:

"Rijk van Geijtenbeek" <rijk (AT) opera (DOT) com> wrote:
Browsers should (and do) indicate which standards they support,

They cannot, unless there are standards. You cannot claim support to a
moving target. If a "specification" requires A today and B tomorrow and A
and B are two different renderings of the same construct, you can't make
a browser conform.

What should the WG do? Make dozens of CSS 2.x subreleases, one for each
time something comes up that needs clarification or appears to be designed
badly?

Definately. If you publish some software and you find out that there
was some serious bugs in your release, you'll release a new version.
Not something that has the same version number [1]. Why should
specifications work differently? If it isn't "2.0", then don't call
it "2.0" but "2.1" if it's the first revision after the original "2.0".

What's the point of calling something 2.0 when it really is 2.0 plus
a thousand of small or not so small changes? If you end up calling
it 2.152, perhaps it just tells that the specification was released
as final way too early. However, a browser manufacturer can claim to
support CSS 2.132 and that claim doesn't become invalid when the
"2.0" specification yet again changes via "errata".


[1] Some software has been released with the same version number
after changes and no good has ever arised from that. A well known
example is the MFC "4.2" library, which is stored in a file called
"mfc42.dll". There exists at least three different versions of this
file and all of those are incompatible between each another and
pretty much every piece of software that needs that library wants
different version of it. ...or so I've heard.

--
Mikko

On Fri, 21 May 2004, Jim Ley wrote:

On Fri, 21 May 2004 16:27:41 +0100, "Alan J. Flavell"
flavell (AT) ph (DOT) gla.ac.uk> wrote:

On Fri, 21 May 2004, Jim Ley wrote:

Try to create the perfect spec before setting it free? CSS 2.0 was
too ambitious, but at the time it came out the WG was not receiving much
feedback on the www-style mailinglist.

Did it have 1 implementation of every feature?

Were they needed?

W3 Process....

But surely it isn't the policy of the W3C to sit on their hands until
some vendor pops up to say they designed something, and then to set
out and write a specification of what the vendor has built? That way
- remember HTML/3.2(spit)? - lies madness.

[ Don't forget that contemporary with the big two fighting it out over
feechers for HTML/3.2, others with more forward perspective were
calmly working on the i18n draft, which became RFC2070 and became the
basis for the HTML internationalisation which we now have. And a
proof-of-concept browser (Alis Tango) which I remember running under
Windows/3.1 and which amply demonstrated the power of their concept.
And of course there was the Cougar draft, which eventually became
HTML4. And of course CSS, which just about brings us back on-topic.]

maybe both are within the scope of the recommendations; or maybe
neither of them is right: but without a clear specification, it's
impossible to decide.

But if it's optional presentation, what does it matter

It certainly *matters* if the result is unusable. For example IE3.*
taking em units (which it didn't understand) and guessing that they
meant px units (which it did). Or an earlier Netscape version taking
the colour "transparent" (which it didn't understand) and assuming
that it meant some particular colour. Both of which made a number of
pages unreadable, except for those who knew how to override these
blunders.

CSS's "optional presentation" means doing the styling *either* per
specification, *or* not at all. It doesn't mean doing it just any
which way the implementer feels like on the day! Well, it shouldn't,
even if some browser/versions give the impression that it did :-{

if it's implemeted differently- it cannot change the semantics,
that's the whole (utterly erroneous) claim of CSS.

I think you're conflating too many different issues - and thus
reaching a position which, while it would be true in the extreme,
would not be even approached if the participants were playing their
proper part in the compact on which the idea of the WWW was based.
Nor even if *most* of them were - which is sort-of the way things are,
even if they could doubtless be better.

On Sat, 22 May 2004 15:14:45 +0100, "Alan J. Flavell"
<flavell (AT) ph (DOT) gla.ac.uk> wrote:

On Fri, 21 May 2004, Jim Ley wrote:
W3 Process....

But surely it isn't the policy of the W3C to sit on their hands until
some vendor pops up to say they designed something, and then to set
out and write a specification of what the vendor has built?

No, but they do require that before a spec can go to Rec, every part
has at least 1 implementation, preferably 2.

CSS's "optional presentation" means doing the styling *either* per
specification, *or* not at all.

but the optional presentation thing is pretty much a myth (for example
if you support color but not background-color, you're stuffed no
matter how conformant your color support is) CSS needs profiles which
says you implement all these bits exactly conformantly or not at all.
Until we have that, I'm not sure minor spec variations matter - if
margin:1px actually gives a 3px margin - so what, as you say some
situations it can harm, but that's the same as only understanding some
parts of CSS.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

On Sat, 22 May 2004, Jim Ley wrote:

CSS's "optional presentation" means doing the styling *either* per
specification, *or* not at all.

but the optional presentation thing is pretty much a myth

Again I think you're over-doing it. I don't disagree for a moment
that -merely- following the guideline of implementing each individual
feature either accurately or not at all, is going to guarantee
compatibility: it's only one component of compatibility.

(for example if you support color but not background-color, you're
stuffed no matter how conformant your color support is)

Right; and if you support some parts of positioning and not others,
you could land up with some substantive content completely hidden
behind something else. And so on...

So the optionality certainly needs to be used with good sense, not
just tossing a coin.

CSS needs profiles which says you implement all these bits exactly
conformantly or not at all.

Good idea.

Until we have that, I'm not sure minor spec variations matter

It depends what you mean by "minor". Interpreting inches as pixels
is just a "minor" change in units, but the consequence is drastic.

- if margin:1px actually gives a 3px margin - so what,

Fair comment, but the cut between "minor" and "harmful" isn't always
as easy to make as that. Do you recall the chap who had put an
accented character into a CSS comment and consequently got the entire
stylesheet disqualified by one browser?[1]

So, shall we leave this issue as an open question? ;-)

cheers

[1] because the HTML file had been in utf-8, whereas the CSS file,
which in fact was iso-8859-1, had been sent without an HTTP charset
attribute; the browser deduced that the CSS file was also in utf-8
and, finding an octet that was an invalid utf-8 character, had
(correctly) applied the unicode rule that a single invalid octet
sequence in utf-8 makes the entire document invalid. The browser in
question being Mozilla, as I recall.