Re: Coding practices of large sites

On Tue, 22 Jun 2004 19:42:18 +0100, "Barry Pearson"
<news (AT) childsupportanalysis (DOT) co.uk> wrote:

Alan J. Flavell wrote:

On Tue, 22 Jun 2004, Barry Pearson wrote:
But, would Netscape have got really interested in CSS
if IE3 hadn't set a precedent?
Was a poor implementation better than none?

This article may be of interest?
http://css.nu/articles/About-JSSS.html

You'll have read http://www.w3.org/Style/LieBos2e/history/

Yes, of course! It was the basis for my statements...

That is the official "sweet" version of past CSS history.

The following is fact directly from "the horses" mouth.
(I was there and this is what I heard on the spot)

During some informal talks at the WWW meeting in Amsterdam a few years
back, Chris Wilson clearly stated that he was the one that single
handedly wrote the CSS code into MSIE3; and moved on to make his excuses
that the very flawed result was due to him working from an earlier draft
of the CSS1 spec.

Later in the evening of the same day I was at dinner together with
Haakon and a selected few other CSS gurus. I brought up this statement
from Chris and got a clear comment from Haakon that he thought that
Chris "defense" did not really hold up for examination.

According to Haakon only few changes and additions was made to CSS1
between the draft that Chris used and what was to become the CSS1
recommendation later on.

Most especially, the definition of the em unit was clear and stable
since long time back and did not change into the final spec, still Chris
found reason to write code into IE3 that interpreted 1em as 1px. In
general, relative font sizing was basically impossible in IE3, Chris
either did not understand the concept or took the easy way out by some
reason.

...IE3 reliably supports most of the color,
background, font and text properties...

That is one very big overstatement, if you ask me.

"The next browser to announce support was Netscape's Navigator,
version 4.0. Since its inception Netscape had been sceptical
towards style sheets

Well, NS brought attribute based presentation to some (disputable)
heights, they also "invented" Java script (but not the concept of client
side scripting of course, Pei Wei and his 'Viola' browser gets the full
credit of that [1]).

I'd say it was more or less natural for the guys at NS to try to build a
new presentation system on what they already had available.

The NS JSSS proposal started late in time, that's true, but given the
names associated with that proposal I have no doubt about the level of
commitment to the task.

JSSS fell on the requirement to keep client side scripting activated if
styling was required. CSS otoh was a descriptive language only, did not
require client side _execution_ of downloaded code and could as a result
be seen as a much user safe way for an author to suggest styling of his
document.

NS fell too; and thanks to what happened after the so called "MSIE wins
the browser market claim", we now have Mozilla as the "real thing".

A sysadmin that blocks Java script can still allow CSS to get through
without jeopardizing the inner safety of his network. [2]
There is no notation of "conditional execution of code" in CSS and that
is exactly what makes CSS safe, as opposed to client side executable
code.

[1] http://www.xcf.berkeley.edu/~wei/viola/violaHome.html

[2] http://www.w3.org/TR/1999/WD-becss-19990804
If this draft or any of its siblings makes it as a
recommendation we will instantly find a cader of nasty
guys starting to examine the loop holes. You can not
even leave CSS switched on in your browser in fear of
new types of viruses on the net. Please God, take whatever
is left of this activity at W3C to your bosom for good.

--
Rex

Jan Roland Eriksson wrote:

On Tue, 22 Jun 2004 19:42:18 +0100, "Barry Pearson"
news (AT) childsupportanalysis (DOT) co.uk> wrote:
Alan J. Flavell wrote:

On Tue, 22 Jun 2004, Barry Pearson wrote:
But, would Netscape have got really interested in CSS
if IE3 hadn't set a precedent?
Was a poor implementation better than none?

This article may be of interest?
http://css.nu/articles/About-JSSS.html

You'll have read http://www.w3.org/Style/LieBos2e/history/

Yes, of course! It was the basis for my statements...

That is the official "sweet" version of past CSS history.

The following is fact directly from "the horses" mouth.
(I was there and this is what I heard on the spot)
[snip of the insider's version]

Thanks for that. But I don't think it necessarily contradicts the suggestion
(or question) above, that perhaps IE3 set a useful precedent.

Alan hinted (with a smiley) that it was an attempt to discredit CSS for all
time. But how could it do that? I believe that, at the time, IE was not the
dominant browser. That was still NS. And NS had implemented its own scheme,
then put that forward to W3C. How would MS have benefitted by discrediting W3C
or CSS at that time? How would it have helped MS achieve its ambitions?

What MS did was a sensible tactic that is often used by the non-dominant
supplier - use "open standards", and make a virtue out of it. You get some
kudos, and the chance to gang-up on the dominant supplier. (I worked in the
"Open Systems Group" of an IT company that did exactly this, to help compete
with IBM & SNA!)
http://www.quirksmode.org/index.html...s/history.html

At the time that IE3 released its (poor) implementation of CSS1, in
July/August 1996, what credibility did W3C have in the world? How many
recommendations had they published? In fact, how many W3C-originated
specifications of any kind, even draft specifications, had been built into any
non-W3C browser up to that time? I suspect the answer to those is "few if
any". If so, then perhaps some sort of endorsement by MS was useful. Which
were the first such examples?

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

On Wed, 23 Jun 2004, Barry Pearson wrote:

Alan hinted (with a smiley) that it was an attempt to discredit CSS
for all time.

By saying "this apparent attempt" I'm referring to what was visible
externally; I don't impute any intention of malice to the author.

I had *hoped* to express that sufficiently outrageously that it
wouldn't be taken seriously! But whatever Chris's good intentions in
implementing some CSS1, it was IMHO a significant error of judgment to
have the experimental stylesheet support enabled by default at that
stage without consulting the user.

But it started us all off with finding ways of hiding good CSS from
this or that bad browser - which stood us in good stead in the
meantime, hmmm?

How would MS have benefitted by discrediting W3C
or CSS at that time? How would it have helped MS achieve its ambitions?

Presumably they would have implemented their own box model, thus
ensuring that any pages designed by non-specialists to look good on IE
would come out badly on other browsers. Oh, wait - that sounds a
familiar scenario.

But as you hinted, they only got away with that by quickly becoming
"the dominant supplier". Other suppliers then have to square the
circle by not only implementing the standards, but also finding out
what the dominant supplier's quirks are and trying to emulate them.
Sad, really.

Alan J. Flavell wrote:

On Wed, 23 Jun 2004, Barry Pearson wrote:
[snip]
But it started us all off with finding ways of hiding good CSS from
this or that bad browser - which stood us in good stead in the
meantime, hmmm?
[snip]

Perhaps you have a view on this:

There is an IE-specific conditional capability within comments in the head of
HTML documents. So it is possible to make versions of IE see some HTML-like
stuff that won't be seen by other browsers. (OK, you knew that).

What this appears to mean is that, where (say) an IE5-specific bit of CSS is
useful, perhaps to change the box-values, or an IE6-specific bit of CSS is
useful, perhaps to correct a float-bug, it is possible to handle this via such
a conditional. The CSS can be embedded, or linked to. This appears to be a
clean way of correcting an IE-specific bug or non-compliance. Instead of a
hack that is in the CSS seen by all browsers, the correction is where it is
intended to be seen, and is only seen, by the browsers concerned. Up to now,
I've only used this for experimental pages. But it appears to be a better way
of fixing IE-specific problems.

And, to be honest, I wish all other browsers had this capability! IE isn't the
only one with problems. I would prefer to have a standard no-hack CSS that
would work with any totally-compliant browser, then specific add-ons for
specific browsers, rather than have mixed-hack CSSs, which is what I normally
end up with.

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

"Jan Roland Eriksson" <jrexon (AT) newsguy (DOT) com> wrote

[2] http://www.w3.org/TR/1999/WD-becss-19990804
If this draft or any of its siblings makes it as a
recommendation we will instantly find a cader of nasty
guys starting to examine the loop holes. You can not
even leave CSS switched on in your browser in fear of
new types of viruses on the net. Please God, take whatever
is left of this activity at W3C to your bosom for good.

Even though the hooks to code are specified in CSS, the code itself is still
JS, and if you've got your JS turned off it still ought not to run, without
your also having to turn off CSS.

On Wed, 23 Jun 2004, Barry Pearson wrote:

Perhaps you have a view on this:

Perhaps I do... Based on your usual plan, you've already worked out
what it's going to be...

What this appears to mean is that, where (say) an IE5-specific bit of CSS is
useful, perhaps to change the box-values, or an IE6-specific bit of CSS is
useful, perhaps to correct a float-bug, it is possible to handle this via such
a conditional. The CSS can be embedded, or linked to. This appears to be a
clean way of correcting an IE-specific bug or non-compliance. Instead of a
hack that is in the CSS seen by all browsers, the correction is where it is
intended to be seen, and is only seen, by the browsers concerned. Up to now,
I've only used this for experimental pages. But it appears to be a better way
of fixing IE-specific problems.

And, to be honest, I wish all other browsers had this capability!

You've identified the problem, but you're asking for the wrong
solution IMNSHO. If the browser isn't conforming to the spec, then it
should be corrected, rather than providing additional handles for
document authors to work-around the misfeature.

On the other hand, if they implement some vendor extension that is in
conformance with the letter and spirit of the specification, then
other browsers can simply disregard it, and all will be well.

IE isn't the only one with problems.

True enough. But the cure seems worse than the disease. Soon we'd
have megabytes of conditional code extruded by [insert favourite
webpage extruder here] for every conceivable browser, just in order to
display a simple 5-line news item.

I would prefer to have a standard no-hack CSS that
would work with any totally-compliant browser,

Yeah, and how are you going to work-around the inevitable bugs in the
conditional workaround code, riddle me that? Sorry, but this looks
like applying elastoplast over duct tape over hansaplast, instead of
healing the original wound.

The dominant vendor is /always/ a problem. Let's not take that as an
excuse to create problems with every vendor. Minority vendors can't
afford to be nonstandard[1].

ttfn

[1] yes, I said it before: they need to steer a precarious course
between doing what the spec requires, and imitating the bugs on the
majority vendor's offering. That's the reality, whatever one might
wish. But I reckon that content authors *can* work within that
framework, provided they're not getting hamstrung by unrealistic
demands for pixel-exact reproductions; the wide variations between
presentation situations are more radical than the relatively modest
variations between those CSS constructs which can be realistically
applied in a WWW context. But you've heard this litany before.

Alan J. Flavell wrote:

On Wed, 23 Jun 2004, Barry Pearson wrote:

Perhaps you have a view on this:

Perhaps I do... Based on your usual plan, you've already worked out
what it's going to be...

I hadn't a clue what your view would be!

[snip]

You've identified the problem, but you're asking for the wrong
solution IMNSHO. If the browser isn't conforming to the spec, then it
should be corrected, rather than providing additional handles for
document authors to work-around the misfeature.

Once a version of a browser is in the field, how can all instances of it be
corrected? How can all IE 5 in the field be corrected? Or all Opera 7.23?

When I worked for an IT company, we could make a some rules, for example that
we would only support versions for so long. Then we would expect our users to
catch up. What we meant was that users could no longer expect support. But the
web isn't like that. We can't make such rules, if we respect our audience.

MS introduced IE 6, which fixed the IE 5 box-model flaws. So, can all authors
now ignore IE 5 box-model flaws because MS has corrected IE? Or consider
similar questions about Mozilla. Or Opera. No! Demonstrably, correcting a
fault in a browser doesn't ensure that authors don't need to cater for those
faults. Instead, we get another browser that we have to cater for!

[snip]

IE isn't the only one with problems.

True enough. But the cure seems worse than the disease. Soon we'd
have megabytes of conditional code extruded by [insert favourite
webpage extruder here] for every conceivable browser, just in order to
display a simple 5-line news item.

I suspect we already have that. They are browser hacks, and appear to exist in
lots of CSSs worldwide. But they are currently mixed in with the rest of the
CSS, not separated out. I would prefer a way to have them clearly separated
out.

I was prompted by the following from the "Style" section at W3C. See the CSS,
apparently by Bert Bos, who hardly needs an introduction here. It isn't really
a surprise that such an expert on CSS has lots of hacks in his CSS. The more
you push CSS in your work, the more hacks you find useful/necessary.
http://www.w3.org/Style/Examples/007/figures.html

I would prefer to have a standard no-hack CSS that
would work with any totally-compliant browser,

Yeah, and how are you going to work-around the inevitable bugs in the
conditional workaround code, riddle me that? Sorry, but this looks
like applying elastoplast over duct tape over hansaplast, instead of
healing the original wound.

I already put corrections for IE 5 in my CSS. There is the "lack of
margin-left/right: auto" problem. And box-model problems. So I fix them in the
basic CSS. I sometimes use a hack that puts the wrong value in for IE 5, then
uses a "voice-family" parsing-trick to make IE 5 exit from the rule, then put
the right value in. Yeuk! And I have line-height hacks to correct the IE 6
"peekaboo" bug. Etc.

No force on the planet is going to make those browsers go away and become
unimportant in the near future. Why are people still using IE 5 when MS has
made IE 6 available? Indeed, why are some people still using IE 4, and
criticising some of my pages because of how it renders them? MS fixed those
bugs, yet they persist in the field.

The dominant vendor is /always/ a problem. Let's not take that as an
excuse to create problems with every vendor. Minority vendors can't
afford to be nonstandard[1].
[snip]

But, of course, they are sometimes nonstandard! It isn't just IE that causes
problems. There have been recent posts about Opera, and I too have had
problems with Opera 7.23. Quite often I can get IE 5, IE 6, Firefox 0.8,
Netscape 7.1, to agree, while Opera 7.23 does something else entirely,
apparently as non-compliance. They are not emulating IE problems - they are
introducing their own unique problems. Have a look at the W3C CSS I identified
above. It mentions Konqueror & Safari. There is a "be nice to Opera" hack.
Everyone knows how to hide stuff from NN4.

The problem of using browser-specific property/value pairs already exists, and
is tackled, in vast numbers of CSSs world-wide. I would prefer to have a
cleaner way of tackling it.

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

On Wed, 23 Jun 2004, Barry Pearson wrote:

Once a version of a browser is in the field, how can all instances of it be
corrected? How can all IE 5 in the field be corrected? Or all Opera 7.23?

Right. So how do you propose to add your conditional comment handling
extension to all the instances of IE5 or Opera 7 which are out there?

When I worked for an IT company, we could make a some rules, for example that
we would only support versions for so long. Then we would expect our users to
catch up. What we meant was that users could no longer expect support. But the
web isn't like that. We can't make such rules, if we respect our audience.

Do I hear echoes of Dr.John here?

No force on the planet is going to make those browsers go away and
become unimportant in the near future.

So how do you propose to "force" conditional comment support into
those which don't have it? If any effort is to be expended, then I'd
rather see it expended on correcting the bugs, than on erecting yet
more scaffolding onto which the bugs could be elevated to "legacy
support" status.

Why are people still using IE 5 when MS has made IE 6 available?

Why indeed. IE4 (hello Dr.John) is probably so old that no hacker can
be bothered to exploit its security weaknesses any more; but IE5 and
5.5 are demonstrably insecure and in need of attention. Server hits
(with all appropriate disclaimers) seem to show that MSIE users are
more inclined to upgrade than are NN4.* users. Since NN4 doesn't
penetrate their OS to the extent that the Operating System Component
does, there's some logic in that.

Indeed, why are some people still using IE 4, and
criticising some of my pages because of how it renders them?

Sounds as if you -are- playing your part in the concordat, and they
aren't playing theirs. I'd have to recommend
http://www.codesmiths.com/shed/things/clueiron/ in such a situation.
They shouold understand (as you undoubtedly do) that access to the
content is paramount; but the cosmetics only come out right if both
partners play their proper part. Could almost be a paradigm for real
life, what?

Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

Harlan Messinger wrote:
"Jan Roland Eriksson" wrote...

[2] http://www.w3.org/TR/1999/WD-becss-19990804
If this draft or any of its siblings makes it as a
recommendation we will instantly find a cader of nasty
guys starting to examine the loop holes. You can not
even leave CSS switched on in your browser in fear of
new types of viruses on the net. Please God, take whatever
is left of this activity at W3C to your bosom for good.

Even though the hooks to code are specified in CSS, the code itself is still
JS, and if you've got your JS turned off it still ought not to run, without
your also having to turn off CSS.

But what will admins do when they want to block all js? Right now, they
can block js via a firewall while permitting text/css. If this is
implemented, would they have to then block all css?

I see what you mean, as far as the syntax that embeds script into the
CSS property declaration is concerned. That could be avoided in favor
of requiring behaviors to be served from separate .HTC files, with
which a distinctive MIME type could be associated.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

Alan J. Flavell wrote:

On Wed, 23 Jun 2004, Barry Pearson wrote:

Once a version of a browser is in the field, how can all instances
of it be corrected? How can all IE 5 in the field be corrected? Or
all Opera 7.23?

Right. So how do you propose to add your conditional comment handling
extension to all the instances of IE5 or Opera 7 which are out there?

I simply said "And, to be honest, I wish all other browsers had this
capability! IE isn't the only one with problems". Obviously, I can't use this
method with browsers that don't support it. For them, I will have to find
hacks, and put them into my CSS. As many other people do. A pity.

MS have provided a simple & clean way for me to cater for IE deficiencies. I
don't appear to need such hacks for IE, even though there are some available,
(such as the "voice-family" hack for IE 5). The hacks would exist whether or
not IE had the conditional capability. I simply have the opportunity with IE
to move them to a better location. A pity I can't move hacks for other
browsers to better locations. Good for IE.

When I worked for an IT company, we could make a some rules, for
example that we would only support versions for so long. Then we
would expect our users to catch up. What we meant was that users
could no longer expect support. But the web isn't like that. We
can't make such rules, if we respect our audience.

Do I hear echoes of Dr.John here?

Uh?

No force on the planet is going to make those browsers go away and
become unimportant in the near future.

So how do you propose to "force" conditional comment support into
those which don't have it? If any effort is to be expended, then I'd
rather see it expended on correcting the bugs, than on erecting yet
more scaffolding onto which the bugs could be elevated to "legacy
support" status.

Of course I want bugs corrected! But how will that ensure that all relevant
browsers in the field are corrected? And if they are not, how has that helped
me, as an author? I have to cater for the significant instances among my
audience.

Suppose NN4 had provided such a conditional capability. I wonder how much
grief & workaround action would have been avoided as a result? I am not
actually proposing a specific standard for browser conditionals. If you or
someone else said "this should be in the CSS, not in the HTML", I would
examine the consequences, and probably agree. After all, in effect the
well-known NN4 trick *is* in the CSS - using the @include feature. So why not
the others too?

The point I am making is that correcting bugs doesn't solve the author's
problem. I am talking about solutions to the author's problem.

Why are people still using IE 5 when MS has made IE 6 available?

Why indeed. IE4 (hello Dr.John) is probably so old that no hacker can
be bothered to exploit its security weaknesses any more; but IE5 and
5.5 are demonstrably insecure and in need of attention. Server hits
(with all appropriate disclaimers) seem to show that MSIE users are
more inclined to upgrade than are NN4.* users. Since NN4 doesn't
penetrate their OS to the extent that the Operating System Component
does, there's some logic in that.
[snip]

How does that affect the above logic? MS released IE 6 a long time ago. But
lots of people are still using IE 5. So their release of IE 6 didn't resolve
the box-model problem as far as authors are concerned.

I don't presume to know why users do what they do, or use the browsers that
they do. I simply want to deliver the best pages I can to them. If they use IE
5, for some reason, in spite of better products from MS, then I want them to
view my pages favourably.

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