'div id' vs 'div class'

hello,

can anyone tell me or direct me where can I find explanation about
difference between <div id=..> and <div class=..>

TNX

dr. zoidberg wrote:
[color=blue]
> can anyone tell me or direct me where can I find explanation about
> difference between <div id=..> and <div class=..>[/color]

The best place to start is wherever you learnt HTML and CSS. Then follow it
up by reading the specifications:

<URL:http://www.w3.org/TR/html401/struct/global.html#h-7.5.2>

<URL:http://www.w3.org/TR/REC-CSS2/selector.html>

Then, if you still have problems understanding, use Google:

<URL:http://groups.google.com/groups?q=class+id+group%3Acomp.infosystems.www.aut horing.stylesheets>

<URL:http://groups.google.com/groups?selm=CLKdnX48QbsxO8miRVn-vg%40giganews.com>

Also see:

<URL:http://www.catb.org/~esr/faqs/smart-questions.html#before>

--
Jim Dabell

"dr. zoidberg" <zoi@example.org> schreef in bericht
news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=blue]
> hello,
>
> can anyone tell me or direct me where can I find explanation about
> difference between <div id=..> and <div class=..>
>
> TNX[/color]

You know about usenet,
you know enough about CSS to ask this question in this newsgroup
but you don't know where or how to find an answer????

Jakob

dr. zoidberg wrote:
[color=blue]
> can anyone tell me or direct me where can I find explanation about
> difference between <div id=..> and <div class=..>[/color]

The best place to start is wherever you learnt HTML and CSS. Then follow it
up by reading the specifications:

<URL:http://www.w3.org/TR/html401/struct/global.html#h-7.5.2>

<URL:http://www.w3.org/TR/REC-CSS2/selector.html>

Then, if you still have problems understanding, use Google:

<URL:http://groups.google.com/groups?q=class+id+group%3Acomp.infosystems.www.aut horing.stylesheets>

<URL:http://groups.google.com/groups?selm=CLKdnX48QbsxO8miRVn-vg%40giganews.com>

Also see:

<URL:http://www.catb.org/~esr/faqs/smart-questions.html#before>

--
Jim Dabell

http://www.yourhtmlsource.com/styles...tml#CLASSESIDS

"dr. zoidberg" <zoi@example.org> wrote in message
news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=blue]
> hello,
>
> can anyone tell me or direct me where can I find explanation about
> difference between <div id=..> and <div class=..>
>
> TNX[/color]

"dr. zoidberg" <zoi@example.org> schreef in bericht
news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=blue]
> hello,
>
> can anyone tell me or direct me where can I find explanation about
> difference between <div id=..> and <div class=..>
>
> TNX[/color]

You know about usenet,
you know enough about CSS to ask this question in this newsgroup
but you don't know where or how to find an answer????

Jakob

http://www.yourhtmlsource.com/styles...tml#CLASSESIDS

"dr. zoidberg" <zoi@example.org> wrote in message
news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=blue]
> hello,
>
> can anyone tell me or direct me where can I find explanation about
> difference between <div id=..> and <div class=..>
>
> TNX[/color]

"dr. zoidberg" <zoi@example.org> wrote:
[color=blue]
>can anyone tell me or direct me where can I find explanation about
>difference between <div id=..> and <div class=..>[/color]

http://www.w3.org/TR/html401/struct/global.html#h-7.5.2

--
Spartanicus

"dr. zoidberg" <zoi@example.org> wrote:
[color=blue]
>can anyone tell me or direct me where can I find explanation about
>difference between <div id=..> and <div class=..>[/color]

http://www.w3.org/TR/html401/struct/global.html#h-7.5.2

--
Spartanicus

Spartanicus <me@privacy.net> wrote:
[color=blue]
>"dr. zoidberg" <zoi@example.org> wrote:
>[color=green]
>>can anyone tell me or direct me where can I find explanation about
>>difference between <div id=..> and <div class=..>[/color]
>
>http://www.w3.org/TR/html401/struct/global.html#h-7.5.2[/color]

As ever, W3C is always confusing.

"Note that the French "msg1" and the English "msg1" may not appear in
the same document since they share the same id value. Authors may make
further use of the id attribute to refine the presentation of
individual messages, make them target anchors, etc."

Etc? And whether or not they'd wish it, politics aside, the very
example, above, suggests it's in the very self-same document. What the
authors of these mean, and what they write, are often not the same.
They can be very specific, even pedantic, in explaining things on ngs.
I've seen that in other areas. But the documents tend to be almost
written in a shorthand, with much consistency and detail omitted.

And yet aren't these the norms, supposedly, for criticisms of IE, and
even NN (if anyone still uses it), for not being 'standards
compliant'?

Take the pre.example. It's described this way:

"The document is to include a number of preformatted examples. We use
the PRE element to format the examples. We also assign a background
color (green) to all instances of the PRE element belonging to the
class "example". "

What they really mean is that:

One given document might include more than one PRE section. Any of
these can present a green background, if we associate that section
with a certain CLASS; which we called, "example", in this example.

And I'm confused, as well, why W3C doesn't use lower case for XHMTL?
It's the particular version they can call their own.

Anyway.

Spartanicus <me@privacy.net> wrote:
[color=blue]
>"dr. zoidberg" <zoi@example.org> wrote:
>[color=green]
>>can anyone tell me or direct me where can I find explanation about
>>difference between <div id=..> and <div class=..>[/color]
>
>http://www.w3.org/TR/html401/struct/global.html#h-7.5.2[/color]

As ever, W3C is always confusing.

"Note that the French "msg1" and the English "msg1" may not appear in
the same document since they share the same id value. Authors may make
further use of the id attribute to refine the presentation of
individual messages, make them target anchors, etc."

Etc? And whether or not they'd wish it, politics aside, the very
example, above, suggests it's in the very self-same document. What the
authors of these mean, and what they write, are often not the same.
They can be very specific, even pedantic, in explaining things on ngs.
I've seen that in other areas. But the documents tend to be almost
written in a shorthand, with much consistency and detail omitted.

And yet aren't these the norms, supposedly, for criticisms of IE, and
even NN (if anyone still uses it), for not being 'standards
compliant'?

Take the pre.example. It's described this way:

"The document is to include a number of preformatted examples. We use
the PRE element to format the examples. We also assign a background
color (green) to all instances of the PRE element belonging to the
class "example". "

What they really mean is that:

One given document might include more than one PRE section. Any of
these can present a green background, if we associate that section
with a certain CLASS; which we called, "example", in this example.

And I'm confused, as well, why W3C doesn't use lower case for XHMTL?
It's the particular version they can call their own.

Anyway.

On Tue, 13 Apr 2004 20:29:19 -0700, Mark Johnson
<102334.12@compuserve.com> wrote:
[color=blue]
> "Note that the French "msg1" and the English "msg1" may not appear in
> the same document since they share the same id value. Authors may make
> further use of the id attribute to refine the presentation of
> individual messages, make them target anchors, etc."
>
> Etc? And whether or not they'd wish it, politics aside, the very
> example, above, suggests it's in the very self-same document. What the
> authors of these mean, and what they write, are often not the same.
> They can be very specific, even pedantic, in explaining things on ngs.
> I've seen that in other areas. But the documents tend to be almost
> written in a shorthand, with much consistency and detail omitted.[/color]

In this case, I'd look at the example as faulted, and instead hold to the
basic concept of only one instance of id="foo" in a single document. All
the remaining text follows this concept - especially what immediately
folows the example, "Note that the French "msg1" and the English "msg1"
may not appear in the same document." This clearly says that the above
example cannot appear as is in an HTML document.
[color=blue]
> Take the pre.example. It's described this way:
>
> "The document is to include a number of preformatted examples. We use
> the PRE element to format the examples. We also assign a background
> color (green) to all instances of the PRE element belonging to the
> class "example". "
>
> What they really mean is that:
>
> One given document might include more than one PRE section. Any of
> these can present a green background, if we associate that section
> with a certain CLASS; which we called, "example", in this example.[/color]

Yes. And we can further style the specific example using its unique id.
[color=blue]
> And I'm confused, as well, why W3C doesn't use lower case for XHMTL?
> It's the particular version they can call their own.[/color]

The given reference is to HTML 4.01, not XHTML. In the XHTML specs, I am
pretty sure they routinely use lowercase for element tags.

On Tue, 13 Apr 2004 20:29:19 -0700, Mark Johnson
<102334.12@compuserve.com> wrote:
[color=blue]
> "Note that the French "msg1" and the English "msg1" may not appear in
> the same document since they share the same id value. Authors may make
> further use of the id attribute to refine the presentation of
> individual messages, make them target anchors, etc."
>
> Etc? And whether or not they'd wish it, politics aside, the very
> example, above, suggests it's in the very self-same document. What the
> authors of these mean, and what they write, are often not the same.
> They can be very specific, even pedantic, in explaining things on ngs.
> I've seen that in other areas. But the documents tend to be almost
> written in a shorthand, with much consistency and detail omitted.[/color]

In this case, I'd look at the example as faulted, and instead hold to the
basic concept of only one instance of id="foo" in a single document. All
the remaining text follows this concept - especially what immediately
folows the example, "Note that the French "msg1" and the English "msg1"
may not appear in the same document." This clearly says that the above
example cannot appear as is in an HTML document.
[color=blue]
> Take the pre.example. It's described this way:
>
> "The document is to include a number of preformatted examples. We use
> the PRE element to format the examples. We also assign a background
> color (green) to all instances of the PRE element belonging to the
> class "example". "
>
> What they really mean is that:
>
> One given document might include more than one PRE section. Any of
> these can present a green background, if we associate that section
> with a certain CLASS; which we called, "example", in this example.[/color]

Yes. And we can further style the specific example using its unique id.
[color=blue]
> And I'm confused, as well, why W3C doesn't use lower case for XHMTL?
> It's the particular version they can call their own.[/color]

The given reference is to HTML 4.01, not XHTML. In the XHTML specs, I am
pretty sure they routinely use lowercase for element tags.

On Tue, 13 Apr 2004 19:51:34 +0200, "dr. zoidberg" <zoi@example.org> wrote:
[color=blue]
>hello,
>
>can anyone tell me or direct me where can I find explanation about
>difference between <div id=..> and <div class=..>
>[/color]
Use "id" for things that happen only *once*
Use "class" for those that happen *more than once*

Mason C

On Tue, 13 Apr 2004 19:51:34 +0200, "dr. zoidberg" <zoi@example.org> wrote:
[color=blue]
>hello,
>
>can anyone tell me or direct me where can I find explanation about
>difference between <div id=..> and <div class=..>
>[/color]
Use "id" for things that happen only *once*
Use "class" for those that happen *more than once*

Mason C

On Tue, 13 Apr 2004 20:27:34 +0200, "Jakob" <acc_kats@hotmail.com> wrote:
[color=blue]
>
>"dr. zoidberg" <zoi@example.org> schreef in bericht
>news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=green]
>> hello,
>>
>> can anyone tell me or direct me where can I find explanation about
>> difference between <div id=..> and <div class=..>
>>
>> TNX[/color]
>
>You know about usenet,
>you know enough about CSS to ask this question in this newsgroup
>but you don't know where or how to find an answer????
>[/color]
This poster make me think of George W. Bush. If you don't have
the answer, filibuster.

Mason C[color=blue]
>
>
>[/color]

On Tue, 13 Apr 2004 20:27:34 +0200, "Jakob" <acc_kats@hotmail.com> wrote:
[color=blue]
>
>"dr. zoidberg" <zoi@example.org> schreef in bericht
>news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=green]
>> hello,
>>
>> can anyone tell me or direct me where can I find explanation about
>> difference between <div id=..> and <div class=..>
>>
>> TNX[/color]
>
>You know about usenet,
>you know enough about CSS to ask this question in this newsgroup
>but you don't know where or how to find an answer????
>[/color]
This poster make me think of George W. Bush. If you don't have
the answer, filibuster.

Mason C[color=blue]
>
>
>[/color]

Mark Johnson <102334.12@compuserve.com> wrote:
[color=blue][color=green]
>>http://www.w3.org/TR/html401/struct/global.html#h-7.5.2[/color]
>
>As ever, W3C is always confusing.
>
>And yet aren't these the norms, supposedly, for criticisms of IE, and
>even NN (if anyone still uses it), for not being 'standards
>compliant'?[/color]

The HTML spec is pretty sloppy compared to the more properly defined css
spec. But the criticism often levied against IE mainly concerns css
compliance. IE's html compliance is not significantly worse than other
UAs afaik.

--
Spartanicus

Mark Johnson <102334.12@compuserve.com> wrote:
[color=blue][color=green]
>>http://www.w3.org/TR/html401/struct/global.html#h-7.5.2[/color]
>
>As ever, W3C is always confusing.
>
>And yet aren't these the norms, supposedly, for criticisms of IE, and
>even NN (if anyone still uses it), for not being 'standards
>compliant'?[/color]

The HTML spec is pretty sloppy compared to the more properly defined css
spec. But the criticism often levied against IE mainly concerns css
compliance. IE's html compliance is not significantly worse than other
UAs afaik.

--
Spartanicus

"MasonC" <masonc@ix.netcom.xyz.com> schreef in bericht
news:s8hp701nike35urvrb8rvk3eujhhu9cj24@4ax.com...[color=blue]
> On Tue, 13 Apr 2004 20:27:34 +0200, "Jakob" <acc_kats@hotmail.com> wrote:
>[color=green]
> >
> >"dr. zoidberg" <zoi@example.org> schreef in bericht
> >news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=darkred]
> >> hello,
> >>
> >> can anyone tell me or direct me where can I find explanation about
> >> difference between <div id=..> and <div class=..>
> >>
> >> TNX[/color]
> >
> >You know about usenet,
> >you know enough about CSS to ask this question in this newsgroup
> >but you don't know where or how to find an answer????
> >[/color]
> This poster make me think of George W. Bush. If you don't have
> the answer, filibuster.
>
> Mason C[color=green]
> >[/color][/color]

I'm not a CSS-expert, I'm still learning.
And one of the best ways to do that (for me at least) is to follow this
newsgroup
and I read books and magazines.

Maybe I wasn't in the best of moods this morning,
maybe I should've just kept my mouth closed (and my fingers away from the
keys)
but I........
oh well, forget it.

I'm sorry if I offended anyone
and I appologize for my rude behaviour.

*But don't ever compare me to G.W*

Jakob

"MasonC" <masonc@ix.netcom.xyz.com> schreef in bericht
news:s8hp701nike35urvrb8rvk3eujhhu9cj24@4ax.com...[color=blue]
> On Tue, 13 Apr 2004 20:27:34 +0200, "Jakob" <acc_kats@hotmail.com> wrote:
>[color=green]
> >
> >"dr. zoidberg" <zoi@example.org> schreef in bericht
> >news:c5h9b0$1i4fc$1@ID-93631.news.uni-berlin.de...[color=darkred]
> >> hello,
> >>
> >> can anyone tell me or direct me where can I find explanation about
> >> difference between <div id=..> and <div class=..>
> >>
> >> TNX[/color]
> >
> >You know about usenet,
> >you know enough about CSS to ask this question in this newsgroup
> >but you don't know where or how to find an answer????
> >[/color]
> This poster make me think of George W. Bush. If you don't have
> the answer, filibuster.
>
> Mason C[color=green]
> >[/color][/color]

I'm not a CSS-expert, I'm still learning.
And one of the best ways to do that (for me at least) is to follow this
newsgroup
and I read books and magazines.

Maybe I wasn't in the best of moods this morning,
maybe I should've just kept my mouth closed (and my fingers away from the
keys)
but I........
oh well, forget it.

I'm sorry if I offended anyone
and I appologize for my rude behaviour.

*But don't ever compare me to G.W*

Jakob

Spartanicus wrote:
[color=blue]
> the criticism often levied against IE mainly concerns css compliance.
> IE's html compliance is not significantly worse than other UAs afaik.[/color]

IE(*/Win*)'s programmers don't have much faith in its HTML abilities, if
one takes its accept headers seriously. Content-type text/html is
conspicuously absent from the types it will accept. It is only by the
final catch-all */* that html ever reaches that os-component thingy.

In any case, IE/Win's comformance is worst at the http level. (This does
not contradict what you said, but I thought it worth mentioning that
IE/Win's CSS shortcomings, while deplorable, are not its most serious.)

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Spartanicus wrote:
[color=blue]
> the criticism often levied against IE mainly concerns css compliance.
> IE's html compliance is not significantly worse than other UAs afaik.[/color]

IE(*/Win*)'s programmers don't have much faith in its HTML abilities, if
one takes its accept headers seriously. Content-type text/html is
conspicuously absent from the types it will accept. It is only by the
final catch-all */* that html ever reaches that os-component thingy.

In any case, IE/Win's comformance is worst at the http level. (This does
not contradict what you said, but I thought it worth mentioning that
IE/Win's CSS shortcomings, while deplorable, are not its most serious.)

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

MasonC wrote:
[color=blue]
> On Tue, 13 Apr 2004, Jakob wrote:
>[color=green]
>> "dr. zoidberg" schreef...
>>[color=darkred]
>>> can anyone tell me or direct me where can I find explanation
>>> about difference between <div id=..> and <div class=..>[/color]
>>
>> You know about usenet, you know enough about CSS to ask this
>> question in this newsgroup but you don't know where or how to find
>> an answer????[/color]
>
> If you don't have the answer, filibuster.[/color]

I'd point you to "how to ask questions the smart way," but the point
would be lost on you.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

MasonC wrote:
[color=blue]
> On Tue, 13 Apr 2004, Jakob wrote:
>[color=green]
>> "dr. zoidberg" schreef...
>>[color=darkred]
>>> can anyone tell me or direct me where can I find explanation
>>> about difference between <div id=..> and <div class=..>[/color]
>>
>> You know about usenet, you know enough about CSS to ask this
>> question in this newsgroup but you don't know where or how to find
>> an answer????[/color]
>
> If you don't have the answer, filibuster.[/color]

I'd point you to "how to ask questions the smart way," but the point
would be lost on you.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

On Wed, 14 Apr 2004, Brian wrote:
[color=blue]
> IE(*/Win*)'s programmers don't have much faith in its HTML abilities, if
> one takes its accept headers seriously. Content-type text/html is
> conspicuously absent from the types it will accept.[/color]

Yup, if you do content-type negotiation on the server, IE will get
sent MS-Word format for preference, because it says that's what it
prefers (well, I suppose you'd need Office installed too, for that to
apply - but that's standard around here).

But if they then persuade IE to issue a reload, it sends "Accept:
*/*", so you can send them something else ! - So how about
application/postscript on the reload? - it matches their reload
Aaccept" just as well as anything else does :-}

Do you suppose it comes as a surprise to IE users that a reload can
produce an entirely different document format than the original web
access? Or maybe they just take this as a perfectly normal happening
when dealing with the Empire...
[color=blue]
> In any case, IE/Win's comformance is worst at the http level.[/color]

How true, how sadly true.

On Wed, 14 Apr 2004, Brian wrote:
[color=blue]
> IE(*/Win*)'s programmers don't have much faith in its HTML abilities, if
> one takes its accept headers seriously. Content-type text/html is
> conspicuously absent from the types it will accept.[/color]

Yup, if you do content-type negotiation on the server, IE will get
sent MS-Word format for preference, because it says that's what it
prefers (well, I suppose you'd need Office installed too, for that to
apply - but that's standard around here).

But if they then persuade IE to issue a reload, it sends "Accept:
*/*", so you can send them something else ! - So how about
application/postscript on the reload? - it matches their reload
Aaccept" just as well as anything else does :-}

Do you suppose it comes as a surprise to IE users that a reload can
produce an entirely different document format than the original web
access? Or maybe they just take this as a perfectly normal happening
when dealing with the Empire...
[color=blue]
> In any case, IE/Win's comformance is worst at the http level.[/color]

How true, how sadly true.

Alan J. Flavell wrote:
[color=blue]
> On Wed, 14 Apr 2004, Brian wrote:
>[color=green]
>> IE(*/Win*)'s programmers don't have much faith in its HTML
>> abilities, if one takes its accept headers seriously. Content-type
>> text/html is conspicuously absent from the types it will accept.[/color]
>
> Yup, if you do content-type negotiation on the server, IE will get
> sent MS-Word format for preference, because it says that's what it
> prefers[/color]

As I discovered in testing that very negotiation. But the most
remarkable thing is that the accept headers don't include text/html
anywhere (you first pointed this out to me while commenting on my
content negotiation testing). Even text/plain gets included, but not
html. So, given a choice between a marked up document and plain text,
MSIE/Win gives preference to text/plain. What does this say about the
product? about what MS thinks about the html capabilities of its "browser?"
[color=blue]
> But if they then persuade IE to issue a reload, it sends "Accept:
> */*", so you can send them something else ! - So how about
> application/postscript on the reload? - it matches their reload
> Aaccept" just as well as anything else does :-}[/color]

:-D It does match!
[color=blue]
> Do you suppose it comes as a surprise to IE users that a reload can
> produce an entirely different document format than the original web
> access? Or maybe they just take this as a perfectly normal happening
> when dealing with the Empire...[/color]

Probably the latter. My impression is that when something goes wrong,
they are not really sure who to blame. But more often then not they
think something is wrong with the site (which is often also true).

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Alan J. Flavell wrote:
[color=blue]
> On Wed, 14 Apr 2004, Brian wrote:
>[color=green]
>> IE(*/Win*)'s programmers don't have much faith in its HTML
>> abilities, if one takes its accept headers seriously. Content-type
>> text/html is conspicuously absent from the types it will accept.[/color]
>
> Yup, if you do content-type negotiation on the server, IE will get
> sent MS-Word format for preference, because it says that's what it
> prefers[/color]

As I discovered in testing that very negotiation. But the most
remarkable thing is that the accept headers don't include text/html
anywhere (you first pointed this out to me while commenting on my
content negotiation testing). Even text/plain gets included, but not
html. So, given a choice between a marked up document and plain text,
MSIE/Win gives preference to text/plain. What does this say about the
product? about what MS thinks about the html capabilities of its "browser?"
[color=blue]
> But if they then persuade IE to issue a reload, it sends "Accept:
> */*", so you can send them something else ! - So how about
> application/postscript on the reload? - it matches their reload
> Aaccept" just as well as anything else does :-}[/color]

:-D It does match!
[color=blue]
> Do you suppose it comes as a surprise to IE users that a reload can
> produce an entirely different document format than the original web
> access? Or maybe they just take this as a perfectly normal happening
> when dealing with the Empire...[/color]

Probably the latter. My impression is that when something goes wrong,
they are not really sure who to blame. But more often then not they
think something is wrong with the site (which is often also true).

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Brian wrote:[color=blue]
> Alan J. Flavell wrote:[/color]
[snip][color=blue][color=green]
>> Do you suppose it comes as a surprise to IE users that a reload can
>> produce an entirely different document format than the original web
>> access? Or maybe they just take this as a perfectly normal happening
>> when dealing with the Empire...[/color]
>
> Probably the latter. My impression is that when something goes wrong,
> they are not really sure who to blame. But more often then not they
> think something is wrong with the site (which is often also true).[/color]

How often does it go wrong?

I'm sure most sites are tested against IE. It would be foolish not to do so.
In fact, I suspect many sites are *only* tested against IE!

What problems would a user of IE find that would not have been found during
testing?

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

Brian wrote:[color=blue]
> Alan J. Flavell wrote:[/color]
[snip][color=blue][color=green]
>> Do you suppose it comes as a surprise to IE users that a reload can
>> produce an entirely different document format than the original web
>> access? Or maybe they just take this as a perfectly normal happening
>> when dealing with the Empire...[/color]
>
> Probably the latter. My impression is that when something goes wrong,
> they are not really sure who to blame. But more often then not they
> think something is wrong with the site (which is often also true).[/color]

How often does it go wrong?

I'm sure most sites are tested against IE. It would be foolish not to do so.
In fact, I suspect many sites are *only* tested against IE!

What problems would a user of IE find that would not have been found during
testing?

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

Barry Pearson wrote:
[color=blue]
> Brian wrote:
>[color=green]
>> Alan J. Flavell wrote:[/color]
>[color=green][color=darkred]
>>> Do you suppose it comes as a surprise to IE users that a reload
>>> can produce an entirely different document format than the
>>> original web access? Or maybe they just take this as a perfectly
>>> normal happening when dealing with the Empire...[/color]
>>
>> Probably the latter. My impression is that when something goes
>> wrong, they are not really sure who to blame. But more often then
>> not they think something is wrong with the site (which is often
>> also true).[/color]
>
> How often does it go wrong?[/color]

Are you looking for a figure? I thought I made it clear that I was
giving only "my impression" of the situation.
[color=blue]
> I'm sure most sites are tested against IE.[/color]

For most sites created or updated today, that is likely true.
[color=blue]
> In fact, I suspect many sites are *only* tested against IE![/color]

For most sites created or updated today, that is likely true. For legacy
sites that were created when IE was an also-ran, I'm sure there are many
sites that were not tested in it, including some tested only in Netscape.
[color=blue]
> What problems would a user of IE find that would not have been found
> during testing?[/color]

Have you been reading the thread? Let me requote something for you:
[color=blue][color=green]
>> Alan J. Flavell wrote:[/color]
>[color=green][color=darkred]
>>> Do you suppose it comes as a surprise to IE users that a reload
>>> can produce an entirely different document format than the
>>> original web access?[/color][/color][/color]

The question might then be, how many sites use content negotiation? And
do their authors, while testing in IE/Win, attempt to reload[1] the
document associated with each url?

[1] Of course, MSIE insists on calling the reload function "refresh,"
contrary to all reason.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Barry Pearson wrote:
[color=blue]
> Brian wrote:
>[color=green]
>> Alan J. Flavell wrote:[/color]
>[color=green][color=darkred]
>>> Do you suppose it comes as a surprise to IE users that a reload
>>> can produce an entirely different document format than the
>>> original web access? Or maybe they just take this as a perfectly
>>> normal happening when dealing with the Empire...[/color]
>>
>> Probably the latter. My impression is that when something goes
>> wrong, they are not really sure who to blame. But more often then
>> not they think something is wrong with the site (which is often
>> also true).[/color]
>
> How often does it go wrong?[/color]

Are you looking for a figure? I thought I made it clear that I was
giving only "my impression" of the situation.
[color=blue]
> I'm sure most sites are tested against IE.[/color]

For most sites created or updated today, that is likely true.
[color=blue]
> In fact, I suspect many sites are *only* tested against IE![/color]

For most sites created or updated today, that is likely true. For legacy
sites that were created when IE was an also-ran, I'm sure there are many
sites that were not tested in it, including some tested only in Netscape.
[color=blue]
> What problems would a user of IE find that would not have been found
> during testing?[/color]

Have you been reading the thread? Let me requote something for you:
[color=blue][color=green]
>> Alan J. Flavell wrote:[/color]
>[color=green][color=darkred]
>>> Do you suppose it comes as a surprise to IE users that a reload
>>> can produce an entirely different document format than the
>>> original web access?[/color][/color][/color]

The question might then be, how many sites use content negotiation? And
do their authors, while testing in IE/Win, attempt to reload[1] the
document associated with each url?

[1] Of course, MSIE insists on calling the reload function "refresh,"
contrary to all reason.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Brian wrote:[color=blue]
> Barry Pearson wrote:[color=green]
>> Brian wrote:[color=darkred]
>>> Alan J. Flavell wrote:[/color]
>>[color=darkred]
>>>> Do you suppose it comes as a surprise to IE users that a reload
>>>> can produce an entirely different document format than the
>>>> original web access? Or maybe they just take this as a perfectly
>>>> normal happening when dealing with the Empire...
>>>
>>> Probably the latter. My impression is that when something goes
>>> wrong, they are not really sure who to blame. But more often then
>>> not they think something is wrong with the site (which is often
>>> also true).[/color]
>>
>> How often does it go wrong?[/color]
>
> Are you looking for a figure? I thought I made it clear that I was
> giving only "my impression" of the situation.[/color]

I suppose I'm really asking "in what circumstances does it go wrong, and are
they common enough to be important?"

*If* (big IF) all sites were tested using IE 6, would this problem simply
*never* occur? Or are there cases where it could occur even with testing
against IE 6?
[color=blue][color=green]
>> I'm sure most sites are tested against IE.[/color]
>
> For most sites created or updated today, that is likely true.
>[color=green]
>> In fact, I suspect many sites are *only* tested against IE![/color]
>
> For most sites created or updated today, that is likely true. For
> legacy sites that were created when IE was an also-ran, I'm sure
> there are many sites that were not tested in it, including some
> tested only in Netscape.[/color]

True. And I admit I hadn't considered those. When was this - 1996? (I think
that is about when I started to use IE, but obviously an early version.
Perhaps IE 3?)
[color=blue][color=green]
>> What problems would a user of IE find that would not have been found
>> during testing?[/color]
>
> Have you been reading the thread?[/color]

Yes.
[color=blue]
> Let me requote something for you:
>[color=green][color=darkred]
> >> Alan J. Flavell wrote:
> >>> Do you suppose it comes as a surprise to IE users that a reload
> >>> can produce an entirely different document format than the
> >>> original web access?[/color][/color]
>
> The question might then be, how many sites use content negotiation?
> And do their authors, while testing in IE/Win, attempt to reload[1]
> the document associated with each url?[/color]
[snip]

I don't know. Do they? That comes down to my question here. And if they do
reload/refresh, in what proportion will that produce an entirely different
document format?

I'm trying to understand whether this is a theoretical problem that won't
occur in practice because when people test under IE 6 they will eliminate such
problems. Or if it is something worse.

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

Barry Pearson wrote:[color=blue]
>
> I suppose I'm really asking "in what circumstances does it go wrong,
> and are they common enough to be important?"[/color]

(Re)read the thread, and decide for yourself if they are important or not.
[color=blue]
> *If* (big IF) all sites were tested using IE 6, would this problem
> simply *never* occur?[/color]

Which problem are you talking about? Content negotiation? It went so
horribly wrong when I tested it, that I soon removed it.
[color=blue][color=green]
>> The question might then be, how many sites use content negotiation?
>> And do their authors, while testing in IE/Win, attempt to
>> reload[1] the document associated with each url?[/color]
>
> I don't know. Do they?[/color]

I'm sure that you don't expect an answer from me.
[color=blue]
> And if they do reload/refresh, in what proportion will that produce
> an entirely different document format?[/color]

In that proportion of sites where accept headers produce different
results. (?) You did say you were reading the thread, right? So you
know how reload "works" in MSIE/Win. Thus, you have all the information
that I have.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Brian wrote:[color=blue]
> Barry Pearson wrote:[color=green]
>> Brian wrote:[color=darkred]
>>> Alan J. Flavell wrote:[/color]
>>[color=darkred]
>>>> Do you suppose it comes as a surprise to IE users that a reload
>>>> can produce an entirely different document format than the
>>>> original web access? Or maybe they just take this as a perfectly
>>>> normal happening when dealing with the Empire...
>>>
>>> Probably the latter. My impression is that when something goes
>>> wrong, they are not really sure who to blame. But more often then
>>> not they think something is wrong with the site (which is often
>>> also true).[/color]
>>
>> How often does it go wrong?[/color]
>
> Are you looking for a figure? I thought I made it clear that I was
> giving only "my impression" of the situation.[/color]

I suppose I'm really asking "in what circumstances does it go wrong, and are
they common enough to be important?"

*If* (big IF) all sites were tested using IE 6, would this problem simply
*never* occur? Or are there cases where it could occur even with testing
against IE 6?
[color=blue][color=green]
>> I'm sure most sites are tested against IE.[/color]
>
> For most sites created or updated today, that is likely true.
>[color=green]
>> In fact, I suspect many sites are *only* tested against IE![/color]
>
> For most sites created or updated today, that is likely true. For
> legacy sites that were created when IE was an also-ran, I'm sure
> there are many sites that were not tested in it, including some
> tested only in Netscape.[/color]

True. And I admit I hadn't considered those. When was this - 1996? (I think
that is about when I started to use IE, but obviously an early version.
Perhaps IE 3?)
[color=blue][color=green]
>> What problems would a user of IE find that would not have been found
>> during testing?[/color]
>
> Have you been reading the thread?[/color]

Yes.
[color=blue]
> Let me requote something for you:
>[color=green][color=darkred]
> >> Alan J. Flavell wrote:
> >>> Do you suppose it comes as a surprise to IE users that a reload
> >>> can produce an entirely different document format than the
> >>> original web access?[/color][/color]
>
> The question might then be, how many sites use content negotiation?
> And do their authors, while testing in IE/Win, attempt to reload[1]
> the document associated with each url?[/color]
[snip]

I don't know. Do they? That comes down to my question here. And if they do
reload/refresh, in what proportion will that produce an entirely different
document format?

I'm trying to understand whether this is a theoretical problem that won't
occur in practice because when people test under IE 6 they will eliminate such
problems. Or if it is something worse.

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

Barry Pearson wrote:[color=blue]
>
> I suppose I'm really asking "in what circumstances does it go wrong,
> and are they common enough to be important?"[/color]

(Re)read the thread, and decide for yourself if they are important or not.
[color=blue]
> *If* (big IF) all sites were tested using IE 6, would this problem
> simply *never* occur?[/color]

Which problem are you talking about? Content negotiation? It went so
horribly wrong when I tested it, that I soon removed it.
[color=blue][color=green]
>> The question might then be, how many sites use content negotiation?
>> And do their authors, while testing in IE/Win, attempt to
>> reload[1] the document associated with each url?[/color]
>
> I don't know. Do they?[/color]

I'm sure that you don't expect an answer from me.
[color=blue]
> And if they do reload/refresh, in what proportion will that produce
> an entirely different document format?[/color]

In that proportion of sites where accept headers produce different
results. (?) You did say you were reading the thread, right? So you
know how reload "works" in MSIE/Win. Thus, you have all the information
that I have.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Neal <neal413@spamrcn.com> wrote:
[color=blue]
>On Tue, 13 Apr 2004 20:29:19 -0700, Mark Johnson
><102334.12@compuserve.com> wrote:[/color]
[color=blue][color=green]
>> "Note that the French "msg1" and the English "msg1" may not appear in
>> the same document since they share the same id value. Authors may make
>> further use of the id attribute to refine the presentation of
>> individual messages, make them target anchors, etc."[/color][/color]
[color=blue][color=green]
>> Etc? And whether or not they'd wish it, politics aside, the very
>> example, above, suggests it's in the very self-same document. What the
>> authors of these mean, and what they write, are often not the same.
>> They can be very specific, even pedantic, in explaining things on ngs.
>> I've seen that in other areas. But the documents tend to be almost
>> written in a shorthand, with much consistency and detail omitted.[/color][/color]
[color=blue]
>In this case, I'd look at the example as faulted, and instead hold to the
>basic concept of only one instance of id="foo" in a single document.[/color]

They could stand to clarify and rewrite most of their documents. And
documents is basically all W3C does, really. Here's a counter-example,
though:

http://www.fiendish.demon.co.uk/html...tablecols.html

Neal <neal413@spamrcn.com> wrote:
[color=blue]
>On Tue, 13 Apr 2004 20:29:19 -0700, Mark Johnson
><102334.12@compuserve.com> wrote:[/color]
[color=blue][color=green]
>> "Note that the French "msg1" and the English "msg1" may not appear in
>> the same document since they share the same id value. Authors may make
>> further use of the id attribute to refine the presentation of
>> individual messages, make them target anchors, etc."[/color][/color]
[color=blue][color=green]
>> Etc? And whether or not they'd wish it, politics aside, the very
>> example, above, suggests it's in the very self-same document. What the
>> authors of these mean, and what they write, are often not the same.
>> They can be very specific, even pedantic, in explaining things on ngs.
>> I've seen that in other areas. But the documents tend to be almost
>> written in a shorthand, with much consistency and detail omitted.[/color][/color]
[color=blue]
>In this case, I'd look at the example as faulted, and instead hold to the
>basic concept of only one instance of id="foo" in a single document.[/color]

They could stand to clarify and rewrite most of their documents. And
documents is basically all W3C does, really. Here's a counter-example,
though:

http://www.fiendish.demon.co.uk/html...tablecols.html

Mark Johnson <102334.12@compuserve.com> wrote:[color=blue]
>Neal <neal413@spamrcn.com> wrote:
>[color=green]
>>In this case, I'd look at the example as faulted, and instead hold to the
>>basic concept of only one instance of id="foo" in a single document.[/color]
>
>They could stand to clarify and rewrite most of their documents. And
>documents is basically all W3C does, really. Here's a counter-example,
>though:
>
>http://www.fiendish.demon.co.uk/html...tablecols.html[/color]

Of course in browsers that implement the DOM correctly the ids in that
example aren't needed at all. It uses getElementsByName() which
references elements by their name not by their id. If you strip out
all the id attributes then the script still works in Mozilla, but IE
and Opera have worse DOM support and need the ids for some reason.

Conversely, IE works just fine when the names are removed leaving just
the ids. Which means that the statement on the page "Both the id and
name attributes are required so that DOM compliant browsers and IE5
can find the table cells via the DOM. The name attribute is used by
IE5." is arse about tit. IE (5 and 6) need the ids whilst DOM
compliant browsers only need the names.

For Opera things are screwed up nicely by the
if (document.all) showMode='block';
statement that was intended only for IE. Opera 7 understands
document.all (and earlier versions of Opera pretended to understand it
but didn't) and understands what display block really means for a <td>
element.

Anyway, I digress but I guess it shows that examples stating the
opposite of the W3C specs are no more immune from bad wording and
errors than the specs themselves. ;-)

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

Mark Johnson <102334.12@compuserve.com> wrote:[color=blue]
>Neal <neal413@spamrcn.com> wrote:
>[color=green]
>>In this case, I'd look at the example as faulted, and instead hold to the
>>basic concept of only one instance of id="foo" in a single document.[/color]
>
>They could stand to clarify and rewrite most of their documents. And
>documents is basically all W3C does, really. Here's a counter-example,
>though:
>
>http://www.fiendish.demon.co.uk/html...tablecols.html[/color]

Of course in browsers that implement the DOM correctly the ids in that
example aren't needed at all. It uses getElementsByName() which
references elements by their name not by their id. If you strip out
all the id attributes then the script still works in Mozilla, but IE
and Opera have worse DOM support and need the ids for some reason.

Conversely, IE works just fine when the names are removed leaving just
the ids. Which means that the statement on the page "Both the id and
name attributes are required so that DOM compliant browsers and IE5
can find the table cells via the DOM. The name attribute is used by
IE5." is arse about tit. IE (5 and 6) need the ids whilst DOM
compliant browsers only need the names.

For Opera things are screwed up nicely by the
if (document.all) showMode='block';
statement that was intended only for IE. Opera 7 understands
document.all (and earlier versions of Opera pretended to understand it
but didn't) and understands what display block really means for a <td>
element.

Anyway, I digress but I guess it shows that examples stating the
opposite of the W3C specs are no more immune from bad wording and
errors than the specs themselves. ;-)

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

On Wed, 14 Apr 2004 21:25:14 +0100, "Alan J. Flavell"
<flavell@ph.gla.ac.uk> wrote:
[color=blue]
>On Wed, 14 Apr 2004, Brian wrote:
>[color=green]
>> IE(*/Win*)'s programmers don't have much faith in its HTML abilities, if
>> one takes its accept headers seriously. Content-type text/html is
>> conspicuously absent from the types it will accept.[/color]
>
>Yup, if you do content-type negotiation on the server, IE will get
>sent MS-Word format for preference, because it says that's what it
>prefers (well, I suppose you'd need Office installed too, for that to
>apply - but that's standard around here).[/color]

Well, a default setting, remember the accept header is easily
configurable, unlike the mozilla authors who also chose a ridiculous
default, but don't let you change that without a re-compile.

Accept headers are pretty broken all round, unfortunately.
[color=blue][color=green]
>> In any case, IE/Win's comformance is worst at the http level.[/color]
>
>How true, how sadly true.[/color]

The same is true about FireFox and Opera too though (both violating
text/plain), http conformance has failed.

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

On Wed, 14 Apr 2004 21:25:14 +0100, "Alan J. Flavell"
<flavell@ph.gla.ac.uk> wrote:
[color=blue]
>On Wed, 14 Apr 2004, Brian wrote:
>[color=green]
>> IE(*/Win*)'s programmers don't have much faith in its HTML abilities, if
>> one takes its accept headers seriously. Content-type text/html is
>> conspicuously absent from the types it will accept.[/color]
>
>Yup, if you do content-type negotiation on the server, IE will get
>sent MS-Word format for preference, because it says that's what it
>prefers (well, I suppose you'd need Office installed too, for that to
>apply - but that's standard around here).[/color]

Well, a default setting, remember the accept header is easily
configurable, unlike the mozilla authors who also chose a ridiculous
default, but don't let you change that without a re-compile.

Accept headers are pretty broken all round, unfortunately.
[color=blue][color=green]
>> In any case, IE/Win's comformance is worst at the http level.[/color]
>
>How true, how sadly true.[/color]

The same is true about FireFox and Opera too though (both violating
text/plain), http conformance has failed.

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

[this is now decidely off-topic for ciwas, but I am not sure where to
redirect followups; perhaps ciwa.site-design?]

Jim Ley wrote:
[color=blue]
> On Wed, 14 Apr 2004, Alan J. Flavell wrote:
>[color=green]
>> On Wed, 14 Apr 2004, Brian wrote:
>>[color=darkred]
>>> IE(*/Win*)'s programmers don't have much faith in its HTML
>>> abilities, if one takes its accept headers seriously.
>>> Content-type text/html is conspicuously absent from the types it
>>> will accept.[/color]
>>
>> Yup, if you do content-type negotiation on the server, IE will get
>> sent MS-Word format for preference, because it says that's what it
>> prefers (well, I suppose you'd need Office installed too, for that
>> to apply - but that's standard around here).[/color]
>
> Well, a default setting,[/color]

It's rather strange to have a default setting in a web browser which
does not list text/html as an acceptable content type.

127.0.0.1 - - [17/Apr/2004:14:20:34 -0400] "GET / HTTP/1.1" 200 1899
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" "image/gif,
image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint,
application/vnd.ms-excel, application/msword, */*"

In fact, not a single markup variant is specifically deemed acceptable.
MSIE advertises that it wants a bitmap before any text variant. And on
reload, we see:

127.0.0.1 - - [17/Apr/2004:14:20:37 -0400] "GET / HTTP/1.1" 304 0
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" "*/*"

Why does the accept header change on reload?
[color=blue]
> remember the accept header is easily configurable,[/color]

Is it? I cannot find it for IE, including under tools > internet
options. It appears to be only configurable via Windows register. If
true, then it is anything but easy to configure. And can one change the
reload (or "refresh," as MSIE's button reads) accept header, too?
[color=blue]
> unlike the mozilla authors who also chose a ridiculous default[/color]

127.0.0.1 - - [17/Apr/2004:14:24:33 -0400] "GET / HTTP/1.1" 200 1171
"Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113"
"text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1"

I don't see what is "rediculous" about this. It asks first for for xml,
xhtml, and html, with equal wait for them. That seems a pretty logical
choice for a web browser. Compare that to the following:
[color=blue]
> but don't let you change that without a re-compile.[/color]

Wrong. Try typing about:config in the location bar, and look for
network.http.accept.default

*Far* easier than editing the Windows registry, don't you think?
[color=blue]
> Accept headers are pretty broken all round, unfortunately.[/color]

Explain what is broken about Mozilla's? There may be something I'm missing.
[color=blue][color=green][color=darkred]
>>> IE/Win's comformance is worst at the http level.[/color][/color]
>
> The same is true about FireFox and Opera too though (both violating
> text/plain), http conformance has failed.[/color]

Would you mind explaining this?

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[this is now decidely off-topic for ciwas, but I am not sure where to
redirect followups; perhaps ciwa.site-design?]

Jim Ley wrote:
[color=blue]
> On Wed, 14 Apr 2004, Alan J. Flavell wrote:
>[color=green]
>> On Wed, 14 Apr 2004, Brian wrote:
>>[color=darkred]
>>> IE(*/Win*)'s programmers don't have much faith in its HTML
>>> abilities, if one takes its accept headers seriously.
>>> Content-type text/html is conspicuously absent from the types it
>>> will accept.[/color]
>>
>> Yup, if you do content-type negotiation on the server, IE will get
>> sent MS-Word format for preference, because it says that's what it
>> prefers (well, I suppose you'd need Office installed too, for that
>> to apply - but that's standard around here).[/color]
>
> Well, a default setting,[/color]

It's rather strange to have a default setting in a web browser which
does not list text/html as an acceptable content type.

127.0.0.1 - - [17/Apr/2004:14:20:34 -0400] "GET / HTTP/1.1" 200 1899
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" "image/gif,
image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint,
application/vnd.ms-excel, application/msword, */*"

In fact, not a single markup variant is specifically deemed acceptable.
MSIE advertises that it wants a bitmap before any text variant. And on
reload, we see:

127.0.0.1 - - [17/Apr/2004:14:20:37 -0400] "GET / HTTP/1.1" 304 0
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" "*/*"

Why does the accept header change on reload?
[color=blue]
> remember the accept header is easily configurable,[/color]

Is it? I cannot find it for IE, including under tools > internet
options. It appears to be only configurable via Windows register. If
true, then it is anything but easy to configure. And can one change the
reload (or "refresh," as MSIE's button reads) accept header, too?
[color=blue]
> unlike the mozilla authors who also chose a ridiculous default[/color]

127.0.0.1 - - [17/Apr/2004:14:24:33 -0400] "GET / HTTP/1.1" 200 1171
"Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113"
"text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1"

I don't see what is "rediculous" about this. It asks first for for xml,
xhtml, and html, with equal wait for them. That seems a pretty logical
choice for a web browser. Compare that to the following:
[color=blue]
> but don't let you change that without a re-compile.[/color]

Wrong. Try typing about:config in the location bar, and look for
network.http.accept.default

*Far* easier than editing the Windows registry, don't you think?
[color=blue]
> Accept headers are pretty broken all round, unfortunately.[/color]

Explain what is broken about Mozilla's? There may be something I'm missing.
[color=blue][color=green][color=darkred]
>>> IE/Win's comformance is worst at the http level.[/color][/color]
>
> The same is true about FireFox and Opera too though (both violating
> text/plain), http conformance has failed.[/color]

Would you mind explaining this?

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

On Sat, 17 Apr 2004 14:45:04 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
>It's rather strange to have a default setting in a web browser which
>does not list text/html as an acceptable content type.[/color]

Sure it is (hence why I said this whole area had failed) it's just as
odd to prefer content of unknown semantics to content of known
semantics as Mozillla does.
[color=blue][color=green]
>> remember the accept header is easily configurable,[/color]
>
>Is it? I cannot find it for IE, including under tools > internet
>options. It appears to be only configurable via Windows register.[/color]

Yes, which is simple to use, and is how all IE configuration is done.
[color=blue]
>I don't see what is "rediculous" about this. It asks first for for xml,
>xhtml, and html, with equal wait for them. That seems a pretty logical
>choice for a web browser. Compare that to the following:[/color]

Nope, text/xml above text/html is ridicuolous, I've got some XML here,
it's better quality than the HTML version, but as it uses semantics
Mozilla doesn't understand, why does Mozilla say it prefers it - it's
ridiculous.
[color=blue][color=green][color=darkred]
>>>> IE/Win's comformance is worst at the http level.[/color]
>>
>> The same is true about FireFox and Opera too though (both violating
>> text/plain), http conformance has failed.[/color]
>
>Would you mind explaining this?[/color]

See:

http://www.mozilla.org/products/firefox/releases/

Better Handling of File Types
Binary files (e.g. .wma and .rar files) served by servers incorrectly
sending text/plain should no longer be displayed as garbage in the
browser, rather they should be appropriately handled.

The text/plain header is sniffed for content and passed to other
applications rather than being displayed by the user. The exact HTTP
violation that IE has always had, Firefox is just as broken.

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

On Sat, 17 Apr 2004 14:45:04 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
>It's rather strange to have a default setting in a web browser which
>does not list text/html as an acceptable content type.[/color]

Sure it is (hence why I said this whole area had failed) it's just as
odd to prefer content of unknown semantics to content of known
semantics as Mozillla does.
[color=blue][color=green]
>> remember the accept header is easily configurable,[/color]
>
>Is it? I cannot find it for IE, including under tools > internet
>options. It appears to be only configurable via Windows register.[/color]

Yes, which is simple to use, and is how all IE configuration is done.
[color=blue]
>I don't see what is "rediculous" about this. It asks first for for xml,
>xhtml, and html, with equal wait for them. That seems a pretty logical
>choice for a web browser. Compare that to the following:[/color]

Nope, text/xml above text/html is ridicuolous, I've got some XML here,
it's better quality than the HTML version, but as it uses semantics
Mozilla doesn't understand, why does Mozilla say it prefers it - it's
ridiculous.
[color=blue][color=green][color=darkred]
>>>> IE/Win's comformance is worst at the http level.[/color]
>>
>> The same is true about FireFox and Opera too though (both violating
>> text/plain), http conformance has failed.[/color]
>
>Would you mind explaining this?[/color]

See:

http://www.mozilla.org/products/firefox/releases/

Better Handling of File Types
Binary files (e.g. .wma and .rar files) served by servers incorrectly
sending text/plain should no longer be displayed as garbage in the
browser, rather they should be appropriately handled.

The text/plain header is sniffed for content and passed to other
applications rather than being displayed by the user. The exact HTTP
violation that IE has always had, Firefox is just as broken.

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

On Sat, 17 Apr 2004, Brian wrote:
[color=blue]
> [this is now decidely off-topic for ciwas, but I am not sure where to
> redirect followups;[/color]

neither am I, so...
[color=blue]
> Jim Ley wrote:
>[color=green]
> > remember the accept header is easily configurable,[/color]
>
> Is it?[/color]

I -think- Jim is saying that someone who knows how it's done could
provide a user interface for doing it easily....
[color=blue][color=green][color=darkred]
> >>> IE/Win's comformance is worst at the http level.[/color]
> >
> > The same is true about FireFox and Opera too though (both violating
> > text/plain), http conformance has failed.[/color]
>
> Would you mind explaining this?[/color]

Opera, for one, has an option for guessing at the content type of a
resource i.e ignoring what the server said it was (and in their case
guessing by reference to the filename extension, which is of course a
different misbehaviour than the one in IE).

This kind of behaviour is forbidden by RFC2616, and has security
implications. Worse, this option comes enabled by default in Opera,
which might seem to be attractive for those who are unfit to run a web
server. So those misguided authors who are inclined to do nothing
more than verify their site with their favourite browser are
propagating this broken behaviour yet further. Jim evidently thinks
the battle has already been lost.

Opera does at least have the possibility to turn that off and make
the browser conform with the RFC, but the very authors who would need
to do that are the ones who don't know about it.

My interpretation of rfc2616 is that the very furthest that a browser
would be permitted to go down this path is to report explicitly to the
user that the server-provided content type appears to be in error,
warn them that this might be a security exposure, and then offer some
kind of fixup option *with the informed consent of the user*. Going
behind the user's back and fixing-up a broken server response by
stealth is risky, which is one of the reasons that RFC2616 says what
it does.

On Sat, 17 Apr 2004, Brian wrote:
[color=blue]
> [this is now decidely off-topic for ciwas, but I am not sure where to
> redirect followups;[/color]

neither am I, so...
[color=blue]
> Jim Ley wrote:
>[color=green]
> > remember the accept header is easily configurable,[/color]
>
> Is it?[/color]

I -think- Jim is saying that someone who knows how it's done could
provide a user interface for doing it easily....
[color=blue][color=green][color=darkred]
> >>> IE/Win's comformance is worst at the http level.[/color]
> >
> > The same is true about FireFox and Opera too though (both violating
> > text/plain), http conformance has failed.[/color]
>
> Would you mind explaining this?[/color]

Opera, for one, has an option for guessing at the content type of a
resource i.e ignoring what the server said it was (and in their case
guessing by reference to the filename extension, which is of course a
different misbehaviour than the one in IE).

This kind of behaviour is forbidden by RFC2616, and has security
implications. Worse, this option comes enabled by default in Opera,
which might seem to be attractive for those who are unfit to run a web
server. So those misguided authors who are inclined to do nothing
more than verify their site with their favourite browser are
propagating this broken behaviour yet further. Jim evidently thinks
the battle has already been lost.

Opera does at least have the possibility to turn that off and make
the browser conform with the RFC, but the very authors who would need
to do that are the ones who don't know about it.

My interpretation of rfc2616 is that the very furthest that a browser
would be permitted to go down this path is to report explicitly to the
user that the server-provided content type appears to be in error,
warn them that this might be a security exposure, and then offer some
kind of fixup option *with the informed consent of the user*. Going
behind the user's back and fixing-up a broken server response by
stealth is risky, which is one of the reasons that RFC2616 says what
it does.

'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

re: 'div id' vs 'div class'

Similar HTML / CSS bytes

/bytes/development

/bytes/it

/bytes/about