Controlling web browsers with META

[Arne]

Hope this is a proper group for this post :)

I came across this page about META tags that control browsers.
http://www.bauser.com/websnob/meta/browsers.html

Some I know, some I wonder about and would like an opinion on.

For example, the author claims that http-equiv="Content-Style-Type"
and http-equiv="Content-Script-Type" is a echnically "must" to use if
you are using "intrinsic events attributes (like onload or onclick)"
and "if you're using the style attribute to add styles to individual
HTML elements".

There is references only to HTML 4.0 and I wonder if those "must" is
still (if it ever was) a "must"? I can't recall that I ever seen any
page with those META tags.

I'm also interested in the http-equiv="Window-target" META mentioned
on the bottom of the page. I had no knowledge about it before, but it
seems like a good tag to use if it works. But as I understand it only
works on Netscape, maybee not even in the latest versions?

TIA

--
/Arne

[Brian]

Arne wrote:

the author claims that http-equiv="Content-Style-Type"
and http-equiv="Content-Script-Type" is a echnically "must" to use if
you are using "intrinsic events attributes (like onload or onclick)"
Correct, according to the HTML spec. It is thus formally required. I
doubt that it has any practical implications.
and "if you're using the style attribute to add styles to individual
HTML elements".
I think this is also correct, but I'd have to check to make sure. It is
consistent with the script-type mandate.
I'm also interested in the http-equiv="Window-target" META mentioned
on the bottom of the page.

What is that supposed to do? Instruct the ua to open all links in a
certain target, I imagine. Sounds like a bad idea.

--
Brian

[djn]

Arne wrote:

http://www.bauser.com/websnob/meta/browsers.html

There is references only to HTML 4.0 and I wonder if those "must" is
still (if it ever was) a "must"? I can't recall that I ever seen any
page with those META tags.

Actually the 4.01 specs say 'should', meaning that you have to do it
unless you have a solid reason not to.

'Authors should specify the default scripting language for all scripts
in a document by including the following META declaration in the HEAD'
(http://www.w3.org/TR/html4/interact/...default-script)

'Authors should use the META element to set the default style sheet
language for a document.'
(http://www.w3.org/TR/html4/present/s...#default-style)

[Stephen Poley]

On Sat, 22 Jan 2005 01:09:38 GMT, djn <de***@kozina.com> wrote:

Arne wrote:

http://www.bauser.com/websnob/meta/browsers.html

There is references only to HTML 4.0 and I wonder if those "must" is
still (if it ever was) a "must"? I can't recall that I ever seen any
page with those META tags.

Actually the 4.01 specs say 'should', meaning that you have to do it
unless you have a solid reason not to.

'Authors should specify the default scripting language for all scripts
in a document by including the following META declaration in the HEAD'
(http://www.w3.org/TR/html4/interact/...default-script)

'Authors should use the META element to set the default style sheet
language for a document.'
(http://www.w3.org/TR/html4/present/s...#default-style)

Curious. That makes the following pretty silly (18.2.1):

type = content-type [CI]
This attribute specifies the scripting language of the element's
contents and overrides the default scripting language. The
scripting
language is specified as a content type (e.g., "text/javascript").
Authors must supply a value for this attribute. There is no default
value for this attribute.

Why say that one should specify a default language and then state that
you must override it? It looks very much like a classic committee
decision.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[Arne]

Once upon a time *Brian* wrote:

Arne wrote:

the author claims that http-equiv="Content-Style-Type"
and http-equiv="Content-Script-Type" is a echnically "must" to use if
you are using "intrinsic events attributes (like onload or onclick)"

Correct, according to the HTML spec. It is thus formally required. I
doubt that it has any practical implications.

That was my thought also, for the reason that the W3C validator don't
complain when there is no sutch META on a page.

and "if you're using the style attribute to add styles to individual
HTML elements".

I think this is also correct, but I'd have to check to make sure. It is
consistent with the script-type mandate.

I'm also interested in the http-equiv="Window-target" META mentioned
on the bottom of the page.

What is that supposed to do? Instruct the ua to open all links in a
certain target, I imagine. Sounds like a bad idea.

As it says on the page I was refering to:

"The Window-target value tells Netscape Navigator that the tagged page
must be loaded in the frame stated in the content attribute. This is
useful, for example, in preventing a page from being framed (by
setting content to _top). Navigator is the only browser that
implements this function of META"

As I see many sites that use frameset load even external pages within
their own frames, it could be useful to prevent sutch bad behaviour.

--
/Arne
http://web.telia.com/~u97802964/

If you owe the bank a million, you have a problem.
If you owe the bank ten million, the bank has a problem! (Unknown)

[Nick Kew]

djn wrote:

Actually the 4.01 specs say 'should', meaning that you have to do it
unless you have a solid reason not to.

Well that's a good escape clause for everyone then. The sheer idiocy
of specifying an "http-equiv" for something HTTP would never recognise
seems ample reason to me. Especially in the absence of real-life
browsers so clueless as to care about it.

--
Nick Kew

[Henri Sivonen]

In article <PF*******************@newsb.telia.net>,
Arne <us**@domain.invalid> wrote:

That was my thought also, for the reason that the W3C validator don't
complain when there is no sutch META on a page.

The W3C Validator does not care about spec prose. It cares about the DTD
formalism which is inadequate for assessing full spec conformance.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Arne]

Once upon a time *Henri Sivonen* wrote:

In article <PF*******************@newsb.telia.net>,
Arne <us**@domain.invalid> wrote:

That was my thought also, for the reason that the W3C validator don't
complain when there is no sutch META on a page.

The W3C Validator does not care about spec prose. It cares about the DTD
formalism which is inadequate for assessing full spec conformance.

It cares about a missing http-equiv for charset, but that's the only
one I'll guess :)
--
/Arne

[Dan]

Arne wrote:

Once upon a time *Henri Sivonen* wrote:

The W3C Validator does not care about spec prose. It cares about the DTD formalism which is inadequate for assessing full spec conformance.

It cares about a missing http-equiv for charset, but that's the only
one I'll guess :)

That parameter is best given in an actual HTTP header supplied by the
server, rather than a cheap plastic substitute via META tags.

--
Dan

[Dan]

Arne wrote:

For example, the author claims that http-equiv="Content-Style-Type"
and http-equiv="Content-Script-Type" is a echnically "must" to use if
you are using "intrinsic events attributes (like onload or onclick)"
and "if you're using the style attribute to add styles to individual
HTML elements".

Logically speaking, in the absence of these tags, there's nothing
indicating in what language any style="..." and onclick="..." (etc.)
attributes are in, though there is a tradition that they're in CSS and
JavaScript respectively.

--
Dan

[Alan J. Flavell]

On Sat, 22 Jan 2005, Arne wrote:

Once upon a time *Henri Sivonen* wrote:

In article <PF*******************@newsb.telia.net>,
Arne <us**@domain.invalid> wrote:

That was my thought also, for the reason that the W3C validator don't
complain when there is no sutch META on a page.
The W3C Validator does not care about spec prose. It cares about
the DTD formalism
Right
which is inadequate for assessing full spec conformance.

Just so, The term "validation" has a specialised meaning in SGML
contexts, and should not be confused with all kinds of other
conformance detail.
It cares about a missing http-equiv for charset, but that's the only
one I'll guess :)

Now you're seriously confusing the issue. The validator can't even
start its work without a specification (or assumption) about the
character encoding of the document that it's attempting to validate.
There are several ways to supply that to an HTML validator (via a real
HTTP header; via a meta http-equiv; manually via the user interface to
the validator). (And it's analogous, with some differences, for
XHTML).

This doesn't at all mean that the syntax demands the presence of some
specific meta http-equiv (it demands *no such thing*); but rather,
it's about some pre-requisites which need to be satisfied before the
validation can be started at all.

[Arne]

Once upon a time *Dan* wrote:

Arne wrote:

Once upon a time *Henri Sivonen* wrote:

> The W3C Validator does not care about spec prose. It cares about the DTD > formalism which is inadequate for assessing full spec conformance.

It cares about a missing http-equiv for charset, but that's the only
one I'll guess :)

That parameter is best given in an actual HTTP header supplied by the
server, rather than a cheap plastic substitute via META tags.

What is best is not always possible for everybody, and calling it
"cheap plastic substitute" is easy for someone who have and can
everything. Still, it's better than not have it at all as is the case
in millions of pages.

The problem is that most(?) servers don't give that information with
the header. And most(?) people can't or don't have the access to do
that on the server. I have yet to see (as I recall) a page where this
parameter is missing as http-equiv META in the page, and still
validates because the validator gets the information from the header.

This is of cause my personal experience, and you have probably a
different experience :)

--
/Arne

[Alan J. Flavell]

On Sat, 22 Jan 2005, Arne wrote:

The problem is that most(?) servers don't give that information with
the header.
According to CA-2000-02, that *is* indeed a problem - a *security*
problem. And newer versions of Apache have been putting in some
effort to ensure that the relevant content-types don't get sent out
without an explicit charset specification on their real HTTP header.

And as those updated versions of Apache percolate through, I suspect
you're going to increasingly see an HTTP charset sent out. After
which, you can fiddle with meta http-equiv headers in your HTML till
you're blue in the face, but it won't make a damned bit of difference
to conforming HTTP user agents, since they're mandated to give
priority to the *real* HTTP header.
And most(?) people can't or don't have the access to do
that on the server.
I keep hearing this; but, setting of an appropriate charset value on
the real HTTP header is a fundamental technical requirement for
serious publication on the web.
I have yet to see (as I recall) a page where this parameter is
missing as http-equiv META in the page, and still validates because
the validator gets the information from the header.
Whether you've seen it or not, the real HTTP header *does* work.

If your service provider decides to send out a fixed charset of (say)
iso-8859-1 (or charset=utf-8, whatever they choose) and don't let you
change it, well then, you'll just have to code your page to the
charset which they send out - it's as simple as that.

If they /don't/ send out any charset, then they can be accused of
failing to apply the security guidelines of CA-2000-02. Quite
possibly, someone will find out how to exploit that weakness - and
then, browsers might get security-fixed so that they refuse to work
with documents which lack an HTTP-specified charset (just as MSIE has
recently been fixed in respect of some of its previous misbehaviour
with documents sent as text/plain). And then where will you folks be?

It really is much better to do the job properly from the start, than
to keep applying hansaplast over elastoplast over duct tape...
This is of cause my personal experience, and you have probably a
different experience :)

In *theory* (if you read the early web design documents), it was
anticipated that servers would parse the meta http-equiv markup from
the HTML, and use it to influence the real HTTP headers used for
sending the document out. But in practice that hasn't happened, at
least not to a sufficient extent to be able to rely on it. I could
offer an explanation why that's so - but whatever the explanation, the
end result is what it is - for proper publication of web pages, in
general, one /needs/ the ability to do this amount of configuration of
the real HTTP headers - whether by server configuration (e.g
..htaccess), by server-side scripting (.php or .asp as the case may
be), whatever.

If your service provider short-changes you on that, then you'd be
entitled to complain loudly. But if you want to stay with the
limitations of functionality that they're offering, then you're just
going to have to live with the limitations which that brings in terms
of what you can achieve. Trying to overcome the limitations with
kludges doesn't make for a well-engineered web. You're going to have
analogous problems with getting any meaningful control of
cacheability, too (Mark Nottingham's tutorial applies).

[Dan]

Arne wrote:

The problem is that most(?) servers don't give that information with
the header. And most(?) people can't or don't have the access to do
that on the server. I have yet to see (as I recall) a page where this
parameter is missing as http-equiv META in the page, and still
validates because the validator gets the information from the header.

Try my pages:
http://www.dan.info/
http://webtips.dan.info/
http://domains.dan.info/
http://mailformat.dan.info/
http://dan.tobias.name/

All of them have proper HTTP headers, no superfluous http-equiv METAs,
and validate. (Yeah, for all the purists out there, it *is* HTML 4.01
Transitional, not Strict, and I *do* still use tables for layout... the
current design is a few years old and I still cared about it looking
good in Netscape 4.x back then... the next redesign, whenever I get
around to it, will change a lot.)

--
Dan