Re: Browser variations in a "stretchy" CSS design

> This is a valid HTML comment (from <!-- to -->) so I can't see an

HTML doesn't actually have comments.  It's a valid SGML directive with
a null name and a comment, provided that there are no runs of -s in the
text which are not exactly a multiple of four in length (end comment,
immediately followed by begin comment).  Actually odd length runs can
be rounded down to a multiple of two in deciding the above.  A common
way of breaking comments is to do rules like this unterminated one:

<!------------------------------------------------------------------------->

> _accessibility_ reason why it may be a problem. There may be problems with

A number of browsers have historically not parsed comments properly.  Lynx
has three different ways of parsing them:  one  for SGML conforming comments
and two for different styles of broken parsing.  People are quite likely
to use Lynx in one of the broken modes, because it is more likely to
work on the real web.

> 
> <![If IE5]>
>  All browsers will get this (including markup) _except IE5_
> <![ENDIF]>

A more correct way of doing this would have been:

<![%IgnoreIfIE5;[
SGML conditional section that is ignored by an SGML parser if 
%IgnoreIfIE5 is defined as IGNORE.
]]>

which is why this whole hack is aesthetically so horrible; there is a
already a conditional sections features in SGML, but HTML was intended
to be simple, so such features wouldn't be needed, which is why early
browsers didn't implement it.  (Note I'm not sure if it is OK to have
an empty keyword or undefined entity.**)

I can't help but feel that if you need to use this sort of tactic you
have lost sight of the purpose of HTML and really need a page 
description language.

Obviously one can't use the proper SGML syntax for the %IncludeIfIE5;
case, but I'm not convinced one should be trying to emulate conditionals,
anyway.

Note I would expect the "If IE5" structure to fail validation.  I haven't 
tried the conditional section with no keyword on the validator.

(Lynx's broken comment modes are:

1)  to treat ">" as an unconditional delimiter (oops!); 
2)  to treat "-->" as an unconditional delimiter.

(1) is off by default.  (2) is off in the compiled code, but on, for
NS compatibility, in the default configuration file of the version I have.)

** As the first definition wins, I believe there is a way round this by
defining defaults yourself.

Received on Friday, 27 June 2003 17:40:17 UTC