Welcome to WebmasterWorld Guest from 22.214.171.124
Forum Moderators: incrediBILL
But, from the beginning, Netscape and MSIE did not fully accommodate this rule. Most of the time it's just a little annoyance -- most website visitors don't even notice it. And, to be fair, many of these bugs have been worked out in the most recent versions of MSIE. But if you use Netscape, code that looks like this:
This can become a very big deal if you're slicing up graphics and fitting the pieces together on the page.
There are also other code combinations that display an extra space where none should be rendered, and I've not been able to fully come to grips with this. Sometimes I've yet to discover a workaround.
I have one live page on a client site that shows a small sliver between two pieces of graphic -- and I am embarrassed by that. I've minimized the effect with some bgcolor, but in Netscape, it's still there and I know it.
Can anyone shed further light on this little but persistent issue? And why, after all these years and versions, does Netscape still screw it up?
Hmm, not a bug.
The first return encountered is decoded as a space. That is in the 3.2 spec. So the return before the </u> is the problem child.
(btw: old rule of thumb: never under any circumstances except penalty of law should you use an underline tag). Underlines are reserved for links and it confuses people. There was a study done by UIE(?) that showed pages that have underlines on them that are not links are less productive (people leave the site).
The SGML rules for record boundaries are tricky. In particular, a record end immediately following a start tag should be discarded. For example:
is equivalent to:
Similarly, a record end immediately preceding an end tag should be discarded. For example:
is equivalent to:
Except within literal text (e.g. the PRE element), HTML treats contiguous sequences of white space characters as being equivalent to a single space character (ASCII decimal 32). These rules allow authors considerable flexibility when editing the marked-up text directly. Note that future revisions to HTML may allow for the interpretation of the horizontal tab character (ASCII decimal 9) with respect to a tab rule defined by an associated style sheet.