XHTML bug? Transitional/Strict Rendering Issues

Discussion in 'HTML' started by Dave Winter, Apr 26, 2004.

  1. Dave Winter

    Dave Winter Guest

    Hi,

    After smashing my head against the table a few times, I finally was
    able to fix a bug that was causing my site to render incorrectly in all
    browsers.

    An hour ago, I had just finished my conversion from HTML to XHTML/CSS
    Transitional, the site was validating perfectly. So, as it was doing
    this, I thought I'd try it out as XHTML Strict. So I changed the
    doctype in the file and then validated it. Validated fine as XHTML
    Strict. However! Then I noticed it was rendering differently. These
    weird line spaces were appearing in weird places. They hadn't been. So
    I assumed I'd editting something accidently in the CSS file. Checked
    the CSS file, nothing weird in there.

    Hit my head against the table for the first time.

    What had I changed recently? The doctype! From Transitional to Strict.

    So I changed it back from Strict to Transitional.

    Hit my head against the table for the second time.

    The site was rendering correcltly! What the heck?!

    Transitional: http://www.commanderbond.net/xhtml/
    Strict: http://www.commanderbond.net/xhtml_s/

    The only difference between these two versions are the doctypes.
    Nothing else is different.

    What the hell is going on?

    Really appreciate any help of advice.

    Cheers,

    Dave Winter.
    Dave Winter, Apr 26, 2004
    #1
    1. Advertising

  2. Dave Winter

    Dave Winter Guest

    Just to be clear on what exacly doesn't work for me:

    There is a space beneath the top most header graphic.
    There is also a space above the left and right columns. Above the
    images ("General" and "Search CBn")

    I've made the backgrounds bright red so it's clear to see the issue.

    Dave.

    On 2004-04-26 11:03:45 +0100, Dave Winter <> said:

    > Hi,
    >
    > After smashing my head against the table a few times, I finally was
    > able to fix a bug that was causing my site to render incorrectly in all
    > browsers.
    >
    > An hour ago, I had just finished my conversion from HTML to XHTML/CSS
    > Transitional, the site was validating perfectly. So, as it was doing
    > this, I thought I'd try it out as XHTML Strict. So I changed the
    > doctype in the file and then validated it. Validated fine as XHTML
    > Strict. However! Then I noticed it was rendering differently. These
    > weird line spaces were appearing in weird places. They hadn't been. So
    > I assumed I'd editting something accidently in the CSS file. Checked
    > the CSS file, nothing weird in there.
    >
    > Hit my head against the table for the first time.
    >
    > What had I changed recently? The doctype! From Transitional to Strict.
    >
    > So I changed it back from Strict to Transitional.
    >
    > Hit my head against the table for the second time.
    >
    > The site was rendering correcltly! What the heck?!
    >
    > Transitional: http://www.commanderbond.net/xhtml/
    > Strict: http://www.commanderbond.net/xhtml_s/
    >
    > The only difference between these two versions are the doctypes.
    > Nothing else is different.
    >
    > What the hell is going on?
    >
    > Really appreciate any help of advice.
    >
    > Cheers,
    >
    > Dave Winter.
    Dave Winter, Apr 26, 2004
    #2
    1. Advertising

  3. Dave Winter

    SpaceGirl Guest

    "Dave Winter" <> wrote in message
    news:2004042611034516807%davewinter@maccom...
    > Hi,
    >
    > After smashing my head against the table a few times, I finally was
    > able to fix a bug that was causing my site to render incorrectly in all
    > browsers.
    >
    > An hour ago, I had just finished my conversion from HTML to XHTML/CSS
    > Transitional, the site was validating perfectly. So, as it was doing
    > this, I thought I'd try it out as XHTML Strict. So I changed the
    > doctype in the file and then validated it. Validated fine as XHTML
    > Strict. However! Then I noticed it was rendering differently. These
    > weird line spaces were appearing in weird places. They hadn't been. So
    > I assumed I'd editting something accidently in the CSS file. Checked
    > the CSS file, nothing weird in there.
    >
    > Hit my head against the table for the first time.
    >
    > What had I changed recently? The doctype! From Transitional to Strict.
    >
    > So I changed it back from Strict to Transitional.
    >
    > Hit my head against the table for the second time.
    >
    > The site was rendering correcltly! What the heck?!
    >
    > Transitional: http://www.commanderbond.net/xhtml/
    > Strict: http://www.commanderbond.net/xhtml_s/
    >
    > The only difference between these two versions are the doctypes.
    > Nothing else is different.
    >
    > What the hell is going on?
    >
    > Really appreciate any help of advice.
    >
    > Cheers,
    >
    > Dave Winter.


    Both versions looked identical to me in IE6. Which is ironic, considering
    IE6 *does* have some serious XML/XHTML rendering bugs (they are fairly
    random, but are affected completely by the doctype). Generally IE renders
    XHTML *better* if you set the doctype to HTML4 Transitional. Which is just
    plain weird. Of course if you do that, it fails validation and screws up
    some other browsers.

    I miss the old days where everyone hated Netscape and IE was the best
    browser! Now everyone is still using IE and it's by far the *worst* browser.
    Arrrg. And Mozilla is rather nice :)
    SpaceGirl, Apr 26, 2004
    #3
  4. Dave Winter

    Dave Winter Guest

    You're right, it does seem to render ok in IE6.

    However, Firefox, Safari, Camino - none of these do. They render the
    site differently based on the doctype.

    Could this be a bug with all of these? Or, IE 6? Or some other sort of bug?

    Dave.

    On 2004-04-26 11:12:31 +0100, "SpaceGirl" <> said:

    >
    > "Dave Winter" <> wrote in message
    > news:2004042611034516807%davewinter@maccom...
    >> Hi,
    >>
    >> After smashing my head against the table a few times, I finally was
    >> able to fix a bug that was causing my site to render incorrectly in all
    >> browsers.
    >>
    >> An hour ago, I had just finished my conversion from HTML to XHTML/CSS
    >> Transitional, the site was validating perfectly. So, as it was doing
    >> this, I thought I'd try it out as XHTML Strict. So I changed the
    >> doctype in the file and then validated it. Validated fine as XHTML
    >> Strict. However! Then I noticed it was rendering differently. These
    >> weird line spaces were appearing in weird places. They hadn't been. So
    >> I assumed I'd editting something accidently in the CSS file. Checked
    >> the CSS file, nothing weird in there.
    >>
    >> Hit my head against the table for the first time.
    >>
    >> What had I changed recently? The doctype! From Transitional to Strict.
    >>
    >> So I changed it back from Strict to Transitional.
    >>
    >> Hit my head against the table for the second time.
    >>
    >> The site was rendering correcltly! What the heck?!
    >>
    >> Transitional: http://www.commanderbond.net/xhtml/
    >> Strict: http://www.commanderbond.net/xhtml_s/
    >>
    >> The only difference between these two versions are the doctypes.
    >> Nothing else is different.
    >>
    >> What the hell is going on?
    >>
    >> Really appreciate any help of advice.
    >>
    >> Cheers,
    >>
    >> Dave Winter.

    >
    > Both versions looked identical to me in IE6. Which is ironic, considering
    > IE6 *does* have some serious XML/XHTML rendering bugs (they are fairly
    > random, but are affected completely by the doctype). Generally IE renders
    > XHTML *better* if you set the doctype to HTML4 Transitional. Which is just
    > plain weird. Of course if you do that, it fails validation and screws up
    > some other browsers.
    >
    > I miss the old days where everyone hated Netscape and IE was the best
    > browser! Now everyone is still using IE and it's by far the *worst* browser.
    > Arrrg. And Mozilla is rather nice :)
    Dave Winter, Apr 26, 2004
    #4
  5. Dave Winter

    Steve Pugh Guest

    Dave Winter <> wrote:

    >Transitional: http://www.commanderbond.net/xhtml/
    >Strict: http://www.commanderbond.net/xhtml_s/
    >
    >The only difference between these two versions are the doctypes.
    >Nothing else is different.
    >
    >What the hell is going on?


    Doctype sniffing.

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> triggers
    Standards mode in Mozilla.

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> triggers
    Standards mode in Opera and IE, but triggers "Almost Standards" mode
    in Mozilla.

    The difference is slight (nothing like the differences between
    Standards and Quirks) and is most evident in the way images are
    treated if they are the sole content of an element.

    You have
    <div id="header"><img src="resources/images/headers/48/logo.jpg"
    /></div>
    (which is naughty as the alt attribute is mandatory).

    If you had
    <div>abcd<img>efgh</div>
    you would expect a space below the image, as by default the bottom of
    the image sits on the baseline of the text and there must be room
    below the baseline for the descender of the 'g'. To be totally
    standards compliant there must be room below the baseline even when
    there are no characters with descenders used.

    But traditionally browsers have fudged this and so in 'Almost
    Standards' mode (and obviously Quirks mode as well) Mozilla fudges it
    as well.

    #header img {display: block;}
    #leftmenu img {display: block;}
    #rightmenu img {display: block;}
    will fix your problem. By turning the images from inline to block
    elements they no longer need to be treated as text characters.

    Steve

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

    Steve Pugh <> <http://steve.pugh.net/>
    Steve Pugh, Apr 26, 2004
    #5
  6. Dave Winter

    Whitecrest Guest

    In article <2004042611172250073%davewinter@maccom>,
    says...
    > You're right, it does seem to render ok in IE6.
    > However, Firefox, Safari, Camino - none of these do. They render the
    > site differently based on the doctype.
    > Could this be a bug with all of these? Or, IE 6? Or some other sort of bug?


    Yes to all. The problem is that no browser supports 100% of CSS, so if
    you are planning on a CSS design you have to either use only code that
    works identically in all browsers (which pretty much eliminates nested
    divs with borders and padding), or just accept that it will not look the
    same.

    --
    Whitecrest Entertainment
    www.whitecrestent.com
    Whitecrest, Apr 26, 2004
    #6
  7. Dave Winter

    Dave Winter Guest

    On 2004-04-26 11:49:30 +0100, Steve Pugh <> said:

    > Dave Winter <> wrote:
    >
    >> Transitional: http://www.commanderbond.net/xhtml/
    >> Strict: http://www.commanderbond.net/xhtml_s/
    >>
    >> The only difference between these two versions are the doctypes.
    >> Nothing else is different.
    >>
    >> What the hell is going on?

    >
    > Doctype sniffing.
    >
    > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> triggers
    > Standards mode in Mozilla.
    >
    > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> triggers
    > Standards mode in Opera and IE, but triggers "Almost Standards" mode
    > in Mozilla.
    > The difference is slight (nothing like the differences between
    > Standards and Quirks) and is most evident in the way images are
    > treated if they are the sole content of an element.
    >
    > You have <div id="header"><img src="resources/images/headers/48/logo.jpg"
    > /></div>
    > (which is naughty as the alt attribute is mandatory).
    >
    > If you had
    > <div>abcd<img>efgh</div>
    > you would expect a space below the image, as by default the bottom of
    > the image sits on the baseline of the text and there must be room
    > below the baseline for the descender of the 'g'. To be totally
    > standards compliant there must be room below the baseline even when
    > there are no characters with descenders used.
    > But traditionally browsers have fudged this and so in 'Almost
    > Standards' mode (and obviously Quirks mode as well) Mozilla fudges it
    > as well.
    > #header img {display: block;}
    > #leftmenu img {display: block;}
    > #rightmenu img {display: block;}
    > will fix your problem. By turning the images from inline to block
    > elements they no longer need to be treated as text characters.
    >
    > Steve


    Thanks Steve!

    Yeah, I only left out the alt attribute while I smashing around trying
    to get it all working again :) Thanks for reminding me though to
    actually put it back in.

    Would it be a big problem if I set:

    img {display: block;}

    Doing so, making all image on the web page no longer be treated as text
    characters? Or would that mess things up?

    Thanks for your help! Really appreciate it.

    Dave.
    Dave Winter, Apr 26, 2004
    #7
  8. Dave Winter

    Steve Pugh Guest

    Dave Winter <> wrote:

    >Would it be a big problem if I set:
    >
    >img {display: block;}
    >
    >Doing so, making all image on the web page no longer be treated as text
    >characters? Or would that mess things up?


    On the page in question it probably wouldn't make much difference. But
    don't forget that block level elements have a line break before and
    afterwards so it may cause problems elsewhere (when you want an image
    to appear inline with some text).

    Steve

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

    Steve Pugh <> <http://steve.pugh.net/>
    Steve Pugh, Apr 26, 2004
    #8
  9. Steve Pugh <> wrote:

    > If you had
    > <div>abcd<img>efgh</div>
    > you would expect a space below the image, as by default the bottom of
    > the image sits on the baseline of the text and there must be room
    > below the baseline for the descender of the 'g'.


    That's one way of putting it. Another way is to say that there is some
    space below the baseline defined by the text, even when the text has no
    descenders.

    > To be totally
    > standards compliant there must be room below the baseline even when
    > there are no characters with descenders used.


    I don't see how this would be required in any HTML standard. The height
    of text is not defined in HTML.

    But it's a natural assumption that visual browsers leave some space below
    a string of characters even when they have no descenders, just as it is
    natural to expect that there is some space _above_ the characters when a
    line consists of just "aaa". It's a feature of normal rendering of
    characters that the height of the font is decisive here, not the heights
    of characters in the text.

    However, shouldn't the situation change when there are _no_ characters,
    as in <div><img ...></div>? If we had <div> <img ...></div> or
    <div><img ...> </div> (i.e., with a space before or after the img
    element), then it would be a debatable case, since the effect of
    whitespace is not quite exhaustively defined in HTML specifications. But
    when _no_ text is present, the issue of vertically aligning to a baseline
    does not arise, does it?

    I'm not arguing against observations of browser behavior, just against
    the idea that the extra space would be required by standards.

    > #header img {display: block;}
    > #leftmenu img {display: block;}
    > #rightmenu img {display: block;}
    > will fix your problem. By turning the images from inline to block
    > elements they no longer need to be treated as text characters.


    This sounds like bad news. When a document contains an image to be shown
    separately, not as part of a paragraph or other construct, the Strict
    syntax requires that it be wrapped inside a block level container, as in
    <div><img ...></div>
    But now it seems that this may cause undesired spacing effects, unless
    you take the trouble of adding extra CSS rules.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
    Jukka K. Korpela, Apr 26, 2004
    #9
  10. Dave Winter

    Steve Pugh Guest

    "Jukka K. Korpela" <> wrote:
    >Steve Pugh <> wrote:
    >
    >> To be totally
    >> standards compliant there must be room below the baseline even when
    >> there are no characters with descenders used.

    >
    >I don't see how this would be required in any HTML standard. The height
    >of text is not defined in HTML.


    HTML is not the only standard that needs to be considered. It is, of
    course, part of the total stupidity of doctype sniffing that the
    (X)HTML doctype determines not only how browsers (mis)interpret the
    HTML standard but also how they (mis)interpret the CSS standard.

    >But it's a natural assumption that visual browsers leave some space below
    >a string of characters even when they have no descenders, just as it is
    >natural to expect that there is some space _above_ the characters when a
    >line consists of just "aaa". It's a feature of normal rendering of
    >characters that the height of the font is decisive here, not the heights
    >of characters in the text.


    True, but the relationship between the font size and the baseline is
    not instantly obvious. My explanation was simply intended to get the
    point across that the space comes from the font, without going into
    details that aren't strictly relevant to the problem at hand.

    >However, shouldn't the situation change when there are _no_ characters,
    >as in <div><img ...></div>? If we had <div> <img ...></div> or
    ><div><img ...> </div> (i.e., with a space before or after the img
    >element), then it would be a debatable case, since the effect of
    >whitespace is not quite exhaustively defined in HTML specifications. But
    >when _no_ text is present, the issue of vertically aligning to a baseline
    >does not arise, does it?


    One would think so. Clearly, Microsoft and Opera think so.

    >I'm not arguing against observations of browser behavior, just against
    >the idea that the extra space would be required by standards.


    The standards are not 100% clear on this. CSS 2.1 is clearer than CSS
    2 but still leaves certain things unsaid, however...

    Even when there is no text there is still a CSS line box created by
    the presence of the inline element <img>.

    "The line box height is the distance between the uppermost box top and
    the lowermost box bottom." (CSS 2.1, section 10.8)

    In this case one would assume that as the online inline box is that
    generated by the <img> that the line box height would be the height of
    the <img>.

    But, section 10.8.1 defines the line-height property and says that it
    "specifies the *minimal* height of line boxes within the element". The
    emphasis is in the spec.

    This part of the spec continues with "The minimum height consist of a
    minimum height above the block's baseline and a minimum depth below
    it, exactly as if each line box starts with a zero-width inline box
    with the block's font and line height properties (what TEX calls a
    "strut")."

    Now I know nothing of TeX but the description seems clear enough to me
    - even when there is no text present the minimumline box height is
    calculated as if there was.

    BTW this last quote is not present in CSS2. Some cynics claim that CSS
    2.1 is written to make Mozilla's bugs the correct behaviour.

    I may be interpreting the specs incorrectly, and the specs may well
    not be logical but I hope you now see why I said what I said.

    Steve

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

    Steve Pugh <> <http://steve.pugh.net/>
    Steve Pugh, Apr 26, 2004
    #10
  11. Dave Winter

    C A Upsdell Guest

    "Dave Winter" <> wrote in message
    news:2004042611590943658%davewinter@maccom...
    > Would it be a big problem if I set:
    >
    > img {display: block;}


    Mozilla is doing it right, but recent versions only do this in standards
    mode, which is triggered by a strict DTD; transitional uses its
    'almost-standards mode', which is the same as standards mode except that it
    does not produce the unwanted vertical gaps. Setting display:block is the
    correct solution.
    C A Upsdell, Apr 26, 2004
    #11
  12. Steve Pugh <> wrote:

    > HTML is not the only standard that needs to be considered.


    But in the context of alt.html, isn't it a fair assumption that you mean
    HTML "standards" (i.e., W3C Recommendations on HTML) when you just say
    "standard"?

    > It is, of
    > course, part of the total stupidity of doctype sniffing that the
    > (X)HTML doctype determines not only how browsers (mis)interpret the
    > HTML standard but also how they (mis)interpret the CSS standard.


    Quite right, but the CSS "standard" does _not_ specify how HTML shall or
    should be rendered. It defines a style sheet "language", which can be
    used in various contexts, and it assigns meanings to style sheets.
    HTML, on the other hand, does not require any style sheet. And when you
    use HTML and CSS, there is really nothing that binds the two together in
    the sense of prescribing default rendering for HTML in CSS terms. The
    "sample style sheet" for HTML in CSS specs is a poor joke; it is neither
    normative (the spec says this explicitly) nor a realistic description,
    though it might be seen as having ingredients of both.

    By the way, does this mean that when CSS is switched off (on browsers
    that support this), the problem vanishes?

    > In this case one would assume that as the online inline box is that
    > generated by the <img> that the line box height would be the height
    > of the <img>.


    Well, maybe. But there is actually no normative definition of what an img
    element is in CSS terms. Of course this mostly reflects the ways that the
    W3C works, creating specifications that contain quite a lot of things to
    be implied or deduced.

    Is there something that prevents a browser from having
    img { line-height: 0; }
    in its default style sheet? Wouldn't this be very reasonable, in fact?
    After all, since an image has intrinsic dimensions, there is no need to
    set any particular minimum height. And setting a minimum height, if
    implemented consistently, would destroy the layout effect that people try
    to achieve using a table cell containing just a single-pixel GIF, with
    suitable settings for the cell. Whatever one thinks about such tricks, it
    can hardly be useful to mess up pages using them if there is no better
    reason than a strange idea of applying the page's line height (as
    inherited) to images.

    Actually, is img { line-height: 0; } in authors' style sheets a general
    solution to the problem?

    > BTW this last quote is not present in CSS2. Some cynics claim that
    > CSS 2.1 is written to make Mozilla's bugs the correct behaviour.


    In any case, CSS 2.1 is not a standard yet, even by W3C standards.

    > I may be interpreting the specs incorrectly, and the specs may well
    > not be logical but I hope you now see why I said what I said.


    Yes, I see your point, I'm just worried about the consequences.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
    Jukka K. Korpela, Apr 26, 2004
    #12
  13. Dave Winter

    Steve Pugh Guest

    "Jukka K. Korpela" <> wrote:
    >Steve Pugh <> wrote:
    >
    >By the way, does this mean that when CSS is switched off (on browsers
    >that support this), the problem vanishes?


    As far as I can tell the problem is unique to Gecko (I only have
    Windows to hand so can't test in Safari or Konqueror). Disabling CSS
    in Gecko is not possible.

    >Is there something that prevents a browser from having
    >img { line-height: 0; }
    >in its default style sheet? Wouldn't this be very reasonable, in fact?
    >
    >Actually, is img { line-height: 0; } in authors' style sheets a general
    >solution to the problem?


    It wouldn't make any difference. The line-height of the div is what
    determines the minimum height of the line box.

    "If the property is set on a block-level element whose content is
    composed of inline-level elements, it specifies the minimal height of
    each generated inline box."

    (Note the difference from the CSS 2.1 spec I quoted earlier: here in
    CSS 2 it specifies the minimal height of the inline boxes, not as in
    2.1 the line boxes.)

    In fact the effect of line-height on replaced inline elements like img
    is undefined. It explicitly doesn't do what it does for non-replaced
    inline elements, but no alternative meaning is supplied.

    "If the property is set on an inline-level element, it specifies the
    exact height of each box generated by the element. (Except for inline
    replaced elements, where the height of the box is given by the
    'height' property.)"

    Yet "Applies to: all elements".

    http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height

    Steve

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

    Steve Pugh <> <http://steve.pugh.net/>
    Steve Pugh, Apr 26, 2004
    #13
  14. Dave Winter

    Mark Parnell Guest

    On Mon, 26 Apr 2004 17:57:24 +0100, Steve Pugh <> declared
    in alt.html:

    > Disabling CSS in Gecko is not possible.


    If the title attribute has been used for the styles (e.g. <link
    rel="stylesheet type="text/css" title="My Style">), you can disable CSS
    through View>Use Style>Basic Page Style, because the CSS "version" will
    be listed separately (e.g. in the above, as "My Style").

    If there is no title attribute, the Basic Page Style uses the CSS.

    --
    Mark Parnell
    http://www.clarkecomputers.com.au
    Mark Parnell, Apr 27, 2004
    #14
  15. Dave Winter

    Steve Pugh Guest

    Mark Parnell <> wrote:
    >On Mon, 26 Apr 2004 17:57:24 +0100, Steve Pugh <> declared
    >in alt.html:
    >
    >> Disabling CSS in Gecko is not possible.

    >
    >If the title attribute has been used for the styles (e.g. <link
    >rel="stylesheet type="text/css" title="My Style">), you can disable CSS
    >through View>Use Style>Basic Page Style, because the CSS "version" will
    >be listed separately (e.g. in the above, as "My Style").
    >
    >If there is no title attribute, the Basic Page Style uses the CSS.


    How do I disable the CSS used by Gecko's own browser style sheet?

    Steve

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

    Steve Pugh <> <http://steve.pugh.net/>
    Steve Pugh, Apr 27, 2004
    #15
  16. Steve Pugh wrote:

    > How do I disable the CSS used by Gecko's own browser style sheet?


    Delete the "html.css" file, which controls Gecko's default rendering of
    HTML. On my system it's in the "/usr/lib/mozilla-1.6/res" directory.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me - http://www.goddamn.co.uk/tobyink/?page=132
    Toby A Inkster, Apr 27, 2004
    #16
  17. Dave Winter

    Steve Pugh Guest

    Toby A Inkster <> wrote:

    >Steve Pugh wrote:
    >
    >> How do I disable the CSS used by Gecko's own browser style sheet?

    >
    >Delete the "html.css" file, which controls Gecko's default rendering of
    >HTML. On my system it's in the "/usr/lib/mozilla-1.6/res" directory.


    That works. It makes the browser unusable, but it works. ;-)

    Steve

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

    Steve Pugh <> <http://steve.pugh.net/>
    Steve Pugh, Apr 27, 2004
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mark | r

    strict/transitional Q's

    mark | r, May 10, 2004, in forum: HTML
    Replies:
    11
    Views:
    843
    Spartanicus
    May 10, 2004
  2. Sally Thompson
    Replies:
    10
    Views:
    6,201
    Sally Thompson
    Jun 26, 2004
  3. t
    Replies:
    76
    Views:
    1,744
    Neredbojias
    Feb 23, 2008
  4. BessieBee

    HTML transitional vs strict

    BessieBee, Apr 10, 2008, in forum: HTML
    Replies:
    3
    Views:
    632
    Jukka K. Korpela
    Apr 10, 2008
  5. Beauregard T. Shagnasty

    Re: Converting transitional to strict

    Beauregard T. Shagnasty, May 16, 2010, in forum: HTML
    Replies:
    3
    Views:
    525
    Jukka K. Korpela
    May 17, 2010
Loading...

Share This Page