 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / November 2007Border at top of the page
If you take a really simple webpage ("<P>This is a webpage") and add: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> at the top of the source, then the top margin of the webpage changes in most browsers - mostly increases. Is there anything significance in this? How would I reduce the border? I've tried things like: <BODY STYLE="margin:10px"> but have to admit that I'm guessing, and the larger top border survives. No doubt I could find the answer in time; I'm more interested if there is any philosophical reason for the change.  SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk > If you take a really simple webpage ("<P>This is a webpage") and add: > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" [quoted text clipped - 8 lines] > No doubt I could find the answer in time; I'm more interested if there is > any philosophical reason for the change. Quirks mode. SignatureRichard > If you take a really simple webpage ("<P>This is a webpage") and add: > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" [quoted text clipped - 8 lines] > No doubt I could find the answer in time; I'm more interested if there > is any philosophical reason for the change. If you do not supply any style information at all for an html doc, e.g. <html> <head> <title>Title</title> </head> <body> <h1>heading</h1> <p>A sentence...</p> </body> </html> then layouts are calculated by the browsers default settings. These settings change according to doc type in this sense: (1) Some different doctypes trigger different layouts. For example, these two make a difference: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN" "http://www.w3.org/MarkUp/Wilbur/HTML32.dtd"> (2) Having no doctype in some browsers makes them have a similar or identical layout to as if the doc had: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN" "http://www.w3.org/MarkUp/Wilbur/HTML32.dtd"> You should set a doctype. But whether you do or you don't, if you want to maximise consistency across browsers, and bypass the default layouts set by them, you must attend closely to your styles and make sure that you set margins and paddings specifically. For example, in the example above, you would set margins and paddings on body, h1 and p. On body, you best set zero. An extreme levelling technique which some people favour but which can land you with a big job of supplying complete alternatives for all elements in a complex site is: <style type="text/css"> * {margin:0; padding: 0;} </style> Signaturedorayme Scripsit Steve Swift: > If you take a really simple webpage ("<P>This is a webpage") That's not a webpage. An HTML document must contain a title element and a document type declaration. What happens when you throw invalid markup at browsers might be amusing up to a point, but not really the way to create webpages. > and add: > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" > "http://www.w3.org/TR/html4/strict.dtd"> > at the top of the source, then the top margin of the webpage changes > in most browsers - mostly increases. I don't believe you. I just tested this on IE 7, and there was no such effect. > Is there anything significance in this? No. See above. However, adding a Strict doctype to a crappy page may well make things worse, since it triggers "standards" mode, and the phenomenon that the page gives the impression of working is often based on relying on "quirks" mode. > How would I reduce the border? There is no border. > I've tried things like: > <BODY STYLE="margin:10px"> > but have to admit that I'm guessing, and the larger top border > survives. The "I'm guessing" part is true. > No doubt I could find the answer in time; I'm more > interested if there is any philosophical reason for the change. There is a practical reason to stop trying to create webpages before you get some clues. Try reading a book, or a tutorial. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > I don't believe you. I just tested this on IE 7, and there was no such > effect. I don't believe him either. I tested it with IE6, IE7, Firefox 2, Netscape 8 and Opera 9. Only Netscape and Opera showed this variation in the space at the top of the page. Mind you, those probably are the majority of the browsers that he normally uses. Mind you, there's *something* causing the space at the top of the page; I'm fairly certain that I've seen pages where it was absent, with the first line of text on the page hard up against the top edge of the container. I might even have (accidentally) fabricated such a page myself once; I recall seeing the effect and thinking "how horrid!". I suspect this is some obscure setting in Opera, though. SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk >> I don't believe you. I just tested this on IE 7, and there was no such >> effect. > > I don't believe him either. I tested it with IE6, IE7, Firefox 2, > Netscape 8 and Opera 9. You don't believe yourself? > Mind you, there's *something* causing the space at the top of the page; > I'm fairly certain that I've seen pages where it was absent, with the > first line of text on the page hard up against the top edge of the > container. Without the Strict DTD, it will be in Quirks Mode and applying margin:0; to body, the <P>aragraph will be hard up against the top of the viewport. With the Strict DTD, the default margin-top value on <P>aragraph will be applied such that the <P>aragraph is moved down from the top of the viewport by the amount of the default margin-top on <P>aragraph. Those are the reasons, I believe, you are asking about. The way to achieve the "hard up against the top" effect, with the Strict DTD, is to: <body style="margin:0;"> <p style="margin-top:0; background:yellow;">This is a webpage</p> where the background:yellow; is only to aid visually. SignatureGus Scripsit Gus Richter: > Without the Strict DTD, it will be in Quirks Mode and applying > margin:0; to body, the <P>aragraph will be hard up against the top of > the viewport. This is part of the oddities of Quirks Mode in Firefox and actually documented, in a fairly obscure way, at http://lxr.mozilla.org/seamonkey/source/layout/style/quirk.css Firefox and relatives suppress the top margin of several elements in certain contexts. Perhaps the easiest to observe is the case where a <p> element appears as the first element in a <td> element, especially if you use borders for the table cell so that the effect is easy to see. It also happens for <p> at the start of <body>, though this is a somewhat strange case. (Why would you start a page with a paragraph of text and not with a heading or with a block containing a logo, links, etc.?) This is definitely not something general in browsers. Specifically, IE suppresses the top margin of a <p> at the start of a <td>, but it does that in both modes (Quirks and Standards). There's no logic in Firefox in this issue. There is nothing quirky in browsers' "traditional" behavior, and there was no need to change it in the standards mode. It's just a matter of browser defaults, describable in terms of a browser style sheet. If a browser vendor wishes to change such defaults, he should think twice, and surely shouldn't masquerade it as a "standards" issue. It's just as mad as it would be to start using Arial as default font in standards mode and keep using Times New Roman in quirks mode. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit Gus Richter: > [quoted text clipped - 26 lines] > Arial as default font in standards mode and keep using Times New Roman > in quirks mode. This "oddity" is not exclusive to Firefox and relatives. The exact same behavior is with Opera and Safari - in both Quirks and Standards Mode. When there is anonymous text, all browsers are without top margin in either Quirks or Standards Mode, which is the same when <p>aragraph is used in Quirks Mode. IE is the odd man out only in Standards Mode where it applies no top margin to <p>aragraph. SignatureGus Scripsit Gus Richter: [ Fullquote - always a useful signal. ] > When there is anonymous text, all browsers are without top margin in > either Quirks or Standards Mode, You mean loose text, right? That is, text data directly inside <body>. It has no margins. Big surprise. > which is the same when <p>aragraph is > used in Quirks Mode. You're just messing things up, really. > IE is the odd man out only in Standards Mode > where it applies no top margin to <p>aragraph. More confusion. There's nothing illogical in suppressing the top margin of a <p> element that opens the content of <body>. It can easily be described as body > p:first-child { margin-top: 0; } And there was no reason to drop that behavior, and it was illogical to do so in the name of standards conformance and to make this depend on the magic incantation, the doctype string. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit Gus Richter: > [quoted text clipped - 5 lines] > You mean loose text, right? That is, text data directly inside <body>. > It has no margins. Big surprise. I think we're talking about the margin on the <p>, not on the anonymous block surrounding the loose text. Of course the anonymous block has no margin. But the presence of loose text affects whether the margin is suppressed or not in quirks mode. i.e. if you have this: <body> hello <p> world ... The <p> keeps its top margin (in Firefox, quirks or standards modes). But if you have this: <body> <p> world ... it loses it (in Firefox in quirks mode). You can't do this with :first-child, because the presence of the bastard anonymous block around "hello" does not change the fact that in both cases the <p> is still the first legitimate child of <body>. You need :-moz-first-node for that (or some other way of implementing this quirk). [...] > There's nothing illogical in suppressing the top margin of a <p> element > that opens the content of <body>. It can easily be described as > body > p:first-child { margin-top: 0; } > And there was no reason to drop that behavior I agree that body > p:first-child { margin-top: 0; } would be a reasonable thing to have in the default stylesheet anyway, although there are good reasons for sticking to Appendix D of CSS 2.1 (which doesn't do this). > Scripsit Gus Richter: > > [ Fullquote - always a useful signal. ] Actually I felt that I could not cut any portion since it was all relevant). Sorry that you could not appreciate it. >> When there is anonymous text, all browsers are without top margin in >> either Quirks or Standards Mode, > > You mean loose text, right? That is, text data directly inside <body>. > It has no margins. Big surprise. No, I mean "anonymous text" as it is described in CSS2.1 and described as "line box" in CSS3 (WD). Nowhere that I could find is it described as "loose text" - something you made up? >> which is the same when <p>aragraph is >> used in Quirks Mode. > > You're just messing things up, really. I'm disappointed that you could not see the relevance of my introducing "anonymous text". I suggest that you try the tests not as a child of <body> but as a child of <div>. This was what interested me as well. Most certainly you should have noted that I was also reinforcing the behavior in Quirks Mode that <p> also had no top margin just as "anonymous text". I don't see how it messed things up for you. >> IE is the odd man out only in Standards Mode >> where it applies no top margin to <p>aragraph. > > More confusion. Perhaps I can clarify for you. My report says that Firefox, Opera, Safari and IE all apply no top margin to <p> in Quirks Mode. In Standards Mode, Firefox, Opera and Safari apply top margin to <p>, but IE does not. > [Clipped OT material (causing confusion)] I simply reported my findings in order to correct your erroneous contention that Firefox and relatives only were at odds with IE's interpretation. I did not have an opinion about who is right or wrong, but only stated it as it is. SignatureGus > Scripsit Gus Richter: > [quoted text clipped - 17 lines] > suppresses the top margin of a <p> at the start of a <td>, but it does > that in both modes (Quirks and Standards). In fact this sounds a lot like what Gérard Talbot was talking about recently: http://groups.google.co.uk/group/comp.infosystems.www.authoring.html/msg/d5f7633 37eb69cb6 > There's no logic in Firefox in this issue. There is nothing quirky in > browsers' "traditional" behavior, and there was no need to change it in > the standards mode. It's just a matter of browser defaults, describable > in terms of a browser style sheet. Firefox has invented non-standard pseudoselectors ":-moz-first-node" and ":-moz-last-node" to implement this, because what it consists of is outside the CSS specification. There's no way to get that behaviour just with default styles using only a CSS 2.1 conforming implementation. That makes it a quirk and a standards issue. As for browsers' "traditional" behaviour, I'm not sure whether IE's unusual behaviour is an accidental bug or a non-conformance to W3C specifications because they had something else in mind. Who knows and who cares? > If a browser vendor wishes to change such defaults, he should think > twice, and surely shouldn't masquerade it as a "standards" issue. It's > just as mad as it would be to start using Arial as default font in > standards mode and keep using Times New Roman in quirks mode. Scripsit Ben C: > Firefox has invented non-standard pseudoselectors ":-moz-first-node" > and ":-moz-last-node" to implement this, because what it consists of > is outside the CSS specification. It's not clear what you mean by "this", but several of the cases discussed _are_ describable in CSS 2.1 terms. > There's no way to get that behaviour just with default styles using > only a CSS 2.1 conforming implementation. That makes it a quirk and a > standards issue. Even if that were the case, it has nothing to do with the question whether a document contains a particular doctype string or not. That's a markup issue, quite external to all CSS considerations. Besides, the HTML specifications do not specify the default rendering of documents, and they do not require that the default rendering be describable in CSS 2.1 (since HTML is independent of the very existence of CSS) or that it be described at all. > As for browsers' "traditional" behaviour, I'm not sure whether IE's > unusual behaviour is an accidental bug or a non-conformance to W3C > specifications because they had something else in mind. What non-conformance? A browser may display <p> elements with pink background on Sundays, and you still cannot claim that it is non-conforming because of that. And there's nothing unusual in doing what previous versions did. In fact, that's the sensible way to go, unless you have good reasons to do otherwise. >> If a browser vendor wishes to change such defaults, he should think >> twice, and surely shouldn't masquerade it as a "standards" issue. >> It's just as mad as it would be to start using Arial as default font >> in standards mode and keep using Times New Roman in quirks mode. I guess you quoted that, without commenting on it, because you realized, ultimately, that I was right and this paragraph summarized my point well. Thank you. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit Ben C: > [quoted text clipped - 3 lines] > > It's not clear what you mean by "this" By "this" I mean suppressing the top margin of <p> when it is the first child of body, _except when it is preceded by text_. > , but several of the cases discussed _are_ describable in CSS 2.1 > terms. If they are, then they're not quirks. I agree with you about that. >> There's no way to get that behaviour just with default styles using >> only a CSS 2.1 conforming implementation. That makes it a quirk and a [quoted text clipped - 7 lines] > 2.1 (since HTML is independent of the very existence of CSS) or that it > be described at all. I know. But we aren't discussing HTML here. Surely I don't need to remind you this is comp.infosystems.www.authoring.stylesheets. Implementing a rendering behaviour that's outside the CSS specification and switching it on based on the doctype string is what I call a quirk. >> As for browsers' "traditional" behaviour, I'm not sure whether IE's >> unusual behaviour is an accidental bug or a non-conformance to W3C >> specifications because they had something else in mind. > > What non-conformance? I'm thinking specifically of this one: http://groups.google.co.uk/group/comp.infosystems.www.authoring.html/msg/d5f7633 37eb69cb6 That is either a bug or a non-conformance. My money's on bug. > A browser may display <p> elements with pink background on Sundays, > and you still cannot claim that it is non-conforming because of that. I do claim that, unless it's using JS. If there's no style in the cascade that sets background-color: pink on <p> then <p> must have a transparent background. Your browser is non-conforming on at least one day out of seven. [...] >>> If a browser vendor wishes to change such defaults, he should think >>> twice, and surely shouldn't masquerade it as a "standards" issue. [quoted text clipped - 4 lines] > ultimately, that I was right and this paragraph summarized my point > well. Thank you. Yes, that part was right. Scripsit Ben C: >> It's not clear what you mean by "this" > > By "this" I mean suppressing the top margin of <p> when it is the > first child of body, _except when it is preceded by text_. They are obscure, aren't they? They tend to obscure and mislead rather than help, yet we use them much - too much. I mean pronouns, of course. So instead of the simple case <body><p>foo... and the margin for <p>, which seemed (to me at least) to be the topic, you were referring to <body>foo<p>bar... and not the margins of foo but the top margin of <p> in that context. Indeed _that_ presentational feature cannot be described in CSS 2.1. But let's remember that we _also_ have the case of <body><p>foo..., where Firefox behaves differently depending on doctype sniffing. This is just mad, and any features with <body>foo<p>bar... are probably connected with that madness rather than designed separately. >> Besides, the HTML specifications do not specify the default >> rendering of documents, and they do not require that the default [quoted text clipped - 4 lines] > I know. But we aren't discussing HTML here. Surely I don't need to > remind you this is comp.infosystems.www.authoring.stylesheets. Yet doctypes are just about markup, and specifically about formal syntax, with no defined connection with styles. >> What non-conformance? > > I'm thinking specifically of this one: > http://groups.google.co.uk/group/comp.infosystems.www.authoring.html/msg/d5f7633 37eb69cb6 > > That is either a bug or a non-conformance. My money's on bug. It looked too complicated. The message seems to discuss CSS issues, yet it's in the HTML group. Are you referring to HTML or CSS conformance? And non-conformance _is_ a bug, by definition. >> A browser may display <p> elements with pink background on Sundays, >> and you still cannot claim that it is non-conforming because of that. > > I do claim that, unless it's using JS. Please cite the relevant part of the conformance clauses. > If there's no style in the cascade that sets background-color: pink on > <p> then <p> must have a transparent background. Your browser is > non-conforming on at least one day out of seven. You are implying CSS. HTML specifications don't. There is nothing in HTML specs that prevents the behavior I described. How does CSS change that? Do CSS specifications require that presentation is under the control of CSS completely? I don't think they do. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit Ben C: [...] >> I'm thinking specifically of this one: >> http://groups.google.co.uk/group/comp.infosystems.www.authoring.html/msg/d5f7633 37eb69cb6 [quoted text clipped - 3 lines] > It looked too complicated. The message seems to discuss CSS issues, yet > it's in the HTML group. Are you referring to HTML or CSS conformance? CSS conformance. > And non-conformance _is_ a bug, by definition. I'm happy with that definition. >>> A browser may display <p> elements with pink background on Sundays, >>> and you still cannot claim that it is non-conforming because of that. [quoted text clipped - 11 lines] > that? Do CSS specifications require that presentation is under the > control of CSS completely? I don't think they do. Of course not. But background colour _is_ under the control of CSS completely. Section 3.2 (of CSS 2.1) explains that to claim conformance you have to do the cascade and give every element a value for every applicable property. So the <p> must have a value for background-color, either the initial value or some value specified somewhere in the styles. Then later on in 3.2: A user agent that renders a document with associated style sheets must respect points 1-5 and render the document according to the media-specific requirements set forth in this specification. I think that means it has to draw the background the colour that the background-color property says it is. If you set pink, then you must get pink, every day of the week. But is there anything to say that the initial value of a property (which may be pink) can't depend on the day of the week? Well it doesn't say that specifically I suppose, but only because it's obviously ridiculous. > > And non-conformance _is_ a bug, by definition. > > I'm happy with that definition. Surely that is stretching the word too far. If it was a deliberate choice against the standards, it is an unhappy description of it as a bug. Signaturedorayme >>> And non-conformance _is_ a bug, by definition. >> I'm happy with that definition. > > Surely that is stretching the word too far. If it was a > deliberate choice against the standards, it is an unhappy > description of it as a bug. Your right it is not a bug but a *MS Feature* SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com > >>> And non-conformance _is_ a bug, by definition. > >> I'm happy with that definition. [quoted text clipped - 4 lines] > > Your right it is not a bug but a *MS Feature* OK Jonathan, perhaps you are humouring me <g>. But there does seem to me a distinction between the deliberate (even reasoned) departure from standards (not just from MS) and inadvertent consequences from code, (I am having trouble with getting and sending to alt.html via my MT-Newswatcher ng software but not other groups? Messages are stuck "being sent" in the sense that if I try to quit my newsreader it says a message is still being sent ... from maybe an hour back! And some are not appearing as sent. Anyway, have you noticed any trouble with alt.html? Perhaps I have to ring my ISP and ask them if there is any trouble with their news server software?) Signaturedorayme > (I am having trouble with getting and sending to alt.html via my > MT-Newswatcher ng software but not other groups? Messages are [quoted text clipped - 4 lines] > ISP and ask them if there is any trouble with their news server > software?) I am always having problems, but the causes are not so mysterious. The nearly dozen trees, yeah trees not branches, slung in the phone trunk line a short ways down the road might have something to do with my trouble because Verizon puts priority on stockholder profits over basic infrastructure maintenance. A real sore spot for me where a decade ago deregulation and rate hikes were supposed to finance a fiber network to "Wire America for the Millennium". Yeah, right! Still stuck on dialup almost 8 years in... Also my little local ISP cannot seem to keep their servers patched and...well who knows? I do notice of the 3 NGs a mostly monitor alt.html seems to be the flakiest. SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com > I am always having problems, but the causes are not so mysterious. The > nearly dozen trees, yeah trees not branches, slung in the phone trunk > line a short ways down the road might have something to do with my > trouble Please excuse a wild deviation from CSS discussion, but you reminded me of my own connection problems. They happened only in the late spring, and only on wet days. British Telecom was mystified. Then I solved the problem myself by observation. Being late spring there was a family of jackdaws nesting in my false chimney. Their fledglings were using my yew tree as their first landing point on their first flights. The combined weight of the fledglings was making the branch sag until it touched my phone line. When it was wet, this tended to short the line to ground. I pruned off that branch, and have had no problems since, apart from the occasional jackdaw squawk "Where the **** has our perch gone?". British Telecom, bless them, replaced my "bare wire" line with an insulated one when they heard of this problem, so I don't have to worry even when the tree grows back. Neither do the jackdaws. SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk >> I am always having problems, but the causes are not so mysterious. The >> nearly dozen trees, yeah trees not branches, slung in the phone trunk [quoted text clipped - 15 lines] > when they heard of this problem, so I don't have to worry even when the > tree grows back. Neither do the jackdaws. Yeah didn't me to get off track on a tear, but the data line had a hum so loud that the technician could not understand me on that line! Just got it fixed. and extremely corroded terminal block at street-side. Just galls me that I am in the richest country in the world but we are "3rd world" in our communications infrastructure. SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com >> > And non-conformance _is_ a bug, by definition. >> [quoted text clipped - 3 lines] > deliberate choice against the standards, it is an unhappy > description of it as a bug. I'm equally happy with your definition :) It's mainly just a matter of choosing what to quibble with Mr Korpela about. This mistake/non-conformance distinction was tangential to the main point which concerned the definition of a quirk. Of course there is a difference between something that doesn't work as intended and something that does but where the intention differs from the specification (which actually sometimes is a quirk). But often the word "bug" is just used to mean "something which needs fixing", which covers both. Formally you can (only?) show that something's wrong with a program by demonstrating its failure to conform to a specification, usually with a test case. You could argue that a deliberate choice against the standards is correct but according to a different specification and therefore not a bug (even on Mr Korpela's definition). How reasonable that is depends on the absurdity of what you're claiming as a specification. So the definition of bug as non-conformance still works in these cases. Scripsit Ben C: >> It looked too complicated. The message seems to discuss CSS issues, >> yet it's in the HTML group. Are you referring to HTML or CSS >> conformance? > > CSS conformance. However, doctype sniffing affects the rendering even when no style sheet is present. Actually we can use style sheets to _nullify_ the effect of doctype sniffing in these issues, by adding explicit rules for margins (adding a wrapper for the "loose" or "anonymous" text if needed). > Section 3.2 (of CSS 2.1) explains that to claim conformance you have > to do the cascade and give every element a value for every applicable > property. Yes, but does this exclude the possibility of affecting the rendering with something external to CSS? > But is there anything to say that the initial value of a property > (which may be pink) can't depend on the day of the week? Well it > doesn't say that specifically I suppose, but only because it's > obviously ridiculous. Why would that be ridiculous? Browsers are allowed to have different default rendering for documents, or different browser style sheets. Why couldn't a browser have different defaults in different days. I think you agree that a browser update might modify the defaults; it changes the browser to a slightly different browsers. Why couldn't the defaults change otherwise? Or we could just define the different behaviors as updates. :-) SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit Ben C: > [quoted text clipped - 6 lines] > However, doctype sniffing affects the rendering even when no style sheet > is present. Well in some browsers (Firefox at least) one of the results of doctype sniffing is a different default stylesheet. > Actually we can use style sheets to _nullify_ the effect of > doctype sniffing in these issues, by adding explicit rules for margins > (adding a wrapper for the "loose" or "anonymous" text if needed). Only in some of these issues. There are two kinds of quirk: those you can achieve with a default style, and those where you need to implement special behaviour. An implementor might achieve the latter by inventing special properties like -moz-first-node, but it doesn't change the fact that he's having to implement behaviour that isn't in the CSS specification. An example of the first kind of quirk is form { margin-bottom: 1em } which Firefox applies in quirks mode (i.e. as a result of doctype sniffing). You might say that's not a quirk, it's just a different default style. I'm inclined to call a "quirk" anything that gets turned on by doctype sniffing. >> Section 3.2 (of CSS 2.1) explains that to claim conformance you have >> to do the cascade and give every element a value for every applicable >> property. > > Yes, but does this exclude the possibility of affecting the rendering > with something external to CSS? Not in general. For example, suppose instead of the usual toolbar, you alpha-blended "Home" etc. buttons on top of the actual page itself. Someone could argue: I set that div to background-color: red and the stacking rules mean it's on top. So it should be red. Why's it greenish pink and why can I see a picture of a house on it then? But that would be a poor argument. It's clear that this hypothetical browser has rendered the page according to the rules, and then drawn some extra controls on top of it. You might say that's a stupid place for a toolbar, but it doesn't really count as CSS non-conformance. But what about IE's habit of leaving gaps of 3px between floats? You could say: IE conforms to CSS, and then it moves things a bit. This isn't a non-conformance, it's just a feature external to CSS that affects rendering. But that would clearly be rubbish. It's obvious that the 3px gap is a non-conformance to CSS, which says explicitly that floats' margin edges should go flush next to one another. >> But is there anything to say that the initial value of a property >> (which may be pink) can't depend on the day of the week? Well it [quoted text clipped - 8 lines] > change otherwise? Or we could just define the different behaviors as > updates. :-) I hadn't thought of doing it like that-- I was proposing a different initial value on different days, and a constant default stylesheet that doesn't set background-color for <p> at all. The specification doesn't say that the initial value has to remain constant from one day to the next, but only because it doesn't rule out every ridiculous possibility. But I suppose I have to concede that there would be nothing wrong with different default stylesheets for different days of the week. Or days of the year. You might set <p> to green on St Patrick's day for example. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.