This bug has been extracted from #16616 where the reporter provided an URL where the problem is particularly visible. Go to http://www.mnot.net/personal/ with AppRunner and notice how the page is rendered in 2 passes. The following comment was added by sidr@albedo.net: Tried with 1999-10-15-11-M11 on Windows NT. The page appeared with no CSS at all within a second, and a second later changed to match the appearance it gets from Navigator 4.7. Exactly what one would expect if the stylesheet, linked in with LINK, has to wait its turn from an HTTP 1.0 server, and the browser is able to render the page before the stylesheet arrives. M10 may well have failed to use the stylesheet, but the present behaviour seems OK. It begs the question, though: should there be a short delay to wait for the LINKed stylesheet, counting perhaps 4-5 seconds from the first GET, non-renewable, so that short pages do not get rendered twice, once without and once with stylesheet mojo?

In situations like this that can cause a reflow after loading (eg images and alt text), there should be a user choice between quick loading and accurate loading. The latter would not show anything that is not set in stone.

The suggestion of a preference choice between fast and accurate loading makes perfect sense to me, but for it to work well in practice there would also need to be an associated timeout, possibly hidden away in prefs.js, possibly exposed in the Pref UI. The timeout would be a number of seconds after which what can be displayed, is, even if the LINKed stylesheet is not completely loaded, or never started arriving. What to do in the UA to inform the user that the page does not appear as intended due to lack of a stylesheet is an open question. Adding a preference is of course an RFE, but without a preference the only way I see to address this is with a compromise waiting time before display that would likely be called wrong by most, not because it is, but because it is arbitrary and they didn't choose it. Possible Pref UI snippet (draft): (*) Display page immediately; update as stylesheet arrives ( ) Wait up to [15] seconds for stylesheet, then display page. Where the "( )"s are radio buttons, and the "[ }" is a text box.

The opinion here is that over time style sheets will become more and more necessary for a correct rendering, meaning that the temporary display of the page will become less and less legible. The conclusion was that we should wait for primary style sheets, while making sure we don't wait for secondary style sheets until the user requests that a secondary sheet become a primary sheet.

It might become less and less legible, but it's more legible than nothing.

Submitted the preference as bug #17322.

Regardless whether a preference is made available for "quick loading" vs. "accurate loading," a timeout on waiting for the stylesheet to arrive before displaying the page is necessary, and I'd argue that it should be user-configurable. The point-of-view articulated by pierre does make sense, but if the default (or only, if the RFE in bug 17322 is declined) behaviour is going to be to make the user wait for the stylesheet, it is obviously not reasonable to allow that wait to extend to forever, and as I said earlier, *any* arbritrary value will seem wrong to at least a large minority. There are two other issues here. 1. The first is network reliability, cogent because LINKed stylesheets may well be absolutely necessary for proper display of an HTML (let alone XML) page - the linked primary stylesheet is, logically, part of the page even if it arrives in response to a separate GET. A certain fractiobn of dropped packets are a reality at least some of the time (e.g., after a fiber cut or flooded exchange point), and if the packet dropped is the original GET for the primary stylesheet, it won't arrive without another GET being sent. To ensure that the primary stylesheet does arrive, would it make sense to send a second GET around five seconds before the display timeout is done (or when it is done, if the display timeout is less than or equal to, say, 8 seconds)? 2. The second issue the difference in page-loading latency between a UA on a LAN connected to a T1 or better, and a UA on a machine connected to an ISP with a 56k or slower modem. The display timeout appropriate for the former will in many cases be far too fast for the latter, especially if there is any other network activity on the modem link (personally, first thing in the morning, my mail agent is getting 50-100 messages while I bring up the first one or two websites, and then there's ftp d/l while browsing). Conversely, a timeout long enough to be reasonable for a modem link is likely to seem consistently annoying to users with a LAN link. All of this in (2) would become less of a problem if a fix is made for (1), so that the problem of waiting forever would be less likely to occur, but note that the issue of differential latency in (2) then becomes relevant to the re-GET timeout in (1).

In the case of a dropped packet, shouldn't the TCP layer retransmit the GET request? There shouldn't be any need for Mozilla (application layer) to do a second request.

I think that we should wait for all the persistent/preferred style sheets whether they are linked directly from the html document or imported from other style sheets for the following reasons: - Style sheets can still be perceived as a cosmetic enhancement for now but we may quickly be moving to a world where they define the base of the UI (they are already necessary for XML documents) and it means that display with a partial set of style sheets will become more and more meaningless. - When an application (web browser or other) displays something, it must either be based on the final data or there must be a clear feedback that there is something in progress, as we have for instance when receiving a GIF image or when drawing the result a mathematical simulation. - There are some security issues in displaying invalid data and then displaying the correct data without warning. Imagine a page with a form containing various buttons. You display what you can based on the style sheets you receive, then the user moves the mouse and just when he's about to click the "SELL" button, you receive the last style sheet and your new layout puts the "BUY" button underneath the mouse cursor. Bingo! - I wouldn't be able to explain my parents why some web pages change spontaneously and so dramatically without them doing anything. If we keep that way, I'm sure they will see even more magic in their browser. They may even become scared of it. However, I'm still in favor of dying silently when a style sheet cannot be obtained (ie. file not found or network error) and, of course, displaying what we can if the user clicks Stop.

> - There are some security issues in displaying invalid data and then > displaying the correct data without warning. Imagine a page with a > form containing various buttons. You display what you can based on the > style sheets you receive, then the user moves the mouse and just when > he's about to click the "SELL" button, you receive the last style sheet > and your new layout puts the "BUY" button underneath the mouse cursor. You'd better put the same comments on the bugs on bug #1994, bug #17322 and bug #854 because it applies to all of them too. > - I wouldn't be able to explain my parents why some web pages change > spontaneously and so dramatically without them doing anything. If we keep\ > that way, I'm sure they will see even more magic in their browser. They > may even become scared of it. Same as above. You have to realise that this can happen when a page is loading. It's a fact you'll learn just as with any program. I'm trying to not make this sound like an insult, but if someone becomes scared of a browser because the style changes while page is loading, then they shouldn't be using a web browser. I'll assume they wouldn't. It shouldn't be too hard for any non-techie to understand a content/style distinction. People know that text is text no matter where it is, what colour it is and how big it is. So you could explain it. =) What will happen when the DOM is used a lot? Any sort of "magic" could occur - but then I guess that's not a browser problem. But either way, I do care about this, and I'm not enthused about this situation, which is why I submitted bug #17322. I'm not saying I support this either way - I don't really know what to do about this. I certainly hope stylesheets are getting the highest load priority, even higher than the page (if possible). A delay would certainly be feasible too. And just waiting is certainly an option. I assume that's what NN4 did. I'm not sure what you mean by "dying silently", but I think the best solution when we can't fetch the stylesheet is a dialog similar to the "can't fetch page, retrieving from cache" that you find in NN4.

Peter Linss and Ian Hickson had a long and very thorough discussion about these issues when Peter was writing the current code. I was cc:ed in most of the email but contributed little because I was very busy at the time. Ian, what thoughts do you have on this? I could go through my email and reread some of the reasons we all put forth at the time, but my memory is that that thread was at least a few thousand lines overall, and I don't really have time right now either. My opinion (without thoroughly considering the issues again) is that pages should never be delayed for a preferred / alternate stylesheet, but perhaps (??) should be for a persistent one. The document should be reflowed once when *all* persistent stylesheets arrive, and again when *all* of the sheets in the current preferred set arrive (assuming that the persistent sheets have arrived already). (I might reconsider some of this once Ian reminds me of something I've forgotten...) However, once a timing system is in place where incremental reflows are spaced at certain time intervals when the data are arriving quickly, the stylesheet could arrive before the first reflow when the network is fast. I think seeing the progress of the page loading is a good thing.

Regarding the "pressing the wrong button" problem, should we, upon reflow, disable all mouseovers and mousedowns for a period longer than standard reflex time, say 1 or 2 seconds? At least in the sections that have reflowed.

It's important to note that this problem happens even if the style sheet is (or at least should be!) already in memory. Check out <A HREF="http://jadzia.bu.edu/~mattdm/csstest/">http://jadzia.bu.edu/~mattdm/csstest</A> for an example. (Flip through the pages to get an idea of how annoying it would be to, for example, read a book this way.) All of the pages (in Test 1) use the same style sheet, so, while there may be a problem with the very first one, all of the rest should display with the style applied right away.

Urp. Sorry about that. Make that URL: http://jadzia.bu.edu/~mattdm/csstest/

Yes... Style sheets are not cached yet.

Filed the "disable clicks after reflow idea" as bug #17942.

Ok. So that makes this a LOT less of a problem in my mind -- when caching of style sheets is implemented, the most annoying aspect of the problem will go away.

I think it is important that pages _do_ reflow before the first stylesheet is received, especially if the first stylesheet is taking its sweet time about it. I also think that it is important that: 1. all persistent and preferred stylesheets be used together -- if only one is available, do _not_ use it as it more than likely depends on the others. 2. whatever happens, do not reflow until all rel="important stylesheet" have been fetched and are ready. (Excluding alternate importants, of course.) 3. No alternates be fetched before they are needed. (Unless they are being pre-cached, well after the document and all more important resources have been downloaded.) Try the following test pages to see why: http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-persistent.html http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-alternate.html http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-import.html http://www.bath.ac.uk/%7Epy8ieh/ite/loop.html http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-persistent-short.html http://www.bath.ac.uk/%7Epy8ieh/ite/loop-self.html (Tests 72-77 of the ImportTest.) David: My e-mails on the thread you mention have all been archived in cold storage, several kilometers from my present location. If you still have them handy, feel free to forward them all back to me en masse, and I will reread them to refresh my memory of issues that we have forgotten...

Ian: Firstly you say it's OK to flow without a stylesheet if it's taking its time, then you say it's not OK to have one stylesheet yet not another. Surely, one stylesheet is going to be more accurate than none? Hence, given that reflows will hopefully eventually be done on time intervals, why not?

It's bad because if there are things in separate stylesheets that, combined, make the page legible, but cause serious problems when one is used but not the other, then reflowing with only one stylesheet could cause serious problems. Authors shouldn't have to worry about what happens to their pages when only some of the stylesheets are loaded. It's complicated enough to design accessible pages using CSS.

But wouldn't it often be better to show one style sheet than none? I think the real answer is to look at typical pages using multiple stylesheets and visually determine which is better.

No. Suppose that a company has a company style sheet, and a group within that company has another stylesheet that assumes the former will always be used (and they don't use @import because some browsers don't support it). They wouldn't want the latter to be applied without the former. Stylesheets are designed to be optional, but not take one and drop the other...

Yes, but where there is no browser stylesheet support, ie for a site's own XML language, your argument extends to not showing anything at all before the stylesheets arrive, for reasons pierre has mentioned. I don't really mind either way, but I feel it should be consistent - either don't show anything at all until all stylesheets arrive, or reflow when anything new arrives, maybe even when only part of the stylesheet has arrived. So what to do if one of two stylesheets fail? Show with no stylesheet? If not, would it matter is it's higher or lower in the cascade?

Responses by paragraph: 1) I and many others don't think arbitrary XML vocabularies are the way of the future. They destroy acessibility and device-independence. Stylesheets should *always* be optional. 2) Designing accessible stylesheets is really complicated, in ways very few people understand. It's even worse to make the author of pages linking multiple stylesheets make sure that the page is accessible with any set thereof. If @import worked correctly in older browsers, then I'd say that each linked stylesheet could be displayed separately, with all it's @imported sheets, but that isn't the case. You could change my mind on this to agree that once each *sheet* is complete, it can be used. However, you should NEVER use part of a sheet. 3) If a stylesheet failed, we should pretend it didn't exist, because there's nothing better to do. They shouldn't fail. And author stylesheets are all at the same level of the cascade...

I agree with David on everything he's said so far except that I would *never* agree that "once each sheet is complete, it can be used". Apart from the very important issues David has mentioned, there is the original issue again: if you use each sheet as it comes, then you have even more reflows that you do now! Try explaining _that_ to your mother. Currently, we only have two instances of reflows: The incremental reflows that occur as the markup comes in, and the once-off stylesheet reflow once the markup is in and the stylesheets are all available. There is also the concept of blocking loading stylesheets, of which rel="important stylesheet" is one kind, and XML documents' persistent stylesheets are another. Oh, yes, BTW: We already do the blocking-loading thing with XML docs...

There is a test case for the XML blocking stylesheet thing at: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/xml-style/7.xml On thinking about it, we don't really want to be blocking for XML documents. After all, the ua.css file is quite likely to have apply (e.g., with XHTML, XUL, or MathML documents).

Exactly. XML on the web will be almost entirely of known semantics. Either the browser will understand it and have a default stylesheet for it, or the browser won't understand it and a simple stylesheet won't help (e.g., MathML, Extended HTML Forms (unless CSS3 is really good), SVG).

One way to put the page author in a position to ensure that stylesheets are available prior to layout would be to have the browser fully support the rfc2557 MHTML standard, so that the stylesheets could arrive as part of the same HTTP connection as the HTML (or XHTML or XML) document. Bug 18764 "RFE: Full rfc2557 MHTML multipart/related support in BROWSER" created to inquire whether this is reasonable or desirable to do. The implication here is that such an implementation would provide a viable alternative to whatever is decided for this bug, potentially giving more room to manouever in making that decision.

Authors could add the proprietary "important" keyword to the list of keywords in the rel attribute of the link element, e.g., rel="important stylesheet" (or rel="stylesheet important") to do what you want without resorting to RFC2557.

Providing a sensible interpretation for "important" does make sense, so long as it is well-thought-out so the behaviour provided would stay stable into future versions. It doesn't make sense to overload that keyword, though, to mean "required". Adding a behaviour for a "required" keyword (and the keyword itself if it is not supported) would provide a true alternative to rfc2557 MHTML in the browser, and, if "important" were also supported as suggested, provide the author with two levels of escalation, which ought to be enough. If "required" was dependably interpreted and supported in all future versions as just that, support for MHTML in the browser would probably be unnecessary for this purpose. In fact, I couldn't advocate the latter without some clear and unmistakable way for authors to signal that a LINKed stylesheet was required, lest MHTML get overused or abused.

Added another RFE for the "required" keyword - bug 18777. I suspect that that suggestion may be controversial - in that case, discussion belongs over there. One last possibility: does anyone know what is proposed to ensure that single- source-for-multiple-purposes XHTML documents send the correct stylesheet to the correct "browser", from cell-phone to stadium display? In such a case, the document would be unviewable on the cellphone without the stylesheet, so this problem may have already have received thought from those working on XHTML.

The media attribute/pseudoattribute/@import allows different stylesheets for different media.

*** Bug 19549 has been marked as a duplicate of this bug. ***

I suspect that the symptoms that are bothering people on this bug will be largely fixed when the following are working: * cache * timer based reflow Perhaps you should wait for these before deciding how to handle this bug.

See bug 17325 for timer based reflows and the following thread on the same topic: news://news.mozilla.org/81cumq%24ndd1%40secnews.netscape.com

Interesting comments can be found in bug 16050 that will be closed as duplicate.

*** Bug 16050 has been marked as a duplicate of this bug. ***

For your convenience, here's the main text of bug 16050: ------------------------------------------------------- Having spoken with peterl at great length about this, I understand the issues involved here. I argued that stylesheets could load progressively, performing a reflow after a certain calculable timeout. He argued that in some circumstances, a stylesheet might load very slowly, and that cascading rules later in the document might override rules that were already loaded and rendered; which is worse than having no style at all, in his opinion. We seemed to be both pretty much in agreement that using <link rel="important stylesheet" ...> was a somewhat inadequate way of going about things, but I respectfully disagree with the argument that no style is better than wrong style. Granted, wrong style can be pretty egregiously wrong, in some rare cases. People may very well design stylesheets which overload rule after rule, where each overload changes the look of things completely. But I think in the vast majority of cases, cascades describe either extra information (in which case the rendering isn't "wrong" per se, just incomplete) or slight adjustments (in which case the rendering is only slightly wrong). I also believe that out of these cases, most pages will load fast enough that the problem is moot. This leaves us with only a very small percentage of documents where the rendering stays "appreciably wrong" for a significant amount of time, and we score a big win for the other cases. Furthermore, ignoring probabilities for a moment, it's just plain silly to have a styled document render *even once* without at least a portion of its styles (if not all), especially if the document and stylesheet are downloading fast enough. So I propose the following solution: 1. There shouldn't be too many reflows of a page, so calculate a certain threshold (maybe based on time, download rate, document size, etc.) after which the document re-renders. 2. Two downloads are occurring: the document and the stylesheet. The stylesheet may import others, which may pose a problem to this proposal, but just assume that all stylesheets being downloaded are grouped as one. With this, follow this algorithm (or something similar): -- If a new stylesheet rule is received which applies to elements already received: if those elements have already been rendered, schedule a reflow (for when the next threshold gets hit); otherwise just keep this rule for later. -- If a new stylesheet rule is received which applies to no elements already received: keep this rule for later. -- If a new document element is received: do the regular incremental reflow thing as is already done. ------------------------------------------------------- Having read all of your comments, I understand there are further complexities that I don't think my solution considered, but I still believe it may be reasonably modified, and strongly stand by my statistics (even though I agree with dbaron wholeheartedly on his principles) and I'm willing to back them up by writing a spider to grab css files and keep stats on them. (nb. please don't make me do that). I also think that the thresholding should be good enough for pierre's mom... Let me know what you think.

Ok, this bug now depends on The Cache Bug 8305 and The Timed Reflow Bug 17325. I concur with David, we should wait for the cache and incremental reflows to be working properly before investigating what to do with this bug.

*** Bug 23295 has been marked as a duplicate of this bug. ***

*** Bug 24484 has been marked as a duplicate of this bug. ***

*** Bug 25378 has been marked as a duplicate of this bug. ***

*** Bug 22356 has been marked as a duplicate of this bug. ***

Can you quantify the performance difference from 4.7?

It's not just a question of performance. It it was just 2 or 3 times slower (which is about correct), I'd say "ship the beta, we'll optimize later" but the problem is especially annoying because of the flicker. We start displaying the page, then we throw everything away, erasing completely the page and we redraw it with the newly arrived style sheets. It's already bad on a T1 and it gets much worse over a phone line when the style sheets take more time to download.

At times, the browser just does not load the style-sheet, and the plain HTML is rendered. Even reloads do not work then.

The previous problem (style sheet not loading at all) happens mostly when you load the same url with different parameters which change the contents (a PHP script, say). However, this occurs for static pages as well. Go to http://members.xoom.com/Biswapesh/ for an example. You'll have to persist for a while to see this in action , however, since the occurence is unpredictable.

Adding myself to the CC list..

Adding perf keyword.

Sent to rick for a call on dogfood vs. beta....PDT+ vs PDT-.

I'd like to see this fixed for beta; marking PDT+.

The mailnews message pane also includes a linked style sheet. So we also see this extra pass. Fixing this bug will help with our own efforts to make displaying messages faster. so I'm adding myself to the cc list.

mscott: How is your stylesheet linked? Depending on how it is done (or possibly no matter how it is done), there are currently some Mozilla extensions to make stylesheets blocking. This would be useful for stylesheets in the UI.

It looks like every time we load a message body into the message body, iframe we link in the following two style sheets: i.e. the mime emitter generates the following html (excuse the method wrappers around it) UtilityWriteCRLF("<HTML>"); UtilityWriteCRLF("<HEAD>"); // mscott --> we should refer to the style sheet used in msg display...this one is wrong i think. // Stylesheet info! UtilityWriteCRLF("<LINK REL=\"STYLESHEET\" HREF=\"chrome://messenger/skin/mailheader.css\">"); // Make it look consistent... UtilityWriteCRLF("<LINK REL=\"STYLESHEET\" HREF=\"chrome://global/skin\">"); UtilityWriteCRLF("</HEAD>"); UtilityWriteCRLF("<BODY>"); then we write out the mail body..... Does this answer your question? (Thanks for helping!)

mscott: If you change the REL="STYLESHEET" to REL="IMPORTANT STYLESHEET" it should make the stylesheet blocking, assuming the code that does that is still there. ("stylesheet important" should work equally well.)

dbaron: thanks for the tip! This helped a lot. By forcing the style sheet to do a blocking load, we don't get a double load effect when viewing the message where it flickers twice before it's done. I owe you one.

Simple fix in nsHTMLDocumentSink.cpp, where the CSSLoader is invoked. I put in #ifdef to disallow asynch style sheet loading. This makes the pages load beautifully. I tested this with style sheets at bogus urls and it displays the pages immediatly (without style, of course). There could be issues if the style sheet takes a very long time to load, like it is served from a slow Microsoft web server or across a slow connection, however the vast majority of the cases will be MUCH better with this change to load external style sheets synchronously. Oh yea, I test @import and LINK REL forms of external stylesheets, both benefit. Checkin pending review...

Fixed: External Stylesheets are always loaded synchronously now. Changed: nsHTMLContentSink.cpp r=troy,pierre. Thanks to dbaron for pointing out the power of the IMPORTANT keyword in the external stylesheet syntax, as that is what made this an easy fix.

EEEK!!! That is the WRONG fix!!! Try the following test pages to see why: http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-persistent.html http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-alternate.html http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-import.html http://www.bath.ac.uk/%7Epy8ieh/ite/loop.html http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-persistent-short.html http://www.bath.ac.uk/%7Epy8ieh/ite/loop-self.html (Tests 72-77 of the ImportTest.) As has been explained many times above (see particularly messages by either dbaron@has.harvard.edu (David) or py8ieh=bugzilla@bath.ac.uk (me)), this will be 99% fixed by: (a) caching stylesheets, (b) having a backoff time before rendering a page. The first will solve the problem for pages that use the same stylesheet as others on an already-visited site, the second will solve the problem for the first page of a site. I believe that code for these two should already be around, it is just a matter of getting them to work for stylesheets. Are stylesheets cached? How long is the backoff time at the moment? (backoff time = maximum time to wait before starting to construct frames for what has been parsed so far.)

I strongly agree with Ian. This fix should be reconsidered once the cache is working (why is beta1 being released without a disk cache?). Once the cache is working, there will be much less waiting for stylesheets to come in. It would be acceptable to modify the backoff time because of stylesheets. For example, you could wait 200ms to do the first reflow, except wait 1s (or until the stylesheets arrive) if there are stylesheets that you're waiting for. When I browse over a 28.8 modem, I don't want to wait for stylesheets to come in to see if the text is worth reading. You should not wait 10s for a stylesheet to come in.

Is this fix in the nightly build?

Wrong fix??? I disagree (naturally). I think this is the right fix for this time. This is a stopgap fix, there ARE still issues with large (or slow) stylesheets - I documented that in my comments on 2000-02-15 20:18. The consensus is that for a beta release it is more important to have the majority of styled pages look good (ie. render once with style applied instead of rendering without style then rendering again with it) than to worry about the less common (or even contrived) case where the stylesheet take a very long time to deliver. There are better solutions but none that are simple enough for me to slip in for the beta release. IE4 and Nav4 both act this way... which isn't to say that it is correct, but is to say that it is compatible. Compatibility concerns aside, though, I do agree that caching stylesheets and having a backoff time before rendering a page are the better solutions, they are more complicated and riskier too. We probably need to re-open this bug without the PDT+ dogfood beta1 decorations and make it clear that the backoff-time and caching are the key to getting it *really* right.

This is the right fix for now. At least the beta won't suck any more than any other browser. I'm sure that caching the stylesheets would be the panacea (we still have to load them the first time we access the page) and I'm not even sure we are allowed do it (they don't have an expiration date). At the best, it would have to be a per- session cache. An ephemeral cache and a smarter way to calculate the backoff time seem to be the way to go.

Ooops. Please read "I'm NOT sure that caching the stylesheets..."

Ok, as a *temporary* *stop-gap* measure for beta1, making stylesheets blocking is reasonable. VERIFIED. Sites that before used to have flicker on every page, e.g. http://www.bath.ac.uk/%7Esu8buncs/ ...now just have a delay before the page comes up. Pages with very, very slow loading stylesheets, such as: http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-persistent.html ...just take an age to display anything. pierre: I don't see why stylesheets wouldn't have an expiry date. Everything has an expiry date, if it's served by HTTP. No?

Ok, I'll now reopen this bug and remove the beta1/PDT+ markings. Updating summary. Pushing milestone off to M15. Reducing priority to P2. We now need to stop blocking the parser when waiting for the primary stylesheets, and instead implement a backoff time between getting the first packet and doing the first reflow. We also need to ensure that stylesheets that can be cached _are_ cached, so that we don't have to redownload the entire stylesheet for each page of a site when every page uses the same sheet. To see why we must not block, look at this test page: http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-persistent.html To see why we must have a backoff time, see these pages: http://www.bath.ac.uk/%7Esu8buncs/

Thanks for the test pages, Ian. And I guess you're right about the expiration date.

Putting on the PDT- for dogfood.

Adding myself to the CC list...Sorry for the spam!

I quickly checked this out on the latest M14 build and it *appears* fixed to me.

On second look, I see that it only works intermittently. Sometimes the stylesheets entirely fail to load.

The problem with stylesheets that fail to load is described under bug 29370 "Stylesheets are not always loaded" assigned to attinasi.

I have a partial solution for this now: When the first external non-alternate style sheet is loaded it blocks the parser, however it also sets a timer in the ContentSink. When the timer expires we resume the parser. This gives us a backoff time, defined by the timer duration, and prevents waiting a *really* long time for very slow style sheets. I would have preferred to keep the parser running and just block any content creation, however it was getting too complicated and affecting too much code in the content sink. (The backoff timing code in the content sink should probably be looked at again with this purpose in mind as well.) The remaining problem is that memory and disk caching are not working and have been disabled in style sheet loading. When the cache is fixed we can re-enable the use of it. I currently have the timer defaulting to 5 seconds; that means that style sheets that take more than 5 seconds to load will cause a reflow when they do complete loading because after waiting a default of 5 seconds the parser will be resumed and non-styled or partially-styled content will be displayed. Also, it means that there can be up to 5 seconds of blank display while waiting for the style sheet. The actual time should probably be more like 2 or 3 seconds, however my net-link is so pathetic today that I had to put it up to 5 seconds to get any benefit from this. I will test this from home using a 56K modem to see how it works before checking in the final default value. I added code to load the value from a pref if available as well, just in case we want to tweak it at runtime later. I'll attach a diff in case anyone is interested in seeing the code...

I don't like this solution unless we set the backoff time to the same duration as the timeout we use to load HTML pages. Loading a page without some of its non- alternate stylesheets is similar to running a program with only part of the code, see what happens and then restart it when we receive another chunk. It doesn't make sense to me. Stylesheets, in my view, will not be used by web designers as a sprinkle of magic to make their pages look smart; they will be an inherent part of the design that makes the data legible. If we want to improve the speed, we should first focus on making the cache work. I know... I repeated the same thing several times in the past 6 months.

Maybe the best solution is to let the users decide if they want to wait for style sheets or not. If they do we set the timeout very high, like 30 seconds, if not we set it very low, like 2 seconds. Getting the value from the pref is done, we would just need some UI for it.

Another note on Pierre's last comment: I think some authors will rely on style sheets being there and some will not. Those that rely on the style sheet will know it and can make the style sheets !important. Those who use style to *just* pretty-up their pages but who also believe their content is more important than the presentation can skip the !important designation. We really have a solution for both kinds of uses here (while at the same time making crazy testcases like http://www.bath.ac.uk/%7Epy8ieh/ite/infinite-persistent.html function reasonably). If we make all stylesheets important we are doing a disservice to those authors who believe the content is more important than the styling.

I have put in the backoff timer, however the caching is still broken (bug 29370). I am going to change the summary and milestone rather than close this one.

I set a default timeout of 2 minutes, effectively disabling the timer. Below is a slightly modified copy of an email explaining my position. If the situation is locked because we all believe strongly in our positions, we can move the debate to a larger audience like the www-style mailing list. David wrote (1999-10-30 15:22): My opinion (without thoroughly considering the issues again) is that pages should never be delayed for a preferred / alternate stylesheet, but perhaps (??) should be for a persistent one. Ian replied (1999-11-04 19:48): I think it is important that pages _do_ reflow before the first stylesheet is received, especially if the first stylesheet is taking its sweet time about it. I also think that it is important that: 1. all persistent and preferred stylesheets be used together -- if only one is available, do _not_ use it as it more than likely depends on the others. 2. whatever happens, do not reflow until all rel="important stylesheet" have been fetched and are ready. (Excluding alternate importants, of course.) 3. No alternates be fetched before they are needed. (Unless they are being pre-cached, well after the document and all more important resources have been downloaded.) And he added (1999-12-02 06:37 ) Ok, this bug now depends on The Cache Bug 8305 and The Timed Reflow Bug 17325. I concur with David, we should wait for the cache and incremental reflows to be working properly before investigating what to do with this bug. Then both were upset because we checked in a temporary fix that makes *all* stylesheets load in blocking mode. I would tend to ignore the last episode. If we consider the previous comments, we all agree with the 3 points from Ian and we're fine with most of what David said, except that the stylesheets should be seen as "(persistent + preferred) plus (alternate)", instead of "(persistent) plus (preferred + alternate)". Overall, I think that their position is influenced by the nice concept - a long time ago when they were all debating in the WG about how cool a styled Web would be - of having optional style sheets. Web sites would still be designed with HTML and if the users happen to support style sheets, their pages would look much bettter. I'm convinced it will not work that way. For XML, it's obvious: style sheets are required. For HTML, most of the sites designed with CSS in mind will look like crap or be unsable without their stylesheets so I think that the issue of "better showing something incomplete than not showing anything at all" is a bit moot. It's more important to get the cache working correctly, that way we would have to wait for the style sheets only the first time we connect to a site. Another point to consider is that the style sheets are usually declared at the beginning of the HTML page and are the first objects to be parsed and fetched. Also many pages nowadays make use of images with links and are already unusable until they are fully loaded: the style sheets won't make much of a difference, their average size is smaller than most images. Last points: - Assuming it makes sense to preview a page without its stylesheets, the timeout would only be useful if it is relatively short (a 30 seconds timeout would not be hit in 90+% of the cases) but then the duration would have to be set in preferences (let's say 2s, 5s, 10s) because the optimal value would depend on the user's network connection. The result of all this would be a rather technical pref, obscure for most, whose benefits would be to display a crappy page during a few seconds (sometimes tenths of a second) before displaying the real page. It doesn't sound like a neat idea to me. - Internet Explorer loads the style sheets synchronously too so we won't be at a disadvantage with the competition. - Nav4x also loads the style sheets synchronously and it doesn't seem to have caused any problem. As a summary, I think we should: - make the cache work - not block for alternate stylesheets - like IE and Nav, block for the other stylesheets

In response to Marc ("If we make all stylesheets important we are doing a disservice to those authors who believe the content is more important than the styling"): - The 'important' keyword is not about the timing of the loading of the stylesheets, it's about the prioritization of the style rules (http://www.w3.org/TR/REC-CSS2/cascade.html#x11). PeterL imagined he could reuse the keyword to control the timing and force Web designers to interpret it the way *he* intended without having debated over it in any public forum (afaik) and described it in any spec. The procedure is plain wrong. The intent is, I think, equally flawed but as I suggested above, we can move the debate to www-style. - Showing unusable content and causing unexpected page reflows is a disservice to both the users and the authors. Wrong content is a more important bug than a slowness that has always existed, that nobody ever complained about or even noticed, and that can't even be quantified compared to other techniques (like picts for buttons) that are currently used to develop pages.

My apologies; I did not realize that the use of the important keyword in a LINK was proprietary. Shouldn't we be ignoring it if it is not part of the specification?

In response to pierre's most recent comment - this is an entirely different "important" - it's an extention to HTML and has nothing to do with CSS.

I've noticed that the lates build has big problems with multiple <LINK REL...> occurances in the HTML. The page loads one CSS file and then goes completely blank when it loads the others.

Mikeque - Yes, bug 34257 has been entered on that and I am fixing it right now. - thanks.

The last change I made regressed loading some pages with external style sheets. Furthermore, the change was not acceptable to the module owner so I am backing it out. Pierre and I have discussed this and have decided that the better solution is to simply block on Persistent and Preferred external style sheets, and to not block on alternates (see Pierre's comments of 2000-03-31 02:54). I am making that change now. Sorry for the regression...

The only thing left to fix here is to re-enable the cache when the memory cache is working. That is bug 29370 so I am marking this a duplicate of that bug. *** This bug has been marked as a duplicate of 29370 ***

VERIFY duplicate