Closed
Bug 17309
Opened 25 years ago
Closed 25 years ago
Caching needs to be re-enabled when the cache is fixed.
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Core
CSS Parsing and Computation
Tracking
()
M16
People
(Reporter: pierre, Assigned: attinasi)
References
()
Details
(Keywords: perf, Whiteboard: [PDT-]Waiting for cache)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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?
Reporter | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [dogfood]
Target Milestone: M12
Comment 1•25 years ago
|
||
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.
Comment 2•25 years ago
|
||
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.
Reporter | ||
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
It might become less and less legible, but it's more legible than nothing.
Comment 5•25 years ago
|
||
Submitted the preference as bug #17322.
Comment 6•25 years ago
|
||
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.
Reporter | ||
Comment 8•25 years ago
|
||
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.
Comment 9•25 years ago
|
||
> - 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.
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
Urp. Sorry about that. Make that URL: http://jadzia.bu.edu/~mattdm/csstest/
Reporter | ||
Comment 14•25 years ago
|
||
Yes... Style sheets are not cached yet.
Comment 15•25 years ago
|
||
Filed the "disable clicks after reflow idea" as bug #17942.
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
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...
Comment 18•25 years ago
|
||
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?
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
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.
Comment 21•25 years ago
|
||
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...
Comment 22•25 years ago
|
||
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?
Comment 23•25 years ago
|
||
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...
Comment 24•25 years ago
|
||
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...
Comment 25•25 years ago
|
||
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).
Comment 26•25 years ago
|
||
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).
Comment 27•25 years ago
|
||
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.
Comment 28•25 years ago
|
||
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.
Comment 29•25 years ago
|
||
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.
Comment 30•25 years ago
|
||
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.
Comment 31•25 years ago
|
||
The media attribute/pseudoattribute/@import allows different stylesheets for
different media.
Reporter | ||
Comment 32•25 years ago
|
||
*** Bug 19549 has been marked as a duplicate of this bug. ***
Comment 33•25 years ago
|
||
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.
Reporter | ||
Comment 34•25 years ago
|
||
See bug 17325 for timer based reflows and the following thread on the same topic:
news://news.mozilla.org/81cumq%24ndd1%40secnews.netscape.com
Reporter | ||
Comment 35•25 years ago
|
||
Interesting comments can be found in bug 16050 that will be closed as duplicate.
Reporter | ||
Comment 36•25 years ago
|
||
*** Bug 16050 has been marked as a duplicate of this bug. ***
Comment 37•25 years ago
|
||
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.
Reporter | ||
Updated•25 years ago
|
Target Milestone: M12 → M13
Updated•25 years ago
|
Comment 38•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Target Milestone: M13 → M14
Updated•25 years ago
|
Reporter | ||
Comment 39•25 years ago
|
||
*** Bug 23295 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 40•25 years ago
|
||
*** Bug 24484 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 41•25 years ago
|
||
*** Bug 25378 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 42•25 years ago
|
||
*** Bug 22356 has been marked as a duplicate of this bug. ***
Comment 43•25 years ago
|
||
Can you quantify the performance difference from 4.7?
Reporter | ||
Comment 44•25 years ago
|
||
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.
Comment 45•25 years ago
|
||
At times, the browser just does not load the style-sheet, and the plain HTML is
rendered. Even reloads do not work then.
Comment 46•25 years ago
|
||
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.
Comment 47•25 years ago
|
||
Adding myself to the CC list..
Comment 49•25 years ago
|
||
Sent to rick for a call on dogfood vs. beta....PDT+ vs PDT-.
Keywords: dogfood
Comment 50•25 years ago
|
||
I'd like to see this fixed for beta; marking PDT+.
Whiteboard: Waiting for cache... → [PDT+]Waiting for cache...
Comment 51•25 years ago
|
||
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.
Comment 52•25 years ago
|
||
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.
Comment 53•25 years ago
|
||
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!)
Comment 54•25 years ago
|
||
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.)
Comment 55•25 years ago
|
||
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.
Assignee | ||
Comment 56•25 years ago
|
||
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...
Assignee: pierre → attinasi
Status: ASSIGNED → NEW
Assignee | ||
Comment 57•25 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 58•25 years ago
|
||
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.)
Comment 59•25 years ago
|
||
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.
Comment 60•25 years ago
|
||
Is this fix in the nightly build?
Assignee | ||
Comment 61•25 years ago
|
||
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.
Reporter | ||
Comment 62•25 years ago
|
||
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.
Reporter | ||
Comment 63•25 years ago
|
||
Ooops. Please read "I'm NOT sure that caching the stylesheets..."
Comment 64•25 years ago
|
||
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?
Status: RESOLVED → VERIFIED
Comment 65•25 years ago
|
||
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/
Status: VERIFIED → REOPENED
Keywords: beta1
Priority: P1 → P2
Resolution: FIXED → ---
Summary: Wait for primary style sheets before constructing frames → Don't block parser when waiting for primary stylesheets
Whiteboard: [PDT+]Waiting for cache... → Waiting for cache; Backoff time before first reflow should be tweaked.
Target Milestone: M14 → M15
Reporter | ||
Comment 66•25 years ago
|
||
Thanks for the test pages, Ian. And I guess you're right about the expiration
date.
Status: REOPENED → ASSIGNED
Comment 67•25 years ago
|
||
Putting on the PDT- for dogfood.
Whiteboard: Waiting for cache; Backoff time before first reflow should be tweaked. → [PDT-]Waiting for cache; Backoff time before first reflow should be tweaked.
Comment 68•25 years ago
|
||
Adding myself to the CC list...Sorry for the spam!
Comment 69•25 years ago
|
||
I quickly checked this out on the latest M14 build and it *appears* fixed to me.
Comment 70•25 years ago
|
||
On second look, I see that it only works intermittently. Sometimes the
stylesheets entirely fail to load.
Reporter | ||
Comment 71•25 years ago
|
||
The problem with stylesheets that fail to load is described under bug 29370
"Stylesheets are not always loaded" assigned to attinasi.
Assignee | ||
Comment 72•25 years ago
|
||
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...
Assignee | ||
Comment 73•25 years ago
|
||
Reporter | ||
Comment 74•25 years ago
|
||
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.
Assignee | ||
Comment 75•25 years ago
|
||
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.
Assignee | ||
Comment 76•25 years ago
|
||
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.
Assignee | ||
Comment 77•25 years ago
|
||
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.
Summary: Don't block parser when waiting for primary stylesheets → Caching needs to be re-enabled when the cache is fixed.
Whiteboard: [PDT-]Waiting for cache; Backoff time before first reflow should be tweaked. → [PDT-]Waiting for cache
Target Milestone: M15 → M16
Reporter | ||
Comment 78•25 years ago
|
||
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
Reporter | ||
Comment 79•25 years ago
|
||
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.
Assignee | ||
Comment 80•25 years ago
|
||
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?
Comment 81•25 years ago
|
||
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.
Comment 82•25 years ago
|
||
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.
Assignee | ||
Comment 83•25 years ago
|
||
Mikeque - Yes, bug 34257 has been entered on that and I am fixing it right now.
- thanks.
Assignee | ||
Comment 84•25 years ago
|
||
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...
Assignee | ||
Comment 85•25 years ago
|
||
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 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•