Closed
Bug 16050
Opened 26 years ago
Closed 26 years ago
css styles rendered after page load
Categories
(Core :: CSS Parsing and Computation, enhancement, P3)
Tracking
()
People
(Reporter: dr, Assigned: peterl-retired)
References
()
Details
In M10 on Win98, pages with CSS styling seem to completely load and display
without the styling, and then refresh with the styling afterwards.
| Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
| Assignee | ||
Comment 1•26 years ago
|
||
This is by design. When encountering linked stylesheets in HTML documents we do
not hold the rendering of the document until the stylesheets are fully loaded.
Loading the stylesheets can take a significant amount of time (depending on the
site).
The author can override this behavior by 1) putting all stylesheets inline; or
2) setting the "rel" of the link to "important stylesheet".
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 2•26 years ago
|
||
Verified invalid.
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.
Anyway, I'm reopening this bug as an enhancement request, and it would be great
to see some discussion on this.
Updated•26 years ago
|
Whiteboard: 12/1/99: Memo sent to pierre review
Updated•26 years ago
|
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: INVALID → DUPLICATE
Comment 4•26 years ago
|
||
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Whiteboard: 12/1/99: Memo sent to pierre review
Comment 5•26 years ago
|
||
Verified dup of #17309
You need to log in
before you can comment on or make changes to this bug.
Description
•