be used. That
would avoid the reflow except where Ahem is actually used, which
seems like the way things ought to work.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built
087536
But we still rebuild style data from the style rules using the
normal codepaths; we're just making a fast substitution into the
list of matched style rules (i.e., the path in the rule tree).
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla
nt", "well-formedness constraint").
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or w
ferent abilities to
actually skip kids.
These optimizations are made each step down the tree; we repeat the
decision for each frame's kids, and thus it shouldn't be a problem
to adapt this to vertical writing modes or mixed writing modes,
although the performance characteristics would obv
g...
>
> Is there something I'm missing?
No.
The regions spec says that you do two passes and then stop.
The overflow:fragments spec should probably either (a) say the same
or (b) require fragments following an absolutely positioned fragment
to also be absolutely
entirely absolutely positioned)
* alternatively, for columns and pages (but this wouldn't work for
regions/fragments), they could create additional overflow columns
or additional pages without otherwise affecting layout
-David
--
𝄞 L. David Baron
t/fcfeb6506e691f17d7f83793d7ef4c9f28f8898a
So I think it's probably possible to do a good bit better than
current Gecko. And I also think it might be worth seeing how Gecko
does on your test before/after the 2004 margin collapsing changes.
-David
--
𝄞 L. David Ba
that's what Servo needs in its life right now, I'd suggest.
Agreed. But that does really mean assessing options again later
(when we want authors to start caring about Servo).
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla
tect Servo
could lead to authors (eventually) using other techniques to detect
Servo, which could lead to a set of Web-incompatible behaviors that
you can't fix because authors are using one for detection of the
others (in various combinations). (This is the problem IE had
around
tes
(and make sure it performs acceptably) over these tasks that you
list? (As somebody following from a distance, I'm more concerned
about that, because it seems likely to be the sort of thing that
might require changes in architecture and thus rewriting code that
would implement the above.)
rstand exactly how this works yet, but more code reading should
> fix that.
>
> Did I miss something important?
Probably the most important bit is the change-handling
optimizations (see HasStateDependentStyle,
HasDocumentStateDependentStyle, HasAttributeDependentStyle -- both
the im
mment, or if there are really
substantially different states that persist for long segments).
I remember the http://parlab.eecs.berkeley.edu/ folks talking about
doing something like this, I think with HTML, though I don't recall
if it was only for tokenization or more deeply into parsing.
-D
12 matches
Mail list logo
