On 8/10/17 2:25 PM, Chris Peterson wrote:
Besides fixing the regressions, we should review the test cases where
Gecko fails but Stylo passes to make sure we're not unintentionally
shipping new CSS features.
Indeed. And any remaining such should probably be annotated with Gecko
bugs or otherwi
On 7/24/17 1:53 AM, Manish Goregaokar wrote:
and the styloVsGecko / issue (which does not block landing since
it's a
slight discrepancy between stylo and gecko)
Looks like it's a difference in vertical alignment. How sure are we
that this won't affect web pages outside of media controls?
-
On 6/2/17 12:34 PM, Michael Howell wrote:
$ echo -n "Allow style sharing elements with ID selectors" | wc -c
Misleading, unfortunately, because that changeset on its own doesn't
allow anything of the sort.
-Boris
___
dev-servo mailing list
dev-serv
On 6/2/17 12:27 PM, Anthony Ramine wrote:
What was that step? The title you pasted doesn't say what it was about, it only
said what was wrong without it.
That was all. I just removed the if condition in question around the
insertion.
I've tried rewording as this:
Allow inserting element
On 6/2/17 11:50 AM, Anthony Ramine wrote:
Though not required, it’s a good idea to begin the commit message with a single
short (less than 50 character)
Just so we're clear, 50 characters is about 9 words.
- Fix style sharing of elements affected by id selectors
No, that's not what it does
On 6/2/17 5:18 AM, Anthony Ramine wrote:
In the following screenshot, you can see one doesn't even know what that commit
is supposed to do from its title, because it is way too long to be informative.
OK, what is the proposed cap on first line of commit message?
Everything I've seen suggests
On 5/10/17 8:14 PM, Manish Goregaokar wrote:
So I took a try push with all expectations set as passing and went about
categorizing the reftest failures.
Do you mind linking to the try push? Looking at the actual
reftest-analyzer results is helpful for categorizing things.
-Boris
___
On 4/17/17 12:09 PM, Milan Raj wrote:
It would be great to have more control externally to know and control when
records are added or removed from the undo / redo stack.
https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html was an
abortive attempt to create a spec for this sort of
On 4/12/17 2:32 AM, Paul Rouget wrote:
- Prerendering: we will want to prerender documents. A special kind of
pipeline with black-listed functionalities.
I suspect that at least for a web browser this is a huge amount of pain.
Note that Chrome is giving up and removing their implementation, l
On 3/27/17 12:05 PM, Jack Moffitt wrote:
Yes, but since layout runs in parallel and is pretty fast, I'd think
the common case was that it would be done by the time it got the
second request.
I doubt layout is "pretty fast" on the scale involved here, which is
"hundreds of times per frame". Bu
On 3/27/17 10:36 AM, Jack Moffitt wrote:
Responses to layout queries are just sent messages (if layout needed
invoking to answer them). It is possible to send them early as soon as
the relevant data has been computed. Servo does not do this currently
though. An initial implementation could just r
Has there been any thought put into being able to satisfy queries for
layout information without doing a full style + layout flush on the
page? There are obviously things like CSS containment that can help
here, but it seems like it might be worth it to see whether we can
detect situations in
On 3/16/17 7:35 PM, Krishna karthick Balaji wrote:
I am trying to write tests for MutationObserverAPI
(https://github.com/servo/servo/wiki/Mutation-observer-project)
Are these tests covering something not already covered by the various
dom/nodes/MutationObserver* tests?
-Boris
_
On 3/2/17 2:40 PM, Nikhil Shagrithaya wrote:
Shouldn't it be possible to extend speculative parsing to continue parsing
HTML instead of just fetching other resources?
For what it's worth, Gecko does this: speculatively tokenizes off-thread
even if the parser is blocked.
If a document.write()
On 11/3/16 4:30 PM, Simon Sapin wrote:
Servo defines:
type AttrValue = std::string::String;
type Identifier = servo_atoms::Atom;
type ClassName = servo_atoms::Atom;
type LocalName = html5ever_atoms::LocalName;
type NamespacePrefix = html5ever_atoms::Prefix;
Ah, perfect. Th
On 11/3/16 3:17 PM, Simon Sapin wrote:
An important aspect is that atoms with different static sets are
different Rust types.
Just to check that I understand correctly...
Are element names atoms? Which static set do they come from?
Presumably the html5ever one?
When parsing CSS selectors,
On 9/19/16 6:49 PM, Jim Blandy wrote:
grandparent (origin O)
parent (origin P, P != O)
child (origin O, same as grandparent)
then the grandparent and the child are in the same UoRSOBC. The grandparent
can say `frame.contentWindow.frames[0]` to get its grandchild
frame.cont
On 9/7/16 11:55 AM, Geoffrey Sneddon wrote:
There are plenty of rendering bugs that don't involve text, and
practically if you're generating arbitrary web pages it's easy to solve
all of those problems by simply not including text (though you'll need
to give boxes explicit heights!).
Does using
On 9/5/16 8:17 AM, Till Schneidereit wrote:
I don't think it makes too much sense to be able to pause completely
independent browsing contexts that can't possibly interact with each other.
There is no such thing. They can always interact, just async.
-Boris
___
On 6/22/16 11:17 AM, Manish Goregaokar wrote:
We don't close down the tree except for CI fires
Yes, I understand your model. You don't have to explain it to me.
I was just pointing out that for normal commits you prefer the model of
test-each-thing, but for style system you would prefer the
On 6/22/16 9:52 AM, Manish Goregaokar wrote:
This has one significant drawback: it places a pretty serious burden on
whoever performs the sync. In particular, in addition to merging the
actual code (already needs some expertise), they become responsible for
handling any test failures that arise
On 6/22/16 8:47 AM, Manish Goregaokar wrote:
Changes to webrender would be made in m-c or servo/webrender,
whichever is more convenient, and there is a periodic sync operation.
This has one significant drawback: it places a pretty serious burden on
whoever performs the sync. In particular, in
On 6/21/16 12:20 PM, Lars Bergstrom wrote:
I'm still a bit worried about this unless the revert rate comes down pretty
significantly for any shared branch between servo and gecko.
That's fair. We should certainly not make inbound that shared branch! :)
But we'll see how the proposals come
On 6/21/16 8:34 AM, Lars Bergstrom wrote:
If a backout lands as a `git revert` of the offending commit(s) I'm certainly
less concerned, as that's annoying but not impossible for people to continue
rebasing against.
Right, that's how backouts land.
The way it was explained to me (and I may h
On 6/20/16 8:35 PM, Lars Bergstrom wrote:
Backouts came up in the discussion, and I tried to make it pretty clear that
they are not compatible with a GitHub-style development model (even if you
*could* hypothetically do crazy things like force-pushing rewritten histories
to master).
Wait, wh
On 2/20/16 5:10 PM, Josh Matthews wrote:
(as a random comment, I never read multiline comments for Gecko. Only the
first line + the bug number. It is the bug where the relevant information
needs to be available. Whether it it available also elsewhere is less
important, IMHO.)
Having the info in
On 2/3/16 1:46 PM, Josh Matthews wrote:
Nikki asked for suggestions for how to review code, so here's my first
attempt at writing down a general suggested workflow for reviewing Servo
code:
https://github.com/servo/servo/wiki/Code-review
Somewhere in there, one should read the commit messages
On 12/2/15 4:23 PM, Andrew McCreight wrote:
For what it is worth, Gecko uses a single-entry per-zone cache for
converting the result of JS strings to DOM strings in getAttribute (I
think)
No, that's the other direction: DOM strings to JS strings.
-Boris
On 11/4/15 12:09 PM, Manish Goregaokar wrote:
I'd prefer to avoid diverging from the spec wherever possible -- even if
other browsers disagree (with the spec and with each other)
I think Ms2ger was talking about cases in which the spec disagrees with
all browsers, who agree with each other.
On 11/3/15 4:52 AM, David Bruant wrote:
@Manish: additionally, perhaps leave a comment in the open spec bug
Oh, yes. Any time the spec does not match reality or sanity, do let the
spec author know.
-Boris
___
dev-servo mailing list
dev-servo@lis
On 11/2/15 2:21 PM, Manish Goregaokar wrote:
We have three choices here, we can wait indefinitely until the spec gets
fixed, we can implement the spec as is (which require major changes and
affect perf or complexity), or we can hope that nobody relies on this
behaviour (given that it's not follo
On 4/28/15 10:33 AM, Jack Moffitt wrote:
This is an issue, but hasn't hit us much yet.
Sure. I assume if it had you would have been dealing with it. ;)
It's easy enough to use the ``` syntax to include arbitrary things
into a bug report. This is how we often attach logs and such. You
can't d
On 4/28/15 5:23 AM, David Bruant wrote:
Another possibility is for the reporter to make a PR with the test case.
Just stop. We're talking about making it _easy_ to report issues, yes?
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
htt
On 4/27/15 8:38 PM, Josh Matthews wrote:
https://github.com/servo/servo/wiki/Meeting-2015-04-27
I've mentioned this a few times, but...
For a layout engine, being able to attach an actual testcase to a bug
report is _really_ useful once you get out of "just build it" mode and
into "fix all t
On 1/28/15 12:33 PM, Josh Matthews wrote:
I'm not certain what you're asking. The events come from another thread,
so they need through some kind of event queue. Today, that's the
per-origin event loop.
OK. That means, for example, that you can't navigate away from a page
that's in the middle
On 1/28/15 11:49 AM, Josh Matthews wrote:
Those are good points. Since those events go through the regular script
event loop
Should they, though?
we would presumably have to process every pending script
event in line before them, which could be bad? Stuff like
>setTimeout(function() { windo
On 1/28/15 7:21 AM, Josh Matthews wrote:
My current line of thinking is that we send a message to the compositor
that puts the pipeline in the modal state and pops up a dialog.
Additionally, the message contains a Sender, with the script task
waiting synchronously on the corresponding Receiver; w
On 1/27/15 5:46 PM, Josh Matthews wrote:
We don't have the notion of a global event loop or anything. We
effectively have an event loop per script task (ie. event loop per TLD),
but no ability to spin it arbitrarily at the moment.
How do you plan to implement alert()? Do you plan to allow an a
On 1/12/15 2:39 PM, Josh Matthews wrote:
the obvious downside is that a tab's event loop will be cluttered with
constant attempts to poll for incomplete network responses during page
load.
Not just during page load. I expect this to peg the event loop on any
site that uses long polling (see
Apparently Blink has been changing how they handle style invalidation on
DOM mutations.
https://docs.google.com/document/d/1vEW86DaeVs4uQzNFI5R-_xS9TcS1Cs_EUsHRSgCHGu8/edit?pli=1#heading=h.xa3ovcncd2vp
has a writeup of sorts for those who are interested.
-Boris
On 10/28/14, 1:15 PM, Patrick Walton wrote:
In other words, what are examples of
the major pain points that DLBI was designed to handle in Gecko?
You should double-check with Matt Woodrow, but three things come to mind:
1) Pre-DLBI, invalidation code was scattered all over layout and it was
On 10/20/14, 1:29 PM, Josh Matthews wrote:
https://github.com/servo/servo/wiki/Meeting-2014-10-20
I'm not sure I understand the sync script bit.
You don't want to block user interaction with the page while fetching a
On 10/14/14, 12:26 AM, Simon Sapin wrote:
Is there anything other than SVG that might require an XML parser
XMLHttpRequest and DOMParser, no?
but it sounds unlikely that real content relies on an entire
document failing to parse.
XMLHttpRequest not only relies on it, but relies on the exact
On 10/6/14, 7:44 PM, Boris Zbarsky wrote:
Just to check, what's the plan for doing "overflow: sticky"?
I mean "position: sticky", of course. ;)
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists
On 10/6/14, 5:17 PM, Martin Robinson wrote:
This is just an informational message to inform everyone of the design
of current scrolling model. I hope this will also be useful to shine the
way toward overflow:scroll. I'm also interested in hearing about
potential improvements to this model, becaus
On 10/6/14, 3:32 PM, Cameron Zwarich wrote:
then it wouldn’t be able to use JS_NewExternalString in the places where Gecko
is able to use it.
Ah, true.
Is there any particular place where you feel there is tension between the goals
of memory usage and performance?
I don't know yet. I mea
On 10/6/14, 10:27 AM, Cameron Zwarich wrote:
This is an increase in memory usage over all existing engines
Is it an increase over Gecko?
Are we trying to optimize for performance or memory usage here, or both
at once?
-Boris
___
dev-servo mailing
On 10/6/14, 3:53 AM, Cameron Zwarich wrote:
Where do most of the small strings larger than a single character that benefit
from the inline small string optimization originate, the DOM or user JS code?
That's a good question.
When the optimization was added, strings that originated in the DOM
On 10/5/14, 7:51 PM, Cameron Zwarich wrote:
Are there any plans to eliminate the copies in Gecko?
No. Measurement showed that in practice the cost of copying short
strings, which most of these are, is very low. For large strings you do
end up having to copy, but keep in mind that Gecko used
On 10/5/14, 2:27 PM, Cameron Zwarich wrote:
I am opposed to anything that requires string copies between the DOM and JS
The only way to do that with SpiderMonkey in its current state is to use
JSString for your string type. You cannot safely grab the chars from a
SpiderMonkey string and hold
On 9/20/14, 8:46 AM, Josh Matthews wrote:
I've started
https://github.com/servo/servo/wiki/HTTP-library-requirements to collect
Servo's requirements and justifications. Please throw anything you can
think of in there!
I added a few things.
-Boris
___
On 7/18/14, 4:10 PM, Manish Goregaokar wrote:
- Rewrite the Header class to contain bytes
Note that you need header bytes for web APIs like XMLHttpRequest.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/li
On 7/7/14, 10:01 PM, Robert O'Callahan wrote:
One thing not mentioned in the notes is that Spidermonkey is adding Latin-1
string support, so hopefully it will be pretty easy to avoid converting
ASCII-only strings at WebIDL boundaries.
Note that they also are adding GC-unstable string chars, so
On 5/29/14, 11:39 AM, Simon Sapin wrote:
I’m aware that every style struct must contain either only inherited
properties, or only reset (non-inherited properties). Other than that,
what’s the guiding principle to decide how many structs to have, and
which properties go where?
Initially the idea
On 5/8/14, 9:06 PM, Keegan McAllister wrote:
This is all a bit moot if a parser never lives across a JS operation that could
GC.
If you want your parser to be able to parse web pages with
On 4/28/14, 6:02 PM, Keegan McAllister wrote:
Ultimately I'm sort of pessimistic about table-less interning, because it
proposes to speed up parsing at the expense of layout.
A thought.
If the goal is to speed up parsing in a separate task by avoiding
contention on a table, have we considere
On 4/23/14, 8:53 PM, Brian Anderson wrote:
We're assuming nobody is going to be attacking Rust symbols though
Oh, right, that's the other worry.
We've had security issues in the past due to things like type="fİle"> being treated as a file input by some parts of the system
but not others. So
On 4/23/14, 7:38 PM, Keegan McAllister wrote:
* How much does a 128-bit compare cost, vs. 64 bits for a pointer?
Are we more or less assuming we're on 64-bit systems?
My memory is that the 128-bit IID compares we end up doing in
QueryInterface sorta suck, but we do a bunch of them at a time,
On 4/20/14, 2:16 PM, Patrick Walton wrote:
Yes, I think it can. :( But there's an easy workaround: just fall back
to sequential layout for a subtree if the speculation fails. That will
eliminate the "cascading series of speculation failures leading to
exponential blowup" problem and allow paralle
On 4/19/14, 2:38 PM, Patrick Walton wrote:
Any thoughts?
I agree that the speculation described will typically succeed.
The only worry I have is that the idea of doing stuff for an element
then redoing it again if we discover it wasn't right sets off my "can
this lead to O(2^depth) behavior?
On 4/3/14 8:03 AM, Henri Sivonen wrote:
Have we instrumented Gecko to find out what the access patterns are
like?
We have not, but I will bet money the answer is "different for
benchmarks and actual content"...
-Boris
___
dev-servo mailing list
dev
On 4/1/14 3:07 PM, Keegan McAllister wrote:
Who should I talk to about JS string representation changes?
Eddy Bruel. ejpbruel at mozilla dot com.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-se
On 3/31/14 10:01 PM, Keegan McAllister wrote:
Good point. Even if the DOM is a mix of UTF-8 lazily converted to UCS-2, the
argument to document.write or the innerHTML setter is a JS string.
Which may itself in the future be some mix of UCS-2 and ascii, or UCS-2
and "evil UTF-8", or just UTF-
On 3/31/14 8:44 PM, Josh Matthews wrote:
https://github.com/mozilla/servo/wiki/Meeting-2014-03-31
A note on tables and pagination: that's a place where you won't really
be able to lean on Gecko experience. Or more precisely, table
pagination in Gecko is at the state where all pagination is i
On 3/29/14 8:23 PM, Patrick Walton wrote:
This is just 29 bytes of code when assembled. This is likely larger than
the equivalent `nsRuleNode`
The right comparison is not nsRuleNode but nsCSSSelector, right?
These are actually pretty bloated in Gecko right now. For example,
".foo #a" is pars
On 3/29/14 6:56 PM, Simon Sapin wrote:
Or I guess we could use what I’ll call "evil UTF-8", which is UTF-8
without the artificial restriction of not encoding surrogates.
http://en.wikipedia.org/wiki/CESU-8
As far as I understand, a "parse error" in the spec is meant for
conformance checkers (
On 3/6/14 4:53 PM, Keegan McAllister wrote:
but can this happen with innerHTML?
InnerHTML won't run any scripts per se, but will trigger mutation
observers before returning, as well as custom element constructors and
so forth...
Another thing I would like to understand is how real sites us
On 3/4/14 5:33 PM, Josh Matthews wrote:
I know that some contributors have expressed confusion about the new
JS types that are all over the DOM. I've started a guide to try and
clear up how to use them; please feel free to suggest further topics or
make edits yourself:
https://github.com/mozilla/
On 3/4/14 7:31 PM, Robert O'Callahan wrote:
Even when you just need instanceof, can it be shortened to
if (HTMLTitleElement::hasInstance(element))
?
Note that in Gecko that instanceof check would be:
element->IsHTML(nsGkAtoms::title)
While there are more longhand ways to decompose the ch
On 2/25/14 1:02 PM, Patrick Walton wrote:
To that end, Web site compatibility (which Acid2 is a rough proxy for a large
subset of, if
used sensibly [1])
Acid3 is a _much_ worse proxy here than Acid2, even with your sensible
use caveat, fwiw.
-Boris
__
On 2/25/14 6:42 AM, David Bruant wrote:
If I may weigh in, I wonder if passing Acid3 is a valuable goal in the
short term.
Absolutely not. It's not a valuable goal in any term, really, until
we're trying to go for random "standards pr" points.
-Boris
On 2/14/14 9:16 PM, Josh Matthews wrote:
For the short term I'm interested in making layout code always go for
the attributes, because relying on sprinkling
wait_until_safe_to_modify_dom all over content code is easy to get
wrong. Thoughts?
There's some DOM state layout needs that's not actuall
On 2/13/14 6:45 PM, Patrick Walton wrote:
1. This creates multiple sequential barriers, which can result in a
parallelism hazard. As an extreme case, consider:
div { position: absolute; }
...
This will effectively result in fully sequential layout because you have
to wait until layou
On 2/13/14 5:56 PM, Robert O'Callahan wrote:
2) Fragmentation. With something like overflow:fragments, absolute
positioning can affect the number of fragments you generate, which can
affect the size of the container of the fragments.
Ugh. I thought one of the points of absolute positioning was
On 2/13/14 4:48 PM, Patrick Walton wrote:
The pull request #1681 takes approach #2. It deals with the parallel
hazard by deferring height computation of absolutely positioned blocks
until display list construction time (which is top-down).
I sort of think that the right time to do absolutely po
On 2/9/14 1:24 PM, Patrick Walton wrote:
(2) it's easier to benchmark
style recalc against Gecko and WebKit when it's not intertwined with
intrinsic width calculation.
One note here. It's not uncommon for pages to do things that need a
style recalc (e.g. a getComputedStyle() call) but don't n
On 1/30/14 10:25 AM, Patrick Walton wrote:
- "Reflow" (from Gecko; WebKit calls this "layout")
"Geometry computation"? Or is that too long?
The others seem pretty reasonable to me.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
ht
On 12/16/13 2:50 PM, Josh Matthews wrote:
It would not be particularly difficult to take it
with us if we migrated to another system.
Great!
(Note, I expect that's a "when", not an "if", unless Github drastically
revamps how it treats issues.)
-Boris
___
On 12/16/13 2:29 PM, Patrick Walton wrote:
The flow representing the body is semantically reconstructed from scratch. Now
that doesn't have to actually be what happens at the machine level--I have a
TODO that we should reuse parts of flows where possible to accommodate
efficient handling of ca
On 12/16/13 1:54 PM, Josh Matthews wrote:
https://github.com/mozilla/servo/wiki/Meeting-2013-12-16
Some questions on github issues:
1) Do we plan to stick with them for the entire lifetime of servo? That
is, does github plan to grow reasonable options for at a minimum release
tracking and a
On 12/14/13 5:18 PM, Patrick Walton wrote:
Feedback and comments, either here or on the issue tracker, are very
welcomed! Checking my reasoning and ideas for the TBD areas are
particularly valuable.
I'm trying to understand what "The number of primary boxes in each flow
never changes throughou
On 12/6/13 2:59 PM, Niko Matsakis wrote:
This is not necessarily the case -- creating a new kind of GCThing is
rather hard, and wrapping in an object is heavyweight compared to
allocating a data structure on the stack.
Data structures on the stack should be traced with a CustomAutoRooter,
in m
On 9/23/13 1:44 PM, Josh Matthews wrote:
https://github.com/mozilla/servo/wiki/Meeting-2013-09-23
Fwiw, lots of proxies (e.g. document.forms) are definitely
long-lived I realize that's more of a long-term concern, and we
need trace hooks for proxies a
If people familiar with layout co
On 9/11/13 12:37 PM, Patrick Walton wrote:
On 9/11/13 9:35 AM, Boris Zbarsky wrote:
This fails if the node is inside an overflow:auto block that does
multipass layout to figure out which scrollbars to show: in that
situation there will be multiple FinishAndStoreOverflow() calls in Gecko
and
On 9/11/13 12:21 PM, Patrick Walton wrote:
Well, the easiest, but imprecise, thing to do would be to send the
message after the node is visited during the final assign-heights
traversal. No more layout computation happens for each node at that
point. (This final traversal roughly corresponds to
`
On 9/10/13 4:05 PM, Patrick Walton wrote:
Could we do the particular optimization that Chrome is doing in Servo by
just threading "what part of layout are we interested in?" (the
LayoutGoal in Servo terms) throughout layout and sending the answer over
a channel as soon as we know it?
The hard-i
I generally consider it pretty intractable, but the Blink folks are
trying it: http://code.google.com/p/chromium/issues/detail?id=283623
The idea is that a layout flush should only do layout until the part we
care about is stable. Or something.
The Blink bug highlights some of the issues (e
On 8/31/13 10:41 PM, Jack Moffitt wrote:
The DOM ones were specifically what I had in mind. CSS testing
probably doesn't make much sense unless we can test stuff we've
already implemented in order to compare to the upcoming Rust style
system.
The vast majority of the tests labeled as "CSS" in d
On 8/31/13 2:15 PM, Patrick Walton wrote:
Dromaeo is pretty old and is basically SunSpider.
Dromaeo has a bunch of DOM micro-ish-benchmarks on the one hand and
microbenchmarks of common JS libraries (jquery, etc) on the other. Just
make sure to run the "DOM" and "CSS" portions of it, not the
On 8/30/13 11:55 PM, Josh Matthews wrote:
The current DOM bindings can only fallibly unwrap object types that have
complete WebIDL prototype chains (ie. we can grab the interface ID array
from the object and compare the slot in the chain we care about with the
one we're trying to unwrap). This ca
On 8/8/13 8:18 PM, Josh Matthews wrote:
On a related note, saneyuki added support for some element types that
don't have their own interfaces and just use HTMLElement.
Note that there are other cases where multiple element types all use the
same interface that's not HTMLElement (e.g. and ).
On 8/6/13 7:44 AM, Patrick Walton wrote:
Pages with lots of social media "like" buttons are the canonical case
here.
Ah, yes.
The main issue with those is they tend to have not much layout stuff
inside but lots of script. :(
We should think about putting cross-origin iframes on a separate
On 8/6/13 5:19 AM, David Bruant wrote:
I have never even considered writing a page with hundreds of rendered
iframes and I don't think I have seen it in practice.
WebSphere used to use tens of thousands.
But: 1) this is definitely an edge case and 2) iframe reflow is async
anyway, so the test
On 8/2/13 5:17 PM, Brian Anderson wrote:
Is SSL required for servo 0.1?
Imo, no.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
On 8/2/13 4:47 PM, Jack Moffitt wrote:
Using a Reader doesn't imply that we're not reading from a character
buffer.
The question is whether the compiler can devirtualize at the callsite so
it can optimize around the read call, or possibly even inline it
-Boris
P.S. Will we at some point
[with apologies to Jack for the duplicate]
On 8/2/13 3:26 PM, Jack Moffitt wrote:
Simon, Josh, Keegan, and I all reviewed rust-cssparser[1] this morning
since it got added to the tree in one big go. The summary of that
meeting is here:
https://github.com/mozilla/servo/wiki/Rust-cssparser-code-wal
On 7/30/13 3:30 AM, Simon Sapin wrote:
a. A CSS representation of the whole selector list a a string, for the
CSSOM’s selectorText
b. The specificity for the cascade
c. Just the data structures we need for matching
I think this would work, but maybe the cost of a. cancels whatever we
gain in c.?
On 7/29/13 11:38 AM, Simon Sapin wrote:
type Namespace = i32 // Is this some kind of interning as well?
In Gecko, yes.
* Use vectors / arrays instead of linked lists for AtomList,
PseudoClassList and SelectorList. (Less allocations) This could make it
more difficult to point somewhere i
On 7/25/13 11:27 AM, Leo Meyerovich wrote:
Think of it like GC: many little nurseries and an occasional compaction.
OK, so movable DOM nodes. That would be interesting to try...
especially if we're already doing movable DOM nodes because they're in
the GC heap.
-Boris
_
On 7/25/13 9:30 AM, Leo Meyerovich wrote:
To put what I described in perspective, if tiling the tree as 256 nodes / tile
is performed
How well does that setup deal with nodes being removed/inserted?
-Boris
___
dev-servo mailing list
dev-servo@lists
1 - 100 of 159 matches
Mail list logo
