Le 17/04/2017 à 18:09, Milan Raj a écrit :
It would be great to have more control externally to know and control
when records are added or removed from the undo / redo stack.
I think Facebook gave up on this idea and created draft.js on top of React
https://draftjs.org/docs/overview.html#content
Le 08/02/2017 à 12:39, Simon Sapin a écrit :
So here is a proposal to avoid this situation in the future:
Whenever a PR to rust-selectors (and other repositories where we think
that’s appropriate) makes breaking changes, we don’t land it until
there’s also a corresponding PR to update Servo fo
Le 03/08/2016 à 21:38, David Bruant a écrit :
My undertanding of pwalton's email is that the parts written in unsafe
rust binding to complex C++ libraries should be bundled together in
their own process(es).
Were the JS and layout engines written in safe Rust, I don't think
pr
Le 03/08/2016 à 18:47, Andrew McCreight a écrit :
On Wed, Aug 3, 2016 at 8:35 AM, Jack Moffitt wrote:
I asked ekr how much this mattered, and he thought it was important. I
don't think anyone has pointed me to a documented attack, but it
definitely seems like the kind of thing that could be do
Le 10/11/2015 01:50, Lars Bergstrom a écrit :
Bonus meeting from last week on Oxidation (Rust/Servo in Gecko):
https://github.com/servo/servo/wiki/Oxidation-2015-11-05
I asked for access to the Spreadsheet (mostly out of curiosity as I
imagine it'll be filed with bug links?).
Google Spreadshee
Le 02/11/2015 21:00, Boris Zbarsky a écrit :
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
rel
Le 28/04/2015 06:52, Boris Zbarsky a écrit :
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 ou
Hi,
I read something about devtools in recent meeting notes [1].
I don't know to which extent it will be useful, but I wanted to share
the RemoteDebug initiative [2]. There might be things that can be pulled
out from this project.
David
[1] https://github.com/mozilla/servo/wiki/Meeting-2014-
Le 25/02/2014 17:14, Jack Moffitt a écrit :
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.
Acid2 and Acid3 are the current goals of our p
I forgot. I was referring to https://github.com/mozilla/servo/wiki/Roadmap
Le 25/02/2014 12:57, James Graham a écrit :
Having said that, I don't think that using "IE8 parity" as a metric is
very useful. IE8 takes a lot of non-standard codepaths on real sites,
so merely targeting the standard fe
Hi,
If I may weigh in, I wonder if passing Acid3 is a valuable goal in the
short term.
IE8 scores 20/100 at Acid3. All major websites and most websites have to
support IE8, because it's the current "boat-anchor browser" [1]. So most
websites don't need the features that make a 100 score.
Speci
Le 23/09/2013 19:44, Josh Matthews a écrit :
https://github.com/mozilla/servo/wiki/Meeting-2013-09-23
jack: strange loop seemed really impressed that we had anything to
show at all. general impression seems to be vapourware.
That's quite an unfortunate impression :-s
kmc: did you show acid1?
Le 07/08/2013 00:34, Jack Moffitt a écrit :
Love it! This is a game changer for web development. I mean it.
Does this mean you are no longer worried about that suggested benchmark? :)
:-p
I didn't answer, but Patrick Walton made a good point on the fact that
how people use the technology depe
Le 06/08/2013 16:26, Jack Moffitt a écrit :
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 script
task, for now, hopefully in a separate process later...
There wouldn't be much
Le 06/08/2013 03:01, Josh Matthews a écrit :
https://github.com/mozilla/servo/wiki/Meeting-2013-08-05
Thanks for taking these, they are invaluable when following the project
from afar.
resizing with lots of iframes should be a good one, since all iframes
should reflow in parallel unlike other
Hi Devdatta,
Le 26/02/2013 03:03, Devdatta Akhawe a écrit :
Its also not time-invariant when document.domain is used, correct?
True. I guess the cases of "iframe initially has a different origin than its
parent, but JS can change that" are more numerous than I originally thought.
Other than do
Le 25/02/2013 22:51, Brian Smith a écrit :
David Bruant wrote:
It seems like in theory, it could be possible to handle the content
of a cross-origin iframe in a specific Rust task (or bunch of tasks).
I thought Rust tasks were supposed to be very lightweight. If so, why not put
every iframe
Le 25/02/2013 21:03, Boris Zbarsky a écrit :
On 2/25/13 2:33 PM, David Bruant wrote:
2) different-origin iframe. JS from the parent can only interact with it
through message passing via postMessage.
Note that whether an iframe is same-origin or not is not
time-invariant across navigations
Hi,
Servo is new and opens new opportunities, so I'm going to share an idea.
And maybe someone else had it already (I haven't read such a thing yet)
or maybe it's too crazy of an idea, but the discussion may be
interesting anyway.
HTML has s. JavaScript can interact with it. There are 2 type
Le 08/02/2013 18:41, Simon Sapin a écrit :
Hi dev-servo,
For context, see other threads about my new CSS parser.
Servo is made to "parallel all the things", right?
Some algorithms are very hard to parallelize. Parsers would be a very
good example, because they often look like "read a bit, chan
Le 22/10/2012 12:58, Brendan Eich a écrit :
> Boris Zbarsky wrote:
>> So we'd only need to worry about places in the Rust code on the DOM
>> side that hold references to nodes that are not in the DOM tree.
>> There shouldn't be that many (e.g. the -moz-element stuff would have
>> that, perhaps, an
2012/10/16 Boris Zbarsky
> On 10/16/12 10:13 AM, Henri Sivonen wrote:
>
>> Does random charAt() need to be O(1) or is it enough for each charAt
>> in sequence over the string to be O(1)?
>>
>
> For actual uses, or benchmarks? :(
If both are different, Mozilla should release a new benchmark base
22 matches
Mail list logo
