I've posted a followup of sorts to public-houdini:
https://lists.w3.org/Archives/Public/public-houdini/2015Mar/0020.html
There have been no replies, so I suspect I've said something terribly
incomprehensible and/or wrong :-).
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaon
On Mon, Feb 23, 2015 at 11:56 AM, Jonas Sicking wrote:
> On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp
> wrote:
> > What does it mean to "save your for later viewing"?
>
> In gmail it would mean saving the set of emails that you are currently
> looking at.
>
> For facebook it would mean the new
On Mon, Feb 23, 2015 at 4:26 PM, Jonas Sicking wrote:
> On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan
> wrote:
>> On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking wrote:
>>>
>>> I think this would fall over more often than not.
>>>
>>> Most developers will not write their code to be resilie
> 2) UIWorker: some kind of JS worker that receives callbacks during
composition; each callback can take inputs such as time and scroll
position(s) as inputs and can update certain CSS properties (e.g.
transforms, opacity) on elements that the compositor then uses.
>
>
How should we explain the CSS
On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan wrote:
> On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking wrote:
>>
>> I think this would fall over more often than not.
>>
>> Most developers will not write their code to be resilient in the face
>> of being suspended for extended periods of time
On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking wrote:
> I think this would fall over more often than not.
>
> Most developers will not write their code to be resilient in the face
> of being suspended for extended periods of time. Upon reopening they
> would likely display error dialogs, or upda
Le 24 févr. 2015 à 08:02, Robert O'Callahan a écrit :
> Also, there is a way to get "save for later viewing" to work with complex
> apps: serialize all the application state --- DOM, CSS, JS heap, workers,
> etc --- and revive it later, possibly in a jail that blocks it from
> accessing the netwo
On Mon, Feb 23, 2015 at 3:02 PM, Robert O'Callahan wrote:
> On Tue, Feb 24, 2015 at 10:57 AM, Gordon Brander
> wrote:
>>
>> It's funny: I have come to the opposite conclusion for the same reason.
>>
>> The Good: getting 60fps interactions and animations in web apps using a
>> proven approach (UI
On Tue, Feb 24, 2015 at 10:57 AM, Gordon Brander
wrote:
> It’s funny: I have come to the opposite conclusion for the same reason.
>
> The Good: getting 60fps interactions and animations in web apps using a
> proven approach (UI and interaction thread).
> The Ideal: also automatically serializing
It’s funny: I have come to the opposite conclusion for the same reason.
The Good: getting 60fps interactions and animations in web apps using a proven
approach (UI and interaction thread).
The Ideal: also automatically serializing those apps for offline use.
While I very much want the ideal to
On Mon, Feb 23, 2015 at 12:07 PM, Robert O'Callahan
wrote:
> On Tue, Feb 24, 2015 at 8:56 AM, Jonas Sicking wrote:
>>
>> On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp
>> wrote:
>> > What does it mean to "save your for later viewing"?
>>
>> In gmail it would mean saving the set of emails that yo
On Tue, Feb 24, 2015 at 7:36 AM, Jonas Sicking wrote:
> On Sun, Feb 22, 2015 at 3:45 AM, Robert O'Callahan
> wrote:
> > Your use-cases already fail today because many Web pages use scroll event
> > handlers and JS custom layouts. UIWorkers won't make the problem any
> worse.
>
> I agree that it'
On Tue, Feb 24, 2015 at 8:56 AM, Jonas Sicking wrote:
> On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp
> wrote:
> > What does it mean to "save your for later viewing"?
>
> In gmail it would mean saving the set of emails that you are currently
> looking at.
>
> For facebook it would mean the news
A couple thoughts from the perspective of a web app dev who has struggled with
this problem:
I get excited when I hear a proven solution with well-understood scope like
“animations and user interactions on the same thread”. I get nervous about
ambitious and unknown solutions (async DOM). The we
On Sun, Feb 22, 2015 at 3:45 AM, Robert O'Callahan wrote:
> On Fri, Feb 20, 2015 at 9:11 PM, Jonas Sicking wrote:
>>
>> On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan
>> wrote:
>> > Should UIWorkers have access to the full Worker API? It seems like
>> > there's
>> > no reason not to give the
On Fri, Feb 20, 2015 at 10:50 PM, Christopher Lord
wrote:
> I'd like to see #1 implemented first for two reasons; 1- I know this is
> easy to do given our platform, and I expect the same for other browser
> vendors, and 2- behaviour here is 100% predictable. There is nothing
> unexpected that can
On Fri, Feb 20, 2015 at 9:11 PM, Jonas Sicking wrote:
> On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan
> wrote:
> > Should UIWorkers have access to the full Worker API? It seems like
> there's
> > no reason not to give them that.
>
> There's two use-cases that I think argues against that.
>
On Fri, Feb 20, 2015 at 3:20 AM, Jonas Sicking wrote:
> On Thu, Feb 19, 2015 at 7:11 PM, James Long wrote:
>> Note however that people in the native app world believe that it's
>> very important that whatever applies the animations is run on the same
>> thread that handles input. Otherwise it's v
It's great to see this being discussed! Personally, I'd like to see all
three of these, and I think they have quite particular use-cases. #2 is my
least favourite, however, and I'll discuss this below.
I'd like to see #1 implemented first for two reasons; 1- I know this is
easy to do given our pla
On Fri, Feb 20, 2015 at 3:27 AM, Robert O'Callahan wrote:
> One good thing about UIWorkers is extensibility. We can imagine providing
> touch input coordinates to UIWorkers to enable 60fps object dragging (with
> arbitrary effects like resistance, snapping, etc). UIWorkers could render
> to canvas
On Thu, Feb 19, 2015 at 7:11 PM, James Long wrote:
> Note however that people in the native app world believe that it's
> very important that whatever applies the animations is run on the same
> thread that handles input. Otherwise it's very easy for animations to
> get out-of-sync.
Does that mea
On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan wrote:
> Should UIWorkers have access to the full Worker API? It seems like there's
> no reason not to give them that.
There's two use-cases that I think argues against that.
First off I'd like to enable saving a webpage for later viewing. Right
On Thu, Feb 19, 2015 at 10:25 PM, Robert O'Callahan
wrote:
> On Fri, Feb 20, 2015 at 4:02 PM, James Long wrote:
>
> Personally I think what we *really* need to be working on is making
> all of the DOM APIs asynchronous. That's what Servo needs anyway.
> That's a step in the right dire
On Fri, Feb 20, 2015 at 4:02 PM, James Long wrote:
Personally I think what we *really* need to be working on is making
all of the DOM APIs asynchronous. That's what Servo needs anyway.
That's a step in the right direction for #3, and we can see much more
we can get out of the main
Sorry, I may have missed the last part of your email where you say
that you could provide touch positions as input too. This would be
neat research and I'd like to see more details.
Note however that people in the native app world believe that it's
very important that whatever applies the animatio
I'm not heavily involved in platform work, so take my input as a
somewhat naïve outsider. I've been tracking this kind of stuff very
closely, especially after I got to play with react native.
The place where this is most important is mobile, and I don't think #2
is going to cut it. It's not just s
Last week in Sydney I spent a lot of time talking to Chrome devs about
different approaches for 60fps effects in Web pages. There are three
different kinds of approaches being discussed (so far):
1) Apple's animation-timeline proposal, which lets CSS animations use
scroll position as an input inste
27 matches
Mail list logo
