W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-nav-trans] RFC: Proposal for style rule to specify transitions between page navigations

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 24 Jun 2015 08:34:45 -0700
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style list <www-style@w3.org>
Message-Id: <9A0B3CAE-A68F-4EC7-889E-3ADD67FA5A3B@gmail.com>
To: Christopher Lord <clord@mozilla.com>



> On Jun 24, 2015, at 12:46 AM, Christopher Lord <clord@mozilla.com> wrote:
> 
> Hi Daniel,
> 
> Interesting - I think a major difference between those you illustrate and what I've proposed, is that those implementations all consist of a set of predefined transitions that a page can request, where as this proposal lets you define a transition period per page and run your own transition with CSS/JS. All of those effects would be possible except for a curling page turn (unless you somehow render your page into a WebGL texture... Via SVG perhaps?), but I think that's fine, that's more a limitation of current page layout/features.
> 
> The security question is worthy of thought - should a UA impose that input is ignored until transitions finish? 

I was thinking the opposite. Other than declaring within the CSS what transition you want and for how long, all transition rendering should be completely independent of anything else happening in the page. If the whole viewport is transitioned as a separate thread on the GPU, then there should be no way within the page to detect anything different is happening. Inputs should be just as clickable or type-able (by script at least), as when no page transition is happening. If the UA can't maintain responsiveness of the page during transition of larger pages, then it could transition a visual snapshot of the page instead, so that there is no discernible, measurable slowdown from the purely visual transition. This means JavaScript, WebGL, and SVG would not be involved at all. 
Received on Wednesday, 24 June 2015 15:35:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:55 UTC