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

On Wed, Jun 24, 2015 at 4:34 PM, Brad Kemper <> wrote:

> > On Jun 24, 2015, at 12:46 AM, Christopher Lord <>
> 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.

The transitions I'm proposing don't happen on the viewport, it's a block of
CSS that applies during the transition between pages. So by definition, a
page will know that it's transitioning because it would have defined the
transition and there are even signals to detect when it starts and ends
(allowing you to have JS-driven transitions - which would allow WebGL
transitions, for example). Predefined transitions would make it very hard
to perform a transition like this[0] (Firefox only right now), and I think
would be ultimately too limited and uninteresting.

Currently the proposal makes no mention of what happens to input during
transitions, which I suppose is tantamount to saying it's unaffected. But
as previously mentioned, I wonder if this is a security concern? A page
could set an exit transition going to a secure banking site and make itself
appear hidden, but still accept input - in this way, you may be able to
trick the user into entering secure details or details related to one
domain on an entirely different one. You could remove input from the
transitioned-from page, that would seem like a reasonable thing (and
basically matches current behaviour when you initiate a navigation), but I
wonder if there's a situation I've not thought of that could be a cause for
concern in that case too?


(best viewed in a small window/responsive design mode)

Received on Wednesday, 24 June 2015 17:47:59 UTC