On Tue, Apr 28, 2015 at 6:49 AM, Christopher Lord <cl...@mozilla.com> wrote: > > > On Tue, Apr 28, 2015 at 4:26 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> This is awesome!! I completely agree that the Google proposal is much >> too complicated for an initial take on solving transitions. >> >> I agree with Anne that this should be doable by adding CSS rules to a >> normal stylesheet rather than using a special linking mechanism. If >> that sounds good to you, then it would probably be worth updating the >> examples in the proposal to reflect this (don't worry about suboptimal >> names for now). >> > > Yes, good idea - there are a few other things I'd like to amend too, but I > need to discuss with some platform people to know what's feasible and what > isn't.
Sounds good. >> I do have a few questions, but generally this looks great! >> >> * Is it always the right decision to have the new page render on top >> of the old one? Are there situations when you'd want, for example, the >> old page to slide away and have the new one appear underneath? You >> could for example create the effect of turning page in a book if the >> old page folds forward with the new page appearing behind it. >> >> One problem though would be how the old and the new page would >> negotiate which should appears on top, and which should appear on >> bottom. > > Yes, I think you're right - I considered this after, and it would be good to > have a way of specifying z-ordering... Perhaps in that @viewport block that > Anne suggests? The question is, who decide which page goes on top? Specifically, what if both the outgoing and the incoming page request being on top? Or if both explicitly request being on bottom. I guess we simply need to define a winner in that case. >> * We probably should add some form of API which allows the loading >> page to indicate when it's ready to be rendered. I.e. when the browser >> should start triggering the animate-in/out animations. This "page is >> ready to be rendered" feature has come up in several other contexts >> but seems extra important here. >> > > This would be nice, but I think it could be an orthogonal feature again. > Perhaps a feature that lets the page itself control loading progress? I > think that'd make a lot of sense. I agree it's an orthogonal feature. I think we'll find that it'll be very hard to do without though. >> * I think we should make sure that this proposal doesn't make the >> feature Google ask for impossible to add in the future. I don't think >> the current proposal does, but it might be worth explicitly saying >> that that can be added in the future, rather than to just say that >> it's impossible right now. > > Which feature are you referring to here? Being able to interleave from/to > document elements? Yes. Being able to transition, for example, an image element from one to the other. > I'm open to any ideas about this, but I think being able > to do so would make implementation much harder, so I'd certainly like to > avoid it in an initial draft at least. I agree this is significant complexity. So definitely to be avoided in the initial draft. All I'm suggesting is that we explicitly say that it can be added in a later version if that's desired. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
