- From: Kseso <kseso9@gmail.com>
- Date: Tue, 14 Jun 2016 15:28:36 +0200
- To: Florian Rivoal <florian@rivoal.net>
- Cc: Rachel Nabors <rachelnabors@gmail.com>, www-style list <www-style@w3.org>
- Message-ID: <CAAQ7Nj6-yupmZ+z_s201vb1itspEAE-8_q67DZ=RqsEDXKHzGw@mail.gmail.com>
Thanks for your opinion, Florian. 2016-06-14 4:43 GMT+02:00 Florian Rivoal <florian@rivoal.net>: > This is all software, so nothing's impossible if we're creative enough, > but making a pseudo class depend on layout (and scrolling) goes against the > grain of how CSS works. > No. It isn´t layout depended. It is "user interaction depend" as other aspects such as: hover,: target,: checked... "The grain of how CSS works" is not unique nor immutable. CSS offers solutions to specific issues and needs. And his response is a function of the nature of the topic addressed. Each case requires a specific analysis and response commensurate with it. The styles you apply when that selector matches can change the layout, > which can change whether the selector matches. This kind of loops between > the styling layer and the layout layer are really troublesome. > This is the same case that :hover. It is valid to declare el:hover {display: none;} regardless of the effects (repaints and reflows) this envolves. Some time ago el:hover {display: none} create an infinite loop "show / hide". Today, in some browsers like Chrome, the user needs to move the pointer to the declaration applies again (a second time). I mean CSS should not give up new developments because the user can make a possible misuse them. My proposal only provides a way for CSS knows if an item is inside or outside the viewport. Which it is not possible today. The good or bad use a particular developer can do with that knowledge in specific cases should be indifferent. And never reason to rule out a innovation. 2016-06-14 4:43 GMT+02:00 Florian Rivoal <florian@rivoal.net>: > This is all software, so nothing's impossible if we're creative enough, > but making a pseudo class depend on layout (and scrolling) goes against the > grain of how CSS works. > > The styles you apply when that selector matches can change the layout, > which can change whether the selector matches. This kind of loops between > the styling layer and the layout layer are really troublesome. > > I know there are tons of use cases for something like that, and LG was > suggesting something along these lines earlier as well to deal with scroll > effects on round displays, but I don't think this approach will actually > work. > > - Florian > > On Jun 14, 2016, at 09:25, Rachel Nabors <rachelnabors@gmail.com> wrote: > > I would like to vouch for this. I already use waypoints.js to manually > track everything that is in view so I can pause/remove animations that > aren't visible. I do this for performance reasons and others do, too. It's > in the wild already. Would love to see it official. > > > [image: photo] > *Rachel Nabors* > Web Animation Engineer > w:rachelnabors.com > <http://twitter.com/rachelnabors> <http://dribbble.com/rachelthegreat> > <http://plus.google.com/u/0/+RachelNabors> > <http://linkedin.com/in/rachelnabors> > ------------------------------ > > Curator of Web Animation Weekly <http://webanimationweekly.com/> > > *Speaking & Workshops* > - Aug 07 CSS Conf Argentina, Buenos Aires <http://cssconfar.com/> > - Oct 17 –18 CSS Dev Conf, San Antonio <http://2016.cssdevconf.com/>, Animation > Workshop <http://2016.cssdevconf.com/#workshops> > - Oct 26 –27 All Things Open Keynote, Raleigh, NC > <http://allthingsopen.org/> > > On Tue, Jun 7, 2016 at 5:40 AM Kseso <kseso9@gmail.com> wrote: > >> Yestarday, Amelia Bellamy-Royds tweeted: >> *I also want an :in-viewport psuedoclass for scroll-based animations & >> lazy-loading.* >> (see tweet: https://twitter.com/AmeliasBrain/status/739865073745833984 ) >> >> Today I want to know your opinion about a new css pseudoclass >> :in-viewport() >> where the value inside the function () defines a viewport area. >> The pseudoclass rule will be applied while any part of the element is >> inside this area >> >> value for :in.viewport() >> [ <length> | <percentage> | auto]{1,4} >> The value may be negative. >> >> For example: >> >> .el { >> opacity:0; >> transition: .5s; >> } .el:in-viewport(10vh 0) { >> opacity:1; >> } >> >> <Gráfico1.jpg> >> >> >> Could declared exclusion areas inside :in-viewport()? >> >> :in-viewport(0 / 30vh 0) {} >> >> <Gráfico2.jpg> >> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Libre >> de virus. www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >> > -- > Curator of Web Animation Weekly > Speaking & Workshops > • Apr 05 –06 SmashingConf, San Francisco > • Apr 21 Frontend Masters, online, CSS Animations and Transitions Master > Class > • May 18 –20 Front-Trends Keynote, Warsaw > • Jun 01 CSSconf Nordic, Oslo > > >
Received on Tuesday, 14 June 2016 13:29:05 UTC