3 ms·
This looks like a very welcome addition, I will certainly be using it if it makes it to standard. I've often had to resort to JS to "detect" when my sticky elem
by samwillis 3y ago
This looks like a very welcome addition, I will certainly be using it if it makes it to standard. I've often had to resort to JS to "detect" when my sticky elements are stuck before.
I really like all this invitation that's happing with CSS at the moment, and I do believe it's coming from a place of ambition for the open standards. The standards process seems to be doing a good job of selecting the additions that other browsers have tested and committed to, so it doesn't feel like a "embrace/extend/extinguish" process from the Google Chrome team.
I know some people feel these additions are making CSS "too big", but the joy of it is that you can select what subset you want to use. The web platform is a platform for all, and that it what I love about it. You can build anything from a simple text page to a full blown application with one toolkit.
- aloisdg 3y agoI think we are going to come back to a split of jobs between the front stack. html+css template in one side and a js dev or server side dev in another. They will work together as one but with a different skillset.
- The_Colonel 3y ago> I know some people feel these additions are making CSS "too big", but the joy of it is that you can select what subset you want to use. The browser implementation teams don't get to choose what to support, though. The argument is usually that a too big web platform will lead to a browser monoculture and increased control by one company.
- inopinatus 3y agoBrowser implementation teams actually do sometimes refuse to implement a feature of the applicable standards. It's pretty rare, though. The Webkit team's refusal to implement customized built-in elements sticks in the mind, not least because their reasons (and inability to describe an alternative) always sound more like a vendor pissing contest than any kind of engineering discussion.