21–30 of 223 posts
Opinions are my own. I don't think this is recommended to use internally at Google because it's not supported on Safari.
That seems like a bizarre reason not to use it, given that it's strictly a performance optimisation, and browsers will simply ignore CSS rules they don't understand.
I have never heard of the "contain" property before this article. It seems like it can be very useful.
Unfortunately, as is often the case when one learns of a new CSS property or a Web API, the browser support is just not there yet. Safari, for example, doesn't support this at all: https://caniuse.com/mdn-css_properties_contain
In this case it's just a performance hint, so Safari users would have the same experience they do now. Everyone else would benefit.
I’m not a frontend dev so I just stick to vanilla html and js. I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations. So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?
However, it's not like the UI guys in the article didn't do that and implemented some crazy shit poorly. They just slapped a table on the page, incidentally with 38k elements - sounds a lot like what you did actually, and it lagged the page due to browser painting/layout issues.
Now, finally: how exactly is what you did not just the same as this, except they were actually making a usable front-end so the addition of CSS broke the browser rendering engine? Because it sure doesn't sound like you would know what to do in the situation the article discusses...
I’m not a frontend dev so I just stick to vanilla html and js. I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations. So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?
I’m not a frontend dev so I just stick to vanilla html and js. I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations. So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?
Having said that, it just looks like you're arguing about something you don't know much about, while at the same time trying to put down people who have been doing this for a while.
Earlier quoted context omitted.
> There should just be one way to do a scrolling list, implemented natively and left alone. I can't even imagine how that would work without turning into something like that can only be minimally styled and has to be (usually poorly) re-implemented to get it to look the way you want it to.
Maybe webdevelopers should stop trying to make everything look different from its defaults. It used to be that you could reliably predict what clicking the mouse in a region of the screen would do. It wasn't progress, when webdevelopers threw that out...
I’m not a frontend dev so I just stick to vanilla html and js. I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations. So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?
I'm not sure what you are asking. You can of course build a trivial use-case with a native feature and have it perform as one would expect from a native HTML element. However, it's not like the UI guys in the article didn't do that and implemented some crazy shit poorly. They just slapped a table on the page, incidentally with 38k elements - sounds a lot like what you did actually, and it lagged the page due to brows…
I’m not a frontend dev so I just stick to vanilla html and js. I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations. So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?
I have never heard of the "contain" property before this article. It seems like it can be very useful.
Earlier quoted context omitted.
That seems like a bizarre reason not to use it, given that it's strictly a performance optimisation, and browsers will simply ignore CSS rules they don't understand.
I imagine that it could cause accusations from Apple that Google is trying to take their customers out of the ecosystem, putting a nice cash flow at risk.