Comment by roncesvalles
13 hours ago
Your premise that the browser implementation is faster and better is rarely true. And when it is true, it's only true in a very narrow lane.
Take for instance something like suggestions on form fields: you start typing something and it presents some options from a hardcoded list that matches the prefix. This is natively achieved through the HTML element <datalist>. However, <datalist> implementations on most browsers suck to the point of being unusable.
The drive to roll your own is not so much that "it would be fun to learn this" as much as it's "rolling my own would let me express my vision exactly". What draws a lot of people to software engineering is that it lets you make anything you imagine. This is also what makes a lot of devs turn their nose at no-code and vibe-coding.
If you can't build things exactly how you want them to be, then it's hard/impossible to build something that's truly genius.
> Your premise that the browser implementation is faster and better is rarely true.
I know that they’ve optimised this as much as they can, but it still seems to catch pretty much everybody by surprise that every single instance of a web component with a shadow DOM needs the site’s CSS reset added to it individually (or just skip it and keep forgetting that things like box-sizing will be inconsistent with your non-shadow-DOM styles). There’s no way to say “here’s my default styles” that will work consistently across the whole page once you start using web components. And then you have the !important fights between the web component and its contents as well.
Even though it’s been standard practice amongst web developers for 15+ years, the people working on the web platform seem to mostly act like CSS resets aren’t a thing.
The tension is between two kinds of CSS users. The ones who want cascading style sheets, and the ones who want scoped style sheets. And sometimes even people who think they want scope find out they also want the cascade, and just wanted to scope a bit "at the end" (something the cascade can do anyway)
Scoping now is much easier with CSS Modules
1 reply →
I find that developers add a CSS reset without thinking about it as if there is always a need. We never used resets. There was never a need. Typically we would set something according to the design anyway and starting with a reset was like slamming something against one wall only to throw it back to a different wall later.
They were a lot more necessary when each browser threw in fairly random sets of default styling. These days they've converged heavily on the same defaults.
Surely you must reset something? At the very least box-sizing
1 reply →
The history here, as I understand it, was that they imagined you would use custom elements from multiple third parties, so any shared CSS definitions would cause breakages.
See eg the (now removed) HTML imports standard.
[flagged]
fwiw, your comment would almost certainly have positive karma if you had left off the final paragraph. Asking for sources is popular here. Grousing about how you're oppressed by the dumb voters on the site is not.
[flagged]
4 replies →
Native date pickers can’t handle range. So then you need two date pickers with validation logic.
That’s just one example of the native implementation lacking common utility. That’s one thing they could mean when they say the native solution is lacking.
I noticed your comment was down voted quite a bit, so I up voted it. It is not really performance related, but it does make an excellent technical point.
5 replies →
What would you expect a designer to measure when making an aesthetic judgement?
[dead]
> Your premise that the browser implementation is faster and better is rarely true
Thankfully, this opinion is measurably false just by reviewing source code of any website. What you're referring to, primarily, are categories of elements like form elements like <datalist> and that's fair.
This is why the web community is asked to support improving the platform through submissions to Interop, such as this one for <datalist>
https://github.com/web-platform-tests/interop/issues/1402