Making web standards even more complicated one change at a time.
The element can now be customized with CSS
121–130 of 194 posts
Re: The <select> element can now be customized with CSS
#122Developers, don't fall for this! This web API scope creep makes it __harder__ to create and maintain truly independent web browsers.. you have to implement more and more and eventually we arrive at the current state of matters - all non-chromium engines are lagging behind. Developers will happily use this, then users will notice websites "look better" in chrome and firefox will become even less relevant. Don't.. you…
> and firefox will become even less relevant No; Firefox can easily afford financially to add this feature. Firefox is already irrelevant; no developer will shed a tear about just blocking Firefox if they refuse to implement. Boycotting won't work either, because boycotts almost never work.
Firefox doesn't have ad measurement and interests sharing built in yet (or am I wrong?) so it is very relevant for me. I would rather use black-and-white selects everywhere rather than having an advertising engine built into the browser.
Re: The <select> element can now be customized with CSS
#123Can someone explain why this took them literal decades to do?
Because HTML historically was designed for marking up text articles by hand rather than building UI with tools.
Re: The <select> element can now be customized with CSS
#124If they keep this up, we'll soon have feature parity with VB6.
Re: The <select> element can now be customized with CSS
#125Earlier quoted context omitted.
Because frontend is frontend, Javascript frameworks dominated the conversation even for silly things like basic web forms for the past 15 years. Basic HTML/CSS is now catching up to the fact that not everyone wants to run a Javascript monstrosity for custom styling on very basic tasks.
The prevalence of JS and JS backed components is due to the reluctance of browser vendors to introduce new HTML elements that everyone has been lobbying for in the same time period. By and large browser vendors for the longest time, even today still in many respects, repeatedly ignore pleas for more elements that cover common use cases. Even when they do arrive, they can be half baked - like dialog or details / summa…
You can't make enough HTML elements to make everyone happy. This was the wrong idea from the start.
Re: The <select> element can now be customized with CSS
#126Some controls are better left unstyled. Look what happened to scrollbars: either they are too thin to grab, have bad color contrast, so it is hard to see what part to actually grab, and, finally, some smartypants have managed even to remove scrollbars altogether from their website. Sure, default select is not the prettiest control, but it gets it job done.
I may not agree with your ugly scrollbars, but I will defend your right to style them.
(If you want to annoy your users, that's your prerogative)
Re: The <select> element can now be customized with CSS
#127Earlier quoted context omitted.
Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.
There needs to be some middle ground. I'd trade off just being able to set just the background color and font and keep these native-like features
If that's all your changing, then why can't you make do with the system default?
Re: The <select> element can now be customized with CSS
#128Earlier quoted context omitted.
I doubt it'll still be able to do those things. From the article: >Using base-select loses a number of features and behaviors: > The doesn't render outside the browser pane. > It doesn't trigger built-in mobile operating system components. I have mixed feelings about it. Mobile users, get ready for poorly optimized select elements. On the other hand it reduces the need for javascript for styling forms, which is good
> The doesn't render outside the browser pane. ... It doesn't trigger built-in mobile operating system components. To me, this is intrinsically what makes a a . Styling is great, but without these features, this doesn't really bring anything new to the table
Thanks to humanity, supporting this is a surefire ticket to someone figuring out how to phish credentials through a element.
Re: The <select> element can now be customized with CSS
#129Earlier quoted context omitted.
I haven't found this to be the case in my experience.
Maybe it's just iframes that are the issue but they were a devil and a half to get working in chrome (or blink ig) without relying on third party cookies.
Interested in what you are doing with the iframes. Something with complex authentication? I've been forced to use iframes a few times for 3rd party resources that should have been first-party (mostly with banks and credit unions), and have only had some styling issues on mobile (which have been overcome by using JavaScript and window.matchMedia to check for media queries).
Re: The <select> element can now be customized with CSS
#130Earlier quoted context omitted.
with automatic ISO8601 timezone offsets would be awesome too!
ISO-8601 is not the correct format for serializing local time unless it's in the past. In my experience, a local datetime picker is going to be used almost exclusively for a future date and time. What you want instead of a timezone offset is a zone ID. That way date and tzdata can handle it properly on the backend.
For this case, I will often ask for the timezone, since that data is often updated on the operating system, but I don't believe it's often for someone to be in the same location and have their timezone change. The software that I've maintained the most over the years (since 2009 up to deploying an update today) requires a login, so I have a client account that includes choosing their timezone. I then use that to convert everything to UTC in the database, and when I retrieve the data, I use it to convert UTC back to their local date/time. I felt that it was the best option, since a user moving to a different timezone should still be able to get dates/times back relative to where they have their current timezone set.