... this post perfectly encapsulates why I hate web development. A painful and easy to miss bug when trying to reimplement a GUI feature that's been available in every decent GUI framework for over two decades.
Last I checked the form additions from HTML5 were still pretty spotty in support, several don't really have a real world use case, and nobody wants to make any more really.
CSS can fix that once good native controls are implemented.
Another issue is styling checkboxes to use custom images for the different states (including hover and pressed styling).
The CSS UI spec (https://www.w3.org/TR/css-ui-4) doesn't detail any of that, and the WHATWG HTML spec only defines the values of input fields (e.g. https://html.spec.whatwg.org/#the-input-element), not what parts of things like a date control are available and how to style them.
I miss the days when clickable things looked clickable.
We're trying, and we need help: https://open-ui.org/
Come say Hi on Discord, anyone who has written a JS control has input that the project needs.
You can debug one of the most complex softwares in the world (a browser) so effectively you can understand what you did wrong and fix it.
On mobile, as a rule, the second a design transcends things like tables, buttons, and forms is when the “lower level” native APIs start getting broken out.
Wrapped in nice little JS/TS APIs so nobody freaks out, of course.
Having developed custom elements in both web and native, I felt that web was easier and more predictable than native. (For example adding clipping to images on iOS throws away most possible optimisations resulting in abysmal FPS) Of course the “best possible” UI is also slower and worse than what could be done in native.
(Also, on mobile I firmly believe that native is the right way to go with the current tech)
webdev is incredibly flexible by the very nature of "build it yourself", and that's a good thing.
Having performance impact from badly optimized implementation is a testament to this flexibility - what you are saying is akin to "C is bad because i could fk up memory"
It is insane how complicated this is. Then you need to consider the differences between browsers. Ultimately you have to start using a library. And integrate that library with the framework and then hope that the framework won't have a major technical overhaul like Angular or Vue had.
Most of the time you just sit there thinking what will be the best approach and start to get more demotivated the more you dig deeper into it.
It is hard.
CKEditor would have solved most of my issues, but their licensing is absolutely crazy. I'd have to contact them to get an offer to use it for normal internet usage, but if I don't know if it will work, and if the site will be a success, then it simply does not make sense to contact them. 37 USD for 25 users? Or getting a custom contract where I don't know how they will change it in the future? I don't understand what assumptions they have about the usage of their editor, but just embedding it into a blog or something similar, where you don't really know how many users you will have, definitely isn't one of them.
So if I invest my time into learning this upscaling/downscaling issue, which can get complicated with a Vue component, all this in the context of prototyping the entire app, where the primary functionality gained by CKEditor the ability to enable drag and drop (move) of components as if they were pictures, it seems like overkill, since directly manipulating the DOM to move elements appears to be a a much more simple task.
I've made a test wit ondrag, ondrop and what JavasScript has to offer and it mostly works, but there are some small issues which I just can't resolve and don't know if I can resolve them if I invest more time in that direction.
So currently I'm checking out drag and drop libraries, which mostly seem to fit the purpose, but also have issues.
This is what I was getting at with my initial comment, that it's so hard to make these decisions if the outcome of the paths is so unclear. It's all a struggle between decisions and their tests which need to be made.
Assuming CKEditor would solve the issues for me, then the initial cost would still be to high. That would be different with a stable stream of income, but new services usually don't have that.
Free for up to 5 active users per billing period? This would be take 5 users to just check out the service and then that's it for the rest of the month. 37 USD for 25 active users per billing period? Simply not doable for me in the context of a startup.
> What is the minimum length of subscription-based software licenses? 12 months.
That's 444 USD for 288 potential users which wouldn't get charged more than 2 or 3 USD per month.
It still offers an open source option so you can test all its limits and see if it fits your case or not. Also if your project is not proprietary there is still the free for open source option in case your project is not compatible with GPL2+.
Run your virtualized browser within any browser.
- browsers have had native text tooltips for at least 20 years
- there are active proposals intended to address richer tooltips and similar use cases
- adding new controls to the web is a complex matter because there are a lot of stakeholders to consider, and a lot of consensus to build among implementers/standards authors
- complaints about missing UI features on the web often overlap with complaints about standards bloat and browser bloat
- this article is rich in technical information that’s applicable more broadly than the tooltip use case, and maybe every single article about anything web on HN doesn’t need to be drowned in generic myopic complaints about the web
HTML was not designed to be dynamic. There are too many redundant feature of HTML/CSS/JS, and honestly I would make everything obsolete and design a new document format with a open binary format.
We're now building applications. Applications have a totally different layout model. Only recently we're able to use flexbox. But it's insane. Just build the layout / application in something that really works (any of platform UI toolkits / markups), and use HTML for document flow.
It won't be a problem if the tooltip has delayed appearance by 80ms, but it holds the process. So the site will have a 80ms stutter everytime a tooltip appear.
They get a bad rep, but it's perfectly possible to create something secure, stable, maintainable and performant
it's, like, five frames on a slow monitor. missing a single frame is already bothersome and worthy of bug reports.
With all the downvotes I'm getting I might be missing something though :P
The sum total of ignoring this kind of performance footgun is why apps like Slack feel so crappy. You can't get into the flow because it's a pile of high-latency, asynchronous interactions. I haven't used Photoshop in a long time, but back in the early 2000s even on my Compaq with 32MB of RAM it was snappy. I can't imagine using something as complex as Photoshop built as an Electron SPA and keeping my sanity.
[1] https://stackoverflow.com/questions/536300/what-is-the-short...
just because human's reactions are slow, does not mean that humans do not notice. In music it's routine to have people complain when latency goes above 15 ms and it was recently shown that humans could notice in some physiological way down to half a millisecond of latency.
Just curious