Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

Post reply on HN
Print view View original

301–310 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#301

Post by tobyhinloopen »

b0rsuk wrote: post #295
ziftface wrote: post #117

Earlier quoted context omitted.

The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible. I often need to very quickly make internal services at my job and while I l…

Javascript is as privileged as programming languages get. It's welded into all web browsers except perhaps Lynx. To get traction, an alternative language would need to be simultaneously included in several browsers. Good luck with that.

Only webassembly can save us

Re: The unreasonable effectiveness of simple HTML

#302

Post by petepete »

codazoda wrote: post #127
wizzwizz4 wrote: post #111

Earlier quoted context omitted.

Conceptually, those are links, not buttons. Buttons are for forms and JavaScript and such.

Fair. I would typically us a form tag with an input tag inside it for forms. Sounds like the button tag can be styled a little more because it allows i, em, br, img, and similar tags inside it, while an input does not. They are interchangable in the case of a form (based on your style need).

There are more ways to interact with a link than a button.

You can drag it to your tab bar, bookmarks or desktop, middle click to open in a new tab, copy the target URL etc.

With a button you can push it.

Re: The unreasonable effectiveness of simple HTML

#303

Post by FrontAid »

moring wrote: post #298
grishka wrote: post #76

Earlier quoted context omitted.

That's what a CSS reset is for.

HTML buttons have special behaviour in CSS (not even styles, but differences in the rules how they work) that cannot be reset using a CSS reset. I actually tried to make a button fit into the reset of the UI until I gave up and used a div.

Like what? I can't think of any "special behaviour" that I would not want to have in a button and that cannot be changed by CSS.

Re: The unreasonable effectiveness of simple HTML

#304

Post by moring »

FrontAid wrote: post #303
moring wrote: post #298

Earlier quoted context omitted.

HTML buttons have special behaviour in CSS (not even styles, but differences in the rules how they work) that cannot be reset using a CSS reset. I actually tried to make a button fit into the reset of the UI until I gave up and used a div.

Like what? I can't think of any "special behaviour" that I would not want to have in a button and that cannot be changed by CSS.

Vertical alignment.

"button are special element and their content is always vertically aligned by default. Even all the propertise are the same, if you don't center the text in the link, you won't get the same visual"

https://stackoverflow.com/questions/64766922/what-can-make-t...

Re: The unreasonable effectiveness of simple HTML

#305

Post by corty »

scrollaway wrote: post #239
pvorb wrote: post #181

Earlier quoted context omitted.

I fully agree with all of your points. I just wanted to point out the irony that the manual and other documentation for this "inclusive design" toolkit come as PDFs – the worst choice you can make if you strive for accessibility.

PDFs can be accessible, and many of them are! Everyone who works with PDF needs to know about PDF/A: https://en.wikipedia.org/wiki/PDF/A PDF/A is a small family of sub-formats to PDFs which amount to the accessible subset of PDF + some requirements. PDF/A and PDF/UA are mandated by a variety of governments for PDF distribution. They're very suitable to archival and are accessible (screenreaders can work with them, th…

PDF/A isn't necessarily accessible. First, PDF is very hard to impossible to scale for people who need big writing, due to reflowing being unavailable or not working properly. Text in PDF/A can still be a big image, e.g. in a scan for archival purposes, if you are "lucky" there is an OCR overlay, but then your screenreader reads OCR'd text which is hit-or-miss. And text ordering is supposed to be "reading order" in PDF/A, but many tools, especially DTP tools make a mess of it and jumble up the (screenreader-visible) order of text in textboxes, columns and sometimes even paragraphs.

IME PDF/A is better than nothing, but far worse than plain HTML for accessibility..

Re: The unreasonable effectiveness of simple HTML

#306

Post by midrus »

ziftface wrote: post #117
apabepa wrote: post #19

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more…

The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible. I often need to very quickly make internal services at my job and while I l…

I'm interested in knowing how you get to do "crud stuff" so fast with Next.js

- How do you do validations?

- How do you handle database migrations?

- How do you handle background jobs?

- How do you handle authentication?

- How do you handle authorization?

- How do you handle file uploads (to filesystem or S3)?

- What ORM or database toolkit do you use for queries?

- How do you send emails?

- How do you do websockets/real time?

All of these of course have answers, but each one of these comes with a lot of "decision fatigue", discussions, maintenance work and I highly doubt the cost of reaching the same level of robustness of a full stack framework is any smaller.

Real life production "CRUD stuff" is not just some http handler doing sql inserts into sqlite. There's a lot more involved. That's what Rails/Django/Symfony give you a solution for. I agree Next.js could have a faster startup for a landing page. But as soon as you need the most minimal backend, you are way, way, way further to get something robust working if not using one of the full stack frameworks.

Re: The unreasonable effectiveness of simple HTML

#307

Post by antihero »

zelphirkalt wrote: post #7
antihero wrote: post #4

Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…

I think this is an exclusionary mindset. Just because it is a tiny subset of users, it is OK to exclude them? How about when it is quite easy in many cases to support them, by using standard conform simple HTML? Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? In fact, just today I have seen it, on a VPN login, on a thing, that is suppos…

I think reaching for JS is often a reflex because we want to avoid delving into building backends that aren't a simple REST API. If you stick to HTML and CSS you need to start building pages and managing state server-side, which a lot of people don't really want to do.

Even cheap, old smartphones support JS. You can have fast, efficient JS.

Re: The unreasonable effectiveness of simple HTML

#308

Post by antihero »

kstrauser wrote: post #58
antihero wrote: post #4

Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…

In the US, we collectively decided (via elected representatives) that this is important to us, and we passed the ADA to enforce it. Visually impaired people have as much right to use stuff as you and I do, and the law says so. From a purely economic point of view: if your competitor's website supports the visually impaired, and yours does not, then even though that's a relatively small market segment you're probably…

Don't modern screen-readers work based on rendered content? So if your JS is outputting ARIA tagged DOM, it will be fine.

Re: The unreasonable effectiveness of simple HTML

#309

Post by dvdkon »

Wowfunhappy wrote: post #235
dvdkon wrote: post #227

Earlier quoted context omitted.

Because once one site starts needing X px, most users will just keep their browser at least X px wide. At some point X became so close to the monitor's resolution that not maximising the window is just extra work. I'm not happy about having to maximise my browser, but I would be less happy about having to scroll horizontally. There are definitely some people who just maximise everything out of habit, but I don't thin…

No, I actually don't think websites have much of a problem with this. I generally keep my browser around 1,000 pixels wide (more or less depending on what I"m doing), and websites generally work fine. Responsive design helps a lot, as you say. What surprises me is how many users seem to keep their browsers maximized at all times, particularly on desktop-sized displays! I'm pretty sure I see people doing it more on Wi…

Interesting. A number of websites don't display correctly for me if I use just half of my 1920 horizontal pixels. Keep in mind that many users still use 1366x768 or similar screens.

As for maximising, Mac OS X never had a conventional one-click maximise button, the green button originally did something like resize the window to an optimal size (IIRC), and now it makes the app fullscreen on a separate "virtual desktop" of sorts. It might well be a habit from the times Windows didn't have Aero Snap.

Re: The unreasonable effectiveness of simple HTML

#310

Post by kuschku »

gcblkjaidfj wrote: post #257
pier25 wrote: post #256

Earlier quoted context omitted.

It would be great if browsers implemented other common elements such as sortable data tables, carousels, etc. https://open-ui.org/

You have a great point. Browser UI elements are stuck in time and all the attention now is directed to things that Google can make money from (e.g. DRM, sandbox for rich apps/extensions, webrtc for their video call products, etc) but your cited site is not a good advocacy of that. Not even the most exalted UI framework fix the most obvious problems with those either. e.g. tables still won't hold the header and first…

> e.g. tables still won't hold the header and first column(s) while scrolling.

https://caniuse.com/css-sticky

position:sticky works on tables.

Post reply on HN