Live data from Hacker News

I'm betting on HTML

catskull.net

251–260 of 458 posts

Re: I'm betting on HTML

#251
post #244
post #230

Earlier quoted context omitted.

> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using ` ` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experi…

Covered is stretching it. Most raw HTML elements look terrible and wouldn't pass muster with pretty much anyone. IMHO, this is a big miss with browsers. Sites look awful without styling and you have to be pretty good with CSS to even make them look passable. Way easier to reach for a framework with prebuilt components

Look terrible? Didn't we have this debate a couple of decades ago about separation of semantics and presentation? Sorry, I should have let it slide.

Re: I'm betting on HTML

#253

Some social networks used to offer rich page customization with Wiki or markup or something like that. And that essentially was the HTML wheel reinvented. Some even offer in-app apps, some even lock whole life oof the whole population in them (e.g. China). A social network with (or without) this essentially is reinventing the wheel of the whole Internet which is made of HTML pages (which are replaced by personal page…

You don't use CSS just to make pages pretty. It is useful for accessibility and user experience as well. Not to mention personalization. Not every page needs to have a carbon copy style of others. CSS is so useful it is almost ridiculous to say HTML never needed it.

Not sure why people are banging against css. Its just fundamental separation of content logic from content representation which is best practice (see e.g grammar of graphics)

I think people are just burning out from the oppresive tech environment, the endless hypes, the lack of a feel-good factor. All these negatively experienced developmemts are taking their toll. This forces people into all sorts of extreme corners, like the gemini protocol or css-less sites.

Re: I'm betting on HTML

#254
post #243
post #157

Earlier quoted context omitted.

>Take the [HTML] datepicker * Lets you enter nonexistent dates like 31/2 * Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example). * No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to…

> ...place the user in American-style MM/DD... > No ability to force date style by design. There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc. The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve. > L…

>The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird;

Legacy Edge used to look at keyboard locale and ignore the actual region settings. I have no idea why chromium uses MM/DD on my machine when Firefox does DD/MM. Back when $COMPANY used HTML date widgets we got a small but constant stream of complaints which we tried to triangulate (that's how I know about the Legacy Edge behaviour), but we never understood most cases.

Autodetection has been broken on a tail edge of cases for a long long time, and nobody in browser space seems to have any interest in fixing this - or worse, allowing the server to set the correct date style. The only practical fix is JS datetime widgets.

>or at least not a problem a web-dev should solve.

I think 'a not-insignificant amount of people constantly enters the wrong dates and eventually bothers support and writes bad reviews, plz fix this' is a good business cases and is something web-dev should try to handle.

>> Lets you enter nonexistent dates like 31/2

>server-side validation is needed anyway.

True, but it's a better user experience to disallow this also on client. If we only let the server do validation, why do we even bother with the SPA and the sixty-thousand one-line npm packages?

Re: I'm betting on HTML

#255
post #230

Earlier quoted context omitted.

(I don't know what tools you use so this isn't a comment directed at you specifically) If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot. There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and…

> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using ` ` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experi…

I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.

Re: I'm betting on HTML

#256
I'm aware of all these HTML elements, I use them for my personal digital garden website that just uses CSS grid to align everything, no external scripts or styles.

Guess what? It still looks bad! The element for instance is hard to style with CSS, things don't work the way you'd expect. Frankly that element was leapfrogged in terms of usability and customization by pretty much any jQuery accordion script from 2009.

Re: I'm betting on HTML

#257
post #235

The problem I see with sematic web is that no matter how easy it gets, developers refuse to use it properly. I have been looking closely at the tag since a browser extension of mine uses it, and although it is extremely clear what it should do in the MDN documentation (the documentation itself is a good example usage of , etc.), very little sites use it properly. Even the fancy professional sites wrap all the page co…

> simple element can't be used properly, I have no hope for all the others. The first solution that comes to mind, is stricter validation. Where the browser would just refuse to render a properly unless it's structure is correct. But we had that. Anything before HTML4 really. And it sucked even more. So maybe browser dev-tooling that throws warning or errors when devs are Doing It Wrong?

Give me an incentive to use it. If it looks exactly the same and behaves exactly the same, "div" is half the characters of "footer" so it wins.

Personally, the argument that search engines will do nice things with semantic HTML didn't convince me back then, and I don't even see it brought up today, because search, like fish, stinks from the head, and we stopped pretending otherwise.

So that leaves accessibility. Is there a way to visualize what screen readers to with a page? I know about the tools that check for missing ARIA roles and whatnot, but that still doesn't catch me using a div when I should have used aside. And I know I won't try to navigate and use every aspect of things I make by actually using a screenreader. Call me lazy, but that's just not going to happen. But I also don't want to just give up and make it the problem of other people, either. I wanna meet halfway if possible. Any tips or tools or ideas welcome.

Re: I'm betting on HTML

#258
post #230

Earlier quoted context omitted.

> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using ` ` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experi…

I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.

But it does seem that no one enjoys actually building MPAs and that force is currently winning right now.

Re: I'm betting on HTML

#260
I don't want to totally neg on web dev. But it does suck donkey balls. I've been doing it for years. From writing raw html,to using scripting langs, frameworks and what not. And the amount of time it takes to do not a lot I figure is just a colossal brain drain. We just went on holiday, and all I wanted to do was look up places to go eat and drink, or visit for the day, and most of the sites sucked. Or were out of date. Not updated or whatnot. There's still lots of fire once and forget sites. Probably because budgets are tight and people can't afford updates. Or the updates are just technically too difficult for people to grok.

The complexity of sites is paralysing. What could be a few simple pages of texts and images is totally over-engineered for no good reason and is burning a stupid amount of CPU cycles. Probably built on a hacked off-the-shelf CMS that could do with security updates.

CMS and frameworks are being used, because there wasn't a good alternative to something as neat as frames.

A site I'm working on at the moment has quite a pretty design, but pull the CSS and it's just a mess.

I was looking at going to the cinema recently and the local picture house made it practically impossible to just scan the handful of films that were playing that week. I realised you could pretty much shove it all in a spreadsheet and it would read better. Heck, I downloaded the JSON from their API, and it was easier to read.

Most of it is all tiresome lipstick on a pig.

Facebook was a success for a few reasons, one was the easy on-boarding (which uses nefarious privacy trade-offs), the other is that you could actually share photos easily. Also see: Whatsapp and Instagram. Publishing needs to be easy. And despite a simple FTP being easy, there's a weird disconnect in the usability process that makes this tricky for mere mortals. People want to drag and drop, or upload, fire and forget and edit easily. And those wanting to consume data, really just want the bare essentials: The data.

Post reply on HN