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

I'm betting on HTML

catskull.net

Post reply on HN
Print view View original

81–90 of 458 posts

Re: I'm betting on HTML

#81

Post by andai »

theteapot wrote: post #72
p-e-w wrote: post #26

HTML is the solution to walled-garden lock-in? What? Those walled gardens already use HTML, including some of the semantic elements mentioned (plus ARIA semantic attributes, which are much more sophisticated). > ChatGPT-like interfaces are likely the future of human data access. And the whole point of artificial intelligence systems is that they don't require specialized "machine-readable" annotations in order to pro…

> ChatGPT (and its future offspring) can navigate regular websites the same way humans do. They don't need us to hold their hand. It can?! It does that?

ChatGPT had a Browser Plugin (via the Plus subscription) but last I checked it was removed, (possibly because it cannibalized Bing? Or just the reliability issues).

Re: I'm betting on HTML

#82

Post by infogulch »

klabb3 wrote: post #55
waihtis wrote: post #20

I'm personally betting on HTMX https://htmx.org/

I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume). That said, this is me speaking about htmx based on what I know about it. The…

That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multiple extra round trips and device speed/power. And you could get into the hydration and SSR mess, but then you could just render on the server in the first place and simplify the entire system, reduce your LOC by 5x, opt out of the entire js ecosystem shitshow (or keep it for select high interactivity components, I won't judge), and eliminate an entire api that doesn't need to exist.

If you are building the next google maps, maybe htmx isn't for you. But if you're building another LOB app with mainly forms and data views, or an ecommerce site, or another CMS, there's a 99% chance that htmx is plenty.

Personally, I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing here: https://github.com/infogulch/caddy-xtemplate I'm currently co-developing this with an rss reader webapp to work out the kinks.

Re: I'm betting on HTML

#84

Post by sham1 »

robotresearcher wrote: post #15
mkl95 wrote: post #13

> Pretty much you can highlight text. By default Safari shows a yellow highlight. I like it! Chrome also shows a yellow highlight by default. But since I don't have Safari installed on my machine, I don't know if it's exactly the same color. Also, I'm not sure if other browsers have the same default color. Isn't it a good use case for CSS?

CSS will let you choose the highlight color for your readers. Semantic markup lets the reader choose the highlight rendering, including the choice of leaving it to the browser. A blind reader can configure their client to speak highlights.

Of course it doesn't need to be one or the other. You can still use CSS to give the highlight a uniform colour, while allowing for reader modes to still have the highlights and have the accessibility of the screen readers speak the highlight.

Semantic markdown and CSS should ideally be seen as complementary and be used as such.

Re: I'm betting on HTML

#85

Post by vermilingua »

Amusingly, the MDN guidance [0] on vs is exactly backwards from the example they give a paragraph below:

> The element represents stress emphasis of its contents, while the element represents text that is set off from the normal prose, such as... when the text refers to the definition of a word instead of representing its semantic meaning.

And then [1]:

    

      In HTML 5, what was previously called
      block-level content is now called flow content.
...which would be an exemplar case of when to use .

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...

Re: I'm betting on HTML

#86

Post by klardotsh »

Gigachad wrote: post #56
klardotsh wrote: post #9

I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…

In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you fu…

Unfortunately this is a case where we'll have to agree to disagree. Half the time with Electron apps I wish I could disable CSS completely and just use my system theme because it sucks less than whatever the designer came up with for that app (the definition of "sucks less" falls into many axes that vary per application and context; no point in digressing far into that), so what you described would be a feature, not a bug, to me.

(Further, I basically never, ever want an app to theme itself. Ever. If I set a system theme it's because I want the system to look like that. I've gone on tirades here and on other forums for years about finding https://stopthemingmy.app/ and even just the freedom of every electron app to pick its own HIG and UX as absolute heresy, so if nothing else, my opinions are consistent here.)

Re: I'm betting on HTML

#87

Post by komali2 »

I'm not clear from reading the article twice on how HTML helps solve issues interopping with sites like Facebook, Twitter, or reddit. I've scraped these sites before and they render in html but either do obsfucation or detect that you're scraping and block you. Actually html was worse than the previous reddit thing that used to exist, where you could add `.json` to basically any reddit url and get back the page in json format. So easy!

So, did I miss something in the article?

Re: I'm betting on HTML

#88

Post by klardotsh »

vanarok wrote: post #39
klardotsh wrote: post #9

I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…

https://qutebrowser.org

I've used qutebrowser off and on for many, many years. At the end of the day, it's a skin over QtWebEngine, which uses Blink under the hood, and thus contributes to Google's overdominance of the web and the standards that define it, so I try to avoid it, despite it being a better implementation of a Vim layer than, say, Tridactyl for Firefox is (in my opinion).

Beyond that, QtWebEngine is about the polar opposite of the type of engine I described in one key area: resource usage.

Re: I'm betting on HTML

#89

Post by andai »

Dalewyn wrote: post #74
Gigachad wrote: post #56

Earlier quoted context omitted.

In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you fu…

>And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. Wouldn't that be a feature? "Modern looking" as far as I'm concerned means "Can't figure out WTF this bloody thing is." and that assumes I even know there is a thing in the first place.

I noticed this helping an elderly neighbor with her banking. "No, you don't click there, but there... you can tell because..." then realized there's literally no way to tell. It's all flat.

Re: I'm betting on HTML

#90

Post by b112 »

lelanthran wrote: post #52
jamamp wrote: post #22

Earlier quoted context omitted.

You might like this: http://youmightnotneedjs.com/

There's a scroll indicator! It tells you, by looking at a thin bar, how far down the page you are! What a novel idea! I wish browsers had this builtin so that we didn't need to implement a bar for showing the user how much of the document is left to scroll. (Seriously though, wtf did firefox make the scrollbar autohide? In order to see it the user has to interact with the page. It's worse in the debugger, where horiz…

Because firefox devs are... weird. I don't even mean that detrimentally, just observationally.

You can un-hide that bar permanently, but when you do, it always covers the edge of the webpage.

# scrollbar fixes

user_pref("widget.non-native-theme.scrollbar.style", 1);

user_pref("layout.testing.overlay-scrollbars.always-visible", true);

I literally cannot see the benefit in hiding the scrollbar. It sounds like an edge case made primary.

Post reply on HN