Live data from Hacker News

I'm betting on HTML

catskull.net

351–360 of 458 posts

Re: I'm betting on HTML

#351
post #125

Earlier quoted context omitted.

why annoy users with a custom component Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on. My users alwa…

That's totally on point, but I think the core issue is less about "why the native date picker isn't always appropriate" and more "why do we keep half-assing non-native alternatives?" The way I see it, so much of the web is a clunky mess precisely because software development today pretends to be engineering while simultaneously being about the bottom-line and little else. No doubt, a great date picker could be develo…

There’s a little more harshness than needed in your comment, but I generally agree with it. Having brought this up before, I’ve usually seen either no or strange reactions to it. It feels like web dev consists of people who only have done their job for an unknown faceless client sitting behind layers of teams and toolchains. Driving to a specific person, listening to their brutal feedback on your system and being asked to maybe fix it right now would be a sobering experience to some of them.

Re: I'm betting on HTML

#352
post #282

Earlier quoted context omitted.

CSS3 and HTML5 are not meaningful semantic version numbers anymore and haven’t been for over a decade. Both CSS and HTML are considered “living standards” now and no longer use version numbers: https://html.spec.whatwg.org/multipage/introduction.html#is-... ? Nesting in CSS became broadly supported in Chromium and other evergreen browsers a few months ago. This is a feature that developers have had to use inside of s…

> Nesting in CSS became broadly supported in Chromium and other evergreen browsers a few months ago. Firefox hasn’t shipped it yet. https://caniuse.com/css-nesting shows it landing in 117 next month. > Even now, it’s not supported by older versions of iOS/mobile Safari which could easily be 15-20% of a large US based websites’ traffic. Yeah, actual global support is probably still below ⅔—caniuse.com is showing globa…

i've played with nesting on firefox and, much like the :has() selector, it seems good enough for the 80% case, so i wish they'd unflag it so we could get the clock started on having it be commonplace in a year or two to use it confidently.

Re: I'm betting on HTML

#353

Earlier quoted context omitted.

There is some nuances here. While the general halting problem for a general Turing machine is undecidable, and with a fairly easy to understand proof as well, the computers we run today are not a general Turing machine. They are of a weaker class called Linear Bounded Automatons and for the programs they can run, the halting problem is fact decidable, on a theoretical level due to their finite nature. So we will prob…

It’s fun to think about. What about the Collatz conjecture? If we run it for arbitrary n, on a computer that represents numbers up to n_max, we could know if it will halt within n_max steps. Since only n_max numbers are representable, we could track all visited numbers to detect any cycle that might occur. If on the other hand any iteration would exceed n_max, then the program would halt by crashing. hailstone :: Int…

We have actually done something like that up to the 32bit n_max for sure (but maybe even 64bit?), without any number that would contradict the conjecture.

But yeah, it is not even trivial to say whether it has a bounded max memory, so in case of an arbitrary precision int type, it may not be LBA, but Turing?

Re: I'm betting on HTML

#354
post #341
post #332

Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever." I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of…

agree so much. Projects that aim to build a data resource and then let AI use that resource are missing the point. The AI is the data resource. Some projects claim that knowledge graphs or other data assets can help the AI retrieve 'true' knowledge. Personally, I believe that the better approach is to develop methods that allow AIs to create their own data assets, the weights in their networks is one of those assets.…

While the issue of "truth" is interesting and important, it is also fairly orthogonal to the task of simply extracting what a given page or bit of content claims. (Perhaps not 100% orthogonal in the absolute limit, but generally so.)

As absolutely hard as I have gone against the semantic web community at times over the post few years, I do not in the slightest hold a failure to "determine truth" against them. I consider them to have been tilting at windmills as it is, criticizing them for failing to conquer that windmill, which humanity has been jousting with since the dawn of recorded history (and probably beyond), would be a degree of cruel I couldn't entertain. :)

Re: I'm betting on HTML

#355
post #332

Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever." I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of…

Are you suggesting that AI will solve web accessibility, which is based on semantic HTML and ARIA? Because if not, humans will still be required to ensure that web content is accessible, and in that case semantic HTML remains important.

Re: I'm betting on HTML

#356
post #311

Earlier quoted context omitted.

Well, instead of writing this for every button in your web app: Button You can write this: Button The utility is pretty clear to me

so we've just circled back to good ol bootstrap?

That's even valid bootstrap classes

Re: I'm betting on HTML

#357
> I believe we now have virtually a complete set of all UI elements needed to build any modern web application.

This is pretty far from the case. Three examples:

* Dropdown menu. This is a superset of selects, which can only contain options: a dropdown can contain anything in its dropdown, including a nav which contains links displayed as icons, for example.

* Carousels/slideshows.

* Tab areas.

I've got a library of these kinds of elements implemented as CustomElements, but they're pretty geared toward the websites I've worked on in the last year, so I want to spend more time making them extensible before I release them as open source--I don't want people depending on my work until they are better-designed.

That said, HTML by default has gotten a lot more powerful than a lot of web devs know about. In particular, there's a lot of custom data lists and date pickers out there which are less powerful than the built-in HTML datalist and input type='date'

Re: I'm betting on HTML

#358
post #332

Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever." I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of…

Are you suggesting that AI will solve web accessibility, which is based on semantic HTML and ARIA? Because if not, humans will still be required to ensure that web content is accessible, and in that case semantic HTML remains important.

Actually, that sounds like one of the better startup ideas I've heard around AI. Automated accessibility compliance (or something close to it) would be very useful and definitely something people would pay money for.

I fear LLMs are only about 80% up to the task, though, which is actually a very unpleasant place to be in that curve; sort of the moral equivalent of the uncanny valley. Whatever comes after LLMs though, I bet they could do it, or get very close.

Re: I'm betting on HTML

#359
post #244

Earlier quoted context omitted.

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.

I think what that person meant was if browser default styles made semantic HTML look more beautiful, it would probably reduce the incentive for lazy devs to make div soup.

Like imagine if every browser preloaded a dozen attractive classless CSS frameworks for users and/or devs to choose from sort of like CSS Zen Garden.

If all browsers had that, I think we'd get less div soup.

Re: I'm betting on HTML

#360

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…

I think if the web apps we were working on were marketing landing pages, you'd be right. For any real application that software engineers are hired to work on, "learning HTML" would do very little. Most high-level front-end engineers do know HTML. There's not that much to know. The web today is basically a universal desktop client. Apps like Figma, Slack, Airtable, and thousands of others are not really websites, the…

Attitudes like that are why so many "real applications" have things like progress bars assembled from divs and JS instead of using a progress element or show/hide toggles assembled from divs and JS instead of using details/summary elements. Turns out there are so many HTML elements for a reason.
Post reply on HN