[HN Gopher] I'm betting on HTML
___________________________________________________________________
I'm betting on HTML
Author : catskull
Score : 868 points
Date : 2023-08-02 03:31 UTC (19 hours ago)
(HTM) web link (catskull.net)
(TXT) w3m dump (catskull.net)
| re-thc wrote:
| Time for HTML6!?
| tannhaeuser wrote:
| While the term "HTML 5" hasn't been used by WHATWG HTML
| snapshots, and was neither endorsed by W3C for the single 2021
| snapshot it blessed as recommendation in the past, the post
| below is arguing HTML review draft 2023 and newer should in
| fact be getting a new major release version since it
| removed/de-emphasized and invalidate Ian Hickson's historic
| section elements/outlining which was a major HTML 5 era
| innovation (which, in turn, was the problem since browsers and
| screen readers ignored it).
|
| [1]: https://sgmljs.net/blog/blog2303.html
| jillesvangurp wrote:
| The point of walled garden is that they are very tempting to stay
| inside off for users. Their power comes from most users not
| resisting that temptation.
|
| Becoming the equivalent of a digital hermit and living in a hole
| in the ground outside these walls, which is what I would
| characterize this as, is not going to result on a lot of people
| stepping outside those walls. If you've ever watched Life of
| Brian, you'll have a good mental picture here.
|
| It's a variation of brutalist web development (let's not call it
| design) that just doesn't really appeal to the masses. It never
| has. The history of the web is endless attempts to pimp it with
| Applets, Flash, Shockwave, Silverlight, etc. The latest
| incarnation of that is web assembly. This basically allows you to
| use anything native that works elsewhere (desktop, mobile, game
| consoles, AR/VR, etc.) in a browser as well.
|
| Of course there's a severe risk of this to disappear into more
| walled gardens. But I don't think sitting in a dusty old hole in
| the middle of nowhere while shaking your fists at progress does
| much to change that.
| zelphirkalt wrote:
| Sometimes though, that dusty hole in the middle of nowhere
| seems to be the most progressive in terms of using standards,
| when the person sitting in it adopts new HTML elements,
| immediately having accessibility, while their JS-based rivals
| still struggle with restoring the functionality of the back
| button and adding routes in their SPA to get back something
| resembling normal linking behavior. In a way that is a much
| deeper dusty hole in the ground to dig for oneself.
|
| Anyway, it is questionable, how much progress there is in
| moving into walled gardens and throwing multi megabyte websites
| at visitors, when we can have the same functionality with less.
| beej71 wrote:
| I think there's a middle ground here where we're building good-
| looking web pages with a sub-10 MB weight. Unfortunately, it
| makes no business sense to do so.
| andai wrote:
| Sub 10MB? That's a whole YouTube video!
| giardini wrote:
| Author and posters both are equivocating: the term "semantic
| HTML" is the OP author's term and is not clearly defined. In
| contrast the "semantic web" IS well-defined.
|
| tl;dr - this article and discussion is a confused waste of time.
| robobro wrote:
| I only recently stumbled across <details> and I have to say, it's
| cool to have that available in vanilla HTML.
| gyudin wrote:
| In a world where pages takes x10 more time to load than to render
| some hyperrealistic scenes in AAA games on some Unreal Engine 5
| with 140 fps? Yup, I'm betting too on a front-end stacks that
| change every 6-12 months but only lead to more and more poorly
| optimized websites. Half of the times even mobile apps are
| useless, when they can't download a freaking JSON response in
| areas with poor network coverage.
| SoraNoTenshi wrote:
| Very surprising to me was that there is a semantic difference in
| <i> and <em> (the same is also the case with <b> and <strong>)
| apparently, also PDA readers for e.g., blind people are also
| aware of this semantic difference.
|
| What was also surprising is that there is a Slider as well as
| Color picker element.
|
| Fair enough i am not much of a web person myself, but i know that
| a lot of webpages have their own custom JavaScript implementation
| of those elements (if needed).
| zelphirkalt wrote:
| > Very surprising to me was that there is a semantic difference
| in <i> and <em> (the same is also the case with <b> and
| <strong>) apparently, also PDA readers for e.g., blind people
| are also aware of this semantic difference.
|
| It is in the names:
|
| <em> = emphasized, as in "this part of the text should be
| emphasized in whatever way the styling dictates
|
| <i> = italic, just a way to style directly
|
| <strong> = strongly emphasized
|
| <b> = bold, just a way to style directly
|
| <i> and <b> do not make a statement about semantics, they are
| for styling, and probably not much used in modern valid HTML,
| or at least should not, if you have CSS available. <em> and
| <strong> make statements about importance of a part of text, in
| whatever way you want to style that. It just happens, that the
| default styling for those is italic and bold.
| rapnie wrote:
| Ian 'Hixie' Hickson gave his view on the future of the web in
| January this year in a public Google doc titled "Towards a modern
| Web stack" [0]. On its HN submission (referencing the wrong URL,
| so I resubmitted [1]) he defends against criticism [2]
|
| Quoting from the doc here's the stack: -
| WebAssembly (also known as Wasm) provides a portable compilation
| target for programming languages beyond JavaScript; it is being
| actively extended with features such as WasmGC. - WebGPU
| provides an API (to JavaScript) that exposes a modern computation
| and rendering pipeline. - Accessible Rich Internet
| Applications (ARIA) provides an ontology for enabling
| accessibility of arbitrary content. - WebHID provides an
| API (to JavaScript) that exposes the underlying input devices on
| the device. This document proposes to enable
| browsers to render web pages that are served not as HTML files,
| but as Wasm files, skipping the need for HTML, JS, and CSS
| parsing in the rendering of the page, by having the WebGPU, ARIA,
| and WebHID APIs exposed directly to Wasm.
|
| [0]
| https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...
|
| [1] https://news.ycombinator.com/item?id=36968263
|
| [2] https://news.ycombinator.com/item?id=34612696
| troupo wrote:
| > On its HN submission (referencing the wrong URL) he defends
| against criticism [1]
|
| And it's a very weak defence. There are great rebuttals to
| whatever he writes in there.
|
| I mean, he rants that HTML failed, and then literally proposes
| "By providing low-level primitives instead, applications could
| ship with their own implementations of high-level concepts like
| layout, widgets, and gestures, enabling a much richer set of
| interactions and custom experiences with much less effort on
| the part of the developer."
|
| Has he tried to implement any of those from scratch using only
| low-level primitives? How is it "much less effort on the
| developer"?
|
| In general it just reads like a justification for Flutter:
|
| "This API alone is not useful for application developers, since
| it provides no high-level primitives. However, as with other
| platforms, powerful frameworks will be developed to target this
| set of APIs. A proof of concept already exists in Flutter"
|
| Why not provide high-level powerful primitives out of the box?
| Oh, then Flutter wouldn't have a reason to exist.
|
| ---
|
| As a side note: WebHID is a Chrome-only non-standard. They
| literally dumped a non-spec onto other browser vendors, shipped
| it to prod, and then "updated" the spec later:
| https://github.com/mozilla/standards-positions/issues/459
| mike_hearn wrote:
| So what are these great rebuttals? "Why not provide high-
| level powerful primitives out of the box?" <- the browser is
| a 30 year effort to do that and has always failed at it. This
| thread is full of people complaining that the browser
| implementations of even basic widgets aren't usable, of
| course any higher level or more complex features are often
| missing, and that's with web tech relying heavily on patrons
| that have budgets the size of the Sun.
|
| So in practice most devs bypasses them and write their own
| high level primitives anyway, relying on the browser only for
| low level APIs. That's the point the article is making. Hixie
| is merely observing that this situation exists, has always
| existed and probably always will, so browser makers may as
| well embrace it. And if you see the discussion thread, that's
| essentially what the Chrome WebUI PM says they plan to do:
| just talk to the authors of React and other frameworks, ask
| them what they need and do that i.e. give up on HTML tags
| like <section> and <progress>, refocus on obscure features
| that make framework devs happy. And then just tell web devs
| to adopt a high level framework that isn't HTML.
| troupo wrote:
| > So what are these great rebuttals?
|
| Those that you apparently read but didn't understand.
|
| > the browser is a 30 year effort to do that and has always
| failed at it
|
| And so the "we will not give you anything at all, implement
| everyting including all layouts, all widget all
| interoperability etc. from scratch" will work?
|
| > browser implementations of even basic widgets aren't
| usable
|
| Great article on the topic: "You can't capture the nuance
| of my form fields https://drewdevault.com/2021/06/27/You-
| cant-capture-the-nuan..."
|
| The problem with the basic widgets is not that they are
| incomplete, but that they are not enough. Almost any
| attempt to re-build even the built-in widgets sucks and
| fails in numerous ways. Now Hixie wants to remove _event
| that_ and pretend that building all that from scratch is
| "easier for developers".
|
| > that's essentially what the Chrome WebUI PM says they
| plan to do: just talk to the authors of React and other
| frameworks, ask them what they need and do that i.e. give
| up on HTML tags like <section> and <progress>
|
| Here's what that PM said, verbatim:
|
| --- start quote ---
|
| No one needed <section> and <aside> they needed <tabs> and
| <accordion>
|
| Developers mostly don't want the assembly language of the
| web, they want their chosen frameworks to have excellent DX
| and the UX they produce to be fantastic. When we see
| frameworks as a core customer/partner for web APIs, things
| turn out a lot better.
|
| --- end quote ---
|
| How you read this as "give up on HTML tags" and "refocus on
| obscure features" is beyond me.
|
| BTW, here's what Dan Abramov, on of the key developers of
| React, had to say a while back:
| https://dev.to/dan_abramov/comment/6kh1
|
| --- start quote ---
|
| React users would love to not have to npm install a date
| picker and bloat their bundles! If they need to "use the
| platform" then why doesn't that platform ship the features
| they actually ask for? Instead of a <carousel> they get an
| <aside>. Features like service workers are touted as a
| solution to many problems in the web, but their ergonomics
| are so under-designed that people actually have to change
| domains to bust the cache from a broken build (I'm not
| making this up).
|
| --- end quote
|
| But sure, "give up on HTML tags like <section> and
| <progress>, refocus on obscure features that make framework
| devs happy". Making the platform be only extreme primitives
| will definitely not make framework authors happy.
| mike_hearn wrote:
| To more fully quote the Chrome PM:
|
| _You didn 't solve the problems devs find challenging.
| Frameworks do. The existence of frameworks on the web is
| a feature, not a bug. Developers mostly don't want the
| assembly language of the web, they want their chosen
| frameworks to have excellent DX and the UX they produce
| to be fantastic.
|
| We're shipping container queries, scope, nesting, style
| queries, state queries and a host of other features devs
| tell us they need to architect component systems_
|
| In other words, the Chrome team (today) assumes the use
| of frameworks as a given and sees their job as empowering
| frameworks. Note that "devs" here clearly refers to
| framework authors, the sort of people who architect
| component systems. She doesn't mean app devs.
|
| So HTML as an all-inclusive app framework is going to
| die, arguably has already died, and the argument between
| Hixie and stubbornella is just an argument about what
| specific way to empower framework authors. Hixie argues
| that the focus should be on features for big frameworks
| that skip HTML entirely, stubbornella argues for features
| for smaller frameworks that still use some HTML, but
| they're both in agreement that raw HTML is just kind of
| useless and not the way devs want to go anymore. After
| all "state queries" is not <tabs> either. There's less
| between these positions that may seem.
|
| Now the real question is not could browsers theoretically
| ship really great HTML widgets. Sure, there's no rocket
| science in GUIs, in theory, browsers could do this. Yet
| after 30 years of immense effort they don't do so. That
| suggests some deeper structural issue. It might be team
| scalability issue. Chrome has a truly enormous team, but
| clearly they're struggling to do everything people might
| want from a browser. All that code has to be maintained
| after all, so as Chrome gets bigger we should expect them
| to slow down. Since the death of plugins the web is a
| completely monolithic platform. Given a choice between
| implementing some API that _only_ a browser developer can
| do (e.g. WebUSB) or implementing an API that devs can
| hack up their own alternative to (a widget), it 's clear
| why they always choose the former. Anything that browser
| makers can push off to web developers they clearly will,
| because there's so much to do that can't be pushed off in
| that way. Hence why HTML is still a poor UI toolkit and
| why JS frameworks are so widely used. It's a division of
| labor issue.
| rapnie wrote:
| Ah, that is enlightening, thank you. I knew he works for
| Flutter, but I know very little about Flutter and the
| standards it uses. That WebHID I hadn't heard of till this
| doc, so figures if this is a non-standard. More Google
| worrying power play then, similar to the web integrity bomb
| under the open web.
| zmmmmm wrote:
| Oh man, there's a <dialog> element?!
|
| There are probably occasions where that is the whole reason I
| pulled a JS framework in, since default alert boxes are horrible
| and anything better is a heap of work to do in a nice looking yet
| portable way.
| troupo wrote:
| > Oh man, there's a <dialog> element?!
|
| It only exist because browsers decided to remove
| alert/confirm/prompt. Before this it existed in a limbo plagued
| by so many issues that Chrome even suggested to remove the
| spec.
|
| None of the issues were fixed. But within a year from Chrome's
| botched attempt to remove alert it suddenly shipped in all
| browsers.
| sebastianconcpt wrote:
| It's about structuring text with a consensual function as every
| tag has an intention implied. Creating sites and webapps using
| this, results in a less contradictory foundation of the text and
| elements exposed in the UI.
| DigitalSea wrote:
| The real solution is Web Components.
| p-e-w wrote:
| 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 process input. ChatGPT (and its future offspring) can
| navigate regular websites the same way humans do. They don't need
| us to hold their hand. They know when a sequence of paragraphs
| constitutes a "list", without it having to be explicitly marked
| as such, etc.
|
| What the author appears to be describing is simply an API
| mediated through HTML semantic elements. But if you have an API,
| you don't need a Large Language Model for automatic data access -
| a good old Python script using Beautiful Soup will do just fine.
| And it has the added benefit that it runs entirely locally.
| bob1029 wrote:
| This seems reductive to me.
|
| There's "HTML" and then there's the kind of website where the
| final DOM isn't known until the user has already been
| attempting to read it for 10 seconds. There is a substantial
| difference in the % of browser capabilities that need to be
| exercised between the extremes of use.
|
| Complexity of implementation is what ultimately separates the
| good from the bad. Any tool can be operated skillfully or
| poorly. An apprentice with a circular saw and a fully charged
| battery can do a hell of a lot of damage. A master may elect to
| use no tool at all and simply bang on the side of the thing
| (I.e. push back on the business).
|
| The latest websites I have built are some of my most compatible
| ever. I don't use web sockets anymore. I don't depend on
| JavaScript to have piecemeal conversation with the server. You
| can actually use ~80% of the product with JavaScript entirely
| disabled. How are the engineering choices demonstrated here not
| exactly the solution for walled garden lock-in?
| feitingen wrote:
| Lots of websites already present a machine friendly site to
| google-bot and some other spiders.
|
| I don't see why they can't offer the same to other bots and
| only serve the Javascript-heavy pages to humans.
| flagrant_taco wrote:
| The idea of maintaining two entirely different versions of
| the same side gives me flashbacks to the days when they sir
| had a separate "m." codebase for mobile. There's a reason
| we found better solutions there, building and maintaining
| the same site twice is almost never worth it.
| oneeyedpigeon wrote:
| This is why you wouldn't build "two entirely different
| versions of the same site", you'd build one version and
| toggle the <script> tag on and off.
| flagrant_taco wrote:
| That may not work for a lot of sites that depend on
| client rendering and don't server-render the full page
| content
|
| Its really easy for this to break and go unnoticed for a
| while as well. You could run tests against the static
| version, but I wouldn't be surprised at all to see them
| "temporarily" disabled because a new feature needs to go
| live and something is the breaking in the static tests
| bob1029 wrote:
| > That may not work for a lot of sites that depend on
| client rendering
|
| Products that depend on client-side rendering don't
| deserve to have regression-free experiences. You are
| literally doing layout with _javascript_ and wondering
| why things get funny on edge case clients.
|
| The web is fucked until it becomes truly popular to build
| vanilla, SSR applications again. I feel like we are
| almost at the end of the tunnel of client-side hell, but
| perhaps some aggressive final pushes could help ship the
| narrative.
|
| The server is fast. Stop doing your layout on the client.
| Use media queries to address the wide range of viewport
| dimensions. You can have a responsive website,
| installable as a PWA on home screen of any mobile device
| and also as a 4k detailed desktop layout with _0 lines of
| JS required_. All you have to do is stop outsourcing your
| independence to framework vendors and pick up the MDN
| bible.
| sublinear wrote:
| This sounds regressive and the battle has been over for
| almost a decade now. Server-side rendering is silly and
| client-side rendering should not be used for the entire
| page. Even for complex web apps, the majority of the HTML
| is static.
|
| The best web experiences are static HTML with client-side
| rendering only used for the dynamic sections of the page.
| It's not even a choice to do it any other way anymore if
| you care about a11y and SEO.
| bob1029 wrote:
| > This sounds regressive and the battle has been over for
| almost a decade now
|
| This sounds like what google would like for everyone on
| HN to believe.
|
| Using "a11y" and "SEO" to push bad technology
| abstractions is tantamount to petty bullying in my view.
|
| Genuinely, I don't understand the position that SSR
| somehow makes accessibility _worse_. Can you walk me
| through how adding _more javascript on top_ somehow
| solves the problem of making a website compatible with a
| screen reader?
| sublinear wrote:
| > Can you walk me through how adding more javascript on
| top somehow solves the problem of making a website
| compatible with a screen reader?
|
| I didn't say to add javascript to make the page more
| accessible. I said that a _static HTML page_ is most
| accessible and should be strongly preferred over any
| dynamic content regardless of how it 's rendered. Screen
| readers can misannounce dynamic elements and leave the
| user confused about the state of the page.
|
| But when dynamic elements do need to be reannounced due
| to an event, refreshing the page would be a terrible
| experience since the screen reader loses focus and starts
| back from the top of the page. Aria alerts also require
| javascript. It makes perfect sense that if you're pushing
| out an aria alert with js already that all that rendering
| logic should also go on the client side.
|
| https://developer.mozilla.org/en-
| US/docs/Web/Accessibility/A...
|
| As for SEO, I'm specifically talking about good metadata
| in the head tag, a static page that's comprehensible, and
| a sitemap. Static pages are better than SSR for this
| because SSR doesn't always respond with the same page for
| the same URL.
| sodapopcan wrote:
| > It's not even a choice to do it any other way anymore
| if you care about a11y and SEO.
|
| Can you explain this?
| oneeyedpigeon wrote:
| Sure; I guess it depends if we're talking about a web
| _site_ or a web _app_.
| _jal wrote:
| I don't see why they can't offer the same to humans, at
| least as an option.
|
| There are a few sites I impersonate Googlebot to, they're
| much more usable that way.
| MrDresden wrote:
| The point is that a lot can be done without the need for
| Javascript. Also in pages served to humans.
| mmahemoff wrote:
| Valid point. Ironically the main benefit of semantic markup is
| now an abstraction to help the human developers effect styling
| and control.
| jraph wrote:
| Isn't the main benefit of semantic markup still
| accessibility?
| mmahemoff wrote:
| That's one of the main benefits, but if the machine can
| make sense of the content, it can still present it however
| is clearest for the user.
| oneeyedpigeon wrote:
| But explicit, human-verified metadata is always going to
| beat inferred, fuzzily-extracted data, surely?
| wruza wrote:
| _ChatGPT (and its future offspring) can navigate regular
| websites the same way humans do_
|
| It seems to be at least a not-yet-true claim, but let's ignore
| that for now. It's interesting if LLMs actually could do this.
| As I understand it, LLMs are trained on texts and source code
| among other things. But lacking... let's name it a reasoning
| apparatus, can they really look at a DOM tree and tell what it
| is/does? It's not a text, and barely can be a well-structured
| source code that was ever discussed (it's a result of either
| bundling or componentization). This is almost on par with "LLMs
| will look at any .exe and be able to integrate with it
| immediately".
| delusional wrote:
| > "LLMs will look at any .exe and be able to integrate with
| it immediately".
|
| The LLM will look at any .exe and determine if it halts.
| chromoblob wrote:
| .exe's (for the usual architectures) run on finite-state
| machines, not Turing machines. So, indeed, that is
| possible.
|
| If the .exe connects to a service that runs on something
| more powerful than finite-state machine, though, I don't
| know.
| kaba0 wrote:
| That's still a stupid pedantry, and is even false.
|
| A Turing machine only makes use of at most n cells of its
| tape after n steps - so running it for a finite number of
| steps is possible even in finite memory. Especially that
| modern computers can do arbitrary side effects, having
| access to the whole universe as tape, which is still
| finite, but so is time.
|
| There is no way to differentiate between a magical Turing
| machine with infinite tape and a "fake" one that has
| n-sized memory under any program that takes n steps, so
| for all practical purposes they are identical.
| chromoblob wrote:
| Why are they identical? A program may use more steps than
| memory.
| kaba0 wrote:
| A Turing machine can either go left or right on its tape
| (some versions have a stay step as well, doesn't matter).
| If all your program does is step right forever, than it
| will use the maximum amount of memory, but only ever a
| finite amount, that is equal to the number of steps
| taken.
|
| So if you don't have infinite time (you don't have), and
| you have big enough memory for the particular use case so
| that you don't get OOMKiller involved, then you have a
| Turing machine for all complexity theoretical and
| practical purposes, especially that RAM is _not_
| analogous to the Turing machine tape - your computer has
| much more state than only its memory, if it has network
| access, you can basically make use of a cloud vendors
| whole army of servers as storage, just as an example.
| [deleted]
| chromoblob wrote:
| The reason for undecidability of halting is that a
| program's state may grow without bound. If a program's
| memory usage is bounded, its halting can be determined.
| So the computer is not like a Turing machine since its
| programs don't use Turing machine's key feature -
| infinite tape.
|
| Although the naive way of deciding halting requires
| exponential time in program's memory bound, AGIs will
| speed that up for many programs by using clever math.
| KronisLV wrote:
| > The LLM will look at any .exe and determine if it halts.
|
| At that point you'd need an AGI that can figure out
| something we can't.
|
| Edit: but yeah, sarcasm. Nowadays I can't even tell
| sometimes.
| wruza wrote:
| I believe it was a positive sarcasm in gp.
| kaba0 wrote:
| I am 100% sure that parent poster was being sarcastic at
| the hype around LLMs and how many think they can solve
| everything, even if said thing is impossible to do, e.g.
| the halting problem.
|
| Do note that the halting problem is fundamentally true,
| no AGI will realize some new way around, unless are
| mathematics are flawed to the core.
| thanatropism wrote:
| I remember the hype around XGBoost and Kaggle contests
| asking to solve problems in prime number theory.
| treprinum wrote:
| Halting problem is one of the problems that arise from
| precise mathematical definition and its outskirts. LLMs
| are all about making sense from unstructured text, i.e.
| lying on the opposite end of the spectrum where math has
| no direct way to do anything. So while the poster was
| sarcastic, they also missed the mark.
| kaba0 wrote:
| The halting theory is analogous to Godel's incompleteness
| theorems and these are fundamental truths to _any_
| system. That matrix multiplication that deep learning
| does is hardly immune to that.
| treprinum wrote:
| They are fundamental truths to systems based on certain
| assumptions we are taking for granted, e.g. binary logic
| (and not e.g. quantum logic), Turing-like computing model
| etc. Not that deep learning has anything to do with
| those, but it excels in human-like properties where
| simple formula-derived math descriptions fail all the
| time.
| kaba0 wrote:
| Is a NN a computable function? Yes, as we calculate them
| on Turing machines. Then it is prone to every limitation
| of computable functions.
|
| Humans are also limited by the Turing model's limits, we
| can only ever determine computable functions as well.
| With all due respect, it is stupid to assign more
| capabilities to ML than what we know is fundamentally the
| limit..
| treprinum wrote:
| While that's true, halting problem is completely useless
| in the real world (nobody designs user-facing apps while
| thinking about whether the program halts), whereas
| picking data from speech is a much more useful one that
| was long unreachable for "clean" closed-formula math.
| kaba0 wrote:
| Ok, and it is completely irrelevant. Besides, guess what
| enables the training of those neural networks? I'm fairly
| sure gradient descent has a bit to do with mathematics'
| closed-formulas.
|
| Of course ML has use cases where traditional tools are
| less fit, my gripe is the hype-based anti intellectual
| nonsense that often surrounds it. They are no magic
| tools, the fundamental limits these giants of math/CS
| discovered still apply to them and we can save ourselves
| from a lot of pain if we don't bother solving unsolvable
| problems.
| treprinum wrote:
| Yeah, hype is driven by business and marketing who want
| to sell more of a new thing pointing out what was not
| possible before using all kinds of silly arguments.
| Still, there is some noticeable progress there (compared
| to e.g. crypto that outside logistics and large-scale
| fraud didn't bring much despite being based on super
| solid number theory concepts).
| thanatropism wrote:
| What. There are no proofs of convergence for many of the
| most popular NN optimization algos. IIRC Adam is known
| not to converge in some cases.
|
| The bitter lesson is that Messy AI is better able to cope
| with Messy World Problems than Neat AI (by light-years at
| this point), not that it can hack Neat Problems.
| mythhabit wrote:
| 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 probably never practically solve the halting
| for LBAs, but the quest for this AGI that should be able
| to solve this, is not just day dreaming, it's rooted in
| the theory.
| odyssey7 wrote:
| 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 :: Integer ->
| Integer hailstone n | n `mod` 2 == 0 = n
| `div` 2 | otherwise = 3 * n + 1
| collatz :: Integer -> Bool collatz n |
| hailstone n == 1 = True | otherwise =
| collatz (hailstone n)
|
| Edit: however, you would need enough disk space to store
| the cycle-detection index.
| kaba0 wrote:
| 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?
| odyssey7 wrote:
| I guess I was thinking about indexing the visited numbers
| from a graph-traversal-algorithm-interview perspective
| instead of a CS theory one.
|
| We can actually do it in O(1) space complexity in
| exchange for higher time complexity.
|
| For i in range 1..n, compute n_i, the ith number in the
| hailstone iteration, and then continue the hailstone
| iteration n_(i+1)..n_max to see if n_i is equal to any of
| them. This takes us to quadratic time complexity, O(n *
| n_max), or constant complexity depending on how you look
| at it, but it only requires storing a single n_i at a
| time for cycle detection.
|
| But then again, if you actually loop for n_max iterations
| without halting by reaching 1 or crashing, then you had
| to reuse a number somewhere, so the explicit cycle
| detection isn't really important.
| kaba0 wrote:
| I have to admit my knowledge of complexity theory doesn't
| extend too far, but isn't the solution to LBAs just..
| brute forcing? Also, is it even decidable a priori
| whether a program is LBA vs requiring a tape that is not
| only linear function of its input?
| vidarh wrote:
| The worst case solution is just brute forcing, yes.
|
| An LBA is effectively "just" a Turing machine that has a
| finite tape.
|
| A typical current computer is an LBA _only if you
| disallow all IO of any sort or bound that IO and include
| it as part of the system you analyse_ and so fix the
| values which will be provided as IO, which of course is a
| very unusual situation, and so that constraint does not
| really make the halting problem more tractable in
| situations we usually care about.
| vidarh wrote:
| A machine we have to today _in isolation with no form of
| IO_ are not general Turing machines, but almost all of
| them _do_ have that and so if you consider them in
| isolation rather than the full system (which would
| include all sources of inputs) the halting problem
| applies. E.g. code to the effect of "while gets() {}"
| will either halt or not halt depending on the input, but
| which isn't decidable without knowing or constraining
| that input.
|
| We can certainly look for AGI that can do _better_ at
| deciding the halting of _decidable_ programs, but even
| for current computers the general halting problem is
| undecidable without adding artificial constraints.
| kybernetikos wrote:
| The halting problem is absolutely solvable in some cases,
| it's just the general case in which it is unsolvable. If
| LLMs were able to decode web pages and executables in a
| high proportion of the interesting cases, that would
| already be extremely useful. Humans can't do this in the
| general case either, but we still hire them to do jobs
| like this.
| kaba0 wrote:
| > If LLMs were able to decode web pages and executables
| in a high proportion of the interesting cases
|
| Why would it be extremely useful?
| reichstein wrote:
| I think KronisLV's point, presented ironically, is that
| not even an AI superior to human reasoning, which can
| figure out things we cannot, can decide the undecidable.
|
| Being undecidable is a hard limit, not something that
| requires better algorithms. Another phrasing of it could
| be: No finite program can decide it. (And what even is an
| infinite program? Not something we can run on any current
| computer.)
|
| If an AI is itself a finite-sized program, something we
| run on computers, it cannot possibly solve the halting
| problem.
|
| And _any_ non-trivial property of programs is
| undecidable, so an AI "integrating with any .exe file"
| isn't really meaningful. It's just words.
| vidarh wrote:
| > Another phrasing of it could be: No finite program can
| decide it. (And what even is an infinite program? Not
| something we can run on any current computer.)
|
| The complexity of the program trying to decide is not
| really the issue. An "infinite program" could add an
| infinite number of extra rules to try to cut down on the
| time taken to determine if a decidable program halts, but
| the issue with the halting problem is that there is an
| infinite set of _undecidable_ programs where the size of
| your detector will make no difference to your ability to
| decide them.
|
| E.g. "while next_symbol() == some_arbitrary_symbol {}" is
| undecidable unless you add constraints on the length or
| contents of the input.
|
| Even if you haven infinite-sized program you can't decide
| whether or not the unconstrained version of that halts,
| because deciding it is equivalent to being able to
| determine if an infinite tape contains a given symbol,
| and no matter how long you scan the tape the symbol can
| always be the next one on the tape after the last symbol
| you scan.
|
| > And _any_ non-trivial property of programs is
| undecidable
|
| I don't think I agree with this without adding the
| qualifier "in general". There are a whole lot of useful
| properties we can decide, but often the properties will
| have constraints. E.g. for a whole lot of programs where
| we can't decide whether or not they will halt, we _can_
| still decide whether or not they will halt _assuming
| certain properties of their inputs_. E.g. we _can_ decide
| the property of my pseudo-code above that it _will halt_
| _IF_ "some_arbitrary_symbol" is in the input. We can also
| decide the property that whether or not it will halt _in
| general_ is undecidable, and that is itself useful to
| know, because for many programs knowing what makes them
| undecidable is useful in order to suggest e.g. adding
| timeouts, or ensuring there are ways to bail early from
| certain actions without restarting the machine or killing
| the program.
|
| For a whole lot of problems we also do not really care
| whether or not a given property is decidable. We care
| whether they're decidable _often enough_ within certain
| time constraints, and that 's a very different ballgame.
| wruza wrote:
| It has meaning. By looking at a table in e.g. getopt()
| call and an output of --help I can often infer modes of a
| program that I probably need, to do my job when someone
| asks me to. Whether this getopt() gets called or if a
| program does what it claims in usage() is not my concern.
| I was commanded to guess the usage and I do it without
| burying into the halting problem. And so does that
| hypothetical AI.
|
| Decidable or undecidable is about maths, not practice.
| abwizz wrote:
| i suspect this is because they can divide by zero
| kevinstubbs wrote:
| > can they really look at a DOM tree and tell what it is/does
|
| Yes, if you encode the DOM as a list of options for ChatGPT
| to choose from. In fact I developed a proof of concept of
| this for a client. https://jarvys.ai/ although they seem to
| have pivoted from automating just the browser to automating
| all software.
| rezonant wrote:
| Well if the DOM is all unstructured divs with no semantic
| information, can a human even tell what it means without
| applying the structural styling on the page?
|
| A good example would be a misguided approach at making a
| bunch of labels with values that are aligned. Someone told
| this poor developer that <table> is bad, so they figure
| hey, let's use CSS to lay it out. They make a dictionary of
| the key/value pairs and iterate over all the keys in the
| first column into the first div and then output all the
| values in the second div.
|
| div - label 1 - label 2
|
| div - value 1 - value 2
|
| If there's 100 key/values it's going to be hard for a human
| to figure out which value is for the 76th item, and LLMs
| have proven to be very bad at indexing problems like that
| so I wouldn't expect it to be a better story there.
|
| (Not saying this wouldn't work in some cases, just couldn't
| be a general solution given the crap out there)
| wruza wrote:
| _if you encode the DOM as a list of options for ChatGPT to
| choose from_
|
| Not sure if I understand this, does it mean you have to
| pre-cook DOM in a specific way? If yes, then isn't the
| answer to my question "no", like "no, it can't take any
| site and use it as is"?
| kevinstubbs wrote:
| You have to give GPT an objective, like "find an
| apartment in Florida" and then say something like "given
| the following options, which one would you interact with
| to get closer to your objective."
|
| So if you assume that you start on google.com, then your
| options are like 1.) Input with name "search",
| placeholder "search anything", value "" 2.) Button with
| label "I'm feeling lucky" 3.) Button with label "search"
|
| Obviously, doing just one of these doesn't achieve the
| objective - it just needs to pick which one it thinks has
| the most "value" for completing the objective. If you
| repeat that enough times, then it can actually do what
| your overall goal of the session was.
|
| I'm just giving a simplistic answer, and if you
| implemented only what I've written, then it's going to
| get stuck in a loop more often than not. But that's the
| gist of how you could encode the DOM into something that
| GPT can interpret and make decisions/take actions based
| on.
| wruza wrote:
| Got it, thanks!
| TeMPOraL wrote:
| Remember HATEOAS? I have a feeling LLMs would excel at
| navigating proper REST (not "RESTful") APIs - HATEOAS is,
| in principle, just what you did here: providing a list of
| possible/useful next steps along with the response.
|
| In fact, the problem of HATEOAS is exactly what LLMs seem
| to be good at - _inferring_ the interface at runtime,
| from dynamically received metadata. This should even be
| easy to try in practice today - HATEOAS can be trivially
| mapped to the "function calling" feature of OpenAI's
| GPT-3.5/GPT-4 APIs.
| datagram wrote:
| There's already companies working on this: https://axiom.ai/
|
| I would guess that it's just a matter of converting the DOM
| accessibility tree into text descriptions, e.g. "There is a
| button that says 'Start'" And then converting text like
| "Click the Start button" back into an actual action on the
| page.
| tyingq wrote:
| _" ChatGPT (and its future offspring) can navigate regular
| websites the same way humans do"_
|
| I don't know how much deeper it goes, but it does have some
| context: Prompt: Given this html, what does
| an end user see? <div
| style="display:none">hello</div><div>you</div>
| ChatGPT: An end user would see only the text "you" on
| the webpage. The first <div> element has the
| inline style display:none, which means it is set to be
| hidden, and its content "hello" will not be visible to the
| user. On the other hand, the second <div> element has no
| specific display style, so it will be visible, and its
| content "you" will be displayed on the webpage.
| 3cats-in-a-coat wrote:
| LLM would find it easier to browse through a browser. Like
| us. Implying image model linked.
| abwizz wrote:
| > They know when a sequence of paragraphs constitutes a "list",
| without it having to be explicitly marked as such, etc.
|
| that's the thing; they don't know - they guess
| circuit10 wrote:
| Humans do the same, it's usually obvious from the context
| fauigerzigerk wrote:
| AI in general could "see" a website like we see it. But LLMs
| specialise in text. They will find it much easier to figure out
| the correct semantic interpretation of tag soup than deriving
| the same information from the rendered output like we do.
|
| Also, the big question is cost. I think semi structured text
| will forever be far cheaper for an AI to process than a
| completely unstructured data stream representing visual
| information.
| theteapot wrote:
| > 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?
| andai wrote:
| 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).
| jack_pp wrote:
| In its current form, not as far as I know. Even the OpenAI
| tutorial on this matter scrapes first and uses only normal
| text.
|
| https://github.com/openai/openai-
| cookbook/blob/main/apps/web...
| kennyloginz wrote:
| You don't need a good old Python script using Beautiful soup,
| you can use an LLM with the added benefit of not dealing with
| that cruft.
| selfhoster11 wrote:
| An LLM is much slower and requires more resources at runtime
| than Beautiful Soup (if you are hosting yourself), and could
| fail to retrieve data. It's a worse solution unless your HTML
| parser/scraper is broken by website changes.
|
| This is only the case for now, however. I expect this to
| change in favour of LLMs as time goes on and they become
| easier to deploy and better at their job.
| rezonant wrote:
| I got the sense that the article was advocating for using good
| semantic machine readable content over HTTP instead of (or at
| least in addition to) JS-only div soup so that automated agents
| like the new wave of LLMs can easily pull out the important
| details without spinning up a headless browser and rendering
| the page first.
|
| I have the same interest but for the purpose of crawling and
| upstart search engines. If indexing every page required running
| the page in a headless browser first, the barrier to entry for
| new search engines is a lot higher.
| yellowapple wrote:
| > And the whole point of artificial intelligence systems is
| that they don't require specialized "machine-readable"
| annotations in order to process input.
|
| I don't _require_ a cup to hold my drink. That doesn 't make
| cups useless or undesirable.
|
| Point being: if a machine can make sense of the veritable
| clusterfuck that is the "pile of infinitely-nested divs" status
| quo, then surely it'd have a much easier time making sense of
| pages that actually use HTML properly. If you're an AI trying
| to figure out how far along something is, which is gonna be a
| more obvious indicator? <div
| id="reactElement420" class="wangularClass69"><div
| class="25-long red" visibility="hidden"/><div class="50-long
| yellow" visibility="hidden"/><div class="75-long green"/></div>
| <progress max="100" value="69">69%</progress>
|
| The first example is hyperbolic, sure, but only slightly.
| DrStartup wrote:
| I think SEO is dead and the Semantic web will soon take over as
| search transitions to LLMS. If your data is better digested with
| minimal work by the LLM trainers, does your content perform
| better?
|
| And maybe search isn't the killer feature of the semantic web,
| maybe it will be agents?
| delta_p_delta_x wrote:
| Hey OP, I notice you're using Berkeley Mono, which is beautiful.
| But your website's CSS appears to be applying boldface on an
| already boldface font in the headers (despite the typeface name
| claiming to be 'Regular', it is actually bold; see the
| datasheet[1]), which is causing bad hinting. Consider changing
| your typeface file!
|
| [1]:
| https://cdn.berkeleygraphics.com/static/typefaces/berkeley-m...
| irrational wrote:
| Thank you! I was wondering why the font looked so wonky. It
| looks much better now.
| catskull wrote:
| Thank you, I believe I have fixed it. TIL variable fonts on web
| are not great! AFAIK they don't distribute the
| regular/bold/italic/bold italic 4 font mix?
| bingemaker wrote:
| I've been using `dialog` and `details` of late, and couldn't be
| happier. At the same time, `section`, `article`, `header` and
| `footer` confuse me a lot. I've stopped using them.
| flagrant_taco wrote:
| Section and article really don't add any value, but header and
| footer elements are used as landmarks by adjustive technologies
| like screen readers
| troupo wrote:
| > Section and article really don't add any value
|
| They are nice hints to assistive technologies and reader
| mode.
| flagrant_taco wrote:
| Yep that's totally fair!
|
| I'm not 100% sure if assistive technologies use section and
| article for any end user context like "jump to content",
| but they at least can be used to get more context than just
| another div
|
| Reader mode is one I don't think about enough. I could see
| that purposely hiding content outside of the article
| element.
| troupo wrote:
| Yeah, Reader mode is weird. I know it prioritises
| semantic tags like article, but since the behaviours are
| not standardised, I never know what will and will not
| work.
| sourcecodeplz wrote:
| What's wrong with <iframe>? I find it quite useful.
| pbohun wrote:
| I didn't realize some of these elements existed. Neat! However, I
| think if we want an open/federated system to win, we need to make
| it compelling to normal people. That means making it fun and
| entertaining. I've found that no argument about freedom, privacy,
| or anything actually important will work.
| jackvalentine wrote:
| Might seem elitist but we've seen what 'normal people' looks
| like on the internet and perhaps we do want places where there
| is a barrier to entry.
| willio58 wrote:
| <datalist> is so close to being perfect but I know the people I
| work for would want it to show the full list always and just
| float the selected value or closest spelled value to the top.
| Right now if you select a value on chrome and then click the list
| again it just shows that one value until you delete your entry.
| YLYvYkHeB2NRNT wrote:
| the AI disclaimer put me off from reading it. I want to hear your
| words, not ChatGPT
| azangru wrote:
| > With the advent of large language model-based artificial
| intelligence, semantic HTML is more important now than ever.
|
| It's odd: I remember seeing an argument recently, though can't
| remember where exactly (perhaps [0]?), that LLMs make semantic
| HTML obsolete, because they "understand" the text anyway.
|
| After all, humans didn't need html to be semantic in order to be
| able to read it -- machines did. And if machines are approaching
| humans' capability to read texts, then doesn't this put the whole
| semantic html exercise into question?
|
| 0 - https://shkspr.mobi/blog/2023/05/does-ai-mean-we-dont-
| need-t...
| fauigerzigerk wrote:
| Humans interpret text as rendered by the browser. That includes
| a lot of visual information and even text that only becomes
| visible in response to user interaction.
|
| For an LLM (or an AI in general) to do what humans do, it would
| have to process the rendered output and interact with the site
| like we do (such as clicking on a dropdown to make the
| available options visible).
|
| The same information represented as semantic HTML (i.e text) is
| far cheaper to process for an AI. I think cost is a key
| consideration in everything AI. If it's too expensive then it
| won't happen, even if it could theoretically be done.
| ivolimmen wrote:
| This reminds me that I really need to re-evaluate the stuff I
| already know and keep it all updated.
| leetrout wrote:
| I am lost in CSS these days since letting my skills atrophy
| over the past ~decade
| nathansherburn wrote:
| You'll be fine. If anything CSS is the one thing that's
| gotten easier in web dev. It might take some time but you'll
| be able to grok it for sure if you've dealt with old school
| CSS.
| pcthrowaway wrote:
| ehh... more organized / better? Sure.
|
| Easier? Well, even if you don't have to deal with legacy
| styling (which had moments of insanity, like floats, and
| other things which were fairly reasonable, like tables, br,
| b, i), there is _so_ much new CSS to replace the old:
| variables, transforms, complex animations, using borders to
| make arrows and other visual content, in flow vs out of
| flow, container queries, view transitions api, px, pt, em,
| rem, vh, vw, query units, initial vs inherit, vs unset vs
| revert, new color formats, a million new properties for the
| complexity of interactivity with the gamut of user agent
| form factors
|
| You know what? I'm going to stop because the list goes on
| and I don't even think I touched on 1% of the "new" CSS
|
| These days I mostly just use tailwind. It gives me a sane,
| easy to work with api, and the updates are a more
| manageable trickle than a deluge
| klabb3 wrote:
| CSS is huge. I wish there was a way to shed all that dead
| skin. Only 5% of it is truly powerful. Most of it is
| never used.
| manuelmoreale wrote:
| And yet, those rare times you need something you're happy
| to know the feature is there.
|
| There's no point in removing stuff from CSS. The only
| thing that would do is break old websites.
|
| If only 5% is truly powerful you can easily and happily
| use only that 5%
| Closi wrote:
| By easier they probably mean "it's easier to do the same
| thing" - eg centering a div.
|
| It's also become deeper at the same time though - so it
| might be easier to do the same thing and harder to know
| it all.
| barrenko wrote:
| Kinda beautiful. More resources that focus solo on "modern" HTML
| + CSS?
| chickenfeed wrote:
| 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.
| mmsimanga wrote:
| You hit the nail on the head when you mentioned WhatsApp. In my
| country in Africa WhatsApp is so popular so much so that mobile
| network providers even sell WhatsApp data bundles. If I want to
| find something, like wire fencing I start by asking WhatsApp
| groups I am in. Family, neighborhood and even high school
| friends. Typically I get a few numbers and then I WhatsApp the
| service provider and I get up to date information. The service
| providers can't afford up to date web sites. WhatsApp also has
| a feature to include a catalogue in your profile. This is for
| business accounts which are also free.
| taylodl wrote:
| That's why I suggest for most small business to use Wix. Does
| your site tend to look like everybody else's? Yes - and that's
| not necessarily a bad thing, and since it's so easy-to-use and
| update, customers will appreciate having the up-to-date
| information they need.
|
| What I'd like to see (maybe it exists, I haven't looked in a
| while) is something I would market as "Wix Widgets." These
| would be data-connected widgets where there's some
| customization to wire-in a REST service call and map the data
| points to the widget display. This would go a long way to
| handling the needs for internal-facing web sites every company
| has these days.
|
| We really need simple solutions for the 90%-95% of web pages
| out there.
| [deleted]
| OOPMan wrote:
| I spent some time recently working on a C++ application for
| Windows using Qt for the UI and general application framework.
|
| I was surprised at how easy it is to achieve useful things with
| C++ and Qt in this day and age.
|
| When I used it back in the early 2000s it was a lot more
| painful but both C++ and Qt have come a looking way.
|
| Honestly, to paraphrase Hayao Miyazaki...the web was a mistake.
|
| It's almost a classic example of worse is better.
| ethbr0 wrote:
| > _And those wanting to consume data, really just want the bare
| essentials: The data._
|
| I don't think they do. The average HN reader, probably; but not
| the average person.
|
| What they want is a _well_ styled and _usable_ webpage.
| Unfortunately, there aren 't enough effective and talented UX
| designers (or stakeholders at companies with decent UX
| intuition).
|
| This leads to the current situation where the average person
| would be _better_ served by bare essential data, even if it 's
| not their preference, because it's still better than the kludgy
| UX _average_ design a company is able to afford.
|
| {bad UX} << {raw data} < {good UX}
|
| The end run around this is what WordPress realized: create
| professional styles/themes and allow users to purchase and
| apply them. But that can't solve bad stakeholder taste.
|
| Which brings me back to Facebook, which I would argue succeeded
| _because_ it standardized and mandated a professional UX.
|
| {data from people} + {professional, standardized UX} =
| {winning}
|
| You can dislike the original Facebook UX, but I don't think
| anyone would claim it was amateur level work. Which is what
| everyone's perception of MySpace/Geocities et al. was.
| Technotroll wrote:
| Part of this is the ever increasing amount of tags and elements
| in HTML files. Instead of being a document markup, it's a page
| markup, and it's difficult to discern where one stops and the
| other begins, although the W3C has tried with the addition of
| article and section elements. But then I suppose the raw HTML
| code was never meant to be read by other than devs in the first
| place, so there's that.
| chickenfeed wrote:
| There was that small window of niceness, where the html
| diminished in size. Now it's just all pseudo inline styles
| painted by class names with lashings of scripts. Always
| surprised when you peek under pretty much a bereft page of
| nothing and it's a whole heap of code.
|
| I'm one of those annoying people that just uses reader mode
| anyway - not that it always works. Because I get fed up of
| zooming in and out, inflating text size etc etc.
| jklinger410 wrote:
| It's funny how I hear that web platforms are the best and most
| consistent cross-platform GUI systems, but then building on
| that system is awful.
|
| So I'm wondering if maybe this is just the nature of GUI. Where
| you have to give every single instruction, eat up a bunch of
| cycles, or it simply won't function as cross-platform.
| oneeyedpigeon wrote:
| I don't think it's _that_ funny, given that "best" and "most
| consistent" are both highly subjective.
|
| I am a huge fan of the HTML/CSS/JS stack--it's far, far
| easier to knock up simple GUI-based apps using those
| technologies than, for example, the Visual Basic / Delphi
| tools that we were all using beforehand. And, remember, apps
| are not _really_ what HTML was ever intended for, so _any_
| kind of 'app' support is a big bonus.
| zdimension wrote:
| Funny, I grew up making GUI apps on VB (and then VB.NET)
| using Windows Forms and I've always found it really easy
| compared to the web stack. You're not fighting against a
| flow algorithm that was designed for documents, trying to
| position your widgets in ways NCSA Mosaic wouldn't ever had
| dreamt of, it just works.
| jrm4 wrote:
| I do, and I teach it. It's a lot of ridiculous garbage.
|
| I think an _aggressive defense_ of e.g. what "reader mode"
| does is incredibly important, to the point that I'd support
| e.g. legislation.
| bobajeff wrote:
| This is why I want a browser where I can use Reader Mode on
| everything. Not just articles and blogs but also forums, q&a
| sites, online stores, image galleries, video sites.
|
| Because of this I don't bet on the web because it's really
| designed to be an app framework now (admittedly the best one)
| not for being a simple client that sends and receives data
| (like XMPP, SIP, IRC, SMTP, IMAP and NNTP).
| tambourine_man wrote:
| _Or the updates are just technically too difficult for people
| to grok._
|
| Or because they forget to. And almost no one visit their site
| anyway.
|
| Unfortunately, Facebook and Instagram took that place. Where is
| it, phone number, what time is it open, some pretty pictures.
| Done.
| vermilingua wrote:
| Amusingly, the MDN guidance [0] on <em> vs <i> is exactly
| backwards from the example they give a paragraph below:
|
| > The <em> element represents stress emphasis of its contents,
| while the <i> 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]: <p> In HTML 5, what was
| previously called <em>block-level</em> content is now
| called <em>flow</em> content. </p>
|
| ...which would be an exemplar case of when to use <i>.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/em...
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/em...
| andai wrote:
| I thought <em> was semantic ("emphasis") and <i> is stylistic
| ("italics")? And last I heard (when <em> came out) you weren't
| supposed to use <i> anymore because it's bad form to use HTML
| for styling! Much like <center>.
| Timwi wrote:
| Yes, that was the mantra some 15-20 years ago. Then HTML 5
| came out, in which <center> was indeed obsoleted, but
| <i>/<b>/<u> weren't and instead got a semantic meaning. (A
| semantic meaning which, admittedly, is subtle, borderline
| esoteric, so it's very rarely used as intended.)
| psychoslave wrote:
| Made me read https://www.w3.org/International/questions/qa-
| b-and-i-tags
|
| I think that at this point I can keep my usual habit of
| avoiding them completely.
| beders wrote:
| Where's the modern equivalent of xforms?
|
| It is very telling that you still can't build more sophisticated
| forms declaratively in HTML/CSS.
|
| After decades everyone seems to be cranking out their own custom
| made forms with various levels of JavaScript added.
| qwerty456127 wrote:
| 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 pages on a social network),
| RSS/ATOM (which is replaced with in-app notifications), e-mail
| (which is replaced with in-app direct messages), Usenet (which is
| replaced with in-app groups) etc. Everyone theoretically could
| just have a personal www page on their own domain instead of a
| social network account.
|
| Oh, and HTML never needed CSS to be not ugly - that's the browser
| default settings which make unstyled (styled with default styles)
| HTML pages look this way. We always could just change the default
| fonts/colors or apply a userstyle for more complex things.
|
| Once general population joined to the Internet (where in the past
| there were only nerds) the demand emerged for it to become much
| easier and prettier and the corporations responded offering the
| features pople want taking their freedom, privacy and
| independence in exchange (which an average person doesn't mind,
| all they ace about is that being "for free"). We could just build
| better apps (browsers with sensible defaults, intuitive e-mail
| and Usenet clients and web servers), but we still lack them
| because nobody wants do serious work for free and make great
| products which would suit everybody ather than themselves.
| sourcecodeplz wrote:
| 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.
| qwerty456127 wrote:
| > CSS is so useful it is almost ridiculous to say HTML never
| needed it
|
| I didn't mean CSS is useless, I meant it is not necessary for
| every website to define their own CSS to look nice and not
| ugly. The problem is almost no ordinary user knows they can
| define their own defaults (fonts, background - in browser
| settings, more complex - in user CSS).
| mxuribe wrote:
| Long, long ago, when i first learned that i could define my
| own (css) defaults on my browser, my mind was blown! I
| can't recall if it was back in netscape navigator or early
| fireforx days...but learning the command path from the menu
| to "turn off css styles" (View -> Page Style -> No style)
| made me feel like some sort of superpowered being! lol :-D
| More seriously, it actually helped me better understand the
| web, html, web pages as documents "downloaded" by the
| browser, etc. I became a much better web dev for it -
| beyond feeling like i had more freedom due to
| software/app.!
| nologic01 wrote:
| 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.
| btbuildem wrote:
| What is the author suggesting? That instead of "social" networks,
| people will rush to building their own online presence from first
| principles?
|
| I can't see that working, for so many reasons:
|
| - most people are passive consumers of content, maybe interact a
| little, enough to tweak their feeds
|
| - a small minority creates content on the large networks /
| aggregators, and (I think) a large portion of that is spurred on
| by monetization
|
| - the "internet" and all the devices that access it have become
| so "user friendly" that the people who have come online in the
| last decade or so are effectively technically illiterate; you
| cannot count on them building anything from scratch, only to
| arrange the big duplo pieces already provided
| multicast wrote:
| You have just highlighted the main fact about the www that so
| many technical skilled people are missing to see. Most
| consumers have little to no knowledge about anything technical,
| which is not bad at all since there is no reason why they
| should care. Now imagine telling those people that everyone
| should have their own website instead of a social media
| account. What a horrible and illogical thought in my opinion.
| Digital consumers only change behavior if something is 10x
| better. So from a consumer perspective, who cares about things
| like decentralized networks? Or Duckduckgo.com for example is
| probably for 99% of the www users some chinese russian inbreed
| virus. People started using ChatGPT besides google because it
| is simply 10x better for many cases, and not because it
| promoted with more privacy feature and less ads than google.
| SPBS wrote:
| _ugh_ I was so excited to see pure HTML modals were a thing with
| <dialog> only to find out there's no way of triggering them
| _without_ JavaScript. Using pure HTML you can only dismiss them,
| not trigger them.
|
| https://github.com/whatwg/html/issues/3567
|
| > dialog elements are a great addition and I'm glad they're
| getting implemented, but a key part of their functionality relies
| on JavaScript: to open a <dialog> you need to use JavaScript to
| set the open attribute.
|
| > It'd be great if there was a way to make a <a> or a <button>
| elements capable of opening dialogs.
|
| > Precident already exists for page interactivity baked into HTML
| - for example <a href="#.."> can already scroll the page, and
| <details> elements are capable of hiding elements behind
| interactivity, so I think it stands to reason <dialog> elements
| could be opened by other page elements.
| contravariant wrote:
| You can show or hide it depending on the current hash. Though
| admittedly that does require CSS.
| clairity wrote:
| yah, would be nice if it were baked into html itself, but at
| least the javascript isn't complicated, and can be put in an
| `onclick` attribute: <button
| onclick="document.querySelector('#my-
| dialog').showModal();">open my dialog</button>
| Kiro wrote:
| I don't see the higher purpose of "HTML only" if that means we
| need to extend HTML with scripting capabilities. In that case I
| rather just use JavaScript.
| pbhjpbhj wrote:
| Users might prefer, say, that 99% of the time a data
| selection widget behaves the same whenever accessed by their
| browser. When devs choose a JS UI library then that's usually
| what users get. Wouldn't it be good to have all tables have
| the same features (sort, collapse, column-select, data
| export), rather than only having rich features if the dev
| implemented them, duplicating the effort of millions of other
| devs.
|
| There's a sliding scale here, with html at one end and each
| page ships a parser and libraries at the other - why have an
| img tag, just let the page developer implement a JS based
| interpreter?
| aaviator42 wrote:
| You _can_ implement modals without JS, with HTML and CSS.
|
| For an example, click on '?' in the top right corner here:
| https://aavi.xyz/proj/colors/
| ovao wrote:
| There are useful tricks to changing CSS properties via
| checkbox state and pseudo-selectors to implement simple
| modals (which won't be accessible), but you can't open a
| modal <dialog> element without JS.
|
| Weirdly, you can _close_ them with a form submission, but you
| can't _open_ them with one.
| nzoschke wrote:
| Great read and interactive demo.
|
| After a few years of dabbling with Flutter I just came back to
| the same conclusion: bet on HTML.
|
| Astro / Tailwind / Daisy UI / Alpine.js makes it lovely to build
| an HTML site with a lot of simple SSR and a little bit of client
| side reactivity peppered about.
|
| The result is simple sane HTML files that look and work great on
| desktop web browser and and mobile wrapped web view.
|
| My app is basically static so it caches in a CDN, works offline,
| and view source makes it easy to debug.
| bingemaker wrote:
| Exporting to web using Flutter is a nightmare I believe. When I
| checked last time, rendering happens on a canvas. There is no
| markup at all
| Alifatisk wrote:
| > rendering happens on a canvas
|
| flutter run --web-renderer=html
| satvikpendem wrote:
| I use Flutter for some web apps, it works fine. It's good for
| web apps, not web sites, and compared to other desktop or
| mobile apps, there is literally no difference between
| rendering on a canvas to rendering on Qt or SwiftUI. People,
| in my experience, just get up in arms about the web that does
| not happen with other technologies.
| troupo wrote:
| > compared to other desktop or mobile apps, there is
| literally no difference between rendering on a canvas to
| rendering on Qt or SwiftUI.
|
| Except, you know, accessibility.
|
| > just get up in arms about the web that does not happen
| with other technologies.
|
| And for a good reason.
| frabcus wrote:
| Flutter has a wild accessibility system that also exports
| DOM elements just for the aria labels.
|
| This all breaks the browser's in page search function
| though! Long standing bug with no fix yet.
| satvikpendem wrote:
| Do you realize that Flutter has an accessibility system
| that is often more advanced than most desktop UI
| frameworks? [0] I notice this often from non-Flutter
| devs, Flutter has some pretty good a11y.
|
| [0] https://docs.flutter.dev/accessibility-and-
| localization/acce...
| troupo wrote:
| Good to know! For the longest time ever their export to
| web was just canvas with no attempt at making it
| accessible.
| mhoad wrote:
| I don't know if even that was actually true? As far as I
| know the moment they introduced canvas as a rendering
| target they also produced a DOM structure along side it
| to capture the accessibility tree as they were still
| waiting on a more native solution in the form of AOM
| (accessibility object model) to be finalised.
| juancampa wrote:
| Can you help me understand the utility of Daisy UI? Seems like
| it's the good old classes+stylesheet with extra steps
| (tailwind)
| gbalduzzi wrote:
| Well, instead of writing this for every button in your web
| app:
|
| <button class="bg-indigo-600 px-4 py-3 text-center text-sm
| font-semibold inline-block text-white cursor-pointer
| uppercase transition duration-200 ease-in-out rounded-md
| hover:bg-indigo-700 focus-visible:outline-none focus-
| visible:ring-2 focus-visible:ring-indigo-600 focus-
| visible:ring-offset-2 active:scale-95"> Button </button>
|
| You can write this:
|
| <button class="btn btn-primary"> Button </button>
|
| The utility is pretty clear to me
| 0JzW wrote:
| so we've just circled back to good ol bootstrap?
| juancampa wrote:
| Exactly my point
| Alifatisk wrote:
| That's even valid bootstrap classes
| nathansherburn wrote:
| After trying a bunch of fancy frameworks and platforms I ended
| up doing exactly this - a static site with alpinejs and
| tailwind. It has been by far the best decision I've ever made.
| And the best thing is I'm confident any new dev will be able to
| pick up my 100 line build file and grok it in about 3min. No
| matter whether they're react, angular, PHP or python folks -
| it's dead simple and I love it.
| irrational wrote:
| Now move to the next level and have no build system.
| em-bee wrote:
| i am building sites with aurelia without a build system.
| there used to be a quick-start tutorial where you could
| just download an archive with aurelia ready to run. no
| serverside tools or build tools necessary at all. it even
| used to work loading the whole app via file://... back when
| browsers still trusted that. it no longer works only
| because of browser restrictions on using file://
|
| the tutorial is gone, but the download still exists
| referenced here: https://stackoverflow.com/a/39681911
|
| the downside is that i don't know how to update this to
| newer versions or add extensions.
|
| it might also be possible to create a new version of this
| using aurelia-cli, but i haven't yet figured out how.
| andai wrote:
| My build system is cat!
| WeAddValue wrote:
| Meow!
| resonious wrote:
| Lately I've been doing raw html and css. No build. I just
| write the files. It's really easy. Yeah there's some
| duplicate code in the header but grep is not that hard to
| use.
| cloked wrote:
| yup, Astro and "islands architecture" is such a joy to work
| with.
| komali2 wrote:
| 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?
| adamredwoods wrote:
| >> Moreover, proper tagging is extremely descriptive in a
| machine-readable format. This is likely a more compelling reason
| for adopting modern HTML than saving design time.
|
| Why do I want to make my website AI-accessible? It, or some mega-
| rich company will reap the rewards, not me.
| jcotton42 wrote:
| Machine-readable here also means screenreader-readable
| coldtea wrote:
| > _In fact, recently I've become acutely aware of reader mode.
| All time spent on styling will be obliterated by reader mode, and
| that's a great thing!_
|
| Reader mode is mostly for longer text. Doesn't help with WPAs as
| much.
|
| > _Moreover, proper tagging is extremely descriptive in a
| machine-readable format. This is likely a more compelling reason
| for adopting modern HTML than saving design time. The shift from
| primary data interfaces to secondary interfaces is already
| underway. RSS refuses to die. ChatGPT-like interfaces are likely
| the future of human data access. We're going back to the
| beginning. Advertisers may be scared, but I'm not! Let's start
| the revolution and set the world on fire with modern HTML._
|
| Not sure what this (the most important part) attempts to say.
|
| What does the advent of ChatGPT-like interfaces have to do with
| "adopting modern HTML" and "proper tagging"? If anything ChatGPT-
| like interfaces would require less tagging, and can do the
| "figuring out what the text is" part of semantic web without
| sementic metadata (and they can do it directly on the actual
| text, whereas the metadata would more likely be abused and
| misleading for SEO).
| [deleted]
| aviavinash wrote:
| this article's making me think. In this AI-driven landscape, the
| focus on semantic structure totally makes sense. But, is it
| really the remedy for the social media interoperability problem?
| Are we underestimating the appeal of decentralized platforms?
| And, do people genuinely not care about these alternatives?
| kapitanjakc wrote:
| HTML is that nerd who's rich now.
|
| Give me HTML,CSS,JS combo any day over some complex js library or
| platform.
| netapy wrote:
| Used to work with that combo only - it's a mess as soon as you
| need to make reusable components. Svelte strikes a pretty good
| balance there !
| satvikpendem wrote:
| Good luck making anything complex by relying on a bespoke
| library for DOM updates. In contrast, React became a breath of
| fresh air, emulating the game development approach to rendering
| new frames: just literally rebuild the components.
| klabb3 wrote:
| Yes reactive UI is the only thing I can't live without.
| React, Svelte, Vue are all fine. Trying to mirror state into
| and back from DOM manually is absolute disaster.
|
| I really hope this becomes standardized at some point. Would
| be great to have consensus around.
| dahwolf wrote:
| Not quite getting this article.
|
| When you semantically describe your HTML, indeed the intent and
| meaning of your data becomes easily machine-readable.
|
| That's not a solution, it's the entire problem. In today's
| ecosystem it means somebody takes your shit and runs with it.
| That's why the walled gardens are getting ever higher walls.
| "Open data" is an existential threat if you're the one paying for
| the creation/hosting of that data.
| koito17 wrote:
| I noticed <details> made the list but not <summary>. Is the
| latter a well-known tag compared to the former? In any case,
| semantic HTML is nice because they usually have good
| accessibility attributes by default.
|
| In general, <summary>, <details>, <aside>, <main>, <nav>, and
| <dialog> prove to be highly useful for quickly hacking together a
| personal site without having to write much JavaScript, if at all.
| spondyl wrote:
| I assume <summary> was not explicitly mentioned because it
| generally only appears as a child of <details>.
|
| It's not intended to be used in the same way as say; <article>
| to my knowledge
|
| > A <summary> element may only be used as the first child of a
| <details> element
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/su...
| nsonha wrote:
| The very first sentence:
|
| "With the advent of large language model-based artificial
| intelligence, semantic HTML is more important now than ever"
|
| No it's not, LLM basically invalidates the entire concept of
| semantic web, which never worked anyway.
| sensanaty wrote:
| If proper semantic HTML _helps_ companies like ChatGPT, I 'll
| make sure to try as hard as humanly possible to fuck with it with
| horrible HTML, then.
| omgmajk wrote:
| I've been meaning to build some utility websites like a simple
| forum and a simple pastebin and the like for a while just
| entirely without javascript, kind of like the old days. I want a
| simpler web with less bloat.
| boredumb wrote:
| I'm not javascript free, but i've been actively pursueing
| building useful things with as little if any javascript and
| have been impressed with what I can get done with forms and
| html templating.
|
| A few years ago moving to a new area I was trying to find a CPA
| and saw simple brochure sites are loading 10+ mb of resources
| and 10+ JS snippets and realized how bad things have really
| gotten, even with an adblocker on these days a 3g network is
| hardly enough to browse a massive portion of the web.
| omgmajk wrote:
| Always been fascinated with this type of development. I come
| from the era where JS was typically frowned upon, later
| learned to like it during ES6 because I had to use it a lot
| but now I mostly use it for Node and not the frontend
| anyways.
| ur-mom wrote:
| [flagged]
| kabes wrote:
| There's lots of reasons I think using semantic html is important,
| but making it more easily scrapable by chatGPT isn't one of them.
| nologic01 wrote:
| HTML is one of these technologies that (still) feels pregnant
| with infinite possibilities. But we can't really project
| meaningfully what can / should happen to the web platform (and
| the role of HTML in it) without considering the tortured
| trajectory it already has traversed, e.g., the major XHTML vs
| HTML5 (or W3C vs WHATWG) battles, its more recent "annihilation"
| in the hands of SPA and JS frameworks and the multiple roles it
| can play. In a sense HTML is too powerful for its own good. So
| prevailing interests will always try to tame it towards their own
| needs.
|
| HTML is the conduit and enabler of at least three distinct
| functionalities that are made available by a decentralized
| internet comprising clusters of server and client machines:
|
| * transmitting the information to implement hypertext (=the
| simplest implementation of linked textual documents). This
| transmission of linked natural language data has changed the
| world already and is sufficient to support e.g., a planet of
| interconnected bloggers. HTML purists (like the OP) focus on this
| angle but this is _very limiting_ and will never unlock all the
| positive potential of the web.
|
| * transmitting semantically annotated non-text _data_ of all
| types (numerical, graphical, objects etc). This vision has never
| really materialized in either its XHTML or SVG guises. Today the
| only hint that HTML is capable of transmitting such data is the
| table element. Yet it has enough in-principle semantics to
| transmit any JSON object.
|
| * transmitting UI elements. Why do we need UI elements at all and
| are they intrinsically evil? The core function of UI elements,
| both the semantic aspect (hierarchical relations) and the
| geometric aspect (i.e. CSS and mapping stuff to a 2D screen) are
| essential and entirely benign. They simply help organize more
| complex patterns. HTML ultras that avoid CSS essentially rely on
| default such mappings.
|
| Imho an alternative vision to the degenerate web of today that is
| simply the funnel that gets you to the walled gardens built by
| adtech (actually humanity grinding machines) must stop being
| naive, simplistic and Luddite. In all these web technologies of
| yesterday you can trace battles that were lost, paths not taken.
|
| The web we want is an empowering, democratic, decentralized
| platform that respects and elevates individuals in the digital
| realm. This web is not tech-phobic. It is confident and develops
| / adopts any and all technologies that fit is values.
|
| [1] https://en.wikipedia.org/wiki/WHATWG
| rado wrote:
| Yes, always bet on HTML. I made the chart here in semantic HTML
| with a definition list, which is also keyboard accessible, and
| overlaid by a canvas: https://www.skrill.com/en/currency-
| converter/ - no libraries needed.
| backtoyoujim wrote:
| If you don't want rounded corners then what's this all been about
| ? What am I working toward ?
| shantanujoshi wrote:
| So down for this. Feels intuitive. JS is dead. Superconductors at
| room temp. WERE BACK
| irrational wrote:
| The main thing I want added to the html spec is a spreadsheet
| element. It could be an enhancement to the table element. I want
| it to support sorting, filtering, pagination out of the box. And
| be responsive to boot.
| rado wrote:
| Recently replaced 13 lines of inline SVG by a single <progress>
| element.
| jerf wrote:
| 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 heuristics equipped with best-of-
| breed-at-the-time AI behind it. As AI improves, it improves its
| ability to extract information from any ol' slop, and if "any ol'
| slop" is enough, it's all the effort people are going to put out.
| Eventually in principle both the semantic web and that pile of
| heuristics are entirely replaced by AI.
|
| (Note also my replacement of LLM with the general term AI after
| my first usage of LLM. LLMs are not the whole of "AI". They are
| merely a hot branch right now, but they are not the last hot
| branch. It is not a good idea to project out the next several
| decades on the assumption that LLMs will be the last word in AI.)
| krainboltgreene wrote:
| > The semantic web has failed
|
| literally by no metric is this true other than tech bros saying
| it on HN. The entire internet is powered by websites using
| semantic markup and clients querying it.
| tomlue wrote:
| 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.
|
| The question of truth is still a very hard one. How do you tell
| an AI that some knowledge is more trustworthy than other
| knowledge? People have this issue too though.
| __loam wrote:
| If you're relying on a stochastic process like network
| weights to encode truth then I have some oil to sell you.
| jerf wrote:
| 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. :)
| moritzwarhier wrote:
| > The semantic web has failed and what replaced it was Google
| spending a crap ton of money
|
| Aren't schema.org and Wikidata/Wikipedia still powering most of
| Google's rich search results?
|
| I heard them announce the new result page with bard but I
| probably didn't see it because of ad-blindness or it's not yet
| releases in my location, have to look this up...
| coldtea wrote:
| > _Aren 't schema.org and Wikidata/Wikipedia still powering
| most of Google's rich search results?_
|
| Were they ever?
| moritzwarhier wrote:
| Well schema.org was not referring to an organization or
| entitity, but its published schemas. I'd argue these were
| and are driving a lot of rich results, especially for local
| businesses.
| krainboltgreene wrote:
| Yes.
| zagrebian wrote:
| 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.
| jpochtar wrote:
| AI will solve web accessibility by screen readers that
| summarize visual content, ignoring ARIA and making it
| irrelevant. Multimodal GPT-4 can take a screenshot jpeg and
| answer questions about what's in it (buttons, links, ads,
| headers, etc). The future of accessibility is rendering DOM
| to jpeg and asking GPT to be your eyes; we'll look back on
| semantic markup as a failed idea that was never going to work
| bschne wrote:
| If semantic HTML is important for accessibility and for
| software to be better able to parse information out of it,
| and AI solves the latter, semantic HTML is now less important
| because some of the use cases that needed it previously no
| longer need it. If you take "less important" as a moral/value
| statement instead of in terms of total utility provided, and
| assume that AI will have zero accessibility benefits, it will
| merely be as important as today, which is still at odds with
| the assertion of the original article that it would become
| _more_ important. N.B. this seems doubtful, given how e.g.
| you can now past a bunch of code into an LLM and ask it
| questions quite naturally -- something I can easily see
| adapted to e.g. better navigating apps using only voice and
| screenreaders.
| jerf wrote:
| 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.
| javajosh wrote:
| The idea generalizes. Imagine an archiver which applies a
| transform to a site. Adding semantic markup - or censoring
| parts that someone finds offensive. If the original author
| agrees, they might offer an api so the transformation is
| linked to by the original. Or perhaps the transformer could
| make an agreement with/fool Google into linking to their
| version rather than the original. Perhaps because it's
| "safer".
|
| Oh yes, a great startup idea.
| zagrebian wrote:
| 80% sounds way to optimistic to me. The problem is that
| screen readers (and other assistive technology) have bugs
| and different behaviors, and some people use older versions
| of those tools with even more bugs and quirks. The only way
| to make sure that a website has a high level of
| accessibility is to perform manual testing in different
| environments. I don't see how AI can solve this problem.
| And the people who perform the manual testing need to be
| experts in semantic HTML and ARIA to be able to identify
| problems and create reports. That means that semantic HTML
| remains important.
| coldtea wrote:
| > _80% sounds way to optimistic to me. The problem is
| that screen readers (and other assistive technology) have
| bugs and different behaviors, and some people use older
| versions of those tools with even more bugs and quirks.
| The only way to make sure that a website has a high level
| of accessibility is to perform manual testing in
| different environments._
|
| That's if you want actual accessibility support on a wide
| range of old and new devices.
|
| But the business idea the parent proposes is automated
| accessibility for compliance, which is the real thing
| that could be sold, and has a much lower bar.
| jakubmazanec wrote:
| LLM could transform "bad HTML" into good HTML; add ARIA
| tags, add image captions, etc.
| zagrebian wrote:
| Unless it's 100% reliable or near 100% reliable, you'd
| still need manual testing. Right now, automatic
| accessibility testing can't even _detect_ most
| accessibility issues. So we haven't even reached the
| stage where all issues are detected by tools, and
| probably never will. Fixing all issues automatically is
| significantly harder than detecting them.
| tuckerman wrote:
| Given how bad accessibility is, it seems like even
| something imperfect could be a big leap forward for a lot
| of sites.
| coldtea wrote:
| > _Unless it's 100% reliable or near 100% reliable, you'd
| still need manual testing._
|
| Not unless:
|
| (a) it's X% reliable now, and it would be Y% < X% if done
| via LLMs.
|
| (b) businesses actually care for increased reliability,
| and not just for passing the accessibility requirements.
|
| Most businesses could not give less f...., and don't do
| "manual testing" today either. Just add the token
| required tags. That's true even when they do business
| with the government (which mandates this even more
| highly).
|
| LLM-driven accessibility info would be an improvement.
| jerf wrote:
| My estimate of 80% included 6-12 months of serious
| development first, and a certain amount of budget for
| manual intervention for the first several dozen jobs.
| Certainly just flinging HTML at ChatGPT as it stands
| today would do nothing useful at all. Providing manual
| testing could easily be done as part of a higher service
| plan. Not only is there no rule that a startup using AI
| _has_ to be just in the form of "throw it at the AI and
| then steadfastly refuse to do anything else", that's
| probably a pretty good way of filtering out the ones that
| will make it from the ones that won't.
|
| Do assistive technologies have more "bugs" and "quirks"
| and "different behaviors" than natural text? I don't
| really think so. In fact I'd expect they have
| qualitatively _fewer_ such things.
|
| Semantic HTML would be important in this case... but it
| would be important as the output, not the input.
|
| This hypothetical startup could also pivot into
| developing a better screenreader pretty easily once they
| built this, but there would be a good few years where an
| AI chewing on the HTML and HTML templates in use by a
| server would be practical but you can't expect every
| assistive technology user to be using a 64GB GPU to run
| the model locally. Certainly that would factor into my
| pitch deck, though.
|
| I'd give more credence to the "it has to be perfect to be
| useful at all" argument you're going with here if it
| weren't that I'm pretty sure every user of such
| technology is already encountering a whole bunch of
| suboptimal behavior on almost every site today.
| telotortium wrote:
| Someone's on it already (but maybe there's room for
| competition, if
| https://adrianroselli.com/2020/06/accessibe-will-get-you-
| sue... is any indication):
| https://accessibe.com/accesswidget/artificial-intelligence
| makapuf wrote:
| An LLM-based accessible _browser_ could render 80% of the
| Web accessible at once it the tech works.
| miki123211 wrote:
| This has been tried and doesn't work, which doesn't mean it
| will never work in the future! There are a few companies
| offering solutions in this space, but they don't work, are
| often worse than the problems they're trying to solve and are
| a privacy disaster. The companies peddling them often engage
| in shady business practices, like falsely claiming that their
| overlays can protect you from ADA lawsuits[1], while actually
| suing the people who expose their lies[2]. Most accessibility
| practitioners and disabled users themselves are warning the
| public to avoid those tools[3].
|
| [1] https://adrianroselli.com/2020/06/accessibe-will-get-you-
| sue... [2] https://adrianroselli.com/2023/05/audioeye-is-
| suing-me.html [3] https://overlayfactsheet.com
| chickenfeed wrote:
| AIs are magic to me. The pattern recognition feature of human
| I've always thought pretty unique and hard to replicate. We use
| it when scanning the slop on websites to do some kind of data
| extraction. I was part of the semantic web camp in my brain,
| but you are right, if machines can seemingly make sense of the
| slop then why bother?
| yieldcrv wrote:
| I already knew this was going to be some minimal and ugly website
| that consciously rejects all modern UI conventions
|
| Congratulations, it passed pagerank and was readable.
| pphysch wrote:
| I think the #1 issue with HTML (and CSS) is that it is portrayed
| as being trivial, easy, "not a programming language". Someone who
| has written a few `<td>` "knows HTML". It's not respected.
| Consequently, people don't invest time in learning to use it well
| and keeping up with new features. And then they use it poorly, or
| run into awful examples of it, and come to the wrong conclusions
| about it.
|
| While the idea of a markup/styling language is pretty simple,
| HTML+CSS deal heavily with _difficult_ concepts like ontologies,
| cascading and non-imperative behavior, balancing UX & machine
| interpretability (accessibility), etc. Add in HTTP and browser
| APIs. Web dev is distributed computing par excellence, and is
| extraordinary deep and challenging, yet it's also viewed as among
| the lowest forms of programming. That's a big mismatch.
| teekert wrote:
| Yeah do we need that disclaimer?
|
| If I (non native English speaker) write a blog post it will be
| shit English and won't read "smoothly". Then ChatGPT makes it
| nice and smooth. I check if my intentions are left unaltered and
| then post. For professional stuff I used to ask my American
| colleague, now I don't have to bother her anymore.
| broodbucket wrote:
| I don't see it as confessing their sins, more like "FYI, I used
| X tool to help me with Y" like you'd see "Page generated by Z"
| in a footer except in a header since it's related to the
| content itself. Unless you're writing an assignment for an
| English class I don't think anyone would feel lied to if they
| found out you had help from an AI translator.
| vvpan wrote:
| The argument of the piece completely eludes me. How would HTML
| disenfranchise walled data gardens?
| happythebob wrote:
| Upvote for King Gizzard
| maxfurman wrote:
| I've been doing web development full-time for nearly a decade
| now, and I didn't know about all of these. I think I failed a job
| interview last month because I didn't know about <datalist>.
| Sigh.
| intrasight wrote:
| I've been doing web dev for over 20 years and just discovered
| and used datalist
| asim wrote:
| Honestly, what we need is a new browser. I think everyone is sort
| of done with the URL bar, point click GUIs and we're going to see
| the need to transform things as LLMs become a more dominant query
| medium. It means the starting point is a search interface, it
| means much of what we want is automatically rendered as an
| embedded app in the page and it probably means we stop "browsing"
| and start consuming information on the web in a slightly
| different way.
| gryfft wrote:
| Wow, thanks for the nightmares.
| anyfactor wrote:
| Tangent.
|
| > I wrote this post and then GPT-4 fixed my grammer and spelling
|
| I wrote an Autohotkey + Go script that I constantly use for
| fixing grammar using ChatGPT's API. You can select the text,
| press F8, wait a bit, and your input will be replaced by
| correctly grammatical text. The only catch is that it "fixes" the
| tone and makes it professional, which is kinda annoying.
|
| Feel free to try it out:
| https://github.com/anyfactor/Chatgpt_grammar_checker
| p-e-w wrote:
| Alternatively, you could set up LanguageTool[1], which runs
| much faster, is more reliable, is open source, and, crucially,
| doesn't require sending what you wrote to a server on the
| Internet. Plus, it already has high-quality integrations with
| standard software like LibreOffice, so you don't even need to
| write anything yourself.
|
| [1] https://github.com/languagetool-org/languagetool
| xvilka wrote:
| If only it didn't require Java to run. Then integration with
| lightweight setups like NeoVim or Emacs would be so much
| better and easier.
| billforsternz wrote:
| The misspelling of grammer instead of grammar is a little
| ironic in this context. Sorry:-)
| anyfactor wrote:
| Grammer, should of, datbase, mangement, timzone,
| accept/except, except/expect ..... We should accept these as
| part of normal written conversations and try to understand
| the context. With the amount of AI-generated content that is
| being produced, misspellings should be celebrated!
|
| But who am I to say that? I am literally converting my rants
| on the internet into professional arguments and using
| sophisticated synonyms like the architect from the Matrix.
| "Ergo", I am part of the problem.
| DharmaPolice wrote:
| I'm going to have disagree with you on misspellings. AI can
| trivially replicate them (the Elizabot you used to get on
| old school BBSes would make deliberate
| mistakes/corrections) and they just make it ever so
| slightly harder for your audience to parse what you've
| written. If nothing else - expect/except sounds quite
| different from a screen reader.
| simonw wrote:
| That was deliberate - if you view the source:
| ... then GPT-4 fixed my <span class="typo">grammer</span> and
| spelling
| latexr wrote:
| > The only catch is that it "fixes" the tone and makes it
| professional, which is kinda annoying.
|
| Then why send your text to a slow third-party in the first
| place? There are craptons of spelling and grammar checkers
| available which will work offline, be significantly faster,
| consume less resources, and not change the meaning of your
| text. We solved this problem decades ago, we don't need to
| shove AI in everything.
|
| It's not like the ChatGPT solution is flawless anyway, there
| are still basic mistakes in the text:
|
| > Can by styled quite aggressively.
| anyfactor wrote:
| Original Text
|
| Grammar checkers are essentially typo checkers and are not
| context aware to be truly grammar checkers. Context aware
| grammar checking means the program has to consider each line
| of text and identify grammar mistakes. As traditional grammar
| checkers check typos in real time, every mistake you do is
| flashed in front of you. You have to stop evaluate, fix and
| continue. This is distracting.
|
| My solution is to get your thoughts immediately out of your
| head in a big chunk. Check the grammar of that chunk of text
| in a single button press wait a few seconds and then just
| paste the text.
|
| The tone shift is good in technical writing, but in forum
| style communication it kinda dehumanizes the comment. But it
| is not a major thing.
|
| I use grammarly pro, but I find this solution to be extremely
| robust as this solution is platform and software agnostic.
| Like writing in my text editor - LiteXL.
|
| Please feel free to give this method a shot for a week.
|
| ---
|
| Edit
|
| ---
|
| Grammar Checker with ChatGPT
|
| Grammar checkers are essentially typo checkers and are not
| context aware enough to be considered truly accurate grammar
| checkers. Context aware grammar checking requires the program
| to analyze each line of text and identify grammar mistakes
| accordingly. Traditional grammar checkers usually highlight
| typos in real-time, which means that every mistake made is
| immediately brought to your attention. Consequently, you are
| forced to pause, evaluate the error, correct it, and then
| resume your writing, creating a distracting workflow.
|
| My solution is to encourage you to initially get your
| thoughts out onto the page without worrying about the
| grammar. In this approach, you can check the grammar of the
| entire chunk of text with a single button press, wait a few
| seconds, and then conveniently paste the corrected text.
|
| The tone shift is acceptable and even beneficial in technical
| writing; however, in forum-style communication, it can
| somewhat dehumanize the comment. Nonetheless, this is not
| considered a major issue.
|
| Although I personally use Grammarly Pro, I find this solution
| to be highly effective as it does not depend on any specific
| platform or software. For instance, I can comfortably write
| in my text editor, LiteXL.
|
| Please feel free to give this method a try for a week.
|
| ---
|
| Grammarly Pro
|
| Grammar checkers are essentially typo checkers and are not
| context aware enough to be considered genuinely accurate
| grammar checkers. Context-aware grammar checking requires the
| program to analyze each line of text and identify grammar
| mistakes accordingly. Traditional grammar checkers usually
| highlight typos in real-time, meaning every mistake made is
| immediately brought to your attention. Consequently, you are
| forced to pause, evaluate, correct the error, and then resume
| your writing, creating a distracting workflow.
|
| My solution is encouraging you to get your thoughts onto the
| page without worrying about the grammar. In this approach,
| you can check the grammar of the entire chunk of text with a
| single button press, wait a few seconds, and then
| conveniently paste the corrected text.
|
| The tone shift is acceptable and even beneficial in technical
| writing; however, forum-style communication can somewhat
| dehumanize the comment. Nonetheless, this is not considered a
| significant issue.
|
| Although I use Grammarly Pro, this solution is highly
| effective as it does not depend on any specific platform or
| software. For instance, I can comfortably write in my text
| editor, LiteXL.
|
| Please feel free to give this method a try for a week.
| latexr wrote:
| > As traditional grammar checkers check typos in real time,
| every mistake you do is flashed in front of you. You have
| to stop evaluate, fix and continue. This is distracting.
|
| Or you can disable that feature (or the software entirely)
| and do a full pass at the end. You're not forced to do live
| checking.
|
| > Please feel free to give this method a shot for a week.
|
| No, thank you. I have no desire to send what I write to
| third-parties I don't trust. Also, your examples were far
| from compelling. I'd rather not have my words padded with
| fluff.
| anyfactor wrote:
| I understand that. It is working for me. And I am happy
| with my system as you are with yours.
| the_king wrote:
| One question is: "How easy is HTML to read for humans." Everyone
| who has spent more than a few months writing software will be
| familiar with the idea. But for someone who has never seen it -
| is the concept intuitive? Do bright 8th graders get it if shown
| it for the first time on a test?
|
| I used to think the answer was "pretty difficult," but I haven't
| come up with anything better. Maybe there is something to be done
| with indentation - but that has it's own challenges.
| klardotsh wrote:
| 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 browser might be something like
| visurf https://sr.ht/~sircmpwn/visurf/ but with the underlying
| Netsurf engine updated to support various modern HTML+CSS, such
| as these elements. I bet you could have a nearly JS-free smolweb
| through that browser that:
|
| 1. is more accessible (in the "doesn't break screenreaders,
| system theming, keybinds, etc" way)
|
| 2. could be made to use way fewer resources than these heavy JS
| contraptions these elements can replace
|
| 3. would still be able to do most things we expect the median web
| app of today to do (sure, fire up Firefox for WebGL or whatever
| still, but I could see, say, a Matrix client potentially needing
| only a smidge of JS (largely for WebSockets and E2EE stuff) over
| top of very-modern HTML)
| Gigachad wrote:
| 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 full power, works
| identical on all systems, etc.
|
| In the end all these extra components just end up as bloat all
| browsers have to implement but no one uses.
| Sjeiti wrote:
| JS does not 'just work'. This is why a lot of these custom
| components have bad touch interaction and no accessibility.
| Take the datepicker; the native mobile version works great,
| why annoy users with a custom component?
| wruza wrote:
| _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 always appreciated these buttons and modes because
| they were working in accounting and picking dates from that
| stupid standard picker was an ordeal. " / / " pattern is
| also annoying because you have to be precise with your
| cursor.
|
| That said, ios picker _is_ great, and it's unnecessary to
| replace it. But (1) it's not the only useful mode of
| operation, (2) it wasn't always great on all platforms, and
| (3) html attributes usually suck at describing what
| patterns and use cases you want and compatibility among
| browsers is a minefield. I mean not only dates here, also
| numbers and ~numeric fields.
| ravenstine wrote:
| 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 developed in JavaScript that would serve
| everyone 's needs, be totally accessible, and _not_ a
| bowl if <div> soup. So why don't we do it? Why are what
| should be basic HTML forms on corporate websites
| difficult to navigate or in some cases fundamentally
| broken, requiring workarounds? Nobody is interested
| because solving _real_ problems doesn 't carry any of the
| prestige of building another framework. Who wants to
| build a date picker that is standards compliant when you
| could write another web framework, _bro?_ Even if a
| developer is not trying to build the next React, they 're
| probably spending more time on their toolchain than
| actually coding. It's gotten so bad that seemingly every
| company I've joined in the last 6 years needs a bunch of
| people dedicated to maintaining toolchain and CI crap for
| the rest of the team.
|
| I love programming, but the web needs to get its head out
| of its own ass. We're acting like our jobs are more
| important than the value the software delivers, and more
| effort is being put into making sites impractical for
| machines to parse (because muh intellectual properteh!)
| than in making web components that aren't riddled with
| bugs.
| wruza wrote:
| 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.
| Sjeiti wrote:
| You're absolutely right on the 'why' part, but sadly a
| lot of custom implementations are annoying in terms of UX
| and accessibility. My only point here is that building
| proper custom components is far from easy, it takes a lot
| of time and effort.
| yyyk wrote:
| >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
| fix every client configuration - not very likely even in
| small companies.
|
| * No way to have the datetime dialog open by default.
|
| * Poorish but getting better keyboard support (the
| pagedown-up keys finally work in most browsers, but once
| you've opened the dialog you can't enter a new date with
| the keyboard).
|
| * Timezones must be handled separately, which is just poor
| design.
|
| (Entire list checked on desktop)
| berkes wrote:
| > ...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.
|
| > Lets you enter nonexistent dates like 31/2
|
| This may be an issue in specific browsers/versions/os.
| But enabling the "validation" by setting required and/or
| some other attributes, gives an error for these dates
| AFAICS. But, in any and all cases: server-side validation
| is needed anyway. You just cannot trust a value sent by a
| user, whether that's "validated" with sixty npm-packages
| and their dependencies, or by the browser.
| nelgaard wrote:
| I normally use en_US but I want dates formatted as DD-MM-
| YYYY (or using dots, slashes etc ) and I want a 24-hour
| clock.
|
| LC_TIME does not work very well with most apps.
|
| And there is a big difference between just throwing an
| error if a date-time cannot be parsed because of a
| nonextent date, and communicating it to the user in a
| nice way, especially without using JS.
| speedgoose wrote:
| But the webdev has to solve this problem. Users with
| wrong locales and not aware of that are not very
| uncommon. I would also love the US to fix their stupid
| date format and even fully adopt the metric standard but
| sometimes you have to compromise and write code instead.
| berkes wrote:
| WRT dates, there's no "metric" standard. Not really. E.g.
| Belgium commonly uses DD/MM/YYYY whereas the Netherlands
| uses DD-MM-YYYY. Both use "metric standard" for lengths,
| weights etc. Same with currencies: "13,37 EUR" vs "EUR
| 13,37" vs "EUR13,37", all depending on where in Belgium
| you are from, vs Dutch in the Netherlands. It's an utter
| mess.
|
| Which is another reason to let browsers - the _user
| agents_ - deal with this. There 's absolutely no way a
| lonely JS dev, or even a community around something like
| MUI to get all this right. And they don't. There's always
| something broken for me with these custom elements. If
| it's not some US-centric web-app enforcing their
| MM/DD/YYYY format, then it's some "ignorant" dev being
| unaware that in Europe in many countries decimal
| separators are a comma, or that in Thailand the current
| year is 2566 and that this is not "too far in the
| future".
| speedgoose wrote:
| My bad, seems like the metric system is an old thing:
|
| https://en.m.wikipedia.org/wiki/Metric_system
| yyyk wrote:
| >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?
| robocat wrote:
| > the native mobile version [of datepicker] works great
|
| Strong disagree. It does work for simple forms, but
| definitely has a variety of quirks on different
| browsers/devices. Blank dates are especially quirky. Try
| "tabbing" through a date on iPhone or iPad and have some
| poor UI. datepicker really doesn't work well for some less
| common situations (cut n paste, copy, from/to date,
| restricted date min/max past/future, year pick, month pick,
| etcetera).
| zelphirkalt wrote:
| I think the idea is rather, that you "extend" by composing
| primitive elements, and not that you change the primitive
| elements. Kind of like "composition over inheritance".
| Gigachad wrote:
| Take the html select component, you can't extend or compose
| this in any way. A request so common that it goes without
| saying is that you should be able to search for items. This
| is impossible to implement with the default component.
|
| If you want to do another common thing like allow selecting
| multiple items, this is also impossible. It's not worth
| starting with the HTML one and then extending later because
| there is no path to do this. You have to totally scrap the
| HTML version so you may as well start with a JS library
| that does everything you need today and everything you will
| need tomorrow. Which you can theme to fit in with the rest
| of the app rather than looking like a pimple on a pumpkin
| that UX and end users spot and complain about instantly.
| zelphirkalt wrote:
| I think you misunderstand what I mean by "compose".
|
| You can compose most HTML elements including <select>
| easily: <label> What do you
| like? <select name="choice">
| <option value="first">First Value</option>
| <option value="second" selected>Second Value</option>
| <option value="third">Third Value</option>
| </select> </label>
|
| There you go, you did composition. The logic between
| those elements, how doing something with one element
| affects the other element, that is a different matter.
|
| For some elements it might be invalid HTML if one is
| inside the other. Like a <div> inside a <span> or so.
| rado wrote:
| <progress>, <dialog>, <details> etc can be themed
| jayjader wrote:
| <progress> requires some vendor-specific prefixes last time
| I tried theming it using CSS (unless you're using "theme"
| to mean host system/window mananger/browser - wide theme).
| There is no common subset (that I am aware of) of CSS
| properties shared amongst browsers that can be leveraged to
| even decently change the <progress> element's appearance.
| So I'm not sure that it is the best example.
|
| I agree that many of the list _are_ themable enough to
| warrant investing the effort to wrangle their particular
| interfaces over reinventing them entirely with <div>s.
| pmontra wrote:
| Yes, it's still a pain compared to more established
| elements https://css-tricks.com/html5-progress-element/
| klardotsh wrote:
| 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.)
| doix wrote:
| I couldn't agree more, unfortunately we are a minority :(.
| Before react was mainstream, you could "fix" websites
| pretty easily with things like greasemonkey, but even that
| is super painful now. CSS modules mangle classnames, so
| every new version (which are pushed multiple times per
| week/day) will break your naive css modifications. You
| can't naively modify DOM elements because React will
| overwrite them almost instantly.
|
| I know you can write regex in your CSS selectors and use
| MutationObserver's to update the DOM after react and co are
| done with it, but it's just so much more painful. Something
| that used to take maybe 1-2 hours to get some site
| working/looking how you like it, is now a part time job.
| johnnyworker wrote:
| Some like Magic User Interface for the Amiga, but across
| Operating Systems, and which provides the resulting
| stylesheet to the browser (with no ability for sites to
| override it unless I allow it) would be my dream and a
| marketers nightmare. Just information and media, displayed
| how each person prefers them to be displayed (and obviously
| with a lot of user made themes for people to browse and try
| out). With sub-configs like super-compact, whimsical etc.
| that users can apply to individual apps and sites.
| klardotsh wrote:
| Unfortunately, the marketing and branding departments
| would all have aneurysms over this, but I do love and
| share your dream.
| wil421 wrote:
| This is what really bugged my about "portable" Java apps
| way back. Java Spring was especially noticeable. It stuck
| out like a shore thumb compared to the regular system UIs.
| mixmastamyk wrote:
| SKINZ all over againz!
| laurels-marts wrote:
| This is my biggest criticism of all these modern HTML pseudo
| components. It's a wonderful idea, truly, but if you don't
| provide style hooks to customize and theme them they are
| useless.
|
| A month ago I wanted to use the input + datalist to have a
| searchable drop-down but there was no way to control where
| the dropdown will appear when popped open and what width will
| it have. Eventually I just gave up. Such a shame.
| flagrant_taco wrote:
| 100% agree. One big challenge is that we've made browsers
| and the full list of web specs so complicated that we're
| likely not going to see any new browser rendering engines
| competing any time soon.
|
| Ideally we would all take a bit of a step back and throw
| out old specs that aren't needed and improve the ones that
| need it, like styling support for built-ins. Unfortunately
| we're at the whims of Google and Appe though, and I can't
| imagine they would ever be interested in such a potentially
| large rewrite to their browsers when it functions as-is
| Dalewyn wrote:
| >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.
| andai wrote:
| 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.
| Animats wrote:
| _then realized there 's literally no way to tell. It's
| all flat._
|
| I hate that. I'm waiting for that fad to be over. I kind
| of liked material design, but it's too much of a pain to
| put into everything. Flat, borderless, and unidentified
| is so easy to do.
|
| The all flat approach encourages dark patterns. Lists of
| trackers you can opt out of, scrollable, with no scroll
| bar and no window border. There are important buttons
| hidden which, if pressed, do things favorable to the user
| but unfavorable to the site operator.
|
| Also, the pop-up box with no visible dismiss button, just
| an "x" which appears if you mouse over it.
|
| A non-web example - someone made the console window in
| Ubuntu borderless. If you have two console windows
| overlapping, you can't see the boundary.
| zelphirkalt wrote:
| There is something nice about plain old <button> default
| look and feel. It probably is the kind of feedback they
| give, that does not require me to always roll my eyeballs
| elsewhere for confirmation, that my click did actually
| cause some action to start.
| Animats wrote:
| Right.
|
| The flat look is borrowed from phones, from UIs where
| buttons were few and large, and the concept of "mouse-
| over" is not meaningful. Now it's everywhere, even for
| complex interfaces where it's not appropriate.
| dleeftink wrote:
| > There are important buttons hidden which, if pressed,
| do things favorable to the user but unfavorable to the
| site operator.
|
| Could you elaborate a bit? How is the flat look
| benefitting users over site owners? (Is this regarding
| lists of trackers?)
| trealira wrote:
| The process pretty much started with Windows 8, which was
| released in 2012. I don't think the flat style will go
| away anytime soon. At most, skeuomorphic elements will be
| slowly phased in. Material design at least adds shadows,
| and "neumorphism" adds back some 3d popping out, although
| I haven't seen it much.
| oneeyedpigeon wrote:
| Windows 95 was probably the optimal UI--in the Windows
| world, at least. Meaningful buttons, a reasonably-
| contained set of components, proper scrollbars. I'm not
| sure what the next major revision was after that (98
| didn't change that much, IIRC) but I bet it was probably
| a regression.
| renegade-otter wrote:
| I just ran into "datalist" and my first impression was "wow,
| game changer". The behavior is the same across browsers but the
| appearance is strictly browser-specific. You can't style it
| with CSS.
|
| Sometimes the list displays the text of the data, sometimes,
| the text and the "value" attribute. So you are not selecting
| "Atlanta" - you are selecting "234290780 Atlanta" (the ID and
| the value).
|
| And with the on-click action, you can't just get the ID - you
| have to get the whole thing and parse the ID out.
|
| It just seems... abandoned.
| datagram wrote:
| > You can't style it with CSS.
|
| Unfortunately, I suspect that this is 100% intentional.
| datalists can draw outside of the browser window, which is
| fantastic, but also probably means that there are security
| considerations for letting it be styled by users. Imagine
| malicious ads/websites being able to draw outside the browser
| window.
| iamflimflam1 wrote:
| That's the problem with most of these things, half assed
| implementations that just tick the box of "compliant with a
| standard".
|
| There's a reason why we have all these frameworks built on
| top of HTML - it's because the browser manufacturers have not
| done their jobs.
| flagrant_taco wrote:
| That's am incentive alignment problem, browser vendors' job
| is ultimately to make money not improve the specs.
|
| Anyone that's interested can get involved in the specs
| process though. If anything it's web developers who haven't
| done our job there, it feels to me good specs are more our
| concern and responsibility than anyone else's.
| noelwelsh wrote:
| Extensibility is the problem here. Either you force everyone to
| use the a limited set of UI controls (won't happen) or you need
| to allow some way to create custom UI controls, which leads to
| JS (or some other programmable system).
| tannhaeuser wrote:
| > _I had heard of almost none of these HTML elements_
|
| I'm not disagreeing with the gist of your post, but come on,
| these elements have been around for ages. It's definitely on
| you to become acquainted with the basics before your HTML
| critic can be taken seriously ;)
|
| The post links to MDN (arguably the most useful short
| reference) but there is of course also WHATWG's HTML spec or,
| if that's too voluminous, SGML DTD formal grammars for WHATWG
| HTML 2021 and 2023 snapshots [1], as well as for the older HTML
| 5.x series.
|
| [1]: https://sgmljs.net/docs/html200129.html
| didntcheck wrote:
| <abbr> has always been interesting to me. I've been aware of
| it for as long as I can remember, since it's been in all the
| tutorials I remember reading as a teen, and other docs as I
| got older. Unlike some other forgotten elements, it's one
| that's clearly very useful, and yet I can count on one hand
| the amount of times I've seen it used in the real world (yet
| plenty of times where someone has reinvented it with JS)
|
| Likewise, image maps. Remember messing about with those when
| I was young, but Wikipedia is the only place I've seen them
| used. To be fair, the UX isn't great, and I've often ended up
| navigating to an article when I was expecting to view the
| image page instead
| pmontra wrote:
| Everybody was using imagemaps in the 90s because it was the
| only way to have multiple links over an image, something we
| wanted to do because without CSS we could not have a row or
| a column of buttons with fancy colors and fonts and placed
| where we wanted them to be. So nav bars were a large image
| with imagemap anchors placed over the buttons. Then we got
| CSS, tables (used for layout!), divs with positioning and
| eventually the features that web developers are using
| today.
| mattmanser wrote:
| Most of them don't work properly and/or look terrible by
| default in all browsers.
|
| So no-one uses them, so lots of people don't know about them.
| geysersam wrote:
| What do you mean with "they don't work properly"? Could you
| give an example?
| TheFlyingFish wrote:
| When I use the datalist element with a text input, Chrome
| shows an arrow on the right and the list drops down when
| you focus the input. Firefox, however, shows neither
| until you start typing, at which point it suggests just
| those items that match your input. So there's no way to
| see the full list of options.
|
| I think Chrome's behavior is correct here, but the larger
| point is that precisely _because_ these are native
| elements, when they don 't work there's _nothing you can
| do_. So your only option is to reimplement them from
| scratch.
| iamflimflam1 wrote:
| Datepicker was fundamentally broken in many ways in
| safari for a long time. And it still doesn't have the
| functionality that most apps need, so it's pretty
| pointless.
| vanarok wrote:
| https://qutebrowser.org
| klardotsh wrote:
| 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.
| EspressoGPT wrote:
| > I had heard of almost none of these HTML elements, and that's
| such a shame
|
| I guess, that's on you - if you're a web developer, you
| definitely 100% need to know these elements. They're not new.
| jamamp wrote:
| You might like this: http://youmightnotneedjs.com/
| liam_ja wrote:
| You might not need JS, but you will need a SCSS transpiler.
| flagrant_taco wrote:
| Seems like aot of people misunderstand what these examples
| are best for. Sure you wouldn't want to ship these as-is on
| most sites, but it shows how much can be done without JS.
| That can/should make it more clear that you can likely get by
| with much less JS when you do need to reach for it.
|
| It's not about throwing out JS, it's about avoiding 30kb of
| JS if all you need is a few summary/detail elements where
| only one can be opened at a time. Use the example code here
| then write a small I line script that closes all siblings.
| Done.
| klabb3 wrote:
| Hahaha wow I have to say that was the least convincing demo
| I've seen.
|
| - Fills history with massive amounts of entries, and back
| button doesn't do anything
|
| - Slider UI look like crap (ok fine, can be fixed) but use
| not just css but SCSS (requires a precompiler) but wait, not
| enough, it also needs hardcoded number of images. It's not
| reusable in the most basic sense.
|
| - Input validation has phone number on xxxx-xxx-... format
| and doesn't fill dashes automatically. It's also type=number
| which opens a numpad on iOS which does not have dashes
| available at all. I can't proceed unless copy pasting a dash
| from somewhere else?
|
| - Gave up after that but I'm sure there's plenty more
|
| Yeah, I'm leaning towards that JS isn't the nemesis of
| accessibility. It's simply not knowing what works and testing
| properly. It's funny that frontend folks are seen as lesser
| beings and then counter-claims like this is passed as
| enlightened. Yeah on first glance maybe, but it's proof that
| these regurgitated claims are made with very little insight.
| Like all tech, you have to know how to hold it right which
| takes a little time and humility to get right.
|
| And yes, we still use too much JS. But it's not the fault of
| JS or dev practices that we have newsletter popovers, cookie
| banners and 100 ad delivery and click tracking requests per
| page load. Indeed JS became extremely bloated for a while but
| nowadays everything is equally bloated, just look at all the
| backend snake oil with 1000 cloud microservices and leftpad-
| like APIs.
| Freedom2 wrote:
| I disagree. I've built entire sites that rival the most
| popular SPA's today with HTML / CSS and a tiny bit of JS,
| and I've had less issues with those than other sites at my
| agency built with a JS framework. User reports often come
| in telling me "Wow, this site is so good! I'm really glad
| you took on this project".
| toastal wrote:
| Beware: some of these are effectively hacks possibly messing
| up the browser history or introducing accessibility issues
| for screen readers, keyboard users, or otherwise.
| o1y32 wrote:
| Exactly.
|
| Level 0 developer: don't know how to do this in JS Level 1
| developer: knows how to do things in JS, even when
| sometimes it should not Level 2 developer: knows how to do
| things without JS Level 3 developer: knows _when_ to use JS
| and when to use CSS or something else to achieve the goal
| toastal wrote:
| I was more the opposite. I avoid learning JS for as long
| as possible since it seemed so complicated following the
| resources I tried to learn.
|
| Ideally we'd have just a few more semantic elements that
| are obvious common patterns introduced to the HTML spec
| (like details & dialog were). We're pretty close now, but
| I would like to see better accessible no-JS options for
| building menus.
| lelanthran wrote:
| 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 horizontal
| scrollbar just won't show until you interact with the
| keyboard in some way).
| oneeyedpigeon wrote:
| Yeah, seriously bugs me too. Scrollbars were one of the
| most powerful, useful UI components out there, and we had
| to sacrifice them because of mobile, for some reason.
| bbarnett wrote:
| 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.
| toyg wrote:
| FF devs have to justify their jobs like any other.
| Someone was promoted for shipping a fancy-looking feature
| that some other browser, somewhere, probably has as
| default.
|
| Still better than the Borg, at least you can fix it.
| o1y32 wrote:
| I guess you never used MacOS, where the default system
| scroll bar behavior is even more interesting.
| teaearlgraycold wrote:
| A good resource for developers targeting the tor browser set
| to secure mode.
| onion-soup wrote:
| _Rumble about nothing_
| cratermoon wrote:
| The <i> vs. <em> thing, how did I never realize that before? I
| guess I'd never thought about them having a semantic meaning.
| xp84 wrote:
| Same. This is mind-blowing! And just goes to show how different
| "markup" is _meant_ to be from "formatting." Not that you'd
| know it when so much content is made by people using a WYSIWYG
| editor that basically tells them "you are doing formatting."
| lmm wrote:
| They don't. Like, that linked document is a cool idea but it's
| utterly inaccurate as a description of how the tags are used by
| actually existing website or handled by actually existing user
| agents (yes, including screenreaders).
| cratermoon wrote:
| Perhaps the tags have not been _de facto_ treated
| semantically by existing practices. There's a great deal
| wrong with the tag soup pervading the web. Current convention
| doesn't mean they can't have semantics.
| lmm wrote:
| Potentially they could have semantics in the future, but
| right now they don't. If you make a user agent that relies
| on them having those semantics, that user agent will
| misinterpret a lot of web pages.
| 7373737373 wrote:
| A while ago there was this VR program called JanusVR where rooms
| were specified using custom HTML tags
| (https://janusxr.org/docs/build/introtojml/index.html)
|
| Links are represented as portals, and unlike in VRChat you can
| just walk straight through them like in the Portal games -
| allowing one to "walk through the web":
| https://youtu.be/jYQtAcQddRg?t=48
|
| Now, language models can generate HTML, and I feel this may be an
| opportunity to revive it again. To generate VRChat rooms, you
| have to learn Unity, which is heavy and has a steep learning
| curve. But if you can go from a text description to HTML, then
| you just need a text file!
|
| It's a great alternative to the walled gardens
| skeeter2020 wrote:
| >> ... semantic HTML is more important now than ever
|
| Except... semantic HTML has _never_ been important. Forget about
| implementation and adoption, even the abstraction falls apart
| after about 30 seconds of critique. It 's a weird mix of
| structure-like tags that seem to solely serve the newspaper
| industry from 25 years ago, half-baked UI elements and a handful
| of directives. The non-semantic elements have to make up more
| than 99.9% of the internet today. It seems the author missed the
| of XML and transforms if this is what they wanted.
| dbbr wrote:
| I see a King Gizzard reference in the wild, I upvote.
|
| Gila!
| sproketboy wrote:
| [dead]
| voydik wrote:
| Now I want to listen to King Gizzard.
| NovaDudely wrote:
| Eeyup! Whooo! _reverb noise_
| catskull wrote:
| Also check out Gizzhead.org - my site for tracking their live
| sets!
| NovaDudely wrote:
| Nice, I love it!
|
| That said, I live in Melbourne, Australia, so yeah they are
| considered a local group - information travels fast here to
| support them. That said, it feels like they perform more in
| the US than here!
| flobosg wrote:
| I went to one of their concerts during the "Infest the Rats'
| Nest" tour. It was... wilder than expected. (In a good way!)
| mkl95 wrote:
| > 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?
| politelemon wrote:
| Yep you can style it with background color:
| https://jsfiddle.net/wezkth43/
| robotresearcher wrote:
| 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.
| sham1 wrote:
| 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.
| enriquto wrote:
| > I don't know if it's exactly the same color.
|
| Why would you care? As long as it appears highlighted it is
| alright. Let people chose their own highlight colors, and text
| fonts, and everything.
| ezekiel68 wrote:
| > <iframe>
|
| > Just kidding.
|
| Worth the price of admission!
| jll29 wrote:
| HTML was designed as an SGML application for networked hypertext.
|
| As an alternative to what the original post posits, we could
| leave it for that purpose, and design another (now XML)
| application for user interfaces: windows, buttons, scroll bars
| (if desired), text controls (no I'm not talking about textarea
| for CGI), the kind of controls that Windows or X11+MOTIF provide,
| expressed as tags in a UIML (User Interface Markup Language).
| This would have the advantage that we could start from a clean
| slate, and the open source interpreter for this technology could
| be integrated into all Web browsers, so behavior would be
| identical.
|
| UIML would be designed as an XML application for networked
| software applications' user interfaces.
|
| Of course, you could execute them locally, too. There could be
| graphical UI designer of the types that already exist, e.g.
| Visual Studio would just write out a UIML as a new export format.
|
| Crazy idea? Actually, it's just applying the "Do one thing, and
| do it well." mantra to XML <-> XHTML + UIML instead of packing
| everything possible into one now-bloated markup language it was
| never designed to do. So if this comment had a title, it would be
| "I'm betting on Internet standards" (plural).
| pravus wrote:
| > XML <-> XHTML + UIML
|
| I agree with this idea. We need a toolkit standard for the web
| and to stop shoving application code into a document model.
| What's strange to me is that so many people have been trying so
| hard to either resist or deny this.
|
| The proposed solution is a non-starter, though. Anything
| involving XML is probably DOA for the web. I know I don't want
| to touch it. But something needs to fill this space because UI
| on the web is so god-awfully atrocious.
| mike_hearn wrote:
| It's been done many times. Mozilla had XUL. Internet Explorer
| had XBAPs (XAML Browser Apps) [1]. Android has an XML UI
| language. Java has FXML, which IMHO is the cleanest and nicest
| of the lot.
|
| It never works. Same reason as to why adding non-JS languages
| never works: because making a GUI toolkit or implementing a
| language is a huge amount of work, other browser makers refuse
| to get on board because it'd mean they're playing catchup. Then
| web devs refuse to use it, because not every browser supports
| it. The only acceptable way forward is to gradually glue lots
| of small things onto HTML, and see which ones get implemented
| by the others. Because this is such an incremental and random
| process you end up with a pretty inconsistent platform that
| lacks a lot of stuff you'd intuitively expect.
|
| [1] https://learn.microsoft.com/en-us/dotnet/desktop/wpf/app-
| dev...
| Zen1th wrote:
| Wouldn't that be XUL[1] ? It's been there since 1997 and never
| took off outside of Mozilla, so it was deprecated and removed
| in 2017. It wasn't meant for use in the wen directly as
| replacing an entire ecosystem with a completely different way
| of doing UIs would be close to impossible, all for small
| benefits.
|
| [1]: https://wiki.mozilla.org/XUL:Home_Page
| grumbel wrote:
| I would care more about markup if the browser would actually be
| able to do anything interesting with it, but for most part markup
| is a just a default style for an element, the semantic meaning is
| ignored. The <time> tag is about the last one I can think of that
| actually made a difference from the users perspective.
|
| There is also a lot of markup for really common tasks still
| missing, I'd like to see an <advertisment> and something to
| handle pagination at the browser level (rel="next" has been
| around for decades, but browser don't care). And more broadly,
| I'd really like to see much better support for long-form
| documents in HTML or at the very least native ePub support in the
| browser.
| lancesells wrote:
| So people want to make it easier for LLMs to ingest their work?
| I'm all for HTML but this article is confusing to me.
| klaplume wrote:
| I'd argue that the modern markup elements you're showing are
| still way off from what the Semantic Web (as Tim Berners-Lee
| proposed) would enable. Image the possibilities of an 'AI' if it
| could understand the relationships between data and not just be a
| statistical parrot like LLMs are. Combined with something like
| Solidproject, that give users back control over their data, THAT
| would be a major leap!
| marcus_holmes wrote:
| I use <details> a lot for debugging Go html templates.
| {{if .DevMode}} <details> <summary>Data</summary>
| {{.}} </details> {{end}}
|
| It's nicely unobtrusive when collapsed, doesn't mess up the page
| completely. Then expands to the full glory when needed.
| unsignednoop wrote:
| [dead]
| birracerveza wrote:
| I abuse the <details> element when I can. It's so neat, I don't
| know why it's not used more often.
| dgb23 wrote:
| You can use it for all sorts of things on web pages, including
| collapsible menues and such.
|
| Github markdown lets you use it too. People use it for examples
| and inline explanations.
| [deleted]
| inopinatus wrote:
| Mostly agree, but datepickers are still a problem. The range of
| user experiences is so broad, and sometimes so counterintuitive
| (fuck you in particular, Android), that I still hesitate to
| suggest a native date input.
| nicbou wrote:
| Gov.uk recommends against them. This should be enough to
| discourage most people.
| petepete wrote:
| There are some situations where date pickers do make sense,
| like when booking an appointment in the future - being able
| to see the day is useful. Being able to overlay the date
| picker with other information like days where you're free or
| when appointment slots are available makes them unbeatable.
|
| But, when asking for a date people know, like their date of
| birth, date pickers just slow people down and confuse them.
| User research has shown this repeatedly.
|
| https://github.com/alphagov/govuk-design-system-
| backlog/issu...
| jacksongalan wrote:
| What's with the spelling error in your disclaimer, grammer [sic]?
| Is that pedantic, or is it a joke? Or did you mean "'grammer"?
| merdaverse wrote:
| 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 <main> 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 <main>, <aside> etc.), very little sites use it
| properly. Even the fancy professional sites wrap all the page
| content, including navigation, footers and the like inside the
| <main> tag, which should only be for the main content of the
| page.
|
| If such a simple element can't be used properly, I have no hope
| for all the others.
| mkoubaa wrote:
| The same developers who misuse http verbs, no less.
|
| We shouldn't pretend that these things are contracts
| gbalduzzi wrote:
| There simply is no incentive whatsoever of using them
| correctly. I try to use them correctly but aside from the time
| spent in deciding what each element should be there were no
| differences at all
| berkes wrote:
| > 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 <footer>
| 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?
| johnnyworker wrote:
| 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.
| merdaverse wrote:
| The browser approach is best effort at rendering, rather than
| enforcing conventions.
|
| And I doubt that tooling can help with all the complicated
| ways in which HTML is generated (React, SSR etc). I was
| actually surprised at how underbaked editor support for CSS
| is in VSCode (the most widely used frontend editor). If the
| most modern tooling can't understand that a CSS variable is
| declared in a different file and autocomplete it for me in a
| .vue file, I get the impression that tooling is severely
| lagging behind the frameworks.
| jcpst wrote:
| I would love to just flip a switch in the browser dev tools
| and see html validation errors.
| renegat0x0 wrote:
| This page is missing verbose RSS link.
| lord5et wrote:
| Two questions: 1. How easy styling of these elements is? 2. What
| about browser support. Do all major browsers support them?
| PlatinumBench wrote:
| For any given feature, you can check https://caniuse.com/ to
| see the browser compatibility
| rado wrote:
| It's very easy and they are widely supported. Example:
| https://radogado.github.io/n-modal/
| [deleted]
| Knee_Pain wrote:
| As always, people almost never RTFM. When I see webdevs implement
| a hamburger menu with pure CSS I almost shed a tear.
|
| For the love if god, study your tools! (and not from SEO spam
| articles)
| aitchnyu wrote:
| I have been using JS widgets instead of datetime-local inputs
| because of patchy desktop browser support years back. In FF on
| Mac I noticed time widget with prefilled times in datalist
| doesn't work as intended. Should we still rely on the widgets if
| there are browser kinks?
|
| I also feel multivalued tag inputs also require JS widgets. Is
| there a pure HTML version?
| kerkeslager wrote:
| > 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'
| devjab wrote:
| I find it interesting that many of the comments here seem to view
| this as an anti JS article. To me a lot of these are going to be
| immensely useful tools in combination with the TS heavy
| frameworks we use for modern Enterprise App frontends, exactly
| because they are HTML native tools that aren't going to require a
| bunch of stuff.
|
| Like the meter tag, which I assume will replace every loading
| module we currently use in React when I get to work today because
| that is soooooooo much better than what we currently use.
|
| But maybe I'm just misunderstanding people, or the article in
| some way. But to me this is very interesting even if your entire
| frontend is basically all TypeScript like many larger
| applications are today.
| klardotsh wrote:
| I think (at least with my comment that's one of the kind you
| alluded to) my hope is that it replaces huge piles of
| JavaScript code. I have, sadly, no illusions of a JS-free web,
| but at least we could get rid of huge gobs of it and have more-
| standard UX that the system can help guide and shape (with the
| benefits that entails).
|
| It also enables a whole slew of new applications to be made
| that need _way_ less JS than we used to need. So while, sure,
| these might be in-place "upgrades" for existing Enterprise TS
| apps, the hope is that it'll allow shunning those Enterprise
| Frameworks entirely for net-new app development. Or at least, a
| boy can dream, right?
| devjab wrote:
| I've worked with Enterprise Frontends since the Mainframe
| CICS systems and I'm not sure why things like React and
| Angular gets such hate for Enterprise apps. I can't think of
| a single way of doing client server applications in an
| enterprise setting that's ever been nicer to work with. To be
| completely honest CICS was better than most GUI attempts from
| Java and C#, and it was a console UI.
|
| I'm not saying JS frameworks can't be overused. I'm not
| personally afraid of the page refresh, but it's not like it
| was a joy to work with websites before these enterprise
| frameworks.
|
| Maybe WebGPU and to some extend WASM (and whatever is going
| on with that) will change things, but probably not.
| treis wrote:
| Enterprises want stability and front end technology has
| been everything but stable.
| waihtis wrote:
| I'm personally betting on HTMX
|
| https://htmx.org/
| klabb3 wrote:
| 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. They may have some tricks up their sleeves these days
| to account for those issues. But those tricks would need JS.
| catskull wrote:
| If I had to architect a front end today, I'd start with HTMX.
| Very curious how far a HTMX+Deno stack could get you.
| infogulch wrote:
| 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.
| guggle wrote:
| This... <ul> {{range .Query
| `SELECT id,name FROM contacts`}} <li><a
| href="/contact/{{.id}}">{{.name}}</a></li> {{end}}
| </ul>
|
| ...reminds me of what we used to do in php3 days. That was
| convenient, performant and... unmaintainable. Am I missing
| something ?
| infogulch wrote:
| Who knows if it will be maintainable or not. Can you
| articulate why the php3 projects became unmaintainable?
| klabb3 wrote:
| You make good points. And these are different use cases,
| where one is simple client behavior where JS is suitable,
| whereas the other needs a round trip anyway.
|
| I wouldn't go as far as 99%. There are a lot of web apps
| where you toggle between panes, expand certain things, and
| so on. But I think you are still right in the sense that
| htmx is a very fruitful starter kit that can cover many if
| not most "boring" standard use cases.
|
| One thing is for sure, this SSR hydration shit show is not
| a good state of affairs. It's way too much complexity for
| what it does. And now you have to worry about reaching the
| same logical state from two different starting points.
|
| > 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
|
| This is cool, and indeed reminiscent of PHP. Cycle of life!
| guggle wrote:
| I also like htmx. But one day someone pointed me to unpoly,
| which I find better. So I'll spread the word here:
| https://unpoly.com/
| inktype wrote:
| > No more datepickers please!
|
| Don't be surprised that people don't use native date pickers when
| they can't be configured to display ISO dates
| Conscat wrote:
| Most websites I enter don't work well on mobile, but this one
| does!
| cassepipe wrote:
| I _really_ want to believe in the semantic web, I really want to
| believe in the ability of the browser to provide me with good
| default modules with a good default styling, but for now I just
| have to accept this is not the case. The fact that I have to
| think about labeling a input (why is this not an attribute ?),
| not being sure if I should use it as a wrapper of as a sibling
| with the `for=` attribute... and this is just the tip of the
| iceberg. For each tag, I have to learn the whole history of its
| development and make an inquiry about what 's the _right_ way to
| do it _nowadays_.
|
| We could have had nice things.
|
| _Ssssshhh, calm down, let go._
| jmull wrote:
| > For each tag, I have to learn the whole history of its
| development and make an inquiry about what's the right way to
| do it nowadays.
|
| That you have to learn the semantics of the tags is inherent in
| any semantic tagging system. If you don't like that idea then
| you fundamentally disagree with the idea of the semantic web.
|
| Of course, with any publishing system -- or any system at all
| -- you're going to need to learn how to use the primitives it
| provides to use it effectively, so this isn't really about the
| semantic web.
| flagrant_taco wrote:
| (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 more eyes on when specs could use an update to fix our
| replace some of these quirks.
| berkes wrote:
| > 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 `<template>` 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 experienced developers doing web-ui development for
| their job, 40+ hours a week. And they didn't know, not even
| realized, that HTML had them covered for loads of use-cases.
|
| Edit: I am no frontend-dev, so I have to look up everything
| anyway. Which is probably why I come across those "new"
| things easier.
| JyB wrote:
| I mean. Doesn't it always boils down to supporting all
| "old/different browsers" hence why all web-agencies have to
| use all those JS libraries that seamlessly abstract it all?
| chrisweekly wrote:
| This is one of the things I like best about Remix
| (https://remix.run) -- it leverages React in a way that
| "grounds" it in web fundamentals instead of piling on
| further layers of abstraction. Remix is refreshingly
| simple, and its docs are chock full of references to MDN as
| the more authoritative source for web platform APIs.
| VoodooJuJu wrote:
| >senior engineers flabbergasted by basic HTML & JS
|
| These are the people rejecting your job application.
| afavour wrote:
| Broadly, _broadly broadly_ I agree with you and I'm
| endlessly frustrated with the state of React-based frontend
| dev.
|
| But that said you really do get a lot more out of the box
| with these frameworks. Tailwind makes consistent styling
| far far easier. MUI helps with the same and also (often
| overlooked) has a lot of accessibility features built in.
| boredumb wrote:
| 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.
| tjpnz wrote:
| That would require accepting that the complexity
| merchants sold them a lie.
| syncbehind wrote:
| > complexity merchants
|
| I have never heard of this term before. But I do think it
| is quite apt. Is this an established concept (can I read
| more about it somewhere)? Or did you come up with it on
| the fly?
| Spivak wrote:
| But it does seem that no one enjoys actually building
| MPAs and that force is currently winning right now.
| boredumb wrote:
| Using your favorite language, a simple http
| listerner+routing and what ever HTML templating engines
| are supported, MPAs are simple and enjoyable to build.
|
| I think product people enjoyed pretending they were
| facebook for a while and decided the world needed more
| infinitely scrolling SPAs and forced a lot of people into
| having to use react and other frontend heavy frameworks
| to try to wrangle all the (often times brittle)
| javascript involved to juggle client state. I don't think
| we're better off as users or developers because of this.
| dimmke wrote:
| 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.what
| wg.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 some
| kind of tool that compiles down to "regular" CSS since
| 2006. That's 17 years. 17 YEARS.
|
| And there was no major announcement when it became
| supported, just a blog post:
| https://developer.chrome.com/articles/css-nesting/
|
| 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.
| chrismorgan wrote:
| > _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 2/3
| --caniuse.com is showing global support at 72.89%, and
| its methodology is _hopelessly_ broken for mobile
| browsers (treats all mobile Chrome /Android WebView as
| the latest version, which is _wildly_ wrong), quite apart
| from excluding browsers that block the StatCounter
| script, leading to particularly heavy undercounting of
| Firefox and general undercounting of more conservative or
| unusual configurations; so the true numbers on newish
| features are always _much_ worse than it suggests.
|
| For these sorts of features, if all browsers ship around
| the same time, you'll normally want to wait for about
| another two years before you start _depending_ on it.
| (When shipped out of sync, it depends--you'll encounter
| two-year-old Safari more commonly than six-month-old
| desktop Chrome, for example.)
| clairity wrote:
| 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.
| philistine wrote:
| Part of the slow adoption of ultra modern HTML tags might
| be that the divorce from Internet Explorer 6 to 10
| finished so recently that no one has bothered to update
| their knowledge yet. In my corporate environment, IE 11
| was removed only last year.
| treis wrote:
| 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
| berkes wrote:
| This anecdote was a "pixel perfect" HTML version of some
| figma design. I did some CSS tricks to style the
| `<details>` and was lucky the designer was lazy and never
| specified the styles of all the dialogs around date/time
| pickers (they weren't that important anyway).
|
| You can style a lot of these native elements. And where
| you cannot, I'd argue that's actually good. I've worked
| with designers who insisted that everything looked and
| feeled the way they had designed it. But I've also worked
| with designers who, when showed how the date-picker
| looked on IOS, OSX and even Gnome, were incredibly happy
| that finally there was design that just followed what the
| users were used to.
|
| Point being: it will vary. But I'm _certain_ we need all
| these JS UI-frameworks like MUI far less than we use
| them. I 'm _certain_ plain-old HTML, CSS and a little JS
| suffices far more often than it 's currently used.
| treis wrote:
| >You can style a lot of these native elements. And where
| you cannot, I'd argue that's actually good. I've worked
| with designers who insisted that everything looked and
| feeled the way they had designed it. But I've also worked
| with designers who, when showed how the date-picker
| looked on IOS, OSX and even Gnome, were incredibly happy
| that finally there was design that just followed what the
| users were used to.
|
| The native browser date picker is very limited. You can't
| do basic things like disable weekends or select a range
| making it unsuitable for a wide swath of usecases.
|
| >Point being: it will vary. But I'm certain we need all
| these JS UI-frameworks like MUI far less than we use
| them. I'm certain plain-old HTML, CSS and a little JS
| suffices far more often than it's currently used.
|
| These UI frameworks are just plain-old HTML, CSS, and a
| little JS. All conveniently built for you to easy build a
| site that looks pretty good and covers most UX needs.
|
| >This anecdote was a "pixel perfect" HTML version of some
| figma design. I did some CSS tricks to style the
| `<details>` and was lucky the designer was lazy and never
| specified the styles of all the dialogs around date/time
| pickers (they weren't that important anyway).
|
| If you had used MUI you wouldn't have had to do CSS
| tricks and if it's using a small fraction of MUI then
| treeshaking will result in a negligible amount of JS/CSS
| sent over the wire. So no real performance gain, harder
| for the next engineer, and no great path forward if the
| UI needs to be snazzier. It's just worse all around than
| picking one of the well known frameworks.
| Freedom2 wrote:
| > The native browser date picker is very limited. You
| can't do basic things like disable weekends or select a
| range making it unsuitable for a wide swath of usecases.
|
| I think that you'd have to reevaluate your users and your
| use case then. As someone, like berkes, who builds sites
| almost entirely with HTML / CSS, it's often the case that
| the developer is RIGHT over what the user needs. After
| speaking to many clients about the limitations of native
| HTML elements, I've successfully convinced users to
| change negative browsing patterns.
| treis wrote:
| Why should I write my own HTML and CSS over using what
| Bootstrap gives me? I can't think of a single reason to
| believe that my HTML/CSS will look or perform better than
| Bootstrap's.
|
| Especially since you can selectively import only the
| components you use. You're essentially betting that you
| can like for like implement what Bootstrap gives you
| better than what they can. Which just seems like a
| terrible bet regardless of how good that particular
| developer may be.
| cassepipe wrote:
| That was indeed my point:
|
| Good defaults are the best but when you have bad defaults
| you might as well go for full-fledged well thought-out
| third party tools
| aargh_aargh wrote:
| 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.
| kethinov wrote:
| 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.
| treis wrote:
| Three things I think:
|
| (1) Unstyled HTML looks terrible.
|
| (2) There's relatively few native components and the ones
| that exist are limited. Like not even what JQueryUI gave
| you 15 years ago limited. No cards, accordions, avatars,
| and other sorts of basic building blocks.
|
| (3) No real support for common page layouts. Like a
| Dashboard or Hero marketing page sorts of things.
| cassepipe wrote:
| I am using svelte as it seems the best of both world, I can
| actually pretend I am just writing html and js where related
| pieces are colocated with a module system enough that it is
| actually readable while also harnessing my html and js/ts
| knowledge.
|
| And since js has to be minified there's a "compilation" step
| anyways.
|
| Didn't find a better solution so far. The web is almost nice
| to write code for.
| d357r0y3r wrote:
| 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, they're hosted applications that have a mind
| boggling amount of interactivity.
| kethinov wrote:
| 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.
| d357r0y3r wrote:
| Attitudes like what?
|
| How do you build Figma using "semantic HTML"?
|
| Everyone likes the idea of keeping things simple and
| using web native constructs. The problem is that web
| native constructs can't do the things people them to do.
|
| Even the progress bar example is a good one. Yes, there
| is a minimal progress indicator element shipped in the
| browser. It is completely useless for all but rudimentary
| cases.
| parasti wrote:
| For what it's worth, I've found that I almost always want to
| put the label tag after the input tag. That enables me to
| select and style the label based on the input state via CSS
| pseudoclasses.
| marcosdumay wrote:
| One more hack created by the lack of the :has selector. And
| yet browsers won't prioritize it.
| clairity wrote:
| safari and chrome have had :has() for a while, but it's
| behind a flag in firefox. the firefox version is good
| enough that i wish they'd unflag it already (as in, it's
| good enough to handle this particular input/label issue for
| instance, but not really complex selector combinations and
| edge cases).
| idoubtit wrote:
| > I have to think about labeling a input (why is this not an
| attribute ?)
|
| If input labels were html attributes, forms would be much less
| versatile. It would merge 2 visual elements into one, which
| would make it hard to adjust the display (think of inputs with
| right-aligned labels to their left, or checkboxes with labels
| to their right). And a "label" attribute would mean a plain
| text content... Seems awfully restrictive to me.
|
| Granted, HTML has a complex history and several layers, like
| anything that's been in use for decades. But it hasn't changed
| much recently, and (thanks, MDN) it's easy to learn learn
| enough to identify what is possible with HTML5 and dig later if
| necessary.
| cassepipe wrote:
| I don't understand the following. Would you be kind enough to
| elaborate ?
|
| >And a "label" attribute would mean a plain text content.
| masfuerte wrote:
| You can't put html elements in an attribute. It's just
| plain text.
| rchaud wrote:
| 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 <summary><details> 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.
| divan wrote:
| When browsers finally have full and first-class WASM ecosystem
| integrated (and ecosystem developed), we'll be looking back on
| this "pretend-that-HTML-is-an-UI-framework" thing with genuine
| horror.
| contravariant wrote:
| And the old timers will look upon the WASM mangled unreadable
| mess that webpages have become with equal horror.
| divan wrote:
| Web pages can still be in HTML. It's a bad choice for UI
| apps.
|
| (With current state of web ecosystem it's hard to tell the
| difference between what is page and what is an app, of
| course. But imagine we had a real choice on the outset of
| web.)
| [deleted]
___________________________________________________________________
(page generated 2023-08-02 23:01 UTC)