29 ms·

I'm betting on HTML

• rado 3y ago
  Recently replaced 13 lines of inline SVG by a single <progress> element.
• barrenko 3y ago
  Kinda beautiful. More resources that focus solo on "modern" HTML + CSS?
• ivolimmen 3y ago
  This reminds me that I really need to re-evaluate the stuff I already know and keep it all updated.
  • leetrout 3y ago
    I am lost in CSS these days since letting my skills atrophy over the past ~decade
    • nathansherburn 3y ago
      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 3y ago
        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 3y ago
          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 3y ago
            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 3y ago
          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.
• pbohun 3y ago
  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 3y ago
    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.
• nzoschke 3y ago
  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.
  • nathansherburn 3y ago
    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.
    • resonious 3y ago
      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.
    • andai 3y ago
      My build system is cat!
      • WeAddValue 3y ago
        Meow!
    • irrational 3y ago
      Now move to the next level and have no build system.
      • em-bee 3y ago
• deleted 3y ago
  [deleted]
• kapitanjakc 3y ago
  HTML is that nerd who's rich now. Give me HTML,CSS,JS combo any day over some complex js library or platform.
  • netapy 3y ago
    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 3y ago
    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 3y ago
      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.
• anyfactor 3y ago
  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 https://github.com/anyfactor/Chatgpt_grammar_checker
  • billforsternz 3y ago
    The misspelling of grammer instead of grammar is a little ironic in this context. Sorry:-)
    • anyfactor 3y ago
      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 3y ago
        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 3y ago
      That was deliberate - if you view the source: ... then GPT-4 fixed my <span class="typo">grammer</span> and spelling
• klardotsh 3y ago
  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/ 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)
  • jamamp 3y ago
    You might like this: http://youmightnotneedjs.com/ http://youmightnotneedjs.com/
    • klabb3 3y ago
      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.
• cratermoon 3y ago
  The <i> vs. <em> thing, how did I never realize that before? I guess I'd never thought about them having a semantic meaning.
  • lmm 3y ago
    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 3y ago
      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 3y ago
        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.
        • cratermoon 3y ago
          I can create CSS to style the two tags accordingly, and in within my own work I can make them mean different things to the tools I use to create and manage html.
          • lmm 3y ago
            Sure. But you could always do that for any tags, regardless of - even in opposition to - their official semantics.
            • 3y ago
• voydik 3y ago
  Now I want to listen to King Gizzard.
  • NovaDudely 3y ago
    Eeyup! Whooo! reverb noise
    • catskull 3y ago
      Also check out Gizzhead.org - my site for tracking their live sets!
      • NovaDudely 3y ago
        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 3y ago
    I went to one of their concerts during the “Infest the Rats’ Nest” tour. It was… wilder than expected. (In a good way!)
• mkl95 3y ago
  > 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?
  • robotresearcher 3y ago
    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 3y ago
      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.
  • politelemon 3y ago
    Yep you can style it with background color: https://jsfiddle.net/wezkth43/ https://jsfiddle.net/wezkth43/
  • enriquto 3y ago
    > 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 3y ago
  > <iframe> > Just kidding. Worth the price of admission!
• devjab 3y ago
  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 3y ago
    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 3y ago
      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.
      • 3y ago
• waihtis 3y ago
  I'm personally betting on HTMX https://htmx.org/ https://htmx.org/
  • klabb3 3y ago
    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 3y ago
      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 3y ago
      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 https://github.com/infogulch/caddy-xtemplate I'm currently co-developing this with an rss reader webapp to work out the kinks.
• re-thc 3y ago
  Time for HTML6!?
  • tannhaeuser 3y ago
    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 https://sgmljs.net/blog/blog2303.html
• zmmmmm 3y ago
  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 3y ago
    > 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.
• p-e-w 3y ago
  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.
  • mmahemoff 3y ago
    Valid point. Ironically the main benefit of semantic markup is now an abstraction to help the human developers effect styling and control.
    • jraph 3y ago
      Isn't the main benefit of semantic markup still accessibility?
      • mmahemoff 3y ago
        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 3y ago
          But explicit, human-verified metadata is always going to beat inferred, fuzzily-extracted data, surely?
• delta_p_delta_x 3y ago
  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-mono/datasheet/DX-102-10.pdf https://cdn.berkeleygraphics.com/static/typefaces/berkeley-m...
  • catskull 3y ago
    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?
    • delta_p_delta_x 3y ago
      It looks like they do! Maybe there's some option to select it. I haven't bought it yet, so I can't test it...
  • irrational 3y ago
    Thank you! I was wondering why the font looked so wonky. It looks much better now.
• bingemaker 3y ago
  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 3y ago
    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 3y ago
      > Section and article really don't add any value They are nice hints to assistive technologies and reader mode.
      • flagrant_taco 3y ago
        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 3y ago
          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.
• shantanujoshi 3y ago
  So down for this. Feels intuitive. JS is dead. Superconductors at room temp. WERE BACK
• koito17 3y ago
  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 3y ago
    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/summary https://developer.mozilla.org/en-US/docs/Web/HTML/Element/su...
• marcus_holmes 3y ago
  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 3y ago
    [dead]
  • dgb23 3y ago
    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 3y ago
      [deleted]
  • birracerveza 3y ago
    I abuse the <details> element when I can. It's so neat, I don't know why it's not used more often.
• deleted 3y ago
  [deleted]
• Knee_Pain 3y ago
  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 3y ago
  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?
• Conscat 3y ago
  Most websites I enter don't work well on mobile, but this one does!
• adamredwoods 3y ago
  >> 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 3y ago
    Machine-readable here also means screenreader-readable
• rado 3y ago
  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/ https://www.skrill.com/en/currency-converter/ – no libraries needed.
• inopinatus 3y ago
  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 3y ago
    Gov.uk recommends against them. This should be enough to discourage most people.
    • petepete 3y ago
      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/issues/42 https://github.com/alphagov/govuk-design-system-backlog/issu...
• jillesvangurp 3y ago
  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.
  • beej71 3y ago
    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 3y ago
      Sub 10MB? That's a whole YouTube video!
      • beej71 3y ago
        My home page, which admittedly doesn't contain much, is 11 KB. :)
  • zelphirkalt 3y ago
    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.
• vermilingua 3y ago
  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#i_vs._em https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em... [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em#examples https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...
  • andai 3y ago
    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 3y ago
      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 3y ago
        Made me read https://www.w3.org/International/questions/qa-b-and-i-tags 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.
• komali2 3y ago
  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?
• nsonha 3y ago
  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.
• kabes 3y ago
  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.
• backtoyoujim 3y ago
  If you don't want rounded corners then what's this all been about ? What am I working toward ?
• lord5et 3y ago
  Two questions: 1. How easy styling of these elements is? 2. What about browser support. Do all major browsers support them?
  • PlatinumBench 3y ago
    For any given feature, you can check https://caniuse.com/ https://caniuse.com/ to see the browser compatibility
  • rado 3y ago
    It's very easy and they are widely supported. Example: https://radogado.github.io/n-modal/ https://radogado.github.io/n-modal/
• inktype 3y ago
  > 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
• azangru 3y ago
  > 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-the-semantic-web/ https://shkspr.mobi/blog/2023/05/does-ai-mean-we-dont-need-t...
  • fauigerzigerk 3y ago
    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.
• nologic01 3y ago
  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 https://en.wikipedia.org/wiki/WHATWG
• irrational 3y ago
  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.
• yieldcrv 3y ago
  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.
• robobro 3y ago
  I only recently stumbled across <details> and I have to say, it's cool to have that available in vanilla HTML.
• SoraNoTenshi 3y ago
  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 3y ago
    > 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 3y ago
  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/1peUSMsvFGvqD5yKh3GprskLC3KVdAlLGOsK6gFoEOD0/edit?resourcekey=0-bPajpoo9IBZpG__-uCBE6w#heading=h.s6balucy11bi https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... [1] https://news.ycombinator.com/item?id=36968263 https://news.ycombinator.com/item?id=36968263 [2] https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696
  • troupo 3y ago
    > 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 https://github.com/mozilla/standards-positions/issues/459
• teekert 3y ago
  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 3y ago
    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.
• jll29 3y ago
  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).
  • Zen1th 3y ago
    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 https://wiki.mozilla.org/XUL:Home_Page
  • pravus 3y ago
    > 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 3y ago
    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-development/wpf-xaml-browser-applications-overview?view=netframeworkdesktop-4.8 https://learn.microsoft.com/en-us/dotnet/desktop/wpf/app-dev...
• SPBS 3y ago
  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 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.
  • Kiro 3y ago
    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 3y ago
      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?
  • contravariant 3y ago
    You can show or hide it depending on the current hash. Though admittedly that does require CSS.
  • aaviator42 3y ago
    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/ https://aavi.xyz/proj/colors/
• divan 3y ago
  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 3y ago
    And the old timers will look upon the WASM mangled unreadable mess that webpages have become with equal horror.
    • divan 3y ago
      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.)
• grumbel 3y ago
  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.
• DigitalSea 3y ago
  The real solution is Web Components.
• cassepipe 3y ago
  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.
  • flagrant_taco 3y ago
    (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 3y ago
      > 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.
      • afavour 3y ago
        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.
• aviavinash 3y ago
  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?
• asim 3y ago
  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 3y ago
    Wow, thanks for the nightmares.
• klaplume 3y ago
  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!
• merdaverse 3y ago
  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.
  • berkes 3y ago
    > 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?
    • merdaverse 3y ago
      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.
    • johnnyworker 3y ago
      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.
• DrStartup 3y ago
  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?
• sourcecodeplz 3y ago
  What's wrong with <iframe>? I find it quite useful.
• qwerty456127 3y ago
  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 3y ago
    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.
    • nologic01 3y ago
      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.
• sensanaty 3y ago
  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.
• lancesells 3y ago
  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.
• sebastianconcpt 3y ago
  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.
• onion-soup 3y ago
  Rumble about nothing
• YLYvYkHeB2NRNT 3y ago
  the AI disclaimer put me off from reading it. I want to hear your words, not ChatGPT
• rchaud 3y ago
  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.
• chickenfeed 3y ago
  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.
  • Technotroll 3y ago
    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.
    • 3y ago
• omgmajk 3y ago
  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 3y ago
    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 3y ago
      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.
• happythebob 3y ago
  Upvote for King Gizzard
• renegat0x0 3y ago
  This page is missing verbose RSS link.
• ur-mom 3y ago
  [flagged]
• maxfurman 3y ago
  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 3y ago
    I've been doing web dev for over 20 years and just discovered and used datalist
• skeeter2020 3y ago
  >> ... 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.
• btbuildem 3y ago
  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 3y ago
    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.
• jerf 3y ago
  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.)
  • tomlue 3y ago
    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 3y ago
      If you're relying on a stochastic process like network weights to encode truth then I have some oil to sell you.
    • jerf 3y ago
      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. :)
• the_king 3y ago
  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.
• giardini 3y ago
  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.
• beders 3y ago
  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.
• sproketboy 3y ago
  [dead]
• kerkeslager 3y ago
  > 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'
• willio58 3y ago
  <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.
• vvpan 3y ago
  The argument of the piece completely eludes me. How would HTML disenfranchise walled data gardens?
• pphysch 3y ago
  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.
• dbbr 3y ago
  I see a King Gizzard reference in the wild, I upvote. Gila!
• gyudin 3y ago
  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.
• 7373737373 3y ago
  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 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 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
• jacksongalan 3y ago
  What's with the spelling error in your disclaimer, grammer [sic]? Is that pedantic, or is it a joke? Or did you mean "'grammer"?
• deleted 3y ago
  [deleted]
• coldtea 3y ago
  >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).
• dahwolf 3y ago
  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.
• nektro 3y ago
  literally the worst reason to use semantic html. which is sad because there are so many good ones
• mmwako 3y ago
  I would really really like to see a full-blown retro-looking social network (say, a Twitter/X clone), that works solely with pure HTML. It would be really amazing.
• tfcwebdesign 3y ago
  You misspelled grammar. I only say this because you said you used AI for proofing and then you edited your doc.
• mycryptolord 3y ago
  [flagged]
• jitbit 3y ago
  Every time I decide it's finally time to use HTML5 native inputs like `<input type="date">` instead of JS-datepickers, I stumble on so many problems. No "placeholder" attribute support, no "show picker on focus" functionality, etc. You end up including so many JS/CSS hacks and workarounds that you're back to having a huge datepicker.js file.
• orenmizr 3y ago
  everything good in development makes it eventually(!) into the "Elementals" HTML+JS+CSS. BUT still PUG > HTML any day of the week.