16 ms·

You don't need JavaScript for that

• caditinpiscinam 3y ago
  I bet you could use the <details> element to implement the show/hide comment behavior on hn
• raspyberr 3y ago
  This is literally the first of these articles where the examples work without JS. Everything else I've ever seen posted here usually has the snippets hosted on some CDN and requires JS to work.
• Alifatisk 3y ago
  The custom switch was honestly kind of impressive
  • deleted 3y ago
    [deleted]
  • syslog 3y ago
    From the UX point of view I very much prefer the oldschool way of „ticked“/„nonticked“ instead of „left/right“ switch.
    • jotaen 3y ago
      To me, they have slightly different semantics: I perceive the checkbox as “passive” form element (i.e., only to have an effect on form submission), whereas the toggle switch I understand as instant action (i.e., effectuated immediately, on click). Unfortunately, it’s not consistently used that way in practice, which makes the situation confusing at times.
    • pohuing 3y ago
      I wonder how much the culture you're used to matters for this. What if you grew up with right to left writing system. Should your switches have the off state on the right?
      • qingcharles 3y ago
        Britain has their light switches operate the opposite way around to the USA.
• rcbdev 3y ago
  This is anecdata but in my experience the way WebDev (esp. HTML and CSS) is being taught in academia is very crusty. I've seen Juniors enter the workforce with a solid understanding of table-based layouts from the 2000s for some reason.
  • spongeb00b 3y ago
    The other end of the spectrum: I’m seeing graduates with great knowledge of frameworks, but no understanding of the fundamentals that these are built on. It’s all fine until they’re trying to debug a problem and don’t know where to turn. glares at Tailwind
    • Zetobal 3y ago
      That's not a tailwind problem that's an educational one.
      • kristiandupont 3y ago
        I guess it's a sign of the domain expanding (exploding, really). "Software development" is not a single discipline, even though it's still taught as such in many places.
    • sensanaty 3y ago
      I mean you can't really use Tailwind if you don't understand at least some of the underlying CSS. It's not like it does anything magical for you, it just gets rid of having to give class names to things and has some nice little utility functions as well such as `grid-cols-x`.
• 11235813213455 3y ago
  I'm ok with window.prompt(), window.confirm() etc
  • kristopolous 3y ago
    I was disappointed it wasn't there. In my experience, managers will complain but the users don't actually care and just want something that works.
    • anamexis 3y ago
      They're mentioned in the dialog section.
  • troupo 3y ago
    Moreover, unlike dialogs they are immediately accessible. Dialog was rushed in without fixing many problems it has because Chrome (and apparently other browser, too) want to remove prompt/confirm/alert.
    • goatlover 3y ago
      Removing prompt/confirm/alert breaks the web for all sites making use of it going back to the JS 1.1, so that has to be a no go.
• tiku 3y ago
  The thing is, that sometimes javascript is a lot easier that 40 lines of css.
  • frognumber 3y ago
    Yes, but the 40 lines of CSS puts the logic in the right place. The point is that a person reading system logic shouldn't need to be distracted by layout, and a person worried about styling shouldn't need to think about code. Whether that matters depends on the specific system and the types of abstractions used, but it can be very important to making code maintainable, and in some cases, org structures practical (where the team maintaining the CSS might not be the same as the team maintaining the system logic).
    • sdflhasjd 3y ago
      The big thing you didn't mention is accessibility. Unless you know exactly what you're doing, just a few lines of javascript will let you break a user interface in so many subtle ways.
    • andrewstuart 3y ago
      >> puts the logic in the right place There’s no “right place”. It’s a web browser. You program it in whatever way you like that you enjoy that makes sense to you. Use whatever approach you need to get the job done. Mix and match. Come up with new ways. Do it simple. Do it sophisticated. Combine JS and CSS. It’s all valid. Don’t listen to people who try to tell you how to program.
      • rado 3y ago
        JS for UI is wrong, because there will be FOUC, and if you preload JS, the page will be slower. Of course, if something is impossible with CSS, JS is fine.
        • andrewstuart 3y ago
          >> JS for UI is wrong Yeah that’s showing an incomplete understanding of web application development.
• draw_down 3y ago
  [dead]
• frognumber 3y ago
  This was very nice! I will make an important nit. Keep in mind this is a nit. It's text in bold in the page, but this is NOT an attack on anything else in the article, which describes good design practices. There is no principle that one should "Choose the least powerful language suitable for a given purpose." This would, in fact, be an incredibly stupid principle. One want the most powerful language for any purpose. However, "purpose" is broadly defined: 1) We want code to be semantic. This allows a11y tools, search engines, and various performance optimizations to understand what's going on. 2) We want clean abstractions. In a horizontally-abstracted system, we would like the content designer to be focused on the content, the UX designed to be able to focus on the UX, and the back-end engineer to be focused on the back-end. (Note that, contrary to the beliefs of most people who have only worked on database-backed web applications, vertical abstractions are okay too, and break things up completely differently). 3) We want systems to be bug-free and understandable. This can leads to programming paradigms like functional programming + React, where no mutation is allowed. This isn't a random restriction which reduces power; to the contrary, it increases power by allowing predictable state, avoiding a whole class of bugs, and allowing debugging with time travel. In other words, you want good design discipline. However, the point here is much more on "good design" and not "discipline." Every one of the changes proposed can be derived from first principles from the above. But this does not come from some principle of "least power." To make this even simpler: Think of diet discipline. The goal isn't discipline about being hungry and eating yucky food. The point is about being healthy and losing weight. That probably involves being hungry and eating yucky food, but that's not the point. Food should be as tasty as possible and people should not be hungry to the extent goals on weight, heart health, insulin resistance, etc. can be accomplished. Same thing here. Languages should be as powerful as possible, while allowing goals around readability, introspection, a11y, abstraction, etc. to be accomplished. That requires very specific and narrow constraints on what one bans.
  • deleted 3y ago
    [deleted]
  • MaxBarraclough 3y ago
    > There is no principle that one should "Choose the least powerful language suitable for a given purpose." This is mistaken. https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power
• andrewstuart 3y ago
  >> Choose the least powerful language suitable for a given purpose. No. Choose what you like, what you enjoy, or what the boss told you to use. Ideally the project defines prioritize that give guidance. Otherwise do what feels right. Don’t follow some arbitrary doctrine.
  • tnbp 3y ago
    Do this only if you don't care about the people that use (sometimes: have to use) your software. Otherwise, >> Choose the least powerful language suitable for a given purpose. (Don't make me needlessly enable JavaScript to use your site.)
    • andrewstuart 3y ago
      >> Do this only if you don't care about the people that use (sometimes: have to use) your software. Rubbish. Web technologies are way too sophisticated to boil down to some silly rule of thumb that “the least powerful technologies are the” best in some way. As a professional developer, use every technology at your disposal and use it in whatever way you like, including the most advanced techniques. Ridiculous to be given the most one of the most powerful development tools ever made - the web browser - and artificially constrain how you use it for some dogma. And if you’re a junior developer, ignore people who tell you how you should program - do it how you like unless the boss says different.
      • tnbp 3y ago
        Your web app is most likely rubbish and 20 times as complicated as it needs to be, and probably still nothing special. A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript.
        • unsupp0rted 3y ago
          > A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript. Are users happy? Is dev speed of improvement good enough? Can you onboard new devs easily enough? That’s it. Nobody cares if you used CSS or JS for a toggle switch. The only people who disable JavaScript in their browsers and expect the 2023 internet to accommodate them are right here in this thread. Just componentize it and move on to solving the next business problem, not the next code elegance problem.
• thyselius 3y ago
  Nice. But the second switch doesn’t work on iPhone ( doesn’t toggle when I tap it)
  • deleted 3y ago
    [deleted]
  • Joeri 3y ago
    It is not supposed to, the code is completed in the third example.
  • alserio 3y ago
    they explain that it works but you need the next step to see it
• deleted 3y ago
  [deleted]
• mock-possum 3y ago
  > *The rule of least power* > It's one of the core principles of web development and it means that you should Choose the least powerful language suitable for a given purpose. > On the web this means preferring HTML over CSS, and then CSS over JS. Ah I totally do this, I never though to put a name to it besides taking the ‘minimal’ approach - if you can do it with just HTML, then by all means, just mark up some content and be done with it.
• deleted 3y ago
  [deleted]
• rado 3y ago
  So the unofficial (?) input:before is safe to use now, what's the consensus?
• seanwilson 3y ago
  > Of course, designers may not like the way this looks and we want to create a great looking custom switch. The general UI rule is use a switch when toggling has an immediate impact (similar to pressing a light switch) vs a checkbox when there's a submission step before it has an impact (similar to ticking a paper form then mailing it). See: https://www.nngroup.com/articles/toggle-switch-guidelines/ https://www.nngroup.com/articles/toggle-switch-guidelines/. It made sense after learning this but I didn't find the difference that intuitive before. A lot of UIs get it wrong (e.g. switches in forms, checkboxes for settings that immediately change something) but it only bugs me now I know which one to use. It's not only for cosmetics though.
  • kristiandupont 3y ago
    I personally had not heard this but it does sound intuitive to me. A checkbox is literally something you would check on a form (i.e. piece of paper) before handing it in. A switch on the other hand, it something that offers immediate feedback in the real world.
    • pavlov 3y ago
      It’s a useful distinction but frustrating to apply in practice because we don’t have a similar convention for many other UI elements like input fields and date pickers. You can’t tell at a glance whether these will produce an effect immediately after entering a value, or whether there is a separate submission action. In terms of primitive types and common UI platforms, we have this immediate/deferred distinction for booleans and enums. Booleans are represented by checkboxes vs. switches as already discussed. And enums are represented by radio buttons (the traditional form element) vs. multi-part buttons (which Apple calls segmented controls).
    • tgv 3y ago
      Idk. There are enough switches that don't have an immediately noticeable effect, e.g. when you have to open a panel to turn things on or off, or when you have to go to another room. It's always hard to come up with the perfect definition/metaphor, but perhaps it's more like an operation that has a lasting effect. But like designers shouldn't overdesign, we shouldn't overthink what's "correct" use. If it works and/or feels natural, it's ok. If it doesn't, it's time to consider alternatives, but you shouldn't implement them because some rule says so.
• montroser 3y ago
  I like the sentiment here, and the switch is cool, and summary/details is occasionally handy. But -- the datalist element is almost never a realistic option for anything more than a toy or prototype.
• arun-mani-j 3y ago
  My favorite "no JS, we have CSS" stuff are side bar (drawer) and carousel. DaisyUI (a TailwindCSS components library) has components readily available too :) 1. https://daisyui.com/components/drawer/ https://daisyui.com/components/drawer/ 2. https://daisyui.com/components/carousel/ https://daisyui.com/components/carousel/
  • egeozcan 3y ago
    How do you announce the drawer to the screen readers? For the people down voting: Drawers and other content that appear on the page needs to be announced and needs to have a state aria-expanded next to the controlledby. This is still a genuine question. Maybe there is a way, or maybe developers collectively think that's not important (our auditors would disagree but, anyway).
    • withinboredom 3y ago
      I believe it is announced as soon as you add it to the DOM and make it visible. I don’t have a computer near me to test it, but that’s what I remember when testing this stuff out a few years ago.
      • dawnerd 3y ago
        I’ve had to add a bunch of js to support this in the past when accessibility reports come back saying there’s no announce, mainly around css only dropdown navs.
        • withinboredom 3y ago
          Do you remember which reader software it was?
          • egeozcan 3y ago
            I'm not the person you're replying to but we test with NVDA, and we did have problems with some CSS-only solutions.
• chrismorgan 3y ago
  > Native smooth scrolling with scroll-behavior: smooth But please limit how you use this; it’s not actually a good idea most of the time you might think of using it, and often has undesirable side-effects. > Native carousels with scroll-snap, But carousels are still a bad idea, so scroll-snap is of extremely limited legitimate application. > Scroll driven animations Pages that do this are normally improved by removing it.
  • afavour 3y ago
    The point of the article isn’t to dictate what design elements people use, it’s to point out more user friendly ways of achieving those designs. Smooth scrolling is a great example. The native API allows a user to interrupt at any point. Most JS implementations are janky as all hell and users suffer. Scold design choices all you like but don’t expect to be listened to. Especially when you’re not providing any actual reasons why “carousels are still a bad idea”.
    • chrismorgan 3y ago
      > Especially when you’re not providing any actual reasons why “carousels are still a bad idea”. It’s widely understood and documented that carousels are a bad idea, and plenty has been written about it. (I should clarify that the problems are with carousels as a way of presenting diverse widgets; as a way of presenting a collection of pictures about a single item, it can be acceptable.)
    • ImPostingOnHN 3y ago
      > The point of the article isn’t to dictate what design elements people use, it’s to point out more user friendly ways of achieving those designs. If your goal is user friendliness, it would behoove you to use a design which is user friendly. Using a design which is user unfriendly and asking "how can I make this unfriendly design seem friendly" seems to be approaching the problem from the wrong direction: the design choice itself is the biggest contributor to user friendliness. Either you care more about yourself and your design choices than user friendliness, or vice versa, and both are totally valid options, but don't pick the former and claim the latter.
• cantSpellSober 3y ago
  > know that [outline: none] not a good idea Why recommend a style on summary:focus but not input:focus? Shouldn't we style :focus-visible for both or neither?
• afefers 3y ago
  The irony is using a JavaScript-based static site generator to make the site: https://www.11ty.dev https://www.11ty.dev
  • xutopia 3y ago
    Nothing ironic here. It's a different domain problem and they're using a different domain solution for it. The generator might simplify an otherwise much more complex problem down to its essence.
  • intrasight 3y ago
    Not so ironic now - as there aren't really good alternatives to a build step with a static site. But my opinion is that that may change now with the adoption of HTMX for static sites. There doesn't have to be a build step since you don't have to build full pages from their constituting parts.
    • uxp8u61q 3y ago
      You do realize that HTMX is a Javascript library?
      • intrasight 3y ago
        Of course I do
• redhale 3y ago
  I was unaware of Datalist, but it does not appear to work on Chrome Android, at least not really. I see the options in the keyboard [0], in the place where autocorrect suggestions appear. But that's the first time I have EVER seen that in a mobile web UI for a page's form control (aside from password auto-fill apps that use that same space). I don't hate it -- it's actually much nicer than trying to awkwardly scroll a poorly built custom JS drop-down. But I have no confidence that all normal users would figure out how to use it. So I think it's DOA for mobile. Also, it is flat-out not supported on Firefox Android [1]. [0] https://imgur.com/a/Ecb4503 https://imgur.com/a/Ecb4503 [1] https://caniuse.com/?search=datalist https://caniuse.com/?search=datalist
  • rymiel 3y ago
    This thing where the datalist options show in the keyboard is some recent thing, i.e. a few months ago. It used to be "normal" before that, but I guess someone wanted to change things only for the sake of changing things
  • 11235813213455 3y ago
    works fine on chrome android
  • from-nibly 3y ago
    This is why these solutions take so long to catch on. JavaScript is pretty well standardized, html and CSS is less so.
    • deleted 3y ago
      [deleted]
    • egberts1 3y ago
      CSS is easier than JavaScript. Here is an example of JavaScript-free CSS motion: https://egbert.net/blog/index.html https://egbert.net/blog/index.html
      • demosthanos 3y ago
• victorbjorklund 3y ago
  Really nice. Some elements I wasn't aware of. Will def come back to this.
• deleted 3y ago
  [deleted]
• revskill 3y ago
  My principle is always: The principle of the most power. I would use that to do simplest thing as possible, or i'm not afraid to do the best thing possible. Let's say you start with pure html, now how to decompose your HTML into multiple components with state ? Start with component-approach instead. Compiling to HTML is just the implementation detail.
  • deleted 3y ago
    [deleted]
• shadowgovt 3y ago
  In general, good advice. ... But the trade-off is lack of control, and that can be a problem. The author notes, but I think under emphasizes, that the color picker, for example, has no standard on how it should be implemented and so browsers are free to choose. The Safari color picker, in particular, is so bad that color picking is the one thing I recommend people absolutely roll a custom widget for, unfortunately. And, in general, if you go this approach you are trading off needing to care and feed for your own widget solution with needing at least a passing understanding of how the browser-implemented widget will operate in every browser that your team will choose to support actively. And the implementation spec for browser widgets is far more open-ended then the constraints placed upon a JavaScript implemented widget with assets you have created from scratch.
  • troupo 3y ago
    > The Safari color picker, in particular, is so bad What's bad about it? Can't test it on desktop right now, but on iOS it opens all the bells and whistles, including the "pick color from anywhere on the page". What used to be horrible across all browsers is the date picker: tiny buttons, tiny numbers etc.
    • jwells89 3y ago
      On desktop, the color picker in Safari has two stages: on first click it presents a 10x10 grid of colors with 10 extra basic colors on top, with a “Show Colors” button on the bottom that opens the macOS system color picker. This is actually a bit better than the picker implementations in other browsers because it gives the user a chance to use any colors they’ve saved in the system picker, as well as any color picker plugins the user may have installed.
      • shadowgovt 3y ago
        Yes, but tell that to my clients who keep telling me "Why can I choose any color in Chrome but in Safari I'm limited to a crayon box?" They either can't use color picker plugins or they can't figure out how to access them. And there's no language in the declarative API to, for example, start the user on the Mac OS system color picker.
• dhalucario 3y ago
  The datalist element didnt work for me on Mobile Firefox (Fennec)
  • xigoi 3y ago
    This has been a known issue for a long time. https://bugzil.la/1535985 https://bugzil.la/1535985
• allan_s 3y ago
  An other example of "you don't need js" carousel : https://www.codepel.com/demo/css-carousel-slider-without-javascript/ https://www.codepel.com/demo/css-carousel-slider-without-jav... there's an other comment posting a tailwind version , and I thought having a raw version would be helpful too that's the issue with raw things, as you don't need any library, they are not marketed and it's really hard to find them when libraries take all the first results
  • chrisweekly 3y ago
    fyi, "another" is a single word
    • allan_s 3y ago
      Thank you ! As you may have guessed English is not my first language.
      • chrisweekly 3y ago
        My pleasure. Grammar nitpicking tends to get downvoted (as happened here), but my intent is to help educate. Glad it helped!
  • internetter 3y ago
    This works terribly on mobile and broke my back navigation…
    • allan_s 3y ago
      Can you precise what works terribly ? On which mobile browser ? I m interrested as I plan on replacing our current carousels by this one for the "it broke the back button" isn't because it uses anchor so it works as expected for anchor , i.e you get to the previous anchor before going back ? (Which can be overrided by a line of javascript if you dont want that behaviour, but at least you can link to a specific slide of the caroussel )
• rudasn 3y ago
  Love this. I make heavy use of dialog elements on WireHub.org, along with bootstrap classes to achieve drop downs that work without JS and still look nice. Only issue is you have to click the summary element to hide the dropdown, and that's where I cheat a little and use JS to hide it.
• kichimi 3y ago
  [flagged]
  • deleted 3y ago
    [deleted]
• ptx 3y ago
  Great article! Very clear. Nice examples. I have some complaints about how Firefox handles these features, though. Closing modal dialogs with the escape key doesn't seem to work, even though it's described in the docs on MDN [0]. It does work in Chromium. Also, the native color picker in Firefox is really weird: The Custom/+ button triggers on mousedown, which feels surprising and disconcerting as a user. [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
• eigenvalue 3y ago
  Wish I had read this a month ago before I wasted hours fighting against some of these things in tailwind and JS. That color picker trick is awesome, and the styled toggle switch looks extremely slick.
• dmezzetti 3y ago
  100% agree that everything doesn't have to be JavaScript. You can do a lot with just HTML and CSS. My company's website is all HTML/CSS - https://neuml.com https://neuml.com
  • chupapimunyenyo 3y ago
    Nothing really impressive to be honest, that's just a basic site
    • dmezzetti 3y ago
      The point wasn't for it to be impressive. It's that if you want to keep it simple, you don't need JavaScript.
• eyelidlessness 3y ago
  Edit: my mistake, the first custom-styled switch example isn’t the full example. I realized that after I commented. Original comment below for posterity. It doesn’t apply to this case, but I think it’s still relevant as I’ve encountered the mistake I thought I was seeing in “you don’t need JS” contexts pretty frequently. In any case, sorry I misunderstood the example in the article. The custom-styled switch doesn’t work on iOS Safari. It certainly can work without JS, but this kind of mistake is potentially informative in evaluating whether it should. That’s not to say “if you want a custom-styled switch, JS is a better way to achieve that.” But if you’re already starting from the premise that HTML has a functional equivalent, it’s okay to use that for the default behavior and enhance it with JS to ensure it’s interactive when it’s enhanced with CSS to satisfy a non-standard design.
  • simonw 3y ago
    Did you try all of the custom styled switch example? The first one didn't visibly work for me on Safari but the others did - the examples are meant to build up a demonstration of the final pattern.
    • eyelidlessness 3y ago
      I was just coming back to edit my comment to acknowledge this. My bad! I think the principle still applies, because I have definitely encountered the mistake I thought I was seeing here. But it doesn’t apply to the example. That’s what I get for commenting before the morning coffee sets in :)
  • kilian 3y ago
    Author here. The first styled example doesn’t have the style to respond to the checked state. I explain that in the article right below the example.
• cfr2023 3y ago
  Good spirit, I was just recently seeking reference materials about how to execute an accordion style fold in pure html or CSS and discovered the approach you describe - so simple, we should be seeing it more often.
• dan-robertson 3y ago
  A nice thing about using <details> instead of JavaScript is that Ctrl+F can see into the details and open them up whereas it can’t open a JavaScript accordion.
  • matteason 3y ago
    hidden="until-found" will make this possible in JS-based accordions and other hidden content but is unfortunately only in Chromium-based browsers for now: https://developer.chrome.com/articles/hidden-until-found/ https://developer.chrome.com/articles/hidden-until-found/
    • remram 3y ago
      MDN compatibility table: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/hidden#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
  • agumonkey 3y ago
    Funny we just hit a similar issue while scanning for some docs..
  • remram 3y ago
    TIL, thanks for the tip! Do you know if there are other ways to hide but allow search?
• mediumsmart 3y ago
  [flagged]
  • deleted 3y ago
    [deleted]
• chiefalchemist 3y ago
  Actually, for accordion (i.e., details and summary), as I understand it, is not accessible out of the box. It's odd that the spec for that control / UI element / tags isn't accessible. But you can use JS to fix that. A colleague once shared a blog post with me on this but I can't find it atm.
• Eumenes 3y ago
  I wonder how inefficient web apps contribute to carbon emissions
• ulrischa 3y ago
  Other good example where no JS is needed: styling internal and external links
• joshstrange 3y ago
  > datalist I agree with most of these (I haven't played with dialog enough to have an opinion) but datalist is not a valid choice IMHO unless it's an internal tool. It's ugly, limited in what you can do, and not style-able. This is the problem with a lot of the "just use the built-ins" (looking at you date picker), not only are the defaults not great but you can't change them even if you want to. As soon as you hit one of the many brick walls when it comes to styling or changing behavior (Oh you want the week to start on Monday? Too bad) then your only choice often is to reach for a full replacement library that, yes, uses JS. I'm all for using the lighter-weight options and agree with HTML > CSS > JS hierarchy but sometimes JS is the only answer if you want to make your UI look nice and have the features you want.
  • theandrewbailey 3y ago
    I was implementing a search suggestion box, and thought that datalist could help. It works fine until you want to display options that don't strictly start with what's been typed in, e.g. if the input is misspelled, no options will show. There's no way to force it to display everything, so I opted for an ordered list instead.
  • gibbitz 3y ago
    Always worth noting that using JS to extend the built-in semantic markup is a future-forward approach. When I started working in web development, changes took up to a decade (IE6 held us all back, but the w3c was also fairly toothless back then). Now they happen quickly. Next year, datalists may be stylable in the big three without prefixing but you'll be beholden to your custom JS solution because business won't pay to rebuild. If you use JS to extend the native functionality you can always remove the JS at lower cost when the support is acceptable. Also with this approach, where the native controls are acceptable you can use it now and just apply the JS as a polyfil
    • escot 3y ago
      Are you aware of any frameworks that take this approach? For example, if I could import their Datalist and use it, but at build or maybe runtime it decides what to use based on the target environment? We of course have this for tons of things like language features.
• nonfungibleuser 3y ago
  Article has a typo, now instead of not. "In contrast to JS, which is imperative, HTML and CSS are declarative. You tell the browser what to do, now how to do it. That means the browser gets to choose how to do it, and it can do it in the most efficient way possible."
• throwaway81523 3y ago
  It's a step in the right direction but CSS is another tool of abuse by what Philip Greenspun called "artistes" to make unreadable pages. I'm not a proponent of Gemini but basically all aspects of layout and typography need to be returned to the browser, which must be controlled by the user. Designers have endlessly shown that they can't be trusted with it.
• toldyouso2022 3y ago
  I use them and doing so saves a lot of time developing. Problem is that managers will complain that they are too simple. At least that's my experience working with "enterprise" consultancies
• todotask 3y ago
  Some weird issue with <details> in Safari on iOS is that "open" attributes could disappear when iirc overscroll or something, so I was force to use JavaScript or disable overscroll behaviour.
• demondemidi 3y ago
  The answer is always: of course you don't. But weaving in clever HTML like this is a pain in the ass to maintain, when you can drop in a reusable, extensible widget for your framework that has already been debugged and is one line of code that everyone understands.
• CtrlAltmanDel 3y ago
  [flagged]
• demosthanos 3y ago
  The thing that this article is missing is that we use JavaScript in these places because compatibility is better. We can even use new JavaScript by transpiling, but polyfilling missing CSS and HTML is a lot harder to do and impossible in some cases (not to mention your polyfill will use JavaScript). `appearance` has a lot of caveats on MDN about testing it thoroughly if you're going to use it—even `appearance: none`. This may matter less if you only have to support new browsers, but keep in mind that old versions of Safari stay in circulation longer than you might think. `datalist` does nothing on Firefox Android. It just shows to me as an input box with no functionality at all (not even the suggestions over the keyboard that others report in Chrome Android). The color picker is neat, but extremely nonstandard, which is a dealbreaker for most businesses not just because the designers will complain but because customer support will find it harder to help people. Chromium provides the functionality to pick on a page and pick literally any color, but Firefox Android only gives me the rainbow, a gray, and black and white. The article itself acknowledges the inconsistencies with `details` and `dialog`. I hope we eventually get to a place where browsers that don't support these features (and support them consistently with each other) are no longer used, but in the meantime these elements will only find their way into my side projects, where I have full control of which browsers I support.
  • _the_inflator 3y ago
    I side with you. Sadly, the article itself is of no use and only a rant, since the “you” in “you don’t need” is not defined. Have fun checking for mobile, tablet, desktop, Android, Apple, Chrome, Firefox. It is not that developers rejoice over creating controls all the time. There is still html and css involved.
  • fingerlocks 3y ago
    > The color picker is neat, but extremely nonstandard When I press the button on my iPhone it brings up the actual system native color picker. It’s the same control that appears in dozens of apps because it’s provided by the OS. I much prefer that over some bespoke thing.
    • demosthanos 3y ago
• solatic 3y ago
  details / summary is an important hack when writing bots that post comments to GitHub PRs or issues, such that the details are hidden unless the user clicks on it, and thus helps keep the comments tidy instead of each comment being really, really long. It does, however, run into the 64Ki character limitation per comment. So HTML5 magic isn't by itself a magic panacea.
• kazinator 3y ago
  It has to be usable by users with ten-year-old browsers. Now what?
  • Minor49er 3y ago
    No it doesn't Your move
    • deleted 3y ago
      [deleted]
• timenova 3y ago
  Slightly off-topic, but just wanted to mention, the author of the post is the creator and developer of Polypane [0]. I've been using Polypane for the last few months (got a student discount with the GitHub Student Pack) and it's been amazing. It really helps speed up building light+dark mode, phone+desktop UIs quickly. I highly recommend opening Polypane on a second screen while developing any kind of web UIs. [0] https://polypane.app https://polypane.app
  • deleted 3y ago
    [deleted]
• agumonkey 3y ago
  The detail/summary element is a very common need, I had no idea it was so well implemented.
• corethree 3y ago
  I'd like it so that there's one thing that handles everything. I don't like it where there's react for complex stuff and then another pattern for simple stuff. It's hell either way. Just one thing that is simple and can compose to complex things. Not different patterns to handle different levels of complexity. Any api should be simple and compose-able into complex things. Here we have (react) which is not simple and not de-composable into simple primitives. ANd we have html without JS which isn't composeable into something more complex.
• wly_cdgr 3y ago
  I'm sure you can convince some people once "CSS programmer" starts generating hits on job site searches.
• MagicMoonlight 3y ago
  That toggley button is so good. The front-end meme developers in this thread are absolutely seething over this post but it's a good point. Why do we have all these stupid sites made in JS? If people just followed one standard like HTML, everything could be consistent and you could easily adapt it for things like accessibility or translation. You go on modern sites and the back button doesn't even work because it dynamically loads things all on a single page.
  • nijave 3y ago
    >If people just followed one standard like HTML, everything could be consistent That would also require browser creators to be consistent in implementation & you still have the "relying on people to update things" problem where it could be years after a new feature is introduced until it's widely enough supported to be useful I do tend to agree there are plenty of poor implementations and convoluted JavaScript contraptions. Afaik there's plenty of standardized solutions to keep back button functionality with dynamic content and afaik the popular web frameworks support that out of the box.
    • gibbitz 3y ago
      Well usually the framework requires a plug-in and the plug-in requires RTFM which not all developers do. Also these frameworks and their plug-ins change and have their own dependency management that can cause code rot in short order that leads to accessibility or functionality falling off quickly. The solution to this becomes smoke testing for these already solved problems. Standardizing on built-in behavior makes testing all of this functionality the responsibility of someone not on your payroll or Jira board. I get that this isn't always going to be the solution, but that doesn't mean our code still needs to follow patterns developed to support Internet Explorer.
  • nozzlegear 3y ago
    > The front-end meme developers in this thread are absolutely seething over this post but it's a good point. Are they actually seething? I've read the top comments on this post and don't see much that I'd describe as seething, just some people who bring up valid points about browser support.
• nfw2 3y ago
  Why is choosing the least powerful language for a given purpose a core principle of web development? If a language has flexible abstractions, it can make hard tasks possible, and ALSO make simpler tasks easier. Whereas a language with clunky mechanics makes simple tasks complicated and hard tasks virtually impossible.
  • yakshaving_jgt 3y ago
    For the same reasons that using fewer moving parts is a principle in engineering more broadly.
    • tgv 3y ago
      Friction and wear?
      • couchand 3y ago
        KISS.
    • nfw2 3y ago
      A language feature isn't a moving part. I would say that what makes a language "powerful" is the capacity to express complex concepts simply. CSS and HTML are not a languages built for expressing complex concepts at all
      • yakshaving_jgt 3y ago
        I think you’re familiar with metaphors and that this is a display of obstinacy.
        • nfw2 3y ago
          "Moving parts" is a metaphor for pieces of a system that add operational complexity, and it's not a useful metaphor in this case because a language just having some feature doesn't add any operational complexity
• joveian 3y ago
  Nice to see encouragement to avoid javascript :). Dropdowns that require javascript are particularly common (and unnecessary). It seems on Firefox, focus-visible only appears when tabbing, not when using the space key to toggle. Not sure why that is.
• jasonjmcghee 3y ago
  There sure is a lot of positive responses to this, and I get the draw of removing JavaScript. I usually find myself feeling more optimistic than the peanut gallery... But, at least on this device (Brave, iOS) some of the mentioned features just didn't work (e.g. emoji accordion) or were awful experiences. The autocomplete drop-down seemed very broken and both the checkbox and modal especially felt very sluggish. Like I would look for an alternative sluggish. I've had plenty of positive no-js experiences, but this wasn't it.
• eiiot 3y ago
  Notably, many of the features championed by this article just don’t (yet) work on mobile Safari. JavaScript is used because it (usually) works everywhere, unlike niche browser features.
• beders 3y ago
  Here we are in 2023 still battling with forms (see comments about datalist and color picker) and general UX for users entering data. It blows my mind. Why this isn't a solved space is beyond me. An attempt was made to tackle this once and for all with XForms, but it never got implemented in browsers. Instead we have virtually all CSS/JS component frameworks provide their own limited set of form elements with different semantics.
  • cjauvin 3y ago
    What would it mean for forms to be "solved"? They are solved if you want to stick to boring/vanilla technologies. They are not if you insist on solving them, once again, with React, and then again with React hooks, and again and again, ad infinitum.
  • mikeryan 3y ago
    The reason is not “solved” is that everyone has a different “problem” so it’s impossible to solve for all of them. Businesses solve for their use case using the the solution that fits their constraints. Having a multitude of “solutions” is a feature, not a bug.
    • 9dev 3y ago
      It’s not like a handful of form controls looking like Windows 95 and hyper-specific React form fields are the only options. Here’s an entire industry creating millions of components for basic fields; surely we can come up with better extensions and configuration, slots and styling opportunities that make life better for everyone.
  • hinkley 3y ago
    There are a few things a person could do that we can’t because of CSRF. Intent is not something you can work out programmatically, so we can’t have nice things in some situations. The last fancy form I worked on, I had to make sure the click event fired the form submit fairly directly so the browser would allow it.
  • Devasta 3y ago
• deleted 3y ago
  [deleted]
• hardcopy 3y ago
  In other news, you don't need a native app for that.
• amatecha 3y ago
  Relevant: https://enhance.dev/ https://enhance.dev/ "The HTML-first full stack web framework"
• LAC-Tech 3y ago
  Do any front end developers actually subscribe to the "rule of least power"? I was a frontend dev for a few years but I was stuck at the fringes because I wanted to do things as simply as possible. I always wondered if there existed some secret island of "least javascript possible" front enders, but all I found were "create react app is great, but do you know what would be even better? a tool on top of that to help us!".
• jddj 3y ago
  Well there you go. I've been using dialog a lot but every time I've been hacking some backdrop around/behind it. Had no idea about the property, that's great.
• oglop 3y ago
  Great read. We have been trying our best in the project I work on to rip out as much JS as we can and implement things using the right html tags among other things. Frankly, JS for an open source project used by thousands of users is a nightmare. This was a reason we have done our best to remove it and provide much more stable uses through yaml that then is used to construct the correct html rather than the spaghetti of JS from before. I’ve come to view JS with a lot of skepticism the older I’ve become. People are free to use it, but I do hope web assembly gives more choice in this monopoly, which I believe is the only reason people fundamentally use JS, though they will invent many reasons why “it’s great!”
  • demosthanos 3y ago
    Do you have a link to the FOSS project? I'd be interested to see the specific JS (and YAML) code that you're referring to. My experience over the years has been that the language and tech stack matter much less than the discipline of the team. Rewrites always feel like a huge improvement for the first few months, but as time wears on they become just as convoluted and bloated, either because the domain is inherently complex or because the team thought that the old tooling was to blame for their own poor coding discipline. I find it particularly interesting that YAML of all things is what you've turned to as an improvement. You'll find plenty of people on HN and elsewhere who've learned to avoid YAML like the plague because of bad experiences with it, so it seems clear that it's not objectively a better choice than JS for avoiding spaghetti.
    • oglop 3y ago
      If the admins using your project are sys admins, they seem to prefer yaml. Shrug. I hesitated posting just because I had a feeling this would not make sense. The project is for super computers and so it’s niche for the admins since they are overburdened at their centers and don’t have time or sometimes the expertise to role their own JavaScript to do advanced things with a form that is then used on the backend to submit jobs to clusters and apps on HPC systems. But this is a niche. My perception of the web dev space is it’s a mess and often has endless debates that do nothing for users, and much of the mess and debate centers around JS, a language that is the only choice (a monopoly) which then claims to be a great choice (how is that choice? Seriously, I’ve never understood that statement).
• 1vuio0pswjnm7 3y ago
  But need Javascript for advertising and tracking. If this is incorrect, I'm interested in any examples where Javascript is not used and what percentange of online advertising this comprises.
  • seabass-labrax 3y ago
    Last time I checked, Carbon Ads don't use JavaScript, although it is not a targeted advertising business. As for analytics, there is a considerable amount of personally identifying information you can collect exclusively with User-Agent headers in your sites' requests, and of course the age-old technique of tracking pixels still works in most cases.
  • chupapimunyenyo 3y ago
    Bear blog uses css for tracking Why do you need it?
  • deleted 3y ago
    [deleted]
• matheusmoreira 3y ago
  This is amazing. I'll be studying all of this and applying it to my site as appropriate.
• julienreszka 3y ago
  Designers hate native forms for some reason. (job insecurity?)
  • nfw2 3y ago
    Because they look bad and a designer has to make things look good
• araes 3y ago
  Couple items. - input type="checkbox" - It would be nice if this wasn't so janky to have a different look / function to your checkbox. Like some secondary type you could just apply, such as: subtype="toggle" or subtype="tristate" or subtype="cycle" Its weird you have to hide all the normal elements and then intercept all their functionality. - HTML "dialog" - I like the element, because of "dialog::backdrop", since applying effects to the background for a dialog helps with UI focus. "backdrop-filter: blur(4px)" is also pretty cool. It would also be nice if it "actually" behaved like a div. Tried implementing it on a project [1] with UI popups, and found out it displays different for show() and showModal() [kinda weird], and also has a massive hidden margin. Apparently "backdrop-filter" can be implemented on normal divs though, so gonna try that approach. [1] http://forsako.rf.gd/AmericanCities/LibOfCongressGame.html http://forsako.rf.gd/AmericanCities/LibOfCongressGame.html
• rfrey 3y ago
  "It's one of the core principles of web development and it means that you should Choose the least powerful language suitable for a given purpose." That's one of the core principles of web development? Why? I'm prepared to be embarrassed, like a "senior dev" who asks "uh, what's polymorphism?" but... I've never heard this "core principle" before and I've been doing web applications since DHTML displaced java applets.
  • rzmmm 3y ago
    I think the author might be referring to "Principle of Least Power" or a similar general programming trope which is more or less useful today, depending on who you ask. I.e. see this short write by Tim Berners-Lee https://www.w3.org/DesignIssues/Principles.html https://www.w3.org/DesignIssues/Principles.html
• Andrex 3y ago
  After a decade of personal exuberance building SPAs, I've been heavily trending towards HTML first/only for several years now. I had to kill my excitement for Web Components in the cradle because they (until recently?) don't support decorative HTML-only uses. In my mind there's a hard separation between website and web app. If you're just a site, you don't need JS and should only use it for progressive enhancement. Web apps I have no problem throwing a "You need JS to use this app" error. Use the right tool for the job. JS is an awesome hammer, but it sucks as a screwdriver.
• johnisgood 3y ago
  You can have modals with pure CSS and HTML though, that is how websites compatible with Tor do it. No need for JavaScript.
• shantnutiwari 3y ago
  The whole JS/npm/react world is a black box to me now. If someone told me I needed to sacrifice a chicken to get a website working I wouldnt be surprised...