Hacker News Reader

Comment by ctvo | Hacker News Reader

I've worked with people who did things like this. It's not fun for anyone else on the team to try and figure out why you're using specific pseudo selectors on tags in a child inside a sibling in some label to make an accordion that would take 3 lines in Javascript.

View on HN

I'd agree with the sentiment, but for a different reason. I think the method can be useful and maintainable, but, the problem with this implementation seems to be a mix of design (font colors, sizes) and functionality, and a lack of documentation.

Splitting the CSS into two distinct pieces (or better: files, but I realize that's a limitation of jsfiddle) would go a very long way to making this technique maintainable. Having documentation that then shows the required HTML structure and the necessary classes to add would help immensely.

Essentially, build it like a UI library that just happens to be written in CSS.

Right now, it's just a demo of a technique that's not built in a reusable way, and you need to be pretty decent with CSS in order to understand and use it (since you pretty much have to re-implement it every time you want to use it). To be fair, the HN submission and site don't make any claims it's anything but this.

Using HTML5 tags such as <details>, you don't need CSS or JS!

Try this in Chrome: https://jsfiddle.net/timdavila/f5rcarmn/

Unfortunately this is not yet supported in any version of IE, including Edge.

So I didn't try it in Chrome, and it doesn't work in Firefox, yet. But I can see where this is going and it would be awesome if it actually worked.

On an encouraging note, it does work in Firefox Nightly (50.0a1).

Whoa. I learn something new everyday...

It's defined in HTML 5.1, which is still Candidate Recommendation.

You never know when you're going to be stuck on a desert iframe with only CSS, and no access to JS...

I'm reminded of the Jurassic Park quote when I see people doing "neat" complicated CSS hacks to do stuff a line of JS would do...

"Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should."

For some reason I hear that in my head in Jeff Goldblum's voice

Probably because he said it.

Your complaint is essentially that they are using a language that other people working on the same project don't know. There are good reasons to discourage that: it fosters bikeshedding, and CSS's ways of expressing dynamic behavior doesn't match intuition as well as procedural javascript. However these reasons have to be weighed against technical limitations. Using CSS for dynamic behavior is often better than using javascript because many more people disable javascript than CSS. If the project requires javascript for some other important part of the page, then it's not worth the complexity of specifying dynamic behavior in CSS. But if all parts of the page work well without javascript, then introducing a dependency on javascript for something like an accordion is probably not rational if you have someone who knows how to achieve the same effect with CSS.

Lets be honest, 99% of people who disable javascript are programmers who take great honor in complaining about every website that is more than 200k in size. This is a non-issue for most companies.

You're getting the wrong impression of those who disable javascript. Yes, they tend to be programmers, or otherwise tech-minded, because they have to know what javascript is, know how to disable it, and (most limitingly) understand the reasons for doing so. And naturally, if you disable javascript, you're going to be annoyed when sites don't work, going to consider the trend of requiring javascript regressive, and going to publically complain in the interest of promoting the health of your own profession. Notice that "taking great honor in complaining" is not the underlying cause of disabling javascript but rather an effect. The actual motivations vary.

I started disabling javascript since every site these days includes a gazillion badly crafted scripts that take up too much cpu. It actually brings my laptop to a grind

(when having lots of tabs open)

Anecdotal evidence: I have no problems having more than 200 tabs open on a Thinkpad T60 – as long as any JavaScript is disabled. Enabling JavaScript makes such a thing hard; there exist web pages that raise CPU temperature by more than 10°C.

If we're being honest, then no.

I'm interested in seeing these 3 lines of Javascript that can implement an accordion.

With a sane limit to number of characters on each line as well.

Here you go: http://jsbin.com/codedujeqe/edit?js,output

JS:

    var panels = [...document.querySelectorAll(".accordion li")];
    panels.forEach(x => x.addEventListener('click', e => 
      panels.forEach(y => y.setAttribute('class', 
        y == e.target && !y.classList.contains('open') ? 'open' : ''))
    ));

Minor nitpick: if you're using classList, you might as well also use it to toggle the "open" class (instead of y.setAttribute('class', ...)):

  y.classList.toggle('open', y == e.target && !y.classList.contains('open'))

As the behavior of what to do with the "open" class is only dependent on whether `y` is the clicked element, i find this version more readable:

  y == e.target ? y.classList.toggle('open') : y.classList.remove('open'))

Aaaand, it can be made less readable again by selecting the classList method to call conditionally :)

  y.classList[y == e.target ? 'toggle' : 'remove']('open')

Nice. Wasn't aware of the classList.toggle method.

Thank you, exactly what I was hoping to see instead of the usual arguments that don't actually fulfill the request.

With jQuery it's probably like 4 or 5 lines. With plain JS a few more as you have to write your own iterator function.

All an accordion does is add an event listener that removes a class from all elements and adds it back to one of them. Then there's a 1 line transition for that class in css.

Is jQuery included in those 4 or 5 lines? One line of CSS in your accordion?

If you had read the next sentence of my comments you would have seen that it would be a "few more lines" if you didn't use jQuery, basically you need a function like:

  function eachItem(arrayLike, cb) {
    return [].slice.call(arrayLike).forEach(cb);
  }

So 3 more lines. If I said you can write a very verbose accordion in under 20 lines would that be good enough for you?

>> So 3 more lines. If I said you can write a very verbose accordion in under 20 lines would that be good enough for you?

Since that's more realistic, yes that would do nicely.

Crap, can't edit.

Two others completed the accordion in 3 lines task without jQuery.

I'm not sure why the actual jQuery library matters here. Chances are if you're using jQuery for an accordion you're also using it for a lot of other things.

If one is already using jQuery - https://jsfiddle.net/jw75xznb/

Yeah, it's incredibly crude but it is 3 lines and it took approximately 60 seconds.

If it involves jQuery then it is not 3 lines. The original claim was 3 lines of Javascript. Making a claim something is only 3 lines of Javascript without including the fact that jQuery is required is a disservice to the many people that made jQuery the wonderful library that it is. That is the source of my disagreement.

You're being disingenuous. Firstly, "3 lines of Javascript" wasn't meant to be taken literally. Not only that but 73% of the top 100,000 websites use jQuery - if you are on a large web development project you are more likely than not using jQuery.

[1] http://trends.builtwith.com/javascript/jQuery

Since two others have completed the task with literally "3 lines of Javascript" then I'm not being disingenuous at all. I requested the 3 lines was given roughly the same example by two different people.

And I know the trends around jQuery, that was not the issue at all.

That isn't a disservice to jquery. The fact that people don't explicitly mention it could actually be viewed as a demonstration of its ubiquity.

No, it's people becoming not being able to know the difference between jQuery and Javascript. Calling either of them the other is a disservice to both.

I'm old. I wrote many, many, many lines of JavaScript before jQuery ever existed, I know the difference very well. Nobody is confused.

Ignoring the fact that it clearly wasn't intended to be taken literally, "in 3 lines of JS" when speaking in the context of a team effort on a web application can be understood as "adding 3 additional lines to the source code." Context.

There's no need to be nasty and argumentative for no reason.

>>If it involves jQuery then it is not 3 lines. The original claim was 3 lines of Javascript.

jQuery is JavaScript, so...

Jquery is many lines of javascript.

As pointed out, yes it is indeed Javascript. If you make use of it then you cannot claim your code is shorter in lines by choosing to not include the jQuery code.

I've written a couple of small jQuery plugins and I don't claim I wrote this awesome Javascript code that does this cool thing. I say I made a jQuery plugin that does this cool thing.

https://jsfiddle.net/e77f4hhz/

I think the real question is why are you making an accordion? They are ghastly UI components to navigate for the end user. I could see a few limited cases for them, but if someone says 'we will implement an accordion layout' at work, im jumping all over that screaming NOOOOOO.

Shouldn't pure CSS animations have better performance?

CSS animations are generally on par with JavaScript, except when they're hardware accelerated.

But that's changing once web animations (https://w3c.github.io/web-animations/) hits mainstream anyway - both CSS & JS get access to the same engine.

The point of CSS animations isn't HW accel - you get that just from layerization. What it does get you is animations executing off the JS thread, so if you have piles of third party JS it won't cause frame drops.

Right, which you also get via the web animations API (queue up animations, and have them run on a separate thread)

Good point.

If you use Wordpress, like millions of people do, you will have a fuck ton of JS plugins running, so I can see where this would be advantageous.

If you have a sane amount of JS (ie, not loading entire libraries to accomplish an accordion) the performance differences should be negligible.

The animation, yes, but not the trigger. You can balance this by adding / removing classes in javascript (to limit the complexity in CSS) and with the class performing the animation.

I think the best way to deal with that is to use a CSS processor (I prefer Sass). You can make a "mixin" (or whatever term your processor prefers) that accepts a selector and styles it. Still readable, still no JS required (if you want to go that route), and you can document the heck out of it. "Oh no, more tooling". Yeah, more tooling.

Sounds odd, your teammates are hardcoding extremely common page components from scratch, i.e. at least not an internal library/ module where you only write it once? That seems like the bigger problem you have.

If you only write it once and put it somewhere, among other advantages, you can document it easily.

You still need to write the initial block of code. Advocating for non-custom elements just because it already exists in Bootstrap or Foundation is an easy way out, especially for UI uses. It doesn't matter how an element was created as long as it's re-useable - there's nothing stopping you from handcrafting your own UI elements and re-using that block in your design system...

Do you know of a Github repo that implements these features in javascript? I would love to learn how.

Most of these (carousel, tool tips, modals, etc.) are in the very popular Bootstrap.

Reply on news.ycombinator.com