251–260 of 319 posts
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.
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.
If you only write it once and put it somewhere, among other advantages, you can document it easily.
Earlier quoted context omitted.
> I prefer using CSS for my styling and javascript for my functionality To play devil's advocate, though... is an accordion or a carousel "functionality" any more than, say, a drop-down or a multi-line input box is? I mean, the games examples are pretty wacky (in a cool but "thank God I don't have to debug these" way), but things like tabs and tree views are so ubiquitous that a case could be made for having standard…
> a case could be made for having standard HTML input tags for them. and for the accordion at least, the case was made and approved. check out and
Earlier quoted context omitted.
http://xkcd.com/869/ Anyone know where I can find publication dates for individual comics? I don't see anything on the comic's page.
The archive page -- http://xkcd.com/archive/ -- has each comic listed by title, with the publication date in the hover text. Server Attention Span was published 2011-3-7.
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.
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.
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' : ''))
));Earlier quoted context omitted.
> Ah! Also, nobody cares about unobtrusive JavaScript anymore. I do. I also care about graceful degradation. There are certain times (e.g. Web Apps like Gmail) where graceful degradation is almost impossible and unobtrusive JavaScript would be silly but those are the exception. Most sites on the web are just content and there's no reason to have excessive JavaScript or any reason why the page can't be perfectly funct…
Just because something can be done a certain way doesn't mean it should be done a certain way. Minimizing javascript for the sake of minimizing it is silly. People that disable javascript represent a tiny percentage of the population. No one is going to make engineering decisions based on that tiny percentage, anymore than people still target IE6.
- Page content doesn't need to be side-loaded in AJAX.
- Site layouts don't need to be set in JavaScript at page load. Animated menus don't need to be done in JavaScript and neither do pinned toolbars, doing so usually causes issues and stuttering when scrolling because you have a script running every pixel shift.
- Every link on the page doesn't need to be a JavaScript function, it makes bookmarking or opening in a new window difficult to impossible to what benefit?
- If you do want something to open in a new window, you also do not need JavaScript.
- User controls don't need to be JavaScript and when they are, they usually fail to work in mobile.
- Popover slideshow galleries don't need JavaScript to manage page reflow. Most shopping sites do this for their product images and it completely falls apart on Mobile when you pinch-zoom.
Far to often I find myself on pages that are unresponsive (not referring to Responsive Design) because they're so laden with JavaScript that everything comes to a screeching halt. Or worse still, some syntax error in one script brings the whole page down or one script reference doesn't load and the page is completely unusable.
Earlier quoted context omitted.
Browsers/webapps have only become this crazily successful because they allow seamless delivery of applications to run locally. I haven't seen anything to build "code-less" apps that can implement the complex features people want and isn't a complete nightmare to build and maintain. Until then everything you're talking about is just a pipe dream. You can still make the apps you're talking about with html+css and enfor…
> but there is a reason no one wants to do that these days The reason is, that JS is enabled by default, nothing else. If users had the possibility to actively decide before any remote code will execute on their computer, how many would like to enable it? We are just one default checkbox setting away from what you call "utopia" here - a word that should be used for much bigger things. Of utopic naivity in deed is the…
None of that changes that js adds incredible power to what webpages can do and there is zero chance of rolling back browser-delivered applications at this point.
I also don't understand why you think html+css doesn't have the same fundamental 'code execution' flaw - you're accepting unseen input from a remote source and feeding it into an execution engine which will have exploits - whether that's css or html or js or xml or *.
Back to your question though: yes, 98% of web users want remote code execution on because they want spotify, facebook, and youtube to work. They would be upset if they even had to manually go in and enable it. And I'm not even sure you could make a quality version of those sites without js.
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.
Using HTML5 tags such as , you don't need CSS or JS! Try this in Chrome: https://jsfiddle.net/timdavila/f5rcarmn/
Earlier quoted context omitted.
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.
jQuery is JavaScript, so...