-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
At the bottom of the body? Are you serious?? #531
Comments
I do tend to agree with @teo1978 that it's generally good coding etiquette to bump the major version when releasing backwards-incompatible work, although I personally had absolutely no issue with upgrading to this latest version in my framework. In fact, I prefer scripts being around </body> given performance reasons. So, -1 from me on this "bug report". |
Of course, since as you say, you were already putting the script at the end of body.
Good for you, but a lot of other people prefer scripts in the Actually I've never seen a library before that requires you to put it in a specific place. This is not just about backwards compatibility (which is of course a big deal in itself). Not working unless the library is placed at the end of the body is a bug, whether it affects you in particular or not. |
And a toaster not keeping food cold is also a bug if that's what you're hoping for it to do. However in this case the original author's doc states
Seems pretty clear to me how to install the script. |
Yeah, I forgot the part where it's actually documented. However that's just a bad design decision. There's no good reason for imposing an unnecessary and easily avoidable limitation that goes against widespread common practices (whether they are best practices or not)
To make a better analogy, this would be a freezer that only keeps food cold if you put it in the south side of the kitchen. It is advertised on the box, though, so it's perfectly reasonable. |
maybe this helps: #480 |
Why would you want to put a non-critical script in the header? it goes against SEO practices, and causes load-blocking so your page is slower. The only benefit to keeping it in the head, other than looking pretty, would be if you are using the defer and async attributes, at which point you would have to wrap it in an on-load function anyway. Which is the entire point of putting it in the body, and at the end. So that it is loaded last when the document is ready. And at the least, your page visibly loads before it starts downloading the addon resource! I'm sorry but I had to comment, this doesn't make any sense to me. There are far more critical issues at hand. Not to be dismissive or rude, that's not my intent - i apologize in advance if it came across that way. I just don't understand why anyone would want this!! We overuse the head these days, and it really should only have minimal css and meta tags, and only ONLY super critical resources, like a raw dump of jquery (so its available instantly, and compressed into the html output). The head should be redefined as "only what is needed to load the above-the-fold page goes here", where the word "load" has complete separation from "display" when it comes to body contents. Especially when google, bing, etc require your page to load under 1 second to get a good ranking. Async & footer loading all the way man, hands down. |
Closing out old issues. One point for the record: For fun, you can still take a peek at Version 1 here. |
And you are closing the issue because...? |
I appreciate all the discussion in this thread but I'm only keeping issues open that have actionable items as they are bug reports or feature requests. |
What's not "actionable" about this? It should be actually pretty easy to fix. |
@teo1978 just for you, I'm fixing it. It'll be in the next patch release. :-) The |
I know this issue has been resolved but I think you don't need to delay execution until document is ready. Just a thought here, wouldn't just replacing here |
I've just replaced lightbox 2.7.1 with 2.8.2. To start with, I would expect it to be a 100% backward-compatible drop-in replacement that would work out of the box where the previous version used to work, otherwise you should call it 3.x.
Then I found out what the breaking change is:
The old version used to work by placing it in the
<head>
. Besides the fact that a decently designed script would work either way, having it in<head>
is far more elegant and it is the way most modern frameworks and libraries work.You are going backwards, making things worse rather than better. I'm definitely done with Lightbox.
The text was updated successfully, but these errors were encountered: