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

Deprecate event shorthand methods #3214

Closed
gibson042 opened this Issue Jul 4, 2016 · 39 comments

Comments

Projects
None yet
10 participants
@gibson042
Member

gibson042 commented Jul 4, 2016

As discussed in the core meeting, we should deprecate on/trigger event shorthand methods in a pre-4.0 minor release.

@john2014

This comment has been minimized.

Show comment
Hide comment
@john2014

john2014 Jul 4, 2016

Please DO NOT do this. A huge amount of code, especially in top 1 million websites, relies on a LOT of these event shorthands. The reason .load() was deprecated was because it was ambiguous. Not only these remaining shorthand have no ambiguity but is actually much cleaner code. Do not fix something that is not broken.

A good example: We would have to change $("#div1").focus() to $("#div1").trigger("focus");
$("#div1").focus(function(){ DoSomething() }) to $("#div1").on(""focus",function(){ DoSomething() }));

Please do not break such important shorthands just because one person complained about it. The biggest reason to continue to use any library is its backward compatibility. If it keeps breaking stuff for ZERO apparent gain, then many users will either seriously consider moving to different library or stay with older version. I am guessing jquery does not want that.

In addition, there are millions of jquery plugins which uses these shorthand and there is no way every single one of them would be updated. This would break the entire jquery ecosystem.

I hope you guys see the magnitude of this change. Not only do users not gain from this; but it will break lots of stuff for no reason.

john2014 commented Jul 4, 2016

Please DO NOT do this. A huge amount of code, especially in top 1 million websites, relies on a LOT of these event shorthands. The reason .load() was deprecated was because it was ambiguous. Not only these remaining shorthand have no ambiguity but is actually much cleaner code. Do not fix something that is not broken.

A good example: We would have to change $("#div1").focus() to $("#div1").trigger("focus");
$("#div1").focus(function(){ DoSomething() }) to $("#div1").on(""focus",function(){ DoSomething() }));

Please do not break such important shorthands just because one person complained about it. The biggest reason to continue to use any library is its backward compatibility. If it keeps breaking stuff for ZERO apparent gain, then many users will either seriously consider moving to different library or stay with older version. I am guessing jquery does not want that.

In addition, there are millions of jquery plugins which uses these shorthand and there is no way every single one of them would be updated. This would break the entire jquery ecosystem.

I hope you guys see the magnitude of this change. Not only do users not gain from this; but it will break lots of stuff for no reason.

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Jul 5, 2016

Member

I'm +1 on deprecating, -1 on ever removing from the default build. It's already easy to exclude in a custom build, but the deprecation is a good signal to developers that they should aim to not use them.

Member

scottgonzalez commented Jul 5, 2016

I'm +1 on deprecating, -1 on ever removing from the default build. It's already easy to exclude in a custom build, but the deprecation is a good signal to developers that they should aim to not use them.

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Jul 5, 2016

Member

I'm not a fan of deprecating something we don't plan on removing. Considering that, I might be a -1 on deprecating these. They're just too prevalent to remove, and I don't see the downside of using them if you like them. I prefer .on too, but I have no disadvantages in mind to back up a harangue for using an alias.

Member

timmywil commented Jul 5, 2016

I'm not a fan of deprecating something we don't plan on removing. Considering that, I might be a -1 on deprecating these. They're just too prevalent to remove, and I don't see the downside of using them if you like them. I prefer .on too, but I have no disadvantages in mind to back up a harangue for using an alias.

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Jul 5, 2016

Member

The reason I'm in favor of deprecating, but not removing is that it will encourage plugin developers to support users who want to exclude the event alias module. This is the only module, besides the deprecated module, that we support excluding with jQuery UI.

I've also personally disliked these methods for many years because they operate in the reverse order of what's expected for the trigger scenario (the primary action is firing an event, not taking an action like the native equivalents). The result is close enough to the expected, native behavior that most developers don't notice, but it's definitely been a source of pain for a long time.

Member

scottgonzalez commented Jul 5, 2016

The reason I'm in favor of deprecating, but not removing is that it will encourage plugin developers to support users who want to exclude the event alias module. This is the only module, besides the deprecated module, that we support excluding with jQuery UI.

I've also personally disliked these methods for many years because they operate in the reverse order of what's expected for the trigger scenario (the primary action is firing an event, not taking an action like the native equivalents). The result is close enough to the expected, native behavior that most developers don't notice, but it's definitely been a source of pain for a long time.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jul 5, 2016

Member

The Bootstrap team has a similar thought to @scottgonzalez in twbs/bootstrap#20203 and are planning to use the slim build. Obviously most consumers of Bootstrap will be using the full build but it's nice for end-developers that a plugin doesn't unnecessarily force them to use a full build.

I'm fine with deprecating but not ever removing. Slightly more complicated, we can not deprecate it and come up with another term and use that in the API docs to define APIs that plugins should avoid. It's already possible to exclude event-alias in a custom build, but without some signal to plugin writers about what to avoid that isn't going to help much.

To @john2014's concern, even if we removed event aliases in the core library we have always provided plenty of compatibility helpers to make the transition easier. If someone is moving from jQuery 3 to a hypothetical jQuery 4 without event aliases, they would just add jQuery Migrate 4 at the time they changed to jQuery 4 and it would report the things to fix.

Member

dmethvin commented Jul 5, 2016

The Bootstrap team has a similar thought to @scottgonzalez in twbs/bootstrap#20203 and are planning to use the slim build. Obviously most consumers of Bootstrap will be using the full build but it's nice for end-developers that a plugin doesn't unnecessarily force them to use a full build.

I'm fine with deprecating but not ever removing. Slightly more complicated, we can not deprecate it and come up with another term and use that in the API docs to define APIs that plugins should avoid. It's already possible to exclude event-alias in a custom build, but without some signal to plugin writers about what to avoid that isn't going to help much.

To @john2014's concern, even if we removed event aliases in the core library we have always provided plenty of compatibility helpers to make the transition easier. If someone is moving from jQuery 3 to a hypothetical jQuery 4 without event aliases, they would just add jQuery Migrate 4 at the time they changed to jQuery 4 and it would report the things to fix.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Jul 5, 2016

Member

To add to the above points, deprecating these shorthands will mean the slim
build won't contain them which, in turn, may serve as an incentive to
plugin authors to stop relying on them and at the same time will not block
people from upgrading to a newer jQuery since the full build will continue
to work.

Michał Gołębiowski

Member

mgol commented Jul 5, 2016

To add to the above points, deprecating these shorthands will mean the slim
build won't contain them which, in turn, may serve as an incentive to
plugin authors to stop relying on them and at the same time will not block
people from upgrading to a newer jQuery since the full build will continue
to work.

Michał Gołębiowski

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jul 5, 2016

Member

It's also interesting that Bootstrap actively disables aliases in their unit tests so they won't accidentally be used. They could have used a custom build of course but this way their tests generate a clear error message if one is used accidentally.

Member

dmethvin commented Jul 5, 2016

It's also interesting that Bootstrap actively disables aliases in their unit tests so they won't accidentally be used. They could have used a custom build of course but this way their tests generate a clear error message if one is used accidentally.

@BillJones50

This comment has been minimized.

Show comment
Hide comment
@BillJones50

BillJones50 Jul 5, 2016

I agree with @john2014 that the tradefoff is not worth it (saving few lines of code vs breaking a lot of user code + lots of jquery plugins - maintained or unmaintained; but actively used).

@john2014's concern, even if we removed event aliases in the core library we have always provided plenty of compatibility helpers to make the transition easier. If someone is moving from jQuery 3 to a hypothetical jQuery 4 without event aliases, they would just add jQuery Migrate 4 at the time they changed to jQuery 4 and it would report the things to fix.

The most important point is backward compatibility. Users should not have to keep modifying their code (and every jquery plugins they used), everytime a new jquery major version is released.

Note: Jquery migrate will certainly solve that "newly created" problem. But that will involve users having to add two javascript sources instead of one. Many users may not even be aware that Jquery migrate exists. I dont think saving few lines of code is worth breaking lots of code.

As you may know, Jquery is already less than 34 KB when you load it from Google CDN and its permanently cached. Reducing files size to 33 KB (or even 29 KB) isnt going to make much difference. A single image on Facebook is more than 60 KB. So filesize should not be an important criteria. IMHO, the most important criteria should be backwards compatibility and adding new features to continue to make Jquery a great library.

BillJones50 commented Jul 5, 2016

I agree with @john2014 that the tradefoff is not worth it (saving few lines of code vs breaking a lot of user code + lots of jquery plugins - maintained or unmaintained; but actively used).

@john2014's concern, even if we removed event aliases in the core library we have always provided plenty of compatibility helpers to make the transition easier. If someone is moving from jQuery 3 to a hypothetical jQuery 4 without event aliases, they would just add jQuery Migrate 4 at the time they changed to jQuery 4 and it would report the things to fix.

The most important point is backward compatibility. Users should not have to keep modifying their code (and every jquery plugins they used), everytime a new jquery major version is released.

Note: Jquery migrate will certainly solve that "newly created" problem. But that will involve users having to add two javascript sources instead of one. Many users may not even be aware that Jquery migrate exists. I dont think saving few lines of code is worth breaking lots of code.

As you may know, Jquery is already less than 34 KB when you load it from Google CDN and its permanently cached. Reducing files size to 33 KB (or even 29 KB) isnt going to make much difference. A single image on Facebook is more than 60 KB. So filesize should not be an important criteria. IMHO, the most important criteria should be backwards compatibility and adding new features to continue to make Jquery a great library.

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Jul 5, 2016

Member

@BillJones50 @john2014 I think the whole core team agrees that these should not be removed. Some would like to warn against their use, though, and deprecation might be the best way to do that.

However, I still think the word "deprecation" will give the wrong signal. That is, some people will believe jQuery intends to remove them down the line (as is evidenced by @BillJones50's comment), and we don't.

Member

timmywil commented Jul 5, 2016

@BillJones50 @john2014 I think the whole core team agrees that these should not be removed. Some would like to warn against their use, though, and deprecation might be the best way to do that.

However, I still think the word "deprecation" will give the wrong signal. That is, some people will believe jQuery intends to remove them down the line (as is evidenced by @BillJones50's comment), and we don't.

@BillJones50

This comment has been minimized.

Show comment
Hide comment
@BillJones50

BillJones50 Jul 5, 2016

Thank you @timmywil

I forgot to add that using shorthand not only saves significant coding time, but also reduces end user filesize (since there is less code). Using shorthand is a win-win for developers.

BillJones50 commented Jul 5, 2016

Thank you @timmywil

I forgot to add that using shorthand not only saves significant coding time, but also reduces end user filesize (since there is less code). Using shorthand is a win-win for developers.

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Jul 5, 2016

Member

I forgot to add that using shorthand not only saves significant coding time, but also reduces end user filesize (since there is less code). Using shorthand is a win-win for developers.

Both are a lie.

You don't save significant coding time with any shorthands like this. The time it takes to type a few characters is negligible, even over an entire year's worth of coding. Even the time you spend typing in general while coding is fairly small. Keystrokes are not where you get significant gains in development time.

As for end user file size, I assume you're referring to the number of bytes transferred, not the number of bytes in the cached file on the user's drive. The number of bytes you think you're saving during transfer (bandwidth) disappears when the code runs through gzip prior to the transfer.

Member

scottgonzalez commented Jul 5, 2016

I forgot to add that using shorthand not only saves significant coding time, but also reduces end user filesize (since there is less code). Using shorthand is a win-win for developers.

Both are a lie.

You don't save significant coding time with any shorthands like this. The time it takes to type a few characters is negligible, even over an entire year's worth of coding. Even the time you spend typing in general while coding is fairly small. Keystrokes are not where you get significant gains in development time.

As for end user file size, I assume you're referring to the number of bytes transferred, not the number of bytes in the cached file on the user's drive. The number of bytes you think you're saving during transfer (bandwidth) disappears when the code runs through gzip prior to the transfer.

@BillJones50

This comment has been minimized.

Show comment
Hide comment
@BillJones50

BillJones50 Jul 5, 2016

You do realize that not everyone uses Gzip on their server.

In addition gzipping (compression) increases server loads (it has to compress every single time unique visitor requests javascript files) and is not suitable for all situations. If we can compress codes (using shorthands) before the gzip process, its lot more useful.

I am not sure why you think providing quick shorthand is a problem. Shorthands (called symbolic links) in Linux OS is very widely used and is a feature that should be advertised for saving time/money and not something to be hidden from users.

BillJones50 commented Jul 5, 2016

You do realize that not everyone uses Gzip on their server.

In addition gzipping (compression) increases server loads (it has to compress every single time unique visitor requests javascript files) and is not suitable for all situations. If we can compress codes (using shorthands) before the gzip process, its lot more useful.

I am not sure why you think providing quick shorthand is a problem. Shorthands (called symbolic links) in Linux OS is very widely used and is a feature that should be advertised for saving time/money and not something to be hidden from users.

@gibson042

This comment has been minimized.

Show comment
Hide comment
@gibson042

gibson042 Jul 6, 2016

Member

The most important point is backward compatibility. Users should not have to keep modifying their code (and every jquery plugins they used), everytime a new jquery major version is released.

Breaking backwards compatibility is precisely the reason for releasing a new major version. Not every user will have to modify code, but it is a guarantee that at least some will. So please consider this a strong suggestion to avoid event shorthand methods in all new code.

Member

gibson042 commented Jul 6, 2016

The most important point is backward compatibility. Users should not have to keep modifying their code (and every jquery plugins they used), everytime a new jquery major version is released.

Breaking backwards compatibility is precisely the reason for releasing a new major version. Not every user will have to modify code, but it is a guarantee that at least some will. So please consider this a strong suggestion to avoid event shorthand methods in all new code.

@markelog markelog added the Docs label Jul 7, 2016

@markelog

This comment has been minimized.

Show comment
Hide comment
@markelog

markelog Jul 7, 2016

Member

I think there is confusion about term "deprecating".

Let's go to the wikipedia page for the definition -

Deprecation is the discouragement of use of some feature, design or practice, typically because it has been superseded or is no longer considered safe, without (at least for the time being) removing it from the system of which it is a part or prohibiting its use.

without removing - purpose of tickets like that is only to discourage use of it. Nothing more. For example, DOM method window.unescape is deprecated, but it is not removed until browser vendors will be sure (based on their usage stats) that no one is no longer using it aka "Not to break a web" principle.

We could use same rule - not remove those widely used methods until no one uses them with newer version of jQuery, meanwhile, if we unfavor this practise we should show it. That's all it is.

Not the first time i see this misconception which really sadness me, i urge everyone to see formal limitations of this term.

Member

markelog commented Jul 7, 2016

I think there is confusion about term "deprecating".

Let's go to the wikipedia page for the definition -

Deprecation is the discouragement of use of some feature, design or practice, typically because it has been superseded or is no longer considered safe, without (at least for the time being) removing it from the system of which it is a part or prohibiting its use.

without removing - purpose of tickets like that is only to discourage use of it. Nothing more. For example, DOM method window.unescape is deprecated, but it is not removed until browser vendors will be sure (based on their usage stats) that no one is no longer using it aka "Not to break a web" principle.

We could use same rule - not remove those widely used methods until no one uses them with newer version of jQuery, meanwhile, if we unfavor this practise we should show it. That's all it is.

Not the first time i see this misconception which really sadness me, i urge everyone to see formal limitations of this term.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Jul 7, 2016

Member

Can we move it to 3.2.0? 3.1.0 is almost ready (in fact, I moved all issues previously assigned to 3.1.0 to 3.2.0).

Member

mgol commented Jul 7, 2016

Can we move it to 3.2.0? 3.1.0 is almost ready (in fact, I moved all issues previously assigned to 3.1.0 to 3.2.0).

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Jul 7, 2016

Member

@markelog A formal definition has little bearing on the popular connotations associated with a term, which is why dictionaries change with time. Your point does not change my belief that "deprecation" implies eventual removal, at least to some. I wish there was a way we could say that we recommend avoiding a particular API, which is different than saying we recommend avoiding it and it may be removed in a future version.

Member

timmywil commented Jul 7, 2016

@markelog A formal definition has little bearing on the popular connotations associated with a term, which is why dictionaries change with time. Your point does not change my belief that "deprecation" implies eventual removal, at least to some. I wish there was a way we could say that we recommend avoiding a particular API, which is different than saying we recommend avoiding it and it may be removed in a future version.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Jul 7, 2016

Member

@timmywil How about if we changed the name of the deprecated module to discouraged and moved there stuff that we don't want to remove due to widespread usage but we still recommend to avoid? This module would be then excluded from the slim build which may urge library creators to avoid those APIs for real.

Member

mgol commented Jul 7, 2016

@timmywil How about if we changed the name of the deprecated module to discouraged and moved there stuff that we don't want to remove due to widespread usage but we still recommend to avoid? This module would be then excluded from the slim build which may urge library creators to avoid those APIs for real.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jul 7, 2016

Member

Yeah if we're not going to use Deprecated for these then we should come up with another term. We've got quite a few of these "Deprecate X" issues open and they seem to be blocked on coming to an agreement about this.

Member

dmethvin commented Jul 7, 2016

Yeah if we're not going to use Deprecated for these then we should come up with another term. We've got quite a few of these "Deprecate X" issues open and they seem to be blocked on coming to an agreement about this.

@markelog

This comment has been minimized.

Show comment
Hide comment
@markelog

markelog Jul 7, 2016

Member

@timmywil

Your point does not change my belief that "deprecation" implies eventual removal, at least to some

It does imply that to some because it is a first step in removal process, there isn't any other way really, we can call any way we prefer - discouraged, abandoned or expecto patronum or something.

It wouldn't change the meaning of what we are doing which is discouraging people from using it, so it still would be the first step in removal process

Member

markelog commented Jul 7, 2016

@timmywil

Your point does not change my belief that "deprecation" implies eventual removal, at least to some

It does imply that to some because it is a first step in removal process, there isn't any other way really, we can call any way we prefer - discouraged, abandoned or expecto patronum or something.

It wouldn't change the meaning of what we are doing which is discouraging people from using it, so it still would be the first step in removal process

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Jul 7, 2016

Member

I actually don't think deprecation must mean plans to remove in the nearby future. I would say, though, that deprecating sth means we discourage using it and we'd love to remove it but who knows if and when the removal will be possible. If we don't want to remove it not due to widespread usage but just because we think this API should continue to exist then why would we discourage using it? Those two things don't really go hand in hand with each other.

Applying that to this ticket, I'd say that since we want to discourage it, we should deprecate it even if we can only remove it in 5 or 10 years.

Member

mgol commented Jul 7, 2016

I actually don't think deprecation must mean plans to remove in the nearby future. I would say, though, that deprecating sth means we discourage using it and we'd love to remove it but who knows if and when the removal will be possible. If we don't want to remove it not due to widespread usage but just because we think this API should continue to exist then why would we discourage using it? Those two things don't really go hand in hand with each other.

Applying that to this ticket, I'd say that since we want to discourage it, we should deprecate it even if we can only remove it in 5 or 10 years.

@markelog

This comment has been minimized.

Show comment
Hide comment
@markelog

markelog Jul 7, 2016

Member

That's exactly what i'm trying to say, thank you

Member

markelog commented Jul 7, 2016

That's exactly what i'm trying to say, thank you

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jul 7, 2016

Member

There is some precedent for long deprecation. We deprecated jQuery.browser in 1.3 but didn't remove it until 1.9. In that case we also got a lot of complaints about the deprecation.

The main issue here is that the longer we wait to send the signal "this isn't best practice anymore" using whatever word, the longer it will take for people to change their code because they're not aware of it. Just like jQuery.browser there will be people who disagree with whether something is good practice or not, and there may be a lot of code out there using it. That can affect when we remove it.

Member

dmethvin commented Jul 7, 2016

There is some precedent for long deprecation. We deprecated jQuery.browser in 1.3 but didn't remove it until 1.9. In that case we also got a lot of complaints about the deprecation.

The main issue here is that the longer we wait to send the signal "this isn't best practice anymore" using whatever word, the longer it will take for people to change their code because they're not aware of it. Just like jQuery.browser there will be people who disagree with whether something is good practice or not, and there may be a lot of code out there using it. That can affect when we remove it.

@timmywil timmywil modified the milestones: 3.2.0, 3.1.0 Jul 7, 2016

@BillJones50

This comment has been minimized.

Show comment
Hide comment
@BillJones50

BillJones50 Jul 7, 2016

Is there a particular reason some Jquery members want to actively discourage using shorthands?

The only reason I can think of is reducing file size (by eventually removing it - whenever that would be).

So I did actual calculations and after minify+Gzip, it only saves around 400 bytes. Is there any other reason?

BillJones50 commented Jul 7, 2016

Is there a particular reason some Jquery members want to actively discourage using shorthands?

The only reason I can think of is reducing file size (by eventually removing it - whenever that would be).

So I did actual calculations and after minify+Gzip, it only saves around 400 bytes. Is there any other reason?

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Jul 7, 2016

Member

Is there any other reason?

#3214 (comment)

Member

scottgonzalez commented Jul 7, 2016

Is there any other reason?

#3214 (comment)

@lpd-au

This comment has been minimized.

Show comment
Hide comment
@lpd-au

lpd-au Nov 6, 2017

If these shorthands aren't likely to ever be removed, why not wait for a major version (and new version of jQuery migrate) to deprecate them?

lpd-au commented Nov 6, 2017

If these shorthands aren't likely to ever be removed, why not wait for a major version (and new version of jQuery migrate) to deprecate them?

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Nov 6, 2017

Member

@lpd-au Waiting for a major version wouldn't help in reducing usage of these shorthands. Besides, according to semver deprecations are free to land in minor releases.

Member

mgol commented Nov 6, 2017

@lpd-au Waiting for a major version wouldn't help in reducing usage of these shorthands. Besides, according to semver deprecations are free to land in minor releases.

@lpd-au

This comment has been minimized.

Show comment
Hide comment
@lpd-au

lpd-au Nov 6, 2017

Just because they can, doesn't mean they always should. Especially the .click(function) being such a widely used part of the library, the canonical example to show jQuery's elegance over native JS, which isn't documented anywhere as being in bad style. There is no rush here to deprecate for later removal in an imminent major release, which is probably why it's already been pushed back from 3.1.0 to 3.2.0 to 3.3.0... can we just make the wait official? How do you expect usage to fall anyway among developers who already transitioned to jQ3 and removed the migration plugin?

lpd-au commented Nov 6, 2017

Just because they can, doesn't mean they always should. Especially the .click(function) being such a widely used part of the library, the canonical example to show jQuery's elegance over native JS, which isn't documented anywhere as being in bad style. There is no rush here to deprecate for later removal in an imminent major release, which is probably why it's already been pushed back from 3.1.0 to 3.2.0 to 3.3.0... can we just make the wait official? How do you expect usage to fall anyway among developers who already transitioned to jQ3 and removed the migration plugin?

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Nov 6, 2017

Member

Nothing has broken because of this deprecation. It doesn't make sense to undeprecate the feature just to get rid of a warning in Migrate. You can either ignore the warning or override jQuery.fn.click() after loading Migrate to get rid of it. Or, change the code generating the warning.

Member

dmethvin commented Nov 6, 2017

Nothing has broken because of this deprecation. It doesn't make sense to undeprecate the feature just to get rid of a warning in Migrate. You can either ignore the warning or override jQuery.fn.click() after loading Migrate to get rid of it. Or, change the code generating the warning.

@lpd-au

This comment has been minimized.

Show comment
Hide comment
@lpd-au

lpd-au Nov 6, 2017

Undeprecate? What am I missing here... the issue is still open, marked for an unreleased milestone and isn't documented anywhere that I can find?

lpd-au commented Nov 6, 2017

Undeprecate? What am I missing here... the issue is still open, marked for an unreleased milestone and isn't documented anywhere that I can find?

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Nov 6, 2017

Member

I think it's safe to deprecate in the next version. It's not getting removed so no code will be broken.

Member

timmywil commented Nov 6, 2017

I think it's safe to deprecate in the next version. It's not getting removed so no code will be broken.

dmethvin added a commit to dmethvin/jquery that referenced this issue Jan 8, 2018

dmethvin added a commit to dmethvin/jquery that referenced this issue Jan 8, 2018

@dmethvin dmethvin referenced this issue Jan 8, 2018

Closed

Event: Move event aliases to deprecated #3928

2 of 3 tasks complete

dmethvin added a commit to dmethvin/jquery that referenced this issue Jan 9, 2018

@dmethvin dmethvin closed this in 022b69a Jan 16, 2018

brandonkelly added a commit to craftcms/cms that referenced this issue Feb 1, 2018

immpo added a commit to immpo/jquery that referenced this issue Feb 3, 2018

up (#1)
* Dimensions: ignore transforms when retrieving width/height

Close gh-3561
Fixes gh-3193

* CSS: remove dead code in getWidthOrHeight

- getCSS already falls back to inline styles

Ref gh-3561

* Release: update release dependencies

* Release: update AUTHORS.txt

* Release: update version to 3.2.0-pre

* Release: md5sum -> md5 -r for MAC

* Build: Updating the master version to 3.2.1-pre.

* Release: edit dist README version on release

Fixes gh-3574

* Build: update PR template

- Comment out things we don't need to see in the PR description
- Change CLA link

* Tests: move readywait to an iframe test

Close gh-3576
Fixes gh-3573

* Dimensions: fall back to offsetWidth/Height for inline elems

Close gh-3577
Fixes gh-3571

* Revert "Event: Trigger checkbox and radio click events identically"

This reverts commit b442aba.

* Revert "Event: Add radio click triggering tests"

This reverts commit 5f35b5b.

* Tests: add test for passing trigger data to radio click handler

Close gh-3581
Fixes gh-3579

* Build: Updating the master version to 3.2.2-pre.

* CSS: retrieve inline style before computed

- Fixes an issue with getting computed style on detached elements

* Revert "Build: Updating the master version to 3.2.2-pre."

This reverts commit 066bd86.

* Build: Updating the master version to 3.2.2-pre.

* Tests: Fix incorrect assert name for ensure_iterability_es6

Closes gh-3584
Ref bb026fc.

* Docs: Update links to HTML spec for stripAndCollapse (#3594)

* Offset: Use correct offset parents; include all border/scroll values

Thanks @anseki

Fixes gh-3080
Fixes gh-3107
Closes gh-3096
Closes gh-3487

* Core: Update isFunction to handle unusual-@@toStringTag input

Ref gh-3597
Fixes gh-3600
Fixes gh-3596
Closes gh-3617

* Tests: Improve offset test setup and labels

Hopefully this fixes iOS testing: http://swarm.jquery.org/job/5226

Ref 1d2df77
Closes gh-3641

* Tests: Be even more async for iOS

Ref 1d2df77
Closes gh-3643

* Tests: Attach test iframes to the body for visibility-dependent code

Ref 1d2df77
Closes gh-3645

* Tests: Allow a mock QUnit.test for perfect testIframe fidelity

Ref 1d2df77
Closes gh-3647

* Tests: Prepend test iframes for even *more* consistency

Ref 1d2df77

* Tests: Reset iframe window scroll after updating html/document position

Ref 1d2df77
Closes gh-3649

* Tests: Add debugging to investigate iOS failures

Ref 1d2df77

* Tests: Keep iframes visible in TestSwarm

Ref 1d2df77

* Tests: Adjust by actual scroll position, rather than expected

Ref 1d2df77

* Tests: Clean up offset debugging

Ref 1d2df77
Ref c0edd8d

* Tests: Correct expected assertion count

Ref e94b5b0

* Tests: Revert some testIframe changes to fix dimensions tests

Ref c0edd8d

* Revert "Tests: Revert some testIframe changes to fix dimensions tests"

This reverts commit c4368a9.

* Tests: Revert some testIframe changes to fix dimensions tests

Ref c0edd8d

* CSS: Drop the float mapping from cssProps

Firefox 35 and newer support style.float directly.

Closes #3569

* Docs:Tests: Update IE/Edge-related support comments & tests

Closes gh-3661

* Build: Test on Node.js 8, stop testing on Node.js 7

* Tests: minor typos

Close gh-3671

* Dimensions: Include scroll gutter in "padding" box

Fixes gh-3589
Closes gh-3656

* Deferred: fix memory leak of promise callbacks

Fixes gh-3606
Closes gh-3657

* Build: update node dependencies; commit package-lock.json

- Also ignore yarn.lock
Close gh-3669

* Build: Update sinon, husky, and qunitjs

* Build: fix uglify options for uglify update

- Uses new typeofs option for compression
- See mishoo/UglifyJS2#2198

Close gh-3710

* Event: `stopPropagation()` on native event-handler

Fixes gh-3693
Close gh-3694

* Core: Deprecate jQuery.isWindow

Fixes gh-3629
Close gh-3702

* Test: ensure position/offset return mutable objects

Fixes gh-3612
Closes gh-3695

* Revert "Offset: Resolve strict mode ClientRect "no setter" exception"

This reverts commit 3befe59.

* Offset: fix error from bad merge in #3695

* Dimensions: Detect and account for content-box dimension mishandling

Fixes gh-3699
Closes gh-3700

* Support: Properly check for IE9 absolute scrollbox mishandling

Ref gh-3589
Fixes gh-3699
Fixes gh-3730
Closes gh-3729

* Tests: Try extra hard to control focus

Ref gh-3732

* Tests: Abort focus tests when the environment doesn't cooperate

Ref gh-3732

* Tests: Reduce the abort timeout for simple focus testing

Ref gh-3732

* Tests: Simulate events when CI hinders use of native ones

Ref gh-3732

* Tests: Account for TestSwarm focus issues

Closes gh-3732

* Ajax: add an ontimeout handler to all requests

Fixes gh-3586
Close gh-3590

* Dimensions: Improve offsetWidth/offsetHeight fallback

Fixes gh-3698
Fixes gh-3602
Closes gh-3738

* Tests: Replace non-ASCII whitespace in source code

* Dimensions: Don't trust non-pixel computed width/height

Fixes gh-3611
Closes gh-3741

* Build: Fix comment typo

Closes gh-3747

* Build: Update my name in .mailmap

I got married! 🎉

* Build: Update my name in ATHORS.txt

I forgot .mailmap isn't everything.

* Tests: Update path calculation

Fixes gh-3756
Closes gh-3757

* CSS: Avoid unit-conversion interference from CSS upper bounds

Fixes gh-2144
Closes gh-3745

* Tests: Update lineHeight adjustments to give Android more slop

* CSS: Detect more WebKit styles erroneously reported as percentages

Ref 692f9d4
Fixes gh-3777
Closes gh-3778

* Build: Update to Babel 7, use for-of plugin instead of preset-es2015

Closes gh-3786

* Build: Drop cross-spawn, use child_process.spawn shell option

* Build: increase timeout in Promises/A+ tests 10 times

The promises-aplus-tests sets up a default 200 ms Mocha timeout. This makes
our tests randomly fail on Jenkins. 2 seconds will be safer.

Closes gh-3791

* Build: Remove package-lock.json, add it to .gitignore

npm 5, even the version included in the latest Node.js 8.5.0 re-generates
`package-lock.json` on each install. And when it does on a system that doesn't
support all the optional dependencies that are supported on the OS where the
lockfile was generated, it removes those optional deps from the lockfile.

The effect is that everyone firing `npm install` on our repo on any OS other
than macOS will immediately get a dirty state of the repo as the `fsevents`
dependency subtree gets removed from `package-lock.json`. That's a really bad
experience.

This commit removes package-lock.json from the repository and adds it to
.gitignore. We'll start committing the file again once the issue is resolved
on npm's part.

Fixes gh-3792

* Tests: Make Node tests work for paths with spaces in them

Without this patch Jenkins tests fail as jQuery job names there contain spaces,
e.g. "jQuery Core".

Closes gh-3821

* Tests: Add Safari 11 support test results

* Build: Test on Node.js 9

Closes gh-3840

* Tests: Add iOS 11 support test results

* Manipulation: Reduce size by eliminating single-use variable

Closes gh-3851

* CSS: Correctly set support properties with non-default zoom

Fixes gh-3808
Closes gh-3872

* Docs: Create CODE_OF_CONDUCT.md

Close gh-3865

* Tests: Add support for running unit tests via grunt with karma

- Update QUnit to 1.23.1
- Remove unused dl#dl from test/index.html
- Remove unused map#imgmap from test/index.html
- Ensure all urls to data use baseURI
- Add the 'grunt karma:main' task
  - customContextFile & customDebugFile
- Add 'npm run jenkins' script

Close gh-3744
Fixes gh-1999

* Build: Only run browser tests in one Node version on Travis

Ref gh-3744
Closes gh-3894

* Core: make camelCase function available only for internal usage

Close gh-3604
Fixes gh-3384

* Core: adjust data tests to ensure proper camelCasing

- Add back camelCase to the public object (deprecate not remove)
Ref #3384

* Core: deprecate jQuery.now

Fixes gh-2959
Close gh-3884

* Core: deprecate jQuery.proxy (not slated for removal)

Fixes gh-2958
Close gh-3885

* Manipulation: use `.children` to select tbody elements

- selectors beginning with a child combinator are not valid natively.
  This fixes the tests when using selector-native.js

* Attributes: allow array param in add/remove/toggleClass

+30 bytes instead of +182

Thanks to @faisaliyk for the first pass on this feature.

Fixes gh-3532
Close gh-3917

* Ajax: add unit test for getScript(Object)

Fixes gh-3736
Close gh-3918

* Tests: only run ontimeout test if ontimeout exists

Fixes gh-3742
Close gh-3919

* Build: Fix UglifyJS output in Android 4.0; update uglify

- Thanks to @mgol for first pass

Fixes gh-3743
Close gh-3920

* Tests: fix function reference for unbinding

Ref gh-2958

* Build: Remove CRLF line endings to fix builds on Windows

Close gh-3929

* Core: deprecate jQuery.isFunction

Fixes gh-3609

* Event: Move event aliases to deprecated

Fixes gh-3214

* Ajax: Don't process non-string data property on no-entity-body requests

Fixes gh-3438
Closes gh-3781

* Core: deprecate jQuery.isNumeric

Fixes gh-2960
Closes gh-3888

* Tests: fix weird failure in Edge 16 CSS

Fixes gh-3866
Close gh-3932

* Tests: fix weird flaky attributes test in Edge 16

Fixes gh-3867
Close gh-3931

* Core: deprecate jQuery.type

Fixes gh-3605
Close gh-3895

* Tests: fix number of expected assertions in basic core

* Tests: temporarily require sudo access for karma:main on travis

- This should fix the broken travis build on Node 8
- See travis-ci/travis-ci#8836

* Tests: correctly set sudo in travis config, not karma config

* Manipulation: Add support for scripts with module type

Fixes gh-3871
Close gh-3869

* Tests: fix tests in AMD mode

* Tests: ensure that module assertions run on supported browsers

- Also fixes tests for karma, where the URL for the module is different

Ref gh-3871

* Filter: Use direct filter in winnow

for both simple and complex selectors

Fixes gh-3272
Closes gh-3910

* Build: Add "-debug" suffix to name of karma debug tasks

Ref gh-3922
Close gh-3936

* Tests: skip test with invalid selector for selector-native tests

* Release: add new authors to AUTHORS.txt

* Release: update version to 3.3.0-pre

* Build: Updating the master version to 3.3.1-pre.

* Build: Updating the master version to 3.3.2-pre.
@RinkAttendant6

This comment has been minimized.

Show comment
Hide comment
@RinkAttendant6

RinkAttendant6 Jun 19, 2018

Is there any particular reason that these deprecations are not documented here: https://api.jquery.com/category/deprecated/deprecated-3.3/
Nor are they documented on the API documentation pages for the functions (for example https://api.jquery.com/change/)

RinkAttendant6 commented Jun 19, 2018

Is there any particular reason that these deprecations are not documented here: https://api.jquery.com/category/deprecated/deprecated-3.3/
Nor are they documented on the API documentation pages for the functions (for example https://api.jquery.com/change/)

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Jun 20, 2018

Member

@RinkAttendant6 See jquery/api.jquery.com#972. Someone needs to do the work to document it, we haven't gotten to it, yet. Contributions are welcome!

Member

mgol commented Jun 20, 2018

@RinkAttendant6 See jquery/api.jquery.com#972. Someone needs to do the work to document it, we haven't gotten to it, yet. Contributions are welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment