dmethvin Github contribution chart
dmethvin Github Stats
dmethvin Most Used Languages

Activity

27 Sep 2022

Issue Comment

Dmethvin

data('k') different to attr('data-k') after outside js modified dom

having 3 divs:

<div data-k="1">div 1</div>
<div data-k="2">div 2</div>
<div data-k="3">div 3</div> 
  1. we read their data('k'),
  2. after we modify their order, in my case it is blazor.server.js that modifies their order or perhaps replaces them (I don't know how blazor works) .
  3. now when we read their data('k') again we'll get the data('k') of the element that was previously on the same index, attr('data-k') will give the correct value

using v. 3.6.1

Forked On 27 Sep 2022 at 11:37:33

Dmethvin

There is specific code to ensure that everything stays in sync when jQuery manipulates the DOM. If non-jQuery code is modifying the DOM the jQuery part may be subject to erratic behavior. This includes not only .data() but methods that depend on it such as .clone() and .on().

Commented On 27 Sep 2022 at 11:37:33
Issue Comment

Dmethvin

Case-insensitive selector does not work in some case.

Description

I was happy to see that case-insensitive selectors work with jQuery, but I ran into an issue while updating my code:

This works fine: var a = $("input[name='myfield' i]");

This also works fine: var b = $("input[name='myfield']", "#myform");

But, this does not work: var c = $("input[name='myfield' i]", "#myform");

I got the following error message: Uncaught Error: Syntax error, unrecognized expression: input[name='myfield' i]

The form element has id="myform" and the input field has name="myfield".

Tested with jQuery v.3.6.1.

Forked On 07 Sep 2022 at 01:44:06

Dmethvin

var a = $("input[name='myfield' i]")

What is the role of i in that selector? How does it affect the result?

Commented On 07 Sep 2022 at 01:44:06
Issue Comment

Dmethvin

[BUG] Documentation says `this` refers to the iterated element, inside `.map()`

Description

As per title, the documentation suggest one can use this, into .map() callback, to access the current DOM element:

Within the callback function, this refers to the current DOM element for each iteration.

but according to https://bugs.jquery.com/ticket/2445 this should have been corrected to not mislead the user.

Link to test case

  • https://api.jquery.com/map/ (just before "Examples")
  • https://bugs.jquery.com/ticket/2445 (maybe a regression after this issue?)
  • https://jsfiddle.net/5wmva0o1/ (test case about current behaviour)

Forked On 03 Sep 2022 at 05:32:50

Dmethvin

One thing that might work would be to add a paragraph or two in https://api.jquery.com/Types/#Function to describe the situation. In almost every case it's possible to use an arrow function because what would normally be the this object is duplicated somewhere in the args.

Commented On 03 Sep 2022 at 05:32:50
Issue Comment

Dmethvin

Method return values should be included with parameter list

The return values of API methods are not listed along with parameters. Instead, they're (sometimes) in the paragraph description of the method, which makes it difficult to determine how certain methods should be used (chaining vs not).

Example: It's not immediately obvious that $.replaceWith() returns the replaced node unless one reads through the entire method description.

Forked On 03 Sep 2022 at 03:37:35

Dmethvin

Are you volunteering to create several dozen tickets that request a change? Or to investigate and write a short sentence about exactly what is returned with each API call? I don't think we need the former, but could use the latter.

Commented On 03 Sep 2022 at 03:37:35
Issue Comment

Dmethvin

[BUG] Documentation says `this` refers to the iterated element, inside `.map()`

Description

As per title, the documentation suggest one can use this, into .map() callback, to access the current DOM element:

Within the callback function, this refers to the current DOM element for each iteration.

but according to https://bugs.jquery.com/ticket/2445 this should have been corrected to not mislead the user.

Link to test case

  • https://api.jquery.com/map/ (just before "Examples")
  • https://bugs.jquery.com/ticket/2445 (maybe a regression after this issue?)
  • https://jsfiddle.net/5wmva0o1/ (test case about current behaviour)

Forked On 30 Aug 2022 at 01:05:17

Dmethvin

The reason this isn't the element is because the example is using an arrow function, which does not have its own this and inherits the value from its outer scope. Use function if you want to use this.

I'm not sure if we need any documentation change here because it's a JavaScript thing and not a jQuery thing. Keep in mind that there are likely to be many places in the API where this same change would apply, including .each(), all the setters that take a function (which is most of them), such as .css( propertyName, function), and event handlers.

The old trac-2445 ticket is about jQuery.map() and not jQuery().map() so it's not relevant here.

Commented On 30 Aug 2022 at 01:05:17
Issue Comment

Dmethvin

Differentiate between compatibility patches and pure warnings

jQuery Migrate does two things:

  1. Fills in removed APIs, warning when used.
  2. Warns about deprecated APIs that still exist.

It makes sense to differentiate these two for a few reasons:

  1. Teams may not always have the capacity to tackle all warnings, they may want to resolve just the ones that block Migrate removal and then remove Migrate, leaving resolving the other warnings for later, when they prepare for updating to the next major version.
  2. A project may have already been on jQuery 3.x without Migrate and then it added Migrate to prepare for an update to jQuery 4.0. But Migrate would now also restore some APIs & behaviors removed in jQuery 3.0 which is counterproductive. Since gh-450, it's now possible to exclude warnings but this use case would require first determining those patches.

We should have an easier way to only enable patches required to address before removing Migrate or to only enable the ones preparing for the next major version.

Thoughts, @dmethvin @timmywil @gibson042?

Forked On 14 Aug 2022 at 12:04:51

Dmethvin

I agree we're doing two different things here, but wonder what the solution is for this. Would we create another flag like jQuery.disableDeprecationWarnings or something like that?

Commented On 14 Aug 2022 at 12:04:51

Dmethvin

Core: Accept only jQuery 3.x-4.x
Merged On 14 Aug 2022 at 12:01:55

Dmethvin

The table definitely helps!

Commented On 14 Aug 2022 at 12:01:55
Issue Comment

Dmethvin

Event "load" fires before or after event "ready". This is a little confusing.

See this short example:

<script>
$(function() { console.log("Dom loaded"); });
$(window).on('load', function() { console.log("Window loaded"); });
</script> 

You think "Dom loaded" coming always first? It does not. However, most people think it is. I learned from jquery doc https://api.jquery.com/load-event/ image and overall on every tutorial about jQuery that window event "load" is fired as last, when all images loaded and Dom is ready.

Yes, the event "load" is called correctly when everything is ready. But it happens often enough that this event "load" is called before "ready". Probably because the graphics are already cached in the browser cache, that can lead to crazy results. Everyone assumes that this event will be executed at the end, always after event "ready".

Here should either:

A) the documentation in jQuery should be clearer, that "load" can also be called before "ready", because everything was already loaded, because it was in the browser cache or there were no elements to load.

or/and

B) it would make more sense (for me) to explicitly specify here or that I can say that events "load" should always be executed after all events "ready".

Currently on my project is one time event "ready" fired first, next page refresh its first event "load".

Someone mention this issue years ago on stackoverflow and the last answer after "UPDATE" is interesting https://stackoverflow.com/a/65898996/706420

Forked On 04 Aug 2022 at 10:02:28

Dmethvin

Here is the current doc for .ready():

https://api.jquery.com/ready/#ready-handler

There is a sentence in the docs:

Although handlers added by .ready() will always be executed in a dynamically loaded script, the window's load event has already occurred and those listeners will never run.

Perhaps this is clearer?

Although handlers added by .ready() will always be executed when they are attached, the window's load event may have already occurred so listeners attached after that will never run.

Or perhaps, something like:

Handlers attached by .ready() may be called after handlers attached to a load event in some cases, and handlers attached to a load event will never be called if they are attached after the page has already loaded. Code should not assume they fire in a specific order.

A more extensive rewrite might help, but IMO there are already more words in that description than most people can bear to read. You can make a pull request at https://github.com/jquery/api.jquery.com/ .

Commented On 04 Aug 2022 at 10:02:28
Issue Comment

Dmethvin

:is:contains throw error unsupported pseudo: is

Description

If I use selector :is with selector contains I get error: Uncaught Error: Syntax error, unrecognized expression: unsupported pseudo: is

I checked it on Firefox and Chrome.

example: $(':is(h2):contains(a)')

Link to test case

https://codepen.io/amiadb/pen/qBooYzm

Forked On 04 Aug 2022 at 12:10:55

Dmethvin

jQuery tries to use the browser's native selector engine first. The browsers support :is() but not :contains() so they throw an error. jQuery then passes the selector to Sizzle which doesn't support :is() but does support :contains() so it throws the error you see there.

Also note that the string you are looking for in :contains() should be quoted.

As long as the entire selector can be parsed by either the browser or jQuery this will work. for example, try $(':is(h2)').filter(':contains("a")').css('color', 'red'); The first selector is parsed by the browser, and the second by jQuery.

Commented On 04 Aug 2022 at 12:10:55
Issue Comment

Dmethvin

Core: Drop support for IE (all versions)

Summary

This PR is to show what dropping IE support would look like in code. If we make a decision to drop IE in v4, this PR can be merged, guarded on possible review remarks.

Of course, dropping IE would open a lot of other doors for various refactors but those would be considered separately.

-627 bytes

Checklist

  • ~~New tests have been added to show the fix or feature works~~
  • [x] Grunt build and unit tests pass locally with these changes
  • ~~If needed, a docs issue/PR was created at https://github.com/jquery/api.jquery.com~~

Forked On 02 Aug 2022 at 01:15:17

Dmethvin

Seems like the right move at this point. Things clean up nicely!

Commented On 02 Aug 2022 at 01:15:17
Issue Comment

Dmethvin

KeyboardEvent: Missing getModifierState

Description

Original Ticket: https://github.com/jquery/jquery/issues/2774

The ticket above was accidentally closed but this issue is definitely still happening.

The getModifierState is not being passed in the KeyboardEvent.

With jQuery:

$( window ).on( 'keydown', function( event ) {
  var shift = event.getModifierState && event.getModifierState( 'Shift' );
  console.log( 'jQuery: Shift', shift );
}); 

If you press Shift key:

jQuery: Shift undefined

With plain javascript:

document.addEventListener( 'keydown', function( event ) {
  var shift = event.getModifierState && event.getModifierState( 'Shift' );
  console.log( 'JS: Shift', shift );
}); 

This is seen in the console:

JS: Shift true

Link to test case

JS Fiddle: http://jsfiddle.net/qfr0ocjs/

Forked On 19 Jul 2022 at 11:59:49

Dmethvin

The event in the jQuery handler is a jQuery event which is just a subset. The browser's Keyboard event is in event.originalEvent and should include everything that browser provides.

Commented On 19 Jul 2022 at 11:59:49
Issue Comment

Dmethvin

Cannot access a real data set again?

Description

Recently I have found that when accessing the data set of a jQuery object, we can't get the real one after accessing it again.

Test case

($x => { $x.data(); $x.attr('data-x', 1); return $x.data(); })($('<div>')); // => {}, rather than {x: 1} 

Forked On 08 Jul 2022 at 07:48:25

Dmethvin

That is the way it's documented to work. Setting the attribute after data has been fetched. doesn't have any effect on the data object.

Since jQuery 1.4.3, data-* attributes are used to initialize jQuery data. An element's data-* attributes are retrieved the first time the data() method is invoked upon it, and then are no longer accessed or mutated (all values are stored internally by jQuery).

https://api.jquery.com/data/#data-html5

Commented On 08 Jul 2022 at 07:48:25