jQuery.boxModel should be listed as removed

[usmonster]

jQuery.boxModel was removed in 1.8. There should probably be a note in the doc to this effect, similar to what's in the doc for jQuery.browser:

This property was removed in jQuery [1.8] and is available only through the jQuery.migrate plugin. Please try to use feature detection instead.

Possibly also add this to the "Removed" category?

jQuery.support.boxModel was also removed in 1.10, so perhaps the reference to jQuery.support should also be removed from the boxModel doc.

[mgol]

jQuery.boxModel was removed in 1.8. There should probably be a note in the doc to this effect, similar to what's in the doc for jQuery.browser:

That's true, thanks for noticing! We should also remove the example as it's no longer working (and we shouldn't make obsolete APIs easier to use).

jQuery.support.boxModel was also removed in 1.10, so perhaps the reference to jQuery.support should also be removed from the boxModel doc.

The whole jQuery.support API is subject to change wherever the jQuery team needs; this interface shouldn't be relied on which is clearly stated in the docs. Therefore, I don't think we should document anything about removing a specific property; note that recently we switched some of properties to functions; also, the 2.x branch has way more properties than the 1.x branch so we don't even have API parity here.

To be honest, I'd prefer to unpublish jQuery.support entirely as it's not meant for public consumption. There are three main reasons why it's still public:

1. jQuery UI/Mobile rely on it.
2. We need it for our tests.
3. It was public (a mistake on the team part) so we left it that way.

The second point could perhaps be addressed differently than just by exposing the API; the first could be changed to just export an empty object to which other libs can attach properties (or they could conditionally create it if it doesn't exist).

Anyway, nothing to document here IMO.

[usmonster]

Therefore, I don't think we should document anything about removing a specific property

I only meant the parenthetical part of the deprecation notice in the jQuery.boxModel doc ("see jQuery.support") should probably disappear, not that any part of the actual jQuery.support doc change. Though I agree that it should perhaps be unpublished altogether, if that turns out to be possible..

So, no new documentation to add (for jQuery.support), though maybe some to remove. :]

[mgol]

I only meant the parenthetical part of the deprecation notice in the jQuery.boxModel doc ("see jQuery.support") should probably disappear

Ah, this, you're right. :) Do you maybe want to submit a pull request with all these changes?

[JonathanThiyagarajan]

This removes all internal uses of jQuery.support.boxModel. jQuery has never run unit tests with Quirks Mode and has not even feigned support for several years, so these remnants weren't doing much except giving false hope.

For now, jQuery.support.boxModel continues to have a value indicating whether the W3C box model is generally in use, but be aware that this is easily overridden on an element-by-element basis by the box-model CSS property. So don't trust this value.

[mgol]

For now, jQuery.support.boxModel continues to have a value indicating whether the W3C box model is generally in use, but be aware that this is easily overridden on an element-by-element basis by the box-model CSS property. So don't trust this value.

What do you mean?

[usmonster]

@mzgol Sure, I can probably put in a pull request sometime in the next few days. :]

Also, I think @JonathanThiyagarajan means to say that the box-sizing CSS property could be set for some elements, so certain common use cases for jQuery.support.boxModel could yield false negatives when used without additional tests.

Still, I think it's better to recommend feature detection than to continue to point to jQuery.support.

[mgol]

Still, I think it's better to recommend feature detection than to continue to point to jQuery.support.

We should not discourage using jQuery.support anywhere in documentation, not only in the boxModel case.

[usmonster]

@mzgol Is there an extra "not" in your comment, or should "not only" be "only not"? It sounds like you now don't want me to remove the reference to jQuery.support in the jQuery.boxModel doc.. ?

[JonathanThiyagarajan]

@mzgol, Its not advisable to use when it can easily overridden, so its your Call

[mgol]

@mzgol Is there an extra "not" in your comment, or should "not only" be "only not"? It sounds like you now don't want me to remove the reference to jQuery.support in the jQuery.boxModel doc.. ?

Sorry if I was confusing. :) I meant that we should never encourage using jQuery.support so if there are any other places other than jQuery.boxModel, we should remove the encouragement from those places as well.

[usmonster]

@mzgol Ok, that makes more sense, thanks. :] I assume that should be two separate PRs?

[mgol]

@usmonster It makes sense to do it all in one PR/commit so if you find more of them, feel free to make all the changes together.

[scottgonzalez]

jQuery UI/Mobile rely on it.

I'm not sure about Mobile, but UI doesn't rely on any support tests from core. We do rely on $.support existing, but only because we add to it.

[usmonster]

@mzgol A quick grep shows no other encouragements to use jQuery.support exist.

In view of @scottgonzalez's comment and your desire to unpublish jQuery.support altogether, do you think this PR would be a good opportunity to at least deprecate it in the public API? Or is that something that would need to be discussed at a meeting and coordinated with other @jquery developers?

[dmethvin]

It's definitely an oversight that jQuery.support isn't on the deprecated list in docs. I don't think we can remove it any time soon. I did a search a while back and found plugins that assume it exists and either put their own detects in there or try to use an existing one.

[arschmitz]

mobile uses it the same as ui we only rely on it existing to add our own properties

[mgol]

Those are separate issues; we can expose an empty object in jQuery.support and keep our support tests results in a private place. That was my initial attempt; I've changed it to be able to test it and to limit changes done in 1.11/2.1 but if it can be done differently, I'd be in favor of returning to that previous solution.

[usmonster]

A quick grep shows no other encouragements to use jQuery.support exist.

On second glance, a couple of the examples in jQuery.cssHooks do make use of jQuery.support. We may want to modify or remove those examples if we do still want to deprecate jQuery.support, though I don't know if that needs to be done in the same pull request? Thoughts?

And just a recap of what I understand is wanted for the pull request:

• List jQuery.boxModel as removed (in 1.8)
• In same doc, add note to use feature detection instead
• In same doc, remove parenthetical reference to jQuery.support
• List jQuery.support as deprecated (in 1.11? please verify)

Unclear:

• Remove all examples from newly-deprecated jQuery.boxModel doc? (I'd actually argue against it)
• One of these?:
  1. Remove/rewrite examples in jQuery.cssHooks to not use jQuery.support?
  2. Add a note in the doc for jQuery.support to say that it is "an empty object that can be used for blabla see jQuery.cssHooks for an example" or sumesuch?

Please advise.

[mgol]

A quick grep shows no other encouragements to use jQuery.support exist.

On second glance, a couple of the examples in jQuery.cssHooks do make use of jQuery.support. We may want to modify or remove those examples if we do still want to deprecate jQuery.support, though I don't know if that needs to be done in the same pull request? Thoughts?

OK, this PR is meant to be mostly about jQuery.boxModel so we shouldn't mix removing jQuery.support mentions from many other places into it. It should be done as a separate commit (in a separate PR).

And just a recap of what I understand is wanted for the pull request: * List `jQuery.boxModel` as removed (in 1.9) * In same doc, add note to use feature detection instead

Is that really needed? What's the use case of jQuery.boxModel anyway? In 99% cases you know if you're developing a page in Quirks Mode (or if you don't know, turning quirks is usually not purposeful) so I'm not sure why one would need to even use feature detection here; it's better to just use information in the developer head. ;)

* In same doc, remove parenthetical reference to `jQuery.support`

+1

* List `jQuery.support` as deprecated (in 1.11? please verify)

jQuery.support page already states it's meant for internal use and it can be removed at any point in time; no need to formally deprecate it.

Unclear: * Remove all examples from newly-deprecated `jQuery.boxModel` doc? (I'd actually argue against it)

Yes, definitely remove. Both examples are mostly useless and the live one doesn't even work. They both should be removed.

* One of these?: 1. Remove/rewrite examples in `jQuery.cssHooks` to not use `jQuery.support`?

Yes, but in a separate PR which will generally discourage using jQuery.support.

2. Add a note in the doc for `jQuery.support` to say that is it "an empty object that can be used for blabla see `jQuery.cssHooks` for an example" or sumesuch?

No, that's not needed, we don't want to formalize using an empty object or whatever will be used (and we haven't even discussed it yet in the team), we just want no one to rely on its existence at all.

[scottgonzalez]

What's the use case of jQuery.boxModel anyway?

Third party code.

jQuery.support page already states it's meant for internal use and it can be removed at any point in time; no need to formally deprecate it.

Unless we want to eventually remove the property altogether.

[mgol]

jQuery.support page already states it's meant for internal use and it can be removed at any point in time; no need to formally deprecate it.

Unless we want to eventually remove the property altogether.

OK, in that case let's deprecate it!

[usmonster]

Hooray for deprecating jQuery.support! This will be done in a separate pull request, as suggested (issue forthcoming).

I'll also go ahead and add the note to use feature detection in place of jQuery.boxModel, as was done in the doc for jQuery.browser.

Thanks for the quick responses!

[AurelioDeRosa]

@mzgol in your comment you wrote

also, the 2.x branch has way more properties than the 1.x branch so we don't even have API parity here.

isn't the other way around (1.X has more properties than 2.X)? For example 1.X has ownLast, inlineBlockNeedsLayout, and deleteExpando that 2.X doesn't have.

[mgol]

Yes, I got it backwards, sorry. :)

Michał Gołębiowski

[usmonster]

This good to merge?

[kswedberg]

@usmonster: looks good to me. I'll merge. thanks for the ping.

[kswedberg]

Closed by e708998