Ticket #10485 (closed feature: wontfix)
use @hidden attribute to toggle visibility
| Reported by: | paul.irish | Owned by: | rwaldron |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | effects | Version: | git |
| Keywords: | 1.9-discuss | Cc: | |
| Blocking: | Blocked by: |
Description
(in supporting browsers)
That way we dont need to capture current display value, cache it, and restore it.
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute
Implemented in FF, Chrome, Saf, and Opera: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)#Global
Change History
comment:1 Changed 21 months ago by rwaldron
- Owner set to rwaldron
- Priority changed from undecided to low
- Status changed from new to assigned
- Component changed from unfiled to effects
- Milestone changed from None to 1.next
comment:2 follow-up: ↓ 4 Changed 19 months ago by mikesherov
Holy shit we need this. defaultDisplay() is a disaster.
comment:3 Changed 19 months ago by timmywil
We've explored this before and it didn't seem to give us much. Unfortunately, we'll always need defaultDisplay and we'll always have to check, if for no other reason than user stylesheets can set display to none.
comment:5 Changed 19 months ago by rwaldron
Also, defaultDisplay() doesn't have anything to do with determining if something is hidden or not displayed. It's purpose is to restore display to the correct value for a given node; regardless of what the user land code has done.
comment:7 Changed 9 months ago by dmethvin
- Type changed from enhancement to feature
Bulk change from enhancement to feature.
comment:8 Changed 9 months ago by anonymous
I want to implement this.
What’s the expected behavior? Should IE<10 use old way and browsers that support hidden just toggle hidden attr?
comment:9 Changed 9 months ago by dmethvin
I think that's part of the assignment. Also to determine whether this complicates our own internal checks to see if an element is hidden. If we end up having to create two completely different paths for hiding elements and need additional checks for hidden elements, the benefits would have to be really good.
Also just to clarify, the team may vote that a feature is worth investigating and even implementing, but determine that the final result isn't worth its code or complexity cost. The vote is not a commitment to land any particular code.
comment:10 Changed 9 months ago by dmethvin
-1, We'd need the old path, even in jQuery 2.0, since IE9 doesn't have @hidden. Can't imagine any perf benefit either.
comment:11 Changed 9 months ago by mikesherov
-1, Seems like unnecessary complexity until all browsers without this feature die. It's unfortunate.
comment:12 Changed 9 months ago by gibson042
-1 for the foreseeable future.
comment:13 Changed 8 months ago by gibson042
-1
comment:14 Changed 8 months ago by dmethvin
- Status changed from assigned to closed
- Resolution set to wontfix
No benefit until post-IE9 so let's not tackle any time soon.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.
This will be nice if it can stop the defaultDisplay() path