#16810 closed defect (bug) (fixed)
hide-if-no-js not working on Most Used link
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.3 | Priority: | normal |
Severity: | minor | Version: | |
Component: | Administration | Keywords: | has-patch 3.3-early |
Focuses: | Cc: |
Description
The Most Used link of hierarchical taxonomy like Category is shown on Post page with Java script disabled, which should get hidden by default.
The tab has hide-if-no-js class but it gets overridden with display:inline somehow.
Also shows on WordPress.com sites.
Attachments (2)
Change History (16)
#2
in reply to:
↑ 1
@
14 years ago
Replying to hakre:
Can you add a link on a wp.org install to reproduce it more easily?
To recreate the problem: disable the javascript->open the add new post page->here you can see the most used link on category widget,though i think it shouldn't be visible and it doesn't work either.
@
14 years ago
make sure -no-js styling doesn't get overridden by more specific instructions elsewhere
#3
@
14 years ago
- Keywords has-patch added
It's getting overridden in wp-admin.css by
#side-sortables .category-tabs li, #side-sortables .add-menu-item-tabs li { display: inline }
Actually this happens in quite a few places. We need to bump the importance of the no-js styling.
#4
@
14 years ago
- Keywords 3.3-early added
- Milestone changed from Awaiting Review to Future Release
I'm comfortable with this patch. Early 3.3.
#7
@
14 years ago
I'm generally very much against using !important
anywhere but perhaps it's warranted in this case.
#8
@
14 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In [18664]:
#9
@
14 years ago
Turns out this causing some undesirable side-effects, maybe !important
is a bad idea after all. See #18656.
#11
@
14 years ago
So this probably should be fixed on a case-by-case basis.
16810.patch fixes the initial reported issue with the "Most Used" link.
#12
@
14 years ago
When I looked into this the first time I found at least 3-4 other cases where the same thing was happening. I can't remember where they were now but will see if I can find them.
Fixing them on a case-by-case basis is going to be tedious to maintain, because any change to the specificity of the selectors in future could cause the problem to resurface. That said, I can't think of a less awkward solution either.
Can you add a link on a wp.org install to reproduce it more easily?