Page MenuHomePhabricator
Create Task
Maniphest T32497

Add css classes client-nojs and client-js for styling
Closed, ResolvedPublic
Actions

Description

Author: john

Description:
Add a class to the HTML element to identify clients that have Javascript on would aid developers in hiding things that are Javascript only and do not have a fallback, without having to add them via Javascript.

Example:

.client-nojs #someThing { display: none }

Would hide the #someThing element from showing when Javascript was off, and

.client-js #gizmo { color: blue;

Would set #gizmo to have a blue text color when javascript was on

Version: 1.17.x
Severity: enhancement

Details

Reference
bz30497

Related Objects
Search...

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 21 2014, 11:49 PM
• bzimport added a project: MediaWiki-JavaScript.
• bzimport set Reference to bz30497.
• bzimport created this task.Aug 21 2011, 11:35 PM
• bzimport added a comment.Aug 21 2011, 11:36 PM

john wrote:

Added feature

Attached:

b30497.patch1 KBDownload

• brion added a comment.Aug 23 2011, 6:31 PM

I was worried this could lead to some style flicker, but since we seem to have put the page startup module very early on now there's nothing to render yet at the time we change the class. Probably ok then. :D

• brion added a comment.Aug 23 2011, 6:33 PM

Committed for trunk/1.19 in r95318.

• bzimport added a comment.Sep 29 2011, 12:42 AM

jelle.zijlstra wrote:

This is now causing MediaWiki-generated HTML pages to fail the W3C validator, because html apparently is not allowed to have a class. See [[WP:VPT#There is no attribute "class"]]. Could these classes perhaps be put in <body> instead?

Krinkle added a comment.Sep 29 2011, 6:46 PM

(In reply to comment #4)

This is now causing MediaWiki-generated HTML pages to fail the W3C validator,
because html apparently is not allowed to have a class. See [[WP:VPT#There is
no attribute "class"]]. Could these classes perhaps be put in <body> instead?

Classes are allowed on the HTML element as of HTML5 as far as I know. Besides, the specification is only important as far as it does not contrast reality. The reality is that all browsers support it in HTML4 as well and it's in the specification as of HTML5.

Platonides added a comment.Nov 20 2011, 9:42 PM

Does it provide a benefit there over being at body?

DanielFriesen added a comment.Nov 21 2011, 10:42 PM

(In reply to comment #6)

Does it provide a benefit there over being at body?

Not that I can think of. I went from the assumption we'd have the compatibility issue just like with moving the other classes 'off' of <body>. But it looks like this was added relatively recently (ie: not in 1.18).

So, go ahead and change it. But do it now, and do it quickly, before 1.19 gets branched and the argument becomes "Is breaking compatibility worth moving the class from <html> to <body> simply to put it with the rest of the classes?".

• bzimport added a comment.Nov 21 2011, 10:53 PM

john wrote:

Done in r103856

• bzimport added a comment.Nov 22 2011, 3:59 PM

john wrote:

Nope reverted, <body> isn't available at that point.

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL