Last modified: 2013-09-04 11:49:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T32497, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 30497 - Add css classes client-nojs and client-js for styling
Add css classes client-nojs and client-js for styling
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.17.x
All All
: Low enhancement (vote)
: ---
Assigned To: John Du Hart
: patch, patch-reviewed
Depends on:
Blocks: 29714
  Show dependency treegraph
 
Reported: 2011-08-21 23:35 UTC by John Du Hart
Modified: 2013-09-04 11:49 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Added feature (1.36 KB, patch)
2011-08-21 23:36 UTC, John Du Hart
Details

Description John Du Hart 2011-08-21 23:35:40 UTC
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
Comment 1 John Du Hart 2011-08-21 23:36:24 UTC
Created attachment 8956 [details]
Added feature
Comment 2 Brion Vibber 2011-08-23 18:31:10 UTC
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
Comment 3 Brion Vibber 2011-08-23 18:33:41 UTC
Committed for trunk/1.19 in r95318.
Comment 4 Jelle Zijlstra 2011-09-29 00:42:28 UTC
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?
Comment 5 Krinkle 2011-09-29 18:46:32 UTC
(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.
Comment 6 Platonides 2011-11-20 21:42:59 UTC
Does it provide a benefit there over being at body?
Comment 7 Daniel Friesen 2011-11-21 22:42:56 UTC
(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?".
Comment 8 John Du Hart 2011-11-21 22:53:52 UTC
Done in r103856
Comment 9 John Du Hart 2011-11-22 15:59:45 UTC
Nope reverted, <body> isn't available at that point.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links