Last modified: 2014-08-09 16:38:32 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 T66040, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 64040 - Minor edit class inconsistent
Minor edit class inconsistent
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
1.23.0
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-16 23:54 UTC by Jon
Modified: 2014-08-09 16:38 UTC (History)
2 users (show)

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


Attachments

Description Jon 2014-04-16 23:54:35 UTC
In the history page, the class "minoredit" is used. This should probably be "minor-edit" though since it is two words.

HTML produced is:
<abbr class="minoredit" title="This is a minor edit">m</abbr>

Expected:
<abbr class="minor-edit" title="This is a minor edit">m</abbr>
Comment 1 Umherirrender 2014-04-17 14:39:11 UTC
Support WONTFIX, because changing css classes breaks user styles.

The class is also used on Special:RecentChanges and friends. It is defined in $wgRecentChangesFlags.
Comment 2 Jon 2014-04-17 15:19:19 UTC
This is just one example. I'd like us to move closer to more consistency in our CSS.

I don't think user CSS should hold back development of a piece of software. There are ways round this for example have some kind of legacy class flag which adds two classes minor-edit and minoredit class for wikipedia.

Maybe I should do an audit of other inconsistent class named and turn this into a bigger bug? Andre thoughts?

That said it is a bug although super low priority.
Comment 3 Umherirrender 2014-04-17 15:31:05 UTC
What does it help, when the class is called 'minor-edit'? Breaking user styles just to rename a descriptive name by another descriptive name is bad and should not be done in my opinion. Having two clases makes the html only bigger for now effect.

When the rename is needed, than you should think about a 'mw-' prefix for the new classes.
Comment 4 Jon 2014-04-17 15:55:17 UTC
yes an mw-minor-edit might make more sense. Your mentioning of it proves to me that this bug should be fixed.

I currently develop on mediawiki software I see inconsistent class names in new products and I believe this is due to the broken windows theory. Core has lots of inconsistent classes which lead to bad development practices as people copy what is around them. It also looks bad and offputting to a new would be developer as it looks like we don't care about our code.

Users changing their CSS is a minor inconvenience.

I'm not saying it is urgent this bug should be fixed but there IS gain and it should be fixed.
Comment 5 masterloki 2014-08-07 11:24:16 UTC
Is there a way to trace where the changes should be made?
Comment 6 Gerrit Notification Bot 2014-08-08 08:34:24 UTC
Change 152853 had a related patch set uploaded by Mloki0:
Minor CSS class fix

https://gerrit.wikimedia.org/r/152853
Comment 7 Nemo 2014-08-09 16:38:32 UTC
Patch has -1. So, should class="minoredit" become class="minoredit mw-minor-edit" or what? If there's no BC way to amend the patch, please close this bug as WONTFIX for clarity.

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


Navigation
Links