Last modified: 2010-06-03 15:26:24 UTC
Please add a class to: * Usercssjsyoucanpreview * Userjsyoucanpreview * Usercssyoucanpreview * Userinvalidcssjstitle * Clearyourcache So user can add styles to this information. Thanks.
Should be IDs, not classes, as these messages only appear once per page.
Why IDs? Mostly classes are used in core for $wgOut->wrapWikiMsg( "<div class=... I would like to keep classes for consistency.
Just because we've been doing it badly in other places doesn't mean we should continue to do so in new code. IDs should be used to identify individual objects; classes should be used where the same styles need to be applied to multiple places in a document or site. That is the paradigm around which the scripts and browsers we use are based: an individual object identified by an ID can be accessed much more efficiently by JS using getElementById(), for instance, while there is no native implementation of getElementsByClass(); we have our own inefficient implementation, but it doesn't work particularly well or have good cross-browser support.
IDs added with r67230.
(In reply to comment #3) > IDs should be used to identify individual objects; In general yes, but how do you know what is going to appear only once in the future?
(In reply to comment #5) > (In reply to comment #3) > > IDs should be used to identify individual objects; > > In general yes, but how do you know what is going to appear only once in the > future? By making a common-sense judgement about what type of objects they are: namely, warnings which appear in one particular situation and have absolutely no reason to appear more than once per page. In the very unlikely event it becomes multi-present in the future then it can be changed to a class; any scripts accessing it in the assumption that it's singular will need to be updated anyway.
Scripts like CSS styles? We are already having multiple edit-areas due to ajax and other stuff, so I wouldn't see it highly unlikely that some warnings may appear multiple times in one page.
If the style is "display:none because it annoys me when I see it in-situ", then yes, it probably is appropriate for that stance to be reevaluated if it starts appearing in places other than where it was previously expected. If the script is "getElementById() so I can attach something else around it", then that process *definitely* needs to be reevaluated if we start displaying more than one. We can't magically break things only when they're supposed to be broken, or we wouldn't call it breakage :D Besides, what we're calling "breakage" here is, in most cases, the need to change a dot to a hash; hardly a fundamental rewrite...
