Wikipedia talk:Editnotice/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

Can accountcreators really edit editnotices?

The page says that editnotices can be edited by administrators and users in the "accountcreator" group, but most other pages that only administrators can edit them. Could someone please check this? --Ixfd64 (talk) 21:08, 25 November 2009 (UTC)

I believe the ability stems from the tb-override userright which is included with the acc bundle. (Special:UserGroupRights) –xeno^talk 21:13, 25 November 2009 (UTC)

You're right. I did some testing, and it turns out that accountcreators can indeed editnotices. I'm going to update the documentation. --Ixfd64 (talk) 21:36, 25 November 2009 (UTC)

Yes, it's the tb-override right just as Xeno said. Accountcreators need it since the title blacklist also controls blacklisted user names. Being able to edit editnotices is more or less an accident, but not particularly likely to cause harm. Amalthea 00:02, 26 November 2009 (UTC)

"View source" editnotice

Hey folks,

Where is the editnotice which appears when one tries to edit a protected page located? (for instance the one located at this URL.) I'd like to see if it's possible to have it detect sandboxes like it detects doc pages, to allow for quicker access to the sandbox if one tries to edit a protected template. Chris Cunningham (not at work) - talk 10:31, 2 December 2009 (UTC)

Do you mean MediaWiki:Protectedpagetext? I'm never quite sure which parser functions work in the MediaWiki space, but if it's possible then this sounds like a nice idea. — Martin (MSGJ · talk) 11:34, 2 December 2009 (UTC)

(Editconflict)

First a reminder to any admins reading this: Admins and regular users see different messages when viewing/editing a protected page. So to see what Chris is seeing you need to log out.

Hi Chris. Strictly speaking that is not an editnotice, but a "MediaWiki interface message". But editnotices are loaded in a similar way, so the difference is subtle. The quickest way to find interface messages is to search for them, and a search for "This page is currently" in the MediaWiki space turns up MediaWiki:Protectedpagetext and MediaWiki:Cascadeprotected. That's the two messages you see at the protected page you linked to, and the first is the one you are interested in. So since that one seems to be watched by a number of users, add your suggestion to its talk page. And I agree with your suggestion, the /sandbox pages are a great tool and need more marketing.

--David Göthberg (talk) 11:50, 2 December 2009 (UTC)

Excellent. The code looks pretty straightforward (a trivial alteration of the documentation detection) - I've left a comment on that page's talk with the new code drop. Chris Cunningham (not at work) - talk 11:57, 2 December 2009 (UTC)

Centralized discussion now at Wikipedia:MediaWiki messages. ---— Gadget850 (Ed) ^talk 13:48, 2 December 2009 (UTC)

User talk editnotice

I created an editnotice for my user talk (User talk:Ucucha/Editnotice), but for some reason this displays doubly when I edit my talk page ([1]). Anyone who knows what's going on there? Ucucha 23:45, 5 December 2009 (UTC)

I now see that the same happens at other pages with editnotices I edit, so it might be something in my user settings (Firefox 3.5.5, Vector, several scripts including wikEd). Ucucha 23:48, 5 December 2009 (UTC)

I see it only once. What happens if you log out? ---— Gadget850 (Ed) ^talk 00:25, 6 December 2009 (UTC)

Then I also see it only once. Ucucha 00:41, 6 December 2009 (UTC)

Clear your .js and purge— what happens? If that fixes it, add things back in chunks. ---— Gadget850 (Ed) ^talk 00:58, 6 December 2009 (UTC)

Allow more non-admins to edit?

Restricting editing of these pages to sysops and accountcreators seems to be a bit overkill to me. Could we perhaps use the abusefilter instead of the titleblacklist to allow users with, say, over 500 edits and a month's tenure to edit these pages? It's worth noting that the highly visible editnotices are already generally full protected to protect them from the accountcreators. ⇌ Jake Wartenberg 00:27, 10 December 2009 (UTC)

The AbuseFilter has a limited load, moving this there would probably increase the condition limit too much... Is there a problem this solution is meant to solve? Lack of people available or long wait times to create editnotices on request? –xeno^talk 01:27, 10 December 2009 (UTC)

What about changing the TBL entry to allow autoconfirmed users to edit these pages? I think the potential for vandalism is overblown. ⇌ Jake Wartenberg 01:52, 10 December 2009 (UTC)

Is there really an issue? Why open it up to more potential vandalism? If someone is really requesting edit notices to be created on a regular basis, I'm sure they can make a case for acc. –xeno^talk 01:59, 10 December 2009 (UTC)

I think we should start from a place where we ask, "Is the protection necessary?". People shouldn't have to go through {{editprotected}} if there isn't a compelling reason to make them do so. The unnecessary protection is in itself a problem - it is inconsistent with the ideology of this place. ⇌ Jake Wartenberg 02:08, 10 December 2009 (UTC)

I don't see the need for making them admin-only (or even autoconfirmed-only), but some people are really paranoid about vandalism or something. I don't really get it. Historically, they were protected because they were in the MediaWiki namespace, but that hasn't been the case for a long time. The title blacklist hack is effective, but someone's still going to have to sit me down sometime to explain how it's necessary or warranted. --MZMcBride (talk) 02:20, 10 December 2009 (UTC)

The main concern I have in opening these to general editing is some vandal doing something like this to the edit page. Sure, I could fix it and you could fix it, but there are many who couldn't. And if it were worded differently, many who would be scared out of their pants thinking they were in trouble for trying to "hack" the page or something else stupid like that. Personally, I can't think of any reason for one of these to be edited that an {{editprotected}} wouldn't take care of. Anomie⚔ 03:47, 10 December 2009 (UTC)

You could full protect any page with that logic. ⇌ Jake Wartenberg 08:04, 10 December 2009 (UTC)

How so? Anomie⚔ 13:35, 10 December 2009 (UTC)

I think the argument suggested is "Someone could vandalize an article and while WE could revert, some won't/don't know how. We should full-protect articles just in case." The analogy is a little weak in my opinion, but it does lead to Flagged Revisions pretty clearly. ~ Amory (u • t • c) 02:17, 11 December 2009 (UTC)

I agree in principle these should be open except when vandalized. There is the issue of watching them though - editnotices are much less visible than pages. Perhaps the right solution is to either change "rollbacker" to "highly trusted editor" and assign this to that role, or create a new role "editnoticeseditor" and hand that out on the same terms as rollbacker. Bonus if one or more skins could be modified to display the edit notices when editors viewed the page, so they had more visibility. In the meantime making sure editnotice changes showed up in the recent-change log and requesting recent-change patrollers to scrutinize such edits carefully would probably be sufficient. davidwr/(talk)/(contribs)/(e-mail) 03:15, 10 December 2009 (UTC)

The template newpages backlog is patrolled regularly, I believe. That should suffice. ⇌ Jake Wartenberg 03:24, 10 December 2009 (UTC)

Correct me if I'mw wrong, but WP:NPP only works for new templates, not vandalization of existing ones. davidwr/(talk)/(contribs)/(e-mail) 03:31, 10 December 2009 (UTC)

That's true. Existing editnotices are more likely to be on watchlists, though, and the highly visible ones are fully protected. ⇌ Jake Wartenberg 03:36, 10 December 2009 (UTC)

There are several reasons why it is problematic to let everyone edit the editnotices:

1: The editnotices don't appear on the watchlist of users that are watching a page.

2: As has been already pointed out in this discussion there are some pretty nasty things that can be done with editnotices. And it is possible to do much worse hacks than most of you know about, since the content of editnotices is not filtered by MediaWiki as hard as article text is filtered. But I won't go into details about that... (Especially since the user space editnotices currently are unprotected.) The editnotices are loaded into a MediaWiki message so they are still indirectly in MediaWiki space, and have the same security problems as MediaWiki messages have.

3: But the most frequent problem is the edit wars that editnotices tend to attract. We have tried to have some editnotices open. But what happened was that editors tried to use them to own the article, by telling other editors what they may and may not add in the article. That might scare away editors that don't understand that it is "just" an editnotice. And those editnotices then caused protracted edit wars.

By the way, I find it nice that rollbackers can edit the editnotices, since the rollbackers are editors we trust. I don't see the need to create a new role especially for editnotice editing, but renaming the rollbacker role to "trusted editor" could be nice.

--David Göthberg (talk) 08:06, 10 December 2009 (UTC)

Rollbackers can't edit these pages; if that were the case I would be quite happy with it as a solution. The accountcreator group is much more obscure. You make a very good point with number 3. I imagine in such cases, though, that the editnotice would be protected. ⇌ Jake Wartenberg 08:19, 10 December 2009 (UTC)

I must have missed something. What's the problem being solved by allowing a broader selection of editors access to this? Josh Parris 12:17, 10 December 2009 (UTC)

Jake: Oops, you are right, it is the accountcreators that can edit the editnotices. (And the admins and up.) But it might be nice if the rollbackers could edit them too, if it is easy to make it so.

Regarding point 3: The problem is that it often would take some time before an admin is notified about a bad edit notice and fixes it and protects it. And in the meantime that editnotice can have scared a lot of decent editors.

Josh: It is a pretty big step between being a regular editor and an admin, since as an admin we can do all kinds of "dangerous" stuff. Thus we have pretty stringent procedures to become admin, and thus we have a lack of admins. So having trusted users that can offload some work from us admins would be a good thing. The editnotices are such an intermediate thing that trusted users could help us with. Although as you say, we don't really need help with them, so it is more about the principle to have things as open as possible.

Personally I think that editnotices probably already are overused in articles. But using editnotices in other namespaces is often a good thing.

--David Göthberg (talk) 19:07, 10 December 2009 (UTC)

I think it's high time for a "trusted" user group that includes the rollback,acc,and autoreviewer rights. –xeno^talk 19:09, 10 December 2009 (UTC)

If a "trusted" user group is created, then I think it should take two admins to make a user trusted, but only one admin to make a user untrusted again. Not as now that a single admin can assign such rights to a user.

--David Göthberg (talk) 19:17, 10 December 2009 (UTC)

But it currently only takes 1 admin to assign all three rights groups ;> I think that would be fine though, could be discussed at WT:PERM if/when a group gets created. –xeno^talk 19:22, 10 December 2009 (UTC)

Comment Personally, I would like to see 2 admins to give out "minor" bits like rollback, ipblock-exempt, accountcreator, edit filter manager, and the like, to act as a check and balance on the strength of the justification and the trustworthiness of the editor. One editor should be able to remove them for cause. In cases of dispute, admins as a group could have an admin-chat. davidwr/(talk)/(contribs)/(e-mail) 22:58, 10 December 2009 (UTC)

• I don't see any compelling reason to open editing up and a serious potential to cause problems - in good faith or bad. Additionally, edit notices should only be used rarely to begin with. As such, I would oppose any changes at this time. --ThaddeusB (talk) 01:25, 12 December 2009 (UTC)

I gave this some further thought today (long drive) and had a few more comments to share.

I still find two of the arguments presented here very weak. While it's true that someone could create an editnotice for someone and perhaps they wouldn't notice, the exact same argument applies to someone creating User:User/User hates puppies and kicks them regularly. There's similarly no notification of such a page creation.

The second point involves visibility. There are plenty of templates that are used on dozens or hundreds of pages that are free for anyone and everyone to edit. And changing them has an immediate impact on the contents of a lot of articles that are viewed by a lot of people every minute. That actually impacts our readers, who are far less likely to understand the nature of vandalism on Wikipedia. The same simply can't be said for people who are editors (and not simply readers). Editnotices are dramatically less visible to most people, and those who do see them are generally those who understand Wikipedia's nature (including the vandalism component). These pages really aren't any different from other pages. And they're not really different from the old system that used HTML comments (<!-- -->) instead of putting the message outside the textarea. Making them restricted from improvements, categorizations, etc. seems to heavily favor cost in the cost-benefit equation.

That said, the accountcreator group can override this restriction, so perhaps one hack can beget another. People can simply request that group if they want to edit editnotices regularly. I certainly wouldn't deny such a request. --MZMcBride (talk) 05:00, 15 December 2009 (UTC)

Navbar

Could Template:Editnotice load be adjusted to include a navbar for the edit notice? I think this would be highly convenient. — Martin (MSGJ · talk) 15:28, 18 August 2009 (UTC)

Should it be hidden by default? Since editnotices are only editable by admins... –xeno^talk 15:29, 18 August 2009 (UTC)

In the long section about the loader above I mentioned two possibilities to integrate navigational links into the editnotice template itself: this one and that one.
David's loader had "view" links integrated into the loader, as you propose, Martin, and that could work automatically in most instances. It's a bit less flexible, doesn't work with the group notices (of which there are very few though), and not as neat IMO since it isn't integrated into the editnotice div.
Amalthea 15:58, 18 August 2009 (UTC)

I quite like User:Amalthea/test12/Template:Editnotice. Maybe the v.d.e style link would be less intrusive? And no, I don't think it should be hidden - a link to the talk page of the editnotice would be useful for editors who wish to request changes. — Martin (MSGJ · talk) 13:53, 23 August 2009 (UTC)

Hello? — Martin (MSGJ · talk) 17:23, 3 September 2009 (UTC)

Yes? Amalthea 18:23, 3 September 2009 (UTC)

Can we implement the navbar? :) — Martin (MSGJ · talk) 19:15, 3 September 2009 (UTC)

Would the code in Template:Editnotice load/sandbox work as intended? — Martin (MSGJ · talk) 13:09, 4 September 2009 (UTC)

Ah, the impatience of the young. ;)
It would produce the correct nav links, but they'd be positioned somewhere at the bottom of the page, I think. I've tweaked it a little, but didn't really test it.
It would also show the v·d·e links on every page in template namespace, even if the check in Template:Editnotices/Namespace/Template fails and no actual edit notice is displayed. Amalthea 13:49, 4 September 2009 (UTC)

So what do you think? Should I add the feature to the editnotice template instead, and manually add it to all specialized notice that don't use {{editnotice}}? I'm usually all for automatic solutions, but it won't work with some of the more complex cases, so I guess I prefer adapting the editnotice. Amalthea 17:26, 9 September 2009 (UTC)

(outdent) Testing for a non-empty output as well as existence is pretty easy, e.g.

{{#ifexist:Template:Editnotices/Group/{{FULLROOTPAGENAME}}
 |{{#if:{{Template:Editnotices/Group/{{FULLROOTPAGENAME}}}}
  |{{navbar}}
 }}
}}

So the only issue is whether we can position it correctly from {{editnotice load}}. — Martin (MSGJ · talk) 18:11, 9 September 2009 (UTC)

MSGJ: During testing I realised you are correct, we should treat blanked notices the same as non-existent notices. So I have added that to my new version of the loader, and it works fine. (The new version is not deployed yet, see {{editnotice load/test1}}.) We don't need to check for blanked namespace notices since we don't add links to them. So I only check for blanked group and page notices, and that part of the code is in {{editnotice load/core}}.

--David Göthberg (talk) 12:50, 7 January 2010 (UTC)

Amalthea: Regarding your first message above:

My old prototype {{editnotice loader}} does have "view" links both above the group notices and the page notices.

And there are two reasons why I didn't add the view links inside the editnotice boxes:

1: That would require that all users use the same template to add editnotices, thus being less flexible.

2: I found no good way to place the view link in the upper right corner of a box that worked in all browsers and that didn't interfere with the content layout inside the box. The only way that "works" is to use a table row for it, but that means we are messing with the contents of the box, thus less flexible.

Some of the reasons why I choose to use just a "view" link and not "v-d-e" links are these:

1: For users that can't edit the editnotice the "e" link is silly. And that means 99% of the users that see most editnotices.

2: I don't want the "d" link, since I don't want users to discuss a page editnotice on the talk page of the editnotice, since such talk pages are not watched by many users. Instead I think page editnotices should be discussed on the talk page of the page where the editnotice is used.

I even did build and test a system that worked like this: When you went to the editnotice page (by following the "view" link), and then choose to edit (or for non-admins "view source") then a box was displayed that explained that the page is an editnotice, and what page the editnotice was intended for with a link there, and a link to the talk page where that editnotice should be discussed. I also made an editnotice that automatically showed above all editnotice talk pages, so when you tried to edit the talkpage of an editnotice it would tell you to go to the talk page of the article instead (with link there) to discuss the editnotice.

That works just as well for group editnotices: I think group editnotices should be discussed on the talk page of the top page of the group. And the same functions as I described above for page editnotices works just as well for group editnotices. That is, I can display a box above a group editnotice that links to the right talk page to discuss it, and an editnotice on the group editnotice's talk page that also links to the proper talk page.

I am sorry that my {{editnotice loader}} currently only displays part of that system, since another admin shot my system to pieces by deleting the editnotices used by that system.

Regarding Xenos comment above: Ah, you figured that out too? I recently figured out how we can show things only to admins or selected other groups of users. So when there is no group editnotice or page editnotice we can show small red links to create those editnotices. I wouldn't like to show those links to all users, since 99% of the users can't create those editnotices. Of course, above the user pages is another thing, there we have to decide if we should show the links to everyone, or perhaps just to admins and the user who's user page it is (which is pretty easy to do).

--David Göthberg (talk) 06:29, 30 December 2009 (UTC)

All of these ideas sound interesting. I agree that a "view" link alone is sufficient. Can we see some testcases and think about how to display it in the best way? — Martin (MSGJ · talk) 09:38, 5 January 2010 (UTC)

MSGJ: Just click on {{editnotice loader}}, at the top of that template page you see how my "view" links look. You don't need to edit the template to see those "view" links, since it displays its output right there on the template page. (Unfortunately you don't see them when editing that template, since as I mentioned some admins have deleted most of my demo-system.)

--David Göthberg (talk) 10:05, 5 January 2010 (UTC)

Personally, I wouldn't mind enforcing that all mainspace editnotices use the proper {{editnotice}} template, where the backlink could be built in. True that handcrafted notices would need to add that link manually, that's not difficult to do using a template though. And I believe I checked the two variants I prepared (1 2) in at least four browsers and it looked good, but I'd have to recheck it. I also don't agree that group notices should be discussed at the main group template, not least because it's harder to view it there. Current discussion seems to have taken place at the actual notice, e.g. Template talk:Editnotices/Group/Wikipedia:Arbitration/Requests.
Hmm, I'm unsure. One method gives proper links even to indirect group notices (and actually more flexible, not less), the other is less work and more automatized. Of course, there are so few group notices that it hardly matters. Actually, and even though splitting the approach sounds like a bad idea at first, we could even use the generic system for page and namespace notices and add the view link manually to the four group notices. I think I actually favor that. Amalthea 11:01, 5 January 2010 (UTC)

There are much more than four group notices, see Special:PrefixIndex/Template:Editnotices/Group/. And people have been asking for group notices but this feature has been kept secret, it is not documented anywhere, so no wonder there are not that many group notices. If/when we make the editnotice system user-friendly then the number of group notices will most likely increase quickly. So I say hand-coding it in each group notice is not an option.

And regarding your demonstration notices: Having the links at the bottom looks odd to me. For instance navboxes have their v-d-e links in the top left or right corner. Your User:Amalthea/test12/Template:Editnotice have a whole line at the bottom that is unused, which looks strange. And your User:Amalthea/test12/Template:Editnotice2 breaks in older versions of Internet Explorer.

This needs to work in all namespaces, not just main (article) space. I think many users will strongly oppose if you try to enforce a template like {{editnotice}}. That template isn't parameter compatible with the other message boxes, it doesn't handle images especially well, and last time I looked it used odd layout tricks.

Having the "view" links outside the group and page editnotice boxes (for instance above the top right corner) works no matter what content people add as editnotices, it works in all browsers, it is easy to add in the code of the editnotice loader, and I think it looks good. Also, it means we can show links to create those notices in the same place, if the notice doesn't exist and the user is an admin.

I have demonstrated working code for this for 1 year and 3 months now. But I got tired of waiting so I use a javascript that adds the links I need to the group, page and user notices. But it would be nice if the editnotice system was user-friendly for other users too. (And no, we shouldn't add it with javascript, since we can do it better with template code.)

--David Göthberg (talk) 12:44, 5 January 2010 (UTC)

I'm not objecting the change. Having any kind of backlink is an improvement, and embedding the links in the loader is certainly the most elegant and easy, so feel free to make the change.
What's your trick to only show the redlinks for admins (and accountcreators, hopefully)? I can only think of a bit of css injected by MediaWiki:Sysop.js, to overwrite a group dependent class and make it visible, do you know a more elegant way?
Cheers, Amalthea 13:25, 5 January 2010 (UTC)

Okay, thanks. I'll add the links in some day or so.

I already have the code for the blue links. But for the red links I will have to think a little more, since they flow a little oddly when right aligned. I have some solutions to that, but it involves some messy template code. Here's how the red links could look, if I use simple code:

Group editnotice

Page editnotice

But that takes up two lines, so I would like them to look like this:

Group editnotice   Page editnotice

But the silly thing is since the group notices comes first (above) in the editnotice loader, then the small right floating links tend to place themselves like this:

Page editnotice   Group editnotice

But that is confusing for us humans since we expect the group-notice link to come first (to the left) since group notices are displayed above the page notices. But I can fix that, with some messy template code...

Oh, and is the naming of those red links okay?

Amalthea: Yes, that is the method I would use to make the links only visible to admins and accountcreators.

For anyone else interested in the details: In the editnotice loader I would hardcode <div class="sysop-show accountcreator-show" style="display: none;"></div>. Then I would put the following code in MediaWiki:Sysop.css: div.sysop-show { display: block !important; }. And we could create a MediaWiki:Accountcreator.css too, or simply add that CSS code directly from javascript.

This means that regular users won't see it, even if they have javascript disabled. Also, those classes can be reused for any other items, not just for our editnotice links. That also means any other users that want to see what we admins see can turn it on by adding that CSS to their personal /monobook.css, and I don't think that would hurt.

And for the editnotice for a user page, that anyone can edit: Should we show the red link to the "Page editnotice" to everyone (including IP-users), or just all logged in users, or just the user himself (and admins and accountcreators), or only to admins and accountcreators?

--David Göthberg (talk) 14:43, 5 January 2010 (UTC)

I have now updated the loader with parts of this. It now has "view" links. And I added "clear:both;" in more places so notices won't flow into the next section. (This happens if a notice has a left or right floating box or a large image thumbnail. We have had such cases in some user notices.)

I have not added the red create links yet, since I first have to update several global .css and .js pages so we can hide the links for normal users and show them only for admins and accountcreators. I have done parts of those updates, if anyone is interested in the technical details about that, see MediaWiki talk:Common.css#Hidden items (explains and demonstrates the show/hide function) and MediaWiki talk:Common.js#Accountcreator CSS.

--David Göthberg (talk) 16:32, 6 January 2010 (UTC)

I have now coded up a version of the editnotice loader that shows red create links if there is no group notice or no page notice. When using "view" as link text it became confusing when there were both a group notice and page notice. And it was also weird for us admins since we always see both links. So I have now chosen to always call the links "Group notice" and "Page notice". If there are both notices the links are shown on top of each notice. Like this:

Group notice

Page notice

If there is only one notice, then both links are shown on top of that notice, but one of them is red and one is blue thus making it clear which notice is shown and which can be created. For instance, if there is a group notice but no page notice, then for an admin or accountcreator it can look like this:

Group notice   Page notice

(It looked bad to have a create link dangling below or above the whole thing, it looks better with both links on one line.)

Normal users only see the links for existing notices, except on user basepages where they can also see a create link for a "Page notice". So on a user basepage with only a group notice they would see the same thing as an admin or accountcreator, as in the example above. But on any other kind of page they will see this:

Group notice

There are many more possible combinations, to many to demonstrate here. This is the best layout and link naming I could come up with so far. What do the rest of you guys think?

My new version is at {{editnotice load/test1}}, it is more or less ready to deploy.

--David Göthberg (talk) 04:54, 7 January 2010 (UTC)

Navbar, section break

It's all looking very good. I agree that "view notice" is preferable because "view" alone was quite ambiguous. I have one small concern though. All the examples above look right to me, but if you look at the group notice on Wikipedia:In the news/Candidates/4 January 2010, for example, the "view" link is significantly higher than the box on my browser. Any reason why? — Martin (MSGJ · talk) 16:33, 7 January 2010 (UTC)

I ran some more tests: Sometimes I see it in my old IE 5.5, but just sometimes. But it looks right in my slightly old Firefox 2.0 and my Opera 10.10. What browser and what operating system are you using?

Apparently his happens in (older versions of?) Internet Explorer when there is an empty namespace notice, thus causing an empty namespace-notice <div></div> before that view link. If I give that div some styles, for instance set it to 100% width, then Internet Explorer doesn't choke on it. I have applied that fix to the current namespace loader.

MSGJ: Does it look right for you now? And thanks for reporting this bug.

--David Göthberg (talk) 18:13, 7 January 2010 (UTC)

I did some more tests and Internet Explorer causes the bug under some other circumstances too. But the adding of "width: 100%;" to the divs fixed it for those cases too.

--David Göthberg (talk) 19:36, 7 January 2010 (UTC)

I have deployed the new version with red creation links. The red links are only visible to admins and accountcreators, and to normal users when on a user page. As described above it has better placing and naming of the links. And per MSGJs excellent code suggestion above it now treats blanked notices the same as non-existent notices, which means it doesn't show links to blanked notices to non-admins, and places the links it shows to admins the same way as for non-existing notices.

I have done extensive testing. And I did a run at browsershots.org, it looked good in all 45 browsers in that run. But there is no better way to get feedback and bug reports than deploying...

My only concern is that this perhaps makes the editnotice system to user friendly. People might run amok and create editnotices like never before. :))

--David Göthberg (talk) 21:54, 7 January 2010 (UTC)

Just to confirm that everything is looking good from this end, including from the old version of internet explorer that I have at work. Nice work. — Martin (MSGJ · talk) 00:01, 9 January 2010 (UTC)