May 12 2015
The gadget (on enwiki) was missing the dependency on mediawiki.cookie in gadgets-definition. I've added it. Can you see if that clears the problem? I will try to recreate the error that I encountered.
May 9 2015
May 2 2015
Because most patches are abandoned, and any solution will involve too much payload just to solve an edge case.
Same problem: backward compatibility.
Define 'selected'. Active tabs already have a selected style. I think OP means 'highlighted' to indicate a control has focus? There is a clear distincion between those two in UIX land.
The consensus seems to be that they should not be the same. So yes, 'declined' is the better choice.
Suggest declining. Loading the content before the rest of the UI was a concious design decision.
The min-widht has since been removed. That should resolve the issue. Otherwise, it must be cause by an external factor.
There is little positive feedback for this proposal, so closing.
Apr 30 2015
Please abandon any associated patches.
Apr 29 2015
Claiming task, since nothing is happening. I'll be creating some testcases which we can choose from.
It hasn't been deployed yet. We could ping a dev to ask for a lightning deploy.
Apr 28 2015
Closing, as padding has been adjusted.
It will work in Opera >12 (which is Webkit). The overflow condition only applies to non-textareas. The Mozilla page is slightly outdated. Not really an issue.
Apr 27 2015
Apr 26 2015
Any reason why this should not be applied to every pre-formatted text? Or all text for that matter?
Apr 20 2015
I'm with TheDJ. We still don't have a drop-in replacement... Wasn't this supposed to be superceded with GlobalGadgets/ResourceLoader 3.0 (or whatever version)? Until that is here, we should maintain these as (legacy) wrappers for mw.loader.load.
Apr 13 2015
I agree... I choose 25em initially, but failed to test it 'live'. 24em seems like a good value.
Apr 10 2015
Apr 6 2015
The more I think about it, the more I am puzzled. The argument for sorting is "consistency", but this has not been thought through. When two specific indicators are used on multiple pages, their order would be consistent, but that is also easily achieved within the templates utilizing the indicators.
Apr 2 2015
Pretty much what we had here, but they have a big gutter to work with...
Mar 29 2015
Users should not have to hack around with the name parameter just to get them in the right order (with the unpredictive results mentioned above). How about only excluding user pages from auto-sorting.?
Mar 28 2015
I recommend that users who want reliable custom ordering just place a single <indicator/> tag on their pages, with whatever content they want inside, in whatever order they want it.
Mar 25 2015
U+1F517 is only workable using a webfont, as no standard font (that I know of) supports this character. I suggested putting the link symbol in WikiFont earlier.
Mar 22 2015
Noted and considered. 0.3em vertical is still too high. I'll submit a patch shortly.
That is not much of an argument... I could say no one has made an issue of 0.2em either. 0.3em is just too high and unbalances the horizontal/vertical padding. I conceded to the horizontal padding being too tight, but there was nothing wrong with the vertical padding. So unless there is an actual case for the vertical padding... don't change what's not broken.
Mar 17 2015
Good... it was over-engineered anyway. A simple link within the header toolbar, or right-float inside the header is far simpler and less intrusive.
Mar 16 2015
I have incorporated 0.2em 0.4em for testing on enwiki. Any progress here?
Mar 11 2015
It concerns both desktop and mobile, so i would say rename.
Mar 10 2015
That is somewhat expected; columns actually behave as one long page, which have basically been cut into three pieces. So when content is added, anything 'below' is pushed 'down' to the next column.
Mar 7 2015
It works in so far that the paragraphs are not broken up. In the context of pagebreaks, columns are treated as pages. Anyway, we should just avoid breaks in the list items for the time being.
I know the horizontal padding is tight, but I believe that is because real estate in tables is premium in most uses. So any increase will cause a number of tables to be wider that the display window, necessitating horizontal scrolling.
Created a duplicate task (T91891) shortly after this one. So copying key point here:
Mar 5 2015
In response to the main page, or other pages where the links are not wanted: How about a __NOSECTIONLINKS__ magic word?
@Elitre, right-click, 'Copy link'.
That hurts... :)
@matmarex, the break-before/inside/after properties enjoy a wider support then columns, so I foresee no problems there.
In that case, the avoid-break code should be aplied to the individual list items, and not the entire block.
@Sumit, What determined the break between columns when tables were used? That same algorith can be used to allow/force a column break as well by inserting an element that has page-break-before: always; property set.
Reopening, because I am not quite happy with its implementation.
Mar 2 2015
I've suggested better wording on the patch, because it was quite clunky.
Feb 27 2015
Feb 26 2015
Can't find any off-hand, but there are template relying on it. Also tables are known to fight for space, and this doesn't help. Regardless, such a visual change should have been initiated as a bug/task.
Where is the task discussing this? This is not a "slight" increase, it's doubled, and it is very noticable. It also messes up table based templates like infobox that rely of default wikitable styling.
I was referring to content in general. The main text usually 'flows' around floating obejcts like images and infoboxes. These floating elements have margins to prevent them from colliding with the main content. Since the floating object reside inside the main content, giving a margin to the main content makes no sense.
Feb 25 2015
Non-floating content never has side margins.
Feb 24 2015
Because the frame comes with a (wider) margin.
Feb 23 2015
Even so, without MobileFrontend, he would revert to the Desktop view.
The reported issues may seem different, but the root cause is the same, and known.
It is a duplicate issue; the root cause is the same, namely because lists are styled with list-style-position: outside; to make list indentations uniform. This has always conflicted with left floating content.
Feb 20 2015
Feb 18 2015
You wouldn't have to expand anything (except perhaps as alias for |link=); it would only be there for MediaViewer to pick up so it can display the right image.
Another possible solution is auto-logic is too complicated: add some directive for MediaViewer to image syntax pointing to non-cropped image (|imagelink=).
Feb 17 2015
From what I can see in Resources.php, loading only the (default) skinning/elements.css and not content.css or interface.css.
Feb 16 2015
It works. It does show that the gutter in Monobook is very tight.
For anyone interested in testing out this feature, there's now a public demo at http://m4m.wmflabs.org/wiki/Slate.
In T37338#1040792, @Mattflaschen wrote:
This could be because you don't have MobileFrontend installed.
Feb 15 2015
@polybuildr, That would result in more redundant code.
You know what... I am annoyed enough to reopen this.
I know we don't support IE6 anymore, but does that mean we should actively break IE6?
Feb 14 2015
As for text-decoration:none, the patch does applied it on :hover and :focus while the existing styling already removes it from normal a tags, AFAIK.
The padding only extends the 'clickable' area, but in case of H1 and H2, extends too far into the actual header.
In the off-chance some user script or style actually depends on .first, I'd feel safer if the skin (vector.php) just adds the class statically.
Brilliantly simple, could not be done with a (header) background image. I do have some suggestions:
Feb 11 2015
Feb 9 2015
We shouldn't hack around bugs. Besides, @media is not webkit-only.
That is an edge case where a header is caught between two floating images. Again, not worth the host of other regressions that will emerge, should overflow:hidden be removed.
Feb 8 2015
Please don't do anything.
Using a viewBox hack in the SVG to 'trick' Webkit into using the correct dimensions appears to fix the problem. However, it requires setting the width and height to non-intrinsic values, which makes the SVG image useless for other purposes. So let's not go there.
@Paladox, please do not use the updated icon; it shows too big on the rest. The iOS issue will have to be resolved in another way.
Feb 5 2015
Historically, 16px was the initial fontsize when browsers first came out. The default font was Times/serif, which has a lower x-height, and 16px was good.
Feb 4 2015
- The  link used to be all the way on the right edge of the page. It now sits right next to the header text; it is no longer floating. (There is a gadget on enwiki to move them to the right again.)
- I missed that. I was thinking about a link (chain) symbol as used by the Headanchor gadget.
- Multiple floating inline elements in the header will sit next to eachother wihtout getting in eachothers way
@polybuildr, making the header a link was not a good idea, so forget that.