• The cut-off characters should be solved with line-height. Value depends on font used.
• A header is typically a single line, so needs no flowing.
• The anchor (T18691) no longer needs visible.

Yes I did. But AGAIN, I fail to see the benefit; all issues you describe can be solved by other means.

We are exploring different solutions for the anchors and cut-off characters are fixed by a simple line-height fix.

@Fomafix, I used Chrome 40, but effect is seen in any browser.

In T88220#1008067, @Fomafix wrote:

The underline does not enter margin of the floating element.

OK, it flows around. But the underline crosses the float; the reason hidden exists in the first place. And with other aternatives now investigated, there is no need to remove it.

Just some thoughts... How would just styling the header as a link in hover sound?
(Answering myself, that may interfere with links already in the header.)

It is valid, but overcomplicated and not universally supported; grade A is not all browsers. The hidden overflow does flow around floating objects; I have no idea how you could state otherwise... it was designed to flow around floating objects.

overflow:hidden is perfectly valid CSS and not a 'hack' in any way; it does exactly what it is intended to do. It is the various code proposed here that are hacks because they try to negate lazy coding; if T18691 is not related, then why are we having this discussion about replacing code that works on all browsers with code that does not work on all browsers?

This is an awfull lot of hacks just to add an anchor link. Can we put this aside for now and centralize discussion at T18691?

I was confused with last-child.

:after also lacks IE8 support.

The edit links are not the only floating elements that benefit from overflow:hidden. There are gadgets that might add floating content, and of course all floating templates (with transparent backgrounds) will be malformed. If a key property is in the way, find a way around it; don't just throw it out and hope for the best... that's just lazy.

1em/16px is huge. I think 14px is quite OK. Is there a need to increase the font-size?

The current patch seeks to remove a key property (overflow:hidden) that makes headers behave with nearby floating elements, such as tables, infoboxes, sidebars and whatever other template that may be present. This would cause a regression.

In T88220#1006707, @Fomafix wrote:

@Edokter Do you have any other suggestion?

display: flex; is ment to flow multiple boxes next to, or on top of eachother. Only applying it to the header is a rather unpredictable hack, and so it is misapplied here.

@Jaredzimmerman-WMF, if you see black bullets, it means your browser is reverting to its default bullets, and not using either image. Also note that mobile view always use the default (black square) HTML bullets.

The dimensions for the SVG are exactly the same as for the PNG. It's not the bugs listed above; this is specific to list-style-image on iOS/Webkit. Another sulution is media queries, but that requires a set of SVG images an I feel that is too much work to cater to a bug.

SVG is fixed[1], but still @Paladox reports it to be too small in iOS8. What browser are you using? I cannot imagine Apple's own browser (which is Webkit) having this bug. Can someone else with an iPad confirm? You can test with [2] in your vector.css.

It's not hopeless, but my SVG is just over-optimized. I will report back here when I have a 100% complient SVG image.

Concise summary:

Path can't be the problem; that has always been there. I just got one of the numbers wrong when moving the transform.

That is not required AFAIK. I'll leave it to the experts.

Calling any SVG wizards... did I over-optimize? I removed a <g> (group) element because there is only one <path>. Now my Inkscape won't show image at all... but it opens fine in my browsers.

In T37338#984891, @Paladox wrote:

Hi but the problem is also on ios

That is invalid code; list-style-image does not support that syntax. Instead, add the following to [mediawiki/core.git]/resources/src/mediawiki.less/mediawiki.mixins.less:

A screenshot would help.

They look OK to me. What browser are you using? Screenshot?

It is not the purpose of the title text to "explain the concept" of the watchlist; its purpose is to describe what the button does, and it does exactly that.

Then someone +2 it please (after the patch has been updated with the optimized SVG).

Those browsers have negligable uses. So, do we want IE8 support?

That is the $64,000 question.

That is not possible either; the (default) bullet color is the same as the list item text.

If the use of SVGs in list-style-image result in the display of standard (black) bullets in older browsers (IE6/7/8 does not support SVG), then I consider that a gracefull fallback. No need for these elaborate CSS hacks.

This takes care of invalid scripts when saving, but... what about existing errors that block JS? Is it possible to wrap all user JS in a try..except and throw a visible exception when an error in user JS occurs? Should be trivial to do in ResourceLoader.

What Krinkle said. I just couldn't find the right words.

Ah... OK. Partly my fault. What I meant is the problem is also visible under "Special Characters" toolbar, and every page thereof. You will see everything there almost breaking out of their boxes.

Did I mention that all pages in the WikiEditor are suffering from the missing line-height, not just EditTools? My above patch is targeting WikiEditor, not EditTools! And yes, this patch should be made in the WikiEditor extension, not EditTools!

In T78354#846790, @GOIII wrote:

But the same faux-buttons in WikiEditor's Special Characters drop down menu had no character leakage - what gives?

I was talking about wikieditor toolbar in general... the *cause* lies there because it falis to assign a line-height to the button content to begin with. Any element added to the toolbar -- no matter what the source -- is then misrendered. Just try this fix on Commons, and you'll see all caharcter -- imported or not -- perfectly aligned.

This is a problem on all projects, and a simpler and more robust fix is:

Perhaps this can be solved by use of some keyword or link, making it more universally applicable in the long run, ie. [[css:MediaWiki:Mainpage.css]].

I thought it was defined in core and filtered in mobile, but perhaps, it is just not defined in mobile (Minerva).

I would like some sandbox mechanism though, that allows me to test CSS wihtout having to load it manually via importStylesheet, withCSS or some other hack.

In T56307#843262, @Jaredzimmerman-WMF wrote:

@Edokter, ah! thwarted again by Phabricator collapsing comments. You're referring to the wikilove icon tab or others as well?

You buy a brand new car, sky blue. You walk around it and notice one door is emerald green, and is from a totally different car model... would you still take it?

You all seem to be missing that this is a tab icon, and these have a specific style, which has now been broken. If we're changing icons, they should be changed all at once as a coherent set (or at least in groups thereof).

"The green star of death"? I don't know... We just have to keep nagging that "Vector != Mobile" until this is reverted.

In T56307#840881, @Florian wrote:

I personally see no reason to revert this change, the mobile watchstar matches the Vector design much better as the old one.

I updated the testcases and tested again. To break down what's broken: