Change 607077 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] [CSS] Add rules from HTML5shiv to fix unknown elements in IE9-11

https://gerrit.wikimedia.org/r/607077

Change 607157 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [modern] Fix broken rendering of main and dialog elements in IE9-11

https://gerrit.wikimedia.org/r/607157

Patch has been finalized, awaiting review: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/607077
Patch in Vector to actually enable it: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/607157

Change 607077 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Add 'html5' feature to ResourceLoaderSkinModule for unknown elements in IE9-11

https://gerrit.wikimedia.org/r/c/mediawiki/core/ /607077

Change 607157 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [modern] Fix broken rendering of main and dialog elements in IE9-11

https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/ /607157

This has been reverted without review in https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/608243
It is reasonable to look for a more generic solution in T256520, but we shouldn't break again what's been fixed before the alternative made it to the codebase.

Now IE11 is broken again and work cannot be tested in that browser.

Change 608113 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] mediawiki.skinning: Add 'normalize' module and 'normalize.less'

https://gerrit.wikimedia.org/r/c/mediawiki/core/ /608113

Change 608497 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] [modern] Fix rendering of main element in IE10 & 11

https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/ /608497

From gerrit:

@Volker_E wrote:

A new RL module that goes into production would need to go through deprecation process of a full MW version, which is a huge overhead, that I wanted to prevent as we target all our products and 3rd parties better with a fine-tailored normalize approach.

Yes, that's reasonable, I'd have done the same and seeing the replacement is ready to be merged, there are no issues other than the need for a bit more forward planning.

If you recall, this was originally a quick fix a week ago without any resourceloader complication:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/607077/1

The professional approach that gives the best results and least disruption in handling such cases is to make a quick fix that can be removed anytime without constraints, while working on a more thought-out, long-term solution.
The normalize.less approach is IMO the best option in the long-term, however the unnecessary disruption due to the bug could have been avoided until this approach is stabilized.

I'm happy to help manifesting such staged approaches, in fact that's what I did on T254546 too, unfortunately that was rejected as well and there was no fix provided for a long time.

There seems to be a misunderstanding about urgency. The new Vector is not stable yet and not deployed on any wikis. As a result there is no urgency with any task or bug fix. Quick fixes are not necessary at this point, what's important is we build out long term solutions and lay down maintainable architecture.

The modifications to ResourceLoaderSkinModule are not quick fixes. They become subject to the deprecation process as soon as they are in deployed code. This was why it was important to act quickly.

In T256092#6268858, @Jdlrobson wrote:

There seems to be a misunderstanding about urgency.

Development on IE happens now. This bug was undermining that work, that being the reason I've reported and fixed it.
There's no misunderstanding, but instead developers' needs aren't taken into consideration. I wonder if that could be improved.

The modifications to ResourceLoaderSkinModule are not quick fixes.

I've referred to a "quick fix" in its original form when it was just piggybacked on 'elements.css' without RL involvement (ref), I've highlighted this fact explicitly in my previous comment (T256092#6266569).
Such misunderstandings often happen. Can I do something to improve the communication efficiency?

I agree it was important to remove the html5 ResourceLoader module before it gets on the train and we are burdened with a mandatory deprecation process.
My concern is that this could have been avoided by:

1. Forward planning for the normalize-based solution (T256520), which was created the day before the RL module was merged, thus known about.
2. Merging a minimal, immediate solution - that has no deprecation constraints - for the 2-4 weeks between the bug was discovered and T256520 will be merged: the first solution I've submitted. That temporary solution can be removed once unnecessary without strings attached.

Change 608113 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.skinning: Add 'normalize' module and 'normalize.less'

https://gerrit.wikimedia.org/r/608113

Change 608497 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [modern] Fix rendering of main element in IE10 & 11

https://gerrit.wikimedia.org/r/608497

In T256092#6278144, @Demian wrote:

In T256092#6268858, @Jdlrobson wrote:

There seems to be a misunderstanding about urgency.

There's no misunderstanding, but instead developers' needs aren't taken into consideration. I wonder if that could be improved.

What are “developers' needs” here. Please expand…

Change 609895 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] [modern] Fix rendering of main element in IE10 & 11

https://gerrit.wikimedia.org/r/609895

Change 609895 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [modern] Fix rendering of main element in IE10 & 11 (again)

https://gerrit.wikimedia.org/r/609895

@ovasileva the IE9-11 issues should be fixed now - how do you want to handle QA? As part of this one or as part of a larger task involving the review of all legacy browsers prior to deployment?

@Edtadros This IE9 misbehaviour is somewhat worrisome, but unrelated and should be filed in a separate task.