I'm not totally sure, but if you put your styles into a top queue module, the module would be delivered through RL (with all it's features, including LESS compilation) and the browser requests it without JavaScript (it should be added into one of the RL link tags in head). The change to disable JS on IE8 should affect bottom queued modules, only (the requests for these modules are initialized by JS).

Another solution could (probably) be conditional style sheets, like Vector uses for IE7: https://github.com/wikimedia/mediawiki-skins-Vector/blob/3f1515a7b223793818c...

Best, Florian

-----Original-Nachricht----- Betreff: Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016 Datum: 2015-11-12T18:20:39+0100 Von: "Isarra Yos" <zhorishna@gmail.com> An: "Wikimedia developers" <wikitech-l@lists.wikimedia.org>

Perhaps I should clarify why this is a problem. In fully responsive skins, you generally have separate stylesheets for desktop, mobile, really big desktop, whatever in order to keep the CSS rules simple and not redundant (to avoid having mobile overriding desktop rules or visa versa, you just only send the mobile styles to mobile, the desktop to desktop). You do this by setting maximum and minimum screen sizes in the @media queries, but the problem is, IE8 does not support this, and will not load a stylesheet at all if these sizes are set. So you need to give it the desktop styles some other way, without the @media size rules present.

While it is possible to simply add CSS to the page header using outputPage, probably bypassing RL and all that entirely, this only works with CSS, not LESS, because all the LESS magic is happening within RL. So without RL, that means you need to render your desktop stylesheet into CSS for this, which means you now need to maintain it in two different places even though it's the same rules in both.

Using js got around this whole problem as with that you can simply check the browser there and then conditionally mw.loader.load a size-free module for IE8.

Is there any other way around this?

On 12/11/15 02:56, Isarra Yos wrote:> Is there a way to conditionally load RL modules for folks using IE8?> Because I couldn't figure out any proper way to do that in my skins> and I've just been using js to do it instead as a result.>> But that's not going to work anymore. But it's also stupid regardless.>> On 12/11/15 02:11, Krinkle wrote:>> Hey all,>>>> Starting in January 2016, MediaWiki will end JavaScript support for>> Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.>> Users with this browser will still be able to browse, edit, and>> otherwise>> contribute to the site. However, some features will not be available to>> them. For example, the enhanced edit toolbar will not appear, and the>> notification buttons will take you to a page rather than a pop-out.>>>> This change will affect roughly 0.89% of all traffic to Wikimedia>> wikis (as>> of October 2015). For comparison, 0.33% of traffic comes from Internet>> Explorer 6, and 1.46% from Internet Explorer 7. Support for these was>> dropped in August and September 2014 respectively.>>>> Providing JavaScript for IE 8 adds a significant maintenance burden. It>> also bloats the software we ship to all users, without proportionate>> benefit. This enables us to simplify and streamline the JavaScript>> codebase>> for all other users. Users unable to upgrade from Internet Explorer 8>> will>> have a faster experience going forward, based on well-tested and more>> stable code.>>>> This change will land in the development branch in January, and so>> will be>> part of MediaWiki 1.27 (to be released around May 2016).>>>> Tech News will announce this change as well, but please help carry this>> message into your communities. In January, we will send a reminder>> before>> the change happens.>>>> Yours,>> -- Krinkle>>>> For details about the JavaScript-less experience, see>> https://www.mediawiki.org/wiki/Compatibility%3E%3E _______________________________________________>> Wikitech-l mailing list>> Wikitech-l@lists.wikimedia.org>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l%3E

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

• the stylesheets need to be conditional because IE8 needs a different value for the @media than everything else (and thus can't use the same module)

? You can use media queries inside the stylesheet, too.

But the conditional stylesheet method employed by vector won't work if it's LESS because this method is not for RL modules, and yet it is looking like this will be our only option now

Unfortunately, that's right. If you want to use less with Vector's solution, you probably need to implement dirty hacks with building your own RL load.php call in php and add this, instead of a static file link. But that would be really hacky, and I'm sure, that this is one of the worst solutions.

If we're using LESS on a responsive skin, we simply have to maintain two (probably pretty identical) desktop stylesheets if we want to support IE8 at all?

If you use media queries, no.

Best, Florian

-----Ursprüngliche Nachricht----- Von: Isarra Yos [mailto:zhorishna@gmail.com] Gesendet: Freitag, 13. November 2015 19:14 An: Florian Schmidt florian.schmidt.welzow@t-online.de; Wikimedia developers wikitech-l@lists.wikimedia.org Betreff: Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

I don't really understand how this solves anything, though - the stylesheets need to be conditional because IE8 needs a different value for the @media than everything else (and thus can't use the same module). Other than that, it's still the same stylesheet as is being served to everything else.

But the conditional stylesheet method employed by vector won't work if it's LESS because this method is not for RL modules, and yet it is looking like this will be our only option now? If we're using LESS on a responsive skin, we simply have to maintain two (probably pretty identical) desktop stylesheets if we want to support IE8 at all?

On 13/11/15 10:02, Florian Schmidt wrote:

I'm not totally sure, but if you put your styles into a top queue module, the module would be delivered through RL (with all it's features, including LESS compilation) and the browser requests it without JavaScript (it should be added into one of the RL link tags in head). The change to disable JS on IE8 should affect bottom queued modules, only (the requests for these modules are initialized by JS).

Another solution could (probably) be conditional style sheets, like Vector uses for IE7: https://github.com/wikimedia/mediawiki-skins-Vector/blob/3f1515a7b2237 93818c6ac82805ee3b6c462fe50/SkinVector.php#L58-L62

Best, Florian

-----Original-Nachricht----- Betreff: Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016 Datum: 2015-11-12T18:20:39+0100 Von: "Isarra Yos" <zhorishna@gmail.com> An: "Wikimedia developers" <wikitech-l@lists.wikimedia.org>

Perhaps I should clarify why this is a problem. In fully responsive skins, you generally have separate stylesheets for desktop, mobile, really big desktop, whatever in order to keep the CSS rules simple and not redundant (to avoid having mobile overriding desktop rules or visa versa, you just only send the mobile styles to mobile, the desktop to desktop). You do this by setting maximum and minimum screen sizes in the @media queries, but the problem is, IE8 does not support this, and will not load a stylesheet at all if these sizes are set. So you need to give it the desktop styles some other way, without the @media size rules present.

While it is possible to simply add CSS to the page header using outputPage, probably bypassing RL and all that entirely, this only works with CSS, not LESS, because all the LESS magic is happening within RL. So without RL, that means you need to render your desktop stylesheet into CSS for this, which means you now need to maintain it in two different places even though it's the same rules in both.

Using js got around this whole problem as with that you can simply check the browser there and then conditionally mw.loader.load a size-free module for IE8.

Is there any other way around this?

On 12/11/15 02:56, Isarra Yos wrote:> Is there a way to conditionally load RL modules for folks using IE8?> Because I couldn't figure out any proper way to do that in my skins> and I've just been using js to do it instead as a result.>> But that's not going to work anymore. But it's also stupid regardless.>> On 12/11/15 02:11, Krinkle wrote:>> Hey all,>>>> Starting in January 2016, MediaWiki will end JavaScript support for>> Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.>> Users with this browser will still be able to browse, edit, and>> otherwise>> contribute to the site. However, some features will not be available to>> them. For example, the enhanced edit toolbar will not appear, and the>> notification buttons will take you to a page rather than a pop-out.>>>> This change will affect roughly 0.89% of all traffic to Wikimedia>> wikis (as>> of October 2015). For comparison, 0.33% of traffic comes from Internet>> Explorer 6, and 1.46% from Internet Explorer 7. Support for these was>> dropped in August and September 2014 respectively.>>>> Providing JavaScript for IE 8 adds a significant maintenance burden. It>> also bloats the software we ship to all users, without proportionate>> benefit. This enables us to simplify and streamline the JavaScript>> codebase>> for all other users. Users unable to upgrade from Internet Explorer 8>> will>> have a faster experience going forward, based on well-tested and more>> stable code.>>>> This change will land in the development branch in January, and so>> will be>> part of MediaWiki 1.27 (to be released around May 2016).>>>> Tech News will announce this change as well, but please help carry this>> message into your communities. In January, we will send a reminder>> before>> the change happens.>>>> Yours,>> -- Krinkle>>>> For details about the JavaScript-less experience, see>> https://www.mediawiki.org/wiki/Compatibility%3E%3E _______________________________________________>> Wikitech-l mailing list>> Wikitech-l@lists.wikimedia.org>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l%3E

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Is there any way to use addModuleStyles() so that it outputs browser-conditional stylesheets? Such that such a one could apply only to IE8-? That's really what I need here.

On 15/11/15 00:17, Krinkle wrote:

Just wanna make a small correction here to avoid confusion.

The top and bottom queue are both JavaScript-enabled, using 'position' => 'top' only controls where the load() command is placed (at the top or bottom, naturally). Neither of these will run in IE 8 after January.

What Florian is referring to does exist. That is the "styles-only" queue It is triggered by using addModuleStyles(). This method will ensure the module is included in a regular <link> stylesheet. These modules don't have a position, as stylesheets are always in the top.

One could consider these stylesheets as part of the top queue (based on where they are in the HTML), but we don't do that in our documentation to avoid confusion as instructions you may find about using the "top queue" will refer to the 'position' attribute as used by addModules() – which is not what you want in this case.

These styles-only modules are still processed by ResourceLoader (e.g. LESS can be used, minified, and cached as usual). We've always used this skin styling and other styles associated with server-side generated page output (e.g. thumbnail styles, table of contents, skins etc.).

Primarily because it performs better (browsers discover these urls and start fetching when statically looking ahead in the html parse stream). And because it's a more stable and a semantically correct way to associate styles. For instance, JavaScript runtime could intermittently fail for any number of reasons even in modern browsers, as well as on mobile browsers. In such scenarios the stylesheet more important, and users effectively get the fallback experience (as opposed to a page with no styling, which would happen if we don't do that).

-- Krinkle

On Fri, Nov 13, 2015 at 10:02 AM, Florian Schmidt < florian.schmidt.welzow@t-online.de> wrote:

...

I'm not totally sure, but if you put your styles into a top queue module, the module would be delivered through RL (with all it's features, including LESS compilation) and the browser requests it without JavaScript (it should be added into one of the RL link tags in head). The change to disable JS on IE8 should affect bottom queued modules, only (the requests for these modules are initialized by JS).

-----Original-Nachricht----- Von: "Isarra Yos" <zhorishna@gmail.com lt%3Bzhorishna@gmail.com>

Using js got around this whole problem as with that you can simply check the browser there and then conditionally mw.loader.load a size-free module for IE8.

Is there any other way around this?

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I agree that it's important to move away from desktop-first, but switching to mobile-first isn't the answer either. For complex products (discussion boards, skins, anything that could benefit from a lot of space), there are going mobile-specific styles same as any other resolution - do ANY as the 'main', and you're having to undo and override those styles on every other one, which results in unnecessarily complicated and large code, which just makes it all that much harder to maintain and work with.

As an example, this is an important part of why it's been so hard to make Vector properly responsive - so many of the desktop styles needed to be overridden in order for any mobile design to be applied. (This would have applied in either direction because its desktop and mobile layouts are so completely different.) But suppose that same step had been replaced with instead separating out the desktop styles into a separate stylesheet for a similar amount of effort, and with each as separate, independent stylesheets - code for both desktop and mobile would be made cleaner, and far easier to iterate upon. (People wanted me to iterate on what's there now and I couldn't even figure out where to begin. Not that I'm that good at CSS in the first place, but that code is scary.)

What we need to do is get better at distinguishing and leveraging the common styles, and using common variables and mixins, because this is how you make consistent overall styles and also simplify the overall thing. Then build these into something that works for each platform.

And if we're going to support stupid broken things, we need to explicitly support them with some sort of fallback that doesn't require a lot of manual rejigging. I'm not sure IE8, as an ancient desktop browser, getting mobile styles is really any better than an ancient mobile browser getting desktop styles.

On 14/11/15 22:39, Jon Robson wrote:

The solution to this is to do true mobile first development e.g. wrap your desktop and tablet styles in media queries. Rendering a mobile site in IE8 is an acceptable trade off and ensures the content remains readable which is the most important thing here.

We (Wikimedia devs) still build desktop first in all our major projects and we really need to shift away from this. We can't simply build for desktop and then adapt it to work on mobile which seems to be a common misconception by anyone who hasn't built things for mobile. This approach is costly as we end up rebuilding things we've already built to make them work on mobile. We used to have a mobile department that pretty much did this as a full time job but now that has gone we really need to adopt this tried and tested approach. On 13 Nov 2015 2:20 a.m., "Isarra Yos" zhorishna@gmail.com wrote:

...

Perhaps I should clarify why this is a problem. In fully responsive skins, you generally have separate stylesheets for desktop, mobile, really big desktop, whatever in order to keep the CSS rules simple and not redundant (to avoid having mobile overriding desktop rules or visa versa, you just only send the mobile styles to mobile, the desktop to desktop). You do this by setting maximum and minimum screen sizes in the @media queries, but the problem is, IE8 does not support this, and will not load a stylesheet at all if these sizes are set. So you need to give it the desktop styles some other way, without the @media size rules present.

While it is possible to simply add CSS to the page header using outputPage, probably bypassing RL and all that entirely, this only works with CSS, not LESS, because all the LESS magic is happening within RL. So without RL, that means you need to render your desktop stylesheet into CSS for this, which means you now need to maintain it in two different places even though it's the same rules in both.

Using js got around this whole problem as with that you can simply check the browser there and then conditionally mw.loader.load a size-free module for IE8.

Is there any other way around this?

On 12/11/15 02:56, Isarra Yos wrote:

...

Is there a way to conditionally load RL modules for folks using IE8? Because I couldn't figure out any proper way to do that in my skins and I've just been using js to do it instead as a result.

But that's not going to work anymore. But it's also stupid regardless.

On 12/11/15 02:11, Krinkle wrote:

...

Hey all,

Starting in January 2016, MediaWiki will end JavaScript support for Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7. Users with this browser will still be able to browse, edit, and otherwise contribute to the site. However, some features will not be available to them. For example, the enhanced edit toolbar will not appear, and the notification buttons will take you to a page rather than a pop-out.

This change will affect roughly 0.89% of all traffic to Wikimedia wikis (as of October 2015). For comparison, 0.33% of traffic comes from Internet Explorer 6, and 1.46% from Internet Explorer 7. Support for these was dropped in August and September 2014 respectively.

Providing JavaScript for IE 8 adds a significant maintenance burden. It also bloats the software we ship to all users, without proportionate benefit. This enables us to simplify and streamline the JavaScript codebase for all other users. Users unable to upgrade from Internet Explorer 8 will have a faster experience going forward, based on well-tested and more stable code.

This change will land in the development branch in January, and so will be part of MediaWiki 1.27 (to be released around May 2016).

Tech News will announce this change as well, but please help carry this message into your communities. In January, we will send a reminder before the change happens.

Yours, -- Krinkle

For details about the JavaScript-less experience, see https://www.mediawiki.org/wiki/Compatibility _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Your email client seems to have mangled the indenting for some reason, so I tried to repair it. Apologies if I've messed anything up in the process.

On 15/11/15 09:47, Jon Robson wrote:

On 15 Nov 2015 2:31 p.m., "Isarra Yos" zhorishna@gmail.com wrote:

...

I agree that it's important to move away from desktop-first, but switching to mobile-first isn't the answer either.

Why not? Whats wrong with a fixed width centered site? Old phones do not have media query support nor do they have ability to support conditional statements.

It doesn't work for MediaWiki. As a product, it is too complicated, has too many modes and tools, to effectively communicate to the user what they can and cannot do using only simple styles. (I assume you mean max-width, since just fixed width doesn't work on mobile anyway.)

When you have more space, you can tell them more. When you have less space, you need to use other affordances to tell them things, and hide links and tools behind menus, but this adds to the steps required for both discovery and use, and should only be done when you have no other options. For desktop users who actually do have the space to lay the important things out, having everything hidden behind buttons and menus is simply not fair - or useful.

...

For complex products (discussion boards, skins, anything that could benefit from a lot of space), there are going mobile-specific styles same as any other resolution - do ANY as the 'main', and you're having to undo and override those styles on every other one, which results in unnecessarily complicated and large code, which just makes it all that much harder to maintain and work with.

As an example, this is an important part of why it's been so hard to make Vector properly responsive - so many of the desktop styles needed to be overridden in order for any mobile design to be applied. (This would have applied in either direction because its desktop and mobile layouts are so completely different.) But suppose that same step had been replaced with instead separating out the desktop styles into a separate stylesheet for a similar amount of effort, and with each as separate, independent stylesheets - code for both desktop and mobile would be made cleaner, and far easier to iterate upon.

This will never happen. True mobile development is a lot more than moving around styles.

True mobile development is nothing more than developing for mobile. You lay things out and use the tools mobile affords - same as any other platform. You just need to actually do this for ALL your platforms. Including mobile. Including desktop. Including screen readers.

For example the current responsive vector skin that exists in an experimental state sits at the bottom of the page which is a dead zone. I'm yet to see any good examples of this done well.

What exactly do you mean? Is this a bug in the implementation in which the entire skin shows up off the page on mobile or something?

Or are you referring to the navigation? Because yes, that definitely needs work. I was under the impression nobody had actually gotten to that part yet; my point was more that the skin now renders on mobile in a legible fashion at all, which was previously not the case with the sidebars and tabs and whatnot.

You want a responsive skin though. What you are describing is not one. A responsive site uses the same stylesheet for both desktop and mobile.

'Responsive', in reference to websites, means that the site layout responds to and renders well regardless of the size of or device type on which it is displayed.

A single set of styles for everything can be made to work (or even no styles, technically speaking - just look at motherfuckingwebsite.com), but also introduces serious limitations in terms of what can be done for each, which in particular poses problems for MediaWiki for the reasons I explained above (yes, you can still do it; it's just not exactly optimal). But the fact of the matter is that the entire reason @media size queries were introduced in the first place was mitigate this sort of thing by allowing for more specific styles to be employed, optimised for the different displays and taking full advantage of their different features. This is exactly what it is for, and we should be using it for this.

...

(People wanted me to iterate on what's there now and I couldn't even figure out where to begin. Not that I'm that good at CSS in the first place, but that code is scary.)

What we need to do is get better at distinguishing and leveraging the common styles, and using common variables and mixins, because this is how you make consistent overall styles and also simplify the overall thing. Then build these into something that works for each platform.

And if we're going to support stupid broken things, we need to explicitly support them with some sort of fallback that doesn't require a lot of manual rejigging. I'm not sure IE8, as an ancient desktop browser, getting mobile styles is really any better than an ancient mobile browser getting desktop styles.

Why not?

Effective mobile navigation on a platform of this complexity almost exclusively requires javascript to function due to the extremely limited space it must be optimised for. This includes popups, accordion menus, expanding sections, anything where the content is initially hidden and only made visible upon user action.

IE8 will soon not be served javascript.

Other experts in the field far more qualified than myself think so. For example https://stuffandnonsense.co.uk/blog/about/the-guardians-take-on-mobile-first... There are countless more if you Google.

Does the Guardian use the same interface for authoring, editing and publishing as it does for reading? Does the Guardian only serve js to IE9+?

Those experts are discussing what applies to them, but we have our own use cases, our own problems. What works for others will not necessarily work for us because we are doing different things. But we can still look at and learn from these other things; we just also need to consider why they did what they did and whether those reasons apply to us. We can't blindly follow others, in other fields, when we are the pathfinders in our own field.

On 17 Nov 2015 12:28 a.m., "Brad Jorsch (Anomie)" bjorsch@wikimedia.org wrote:

On Sun, Nov 15, 2015 at 4:47 AM, Jon Robson jdlrobson@gmail.com wrote:

...

Why not? Whats wrong with a fixed width centered site?

Because reading text like this is really annoying when you have gigantic amounts of wasted whitespace on either side. (And it's even worse if someone decides that contrast is bad too...)

If you're annoyed by this yoh should probably upgrade your browser to one that support media queries.

Wikipedia is not that special that it cant follow the various examples on the web, meet its mission by ensuring older browsers can tender our content and focus its energy on the majority of our development time on the people who can upgrade their browsers....

If this point is lost on everyone I give up.

(apologies to people using non-HTML mail readers, you may be missing the point of this reply-by-example) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Thu, Nov 12, 2015 at 11:15 AM, Paladox thomasmulhall410@yahoo.com wrote:

Why not start informing ie8 users now so that it gives them plenty of time to update. I would recommend them switching to chrome or firefox if on windows xp since ie9 is not available on windows xp.

Because everybody who could/cared upgraded ages ago. Also, because we're NPOV and shouldn't bundle our neutral articles with our personal browser preferences.