[BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Krinkle
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Isarra Yos
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Ricordisamoa
In reply to this post by Krinkle
Yes. Yes. YES!

Il 12/11/2015 03:11, Krinkle ha scritto:

> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Isarra Yos
In reply to this post by Isarra Yos
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
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Ryan Kaldari-2
In reply to this post by Krinkle
Would it be worth running a CentralNotice banner in January specifically
for IE8 users to inform them of the change and encourage them to upgrade?

On Wed, Nov 11, 2015 at 7:11 PM, Krinkle <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Paladox
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.


     On Thursday, 12 November 2015, 18:50, Ryan Kaldari <[hidden email]> wrote:
   

 Would it be worth running a CentralNotice banner in January specifically
for IE8 users to inform them of the change and encourage them to upgrade?

On Wed, Nov 11, 2015 at 7:11 PM, Krinkle <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

   
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Max Semenik
On Thu, Nov 12, 2015 at 11:15 AM, Paladox <[hidden email]>
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.


--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

James Forrester-4
In reply to this post by Ryan Kaldari-2
On 12 November 2015 at 10:50, Ryan Kaldari <[hidden email]> wrote:

> Would it be worth running a CentralNotice banner in January specifically
> for IE8 users to inform them of the change and encourage them to upgrade?
>

​Given CN banners are shown with​ JavaScript (and we'd certainly not want
to show it to all users), I'm not sure this would be that useful for the
few days after the fundraiser and before they'd lose them. Did we do this
for IE6/7? I believe not.

J.
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Florian Schmidt
In reply to this post by Isarra Yos
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/3f1515a7b223793818c6ac82805ee3b6c462fe50/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" &lt;[hidden email]&gt;
An: "Wikimedia developers" &lt;[hidden email]&gt;

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>> [hidden email]>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l>


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Isarra Yos
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/3f1515a7b223793818c6ac82805ee3b6c462fe50/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" &lt;[hidden email]&gt;
> An: "Wikimedia developers" &lt;[hidden email]&gt;
>
> 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>> [hidden email]>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Florian Schmidt
> - 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:[hidden email]]
Gesendet: Freitag, 13. November 2015 19:14
An: Florian Schmidt <[hidden email]>; Wikimedia developers <[hidden email]>
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" &lt;[hidden email]&gt;
> An: "Wikimedia developers" &lt;[hidden email]&gt;
>
> 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>> [hidden email]>>
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Jon Robson
In reply to this post by Krinkle
I should also add that the reason I say this is that IE8 is not the only
browser that doesn't support media queries. There are many browsers that
were written before IE8 and installed on phones with no upgrade path. This
is just one of the biggest ones.
On 15 Nov 2015 7:08 a.m., [hidden email] 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" <[hidden email]> 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
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Jon Robson
In reply to this post by Isarra Yos
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" <[hidden email]> 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
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>
>>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Daniel Friesen-2
In reply to this post by Jon Robson
On 2015-11-14 2:39 PM, Jon Robson wrote:
> 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.
>
>
> Is there any other way around this?
If you were ok with IE8 support requiring Node.js, the PostCSS ecosystem
has a bunch of plugins to transform CSS (which someone could try and
plug into RL).

Such as:
https://github.com/jonathantneal/oldie

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Krinkle
In reply to this post by Florian Schmidt
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 <
[hidden email]> 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" <[hidden email] <lt%[hidden email]>>
>
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Isarra Yos
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 <
> [hidden email]> 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" <[hidden email] <lt%[hidden email]>>
>>
>> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Isarra Yos
In reply to this post by Jon Robson
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" <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>>
>>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Jon Robson
On 15 Nov 2015 2:31 p.m., "Isarra Yos" <[hidden email]> wrote:
>
> I agree that it's important to move away from desktop-first, but
switching to mobile-first isn't the answer either. For

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.

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

This will never happen. True mobile development is a lot more than moving
around styles. 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.

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.

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.

(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? 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-responsive-web-design-and-ie8
There are countless more if you Google.

>
>
> 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" <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>>>
>>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Isarra Yos
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" <[hidden email]> 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-responsive-web-design-and-ie8
> 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.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

Brad Jorsch (Anomie)
In reply to this post by Jon Robson
On Sun, Nov 15, 2015 at 4:47 AM, Jon Robson <[hidden email]> 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...)

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