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

[Brad Jorsch (Anomie)]

On Sun, Nov 15, 2015 at 4:47 AM, Jon Robson  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Jon Robson]

On 17 Nov 2015 12:28 a.m., "Brad Jorsch (Anomie)" 
wrote:
>
> On Sun, Nov 15, 2015 at 4:47 AM, Jon Robson  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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Jon Robson]

On 15 Nov 2015 2:31 p.m., "Isarra Yos"  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"  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

Re: [Wikitech-l] [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"  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, 

Re: [Wikitech-l] [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  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.wel...@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" >

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



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

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

[Isarra Yos]

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"  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% 

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

[Jon Robson]

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., jdlrob...@gmail.com 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"  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

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

[Jon Robson]

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"  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

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

[Daniel Friesen]

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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Krinkle]

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  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.wel...@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" >
>
> 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

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

[Florian Schmidt]

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" zhoris...@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>> 
___>> 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

Re: [Wikitech-l] [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" zhoris...@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.

Re: [Wikitech-l] [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:zhoris...@gmail.com] 
Gesendet: Freitag, 13. November 2015 19:14
An: Florian Schmidt <florian.schmidt.wel...@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" zhoris...@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 stil

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

[Ricordisamoa]

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

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

[Max Semenik]

On Thu, Nov 12, 2015 at 11:15 AM, Paladox 
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[James Forrester]

On 12 November 2015 at 10:50, Ryan Kaldari  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.

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

Re: [Wikitech-l] [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 
 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  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

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

[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
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

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

[Ryan Kaldari]

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

Re: [Wikitech-l] [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
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