On 15 Nov 2015 2:31 p.m., "Isarra Yos" <zhorishna(a)gmail.com> wrote:
I agree that it's important to move away from desktop-first, but
switching to
mobile-first isn't the answer either. 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-firs…
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" <zhorishna(a)gmail.com> wrote:
>
>> Perhaps I should clarify why this is a problem. In fully responsive
skins,
>> you generally have separate stylesheets for
desktop, mobile, really big
>> desktop, whatever in order to keep the CSS rules simple and not
redundant
>> (to avoid having mobile overriding desktop
rules or visa versa, you just
>> only send the mobile styles to mobile, the desktop to desktop). You do
this
>> by setting maximum and minimum screen sizes in
the @media queries, but
the
>> problem is, IE8 does not support this, and
will not load a stylesheet at
>> all if these sizes are set. So you need to give it the desktop styles
some
>> other way, without the @media size rules
present.
>>
>> While it is possible to simply add CSS to the page header using
>> outputPage, probably bypassing RL and all that entirely, this only works
>> with CSS, not LESS, because all the LESS magic is happening within RL.
So
>> without RL, that means you need to render your
desktop stylesheet into
CSS
>> for this, which means you now need to maintain
it in two different
places
>> even though it's the same rules in both.
>>
>> Using js got around this whole problem as with that you can simply check
>> the browser there and then conditionally mw.loader.load a size-free
module
>> for IE8.
>>
>> Is there any other way around this?
>>
>> On 12/11/15 02:56, Isarra Yos wrote:
>>
>>> Is there a way to conditionally load RL modules for folks using IE8?
>>> Because I couldn't figure out any proper way to do that in my skins and
>>> I've just been using js to do it instead as a result.
>>>
>>> But that's not going to work anymore. But it's also stupid
regardless.
>>>
>>> On 12/11/15 02:11, Krinkle wrote:
>>>
>>>> Hey all,
>>>>
>>>> Starting in January 2016, MediaWiki will end JavaScript support for
>>>> Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
>>>> Users with this browser will still be able to browse, edit, and
otherwise
>>>> contribute to the site. However, some
features will not be available
to
>>>> them. For example, the enhanced edit
toolbar will not appear, and the
>>>> notification buttons will take you to a page rather than a pop-out.
>>>>
>>>> This change will affect roughly 0.89% of all traffic to Wikimedia
wikis
>>>> (as
>>>> of October 2015). For comparison, 0.33% of traffic comes from Internet
>>>> Explorer 6, and 1.46% from Internet Explorer 7. Support for these was
>>>> dropped in August and September 2014 respectively.
>>>>
>>>> Providing JavaScript for IE 8 adds a significant maintenance burden.
It
>>>> also bloats the software we ship to
all users, without proportionate
>>>> benefit. This enables us to simplify and streamline the JavaScript
>>>> codebase
>>>> for all other users. Users unable to upgrade from Internet Explorer 8
>>>> will
>>>> have a faster experience going forward, based on well-tested and more
>>>> stable code.
>>>>
>>>> This change will land in the development branch in January, and so
will
>>>> be
>>>> part of MediaWiki 1.27 (to be released around May 2016).
>>>>
>>>> Tech News will announce this change as well, but please help carry
this
>>>> message into your communities. In
January, we will send a reminder
before
> the change
happens.
>
> Yours,
> -- Krinkle
>
> For details about the JavaScript-less experience, see
>
https://www.mediawiki.org/wiki/Compatibility
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l