[WikimediaMobile] Material Design Icons

[Bernd Sitzmann]

Google has uploaded the Material Design icons to Github.[1]
At a quick glance it seems to have all the icons we need, and already in
svg format. There's even a toc icon[2]. I think we should consider
switching to those for the Android app to be more in line with other
Android apps.

Bernd

[1] https://github.com/google/material-design-icons
[2]
https://github.com/google/material-design-icons/blob/master/action/svg/production/ic_toc_48px.svg
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Update on ResourceLoader-constrained UAs

[Maryana Pinchuk]

Thanks for the screenshots and further clarification of the problems, Adam!

Jon, do you think these cards will be ready to estimate at our sprint
kickoff on Monday? Is there any more info we need?

On Wed, Nov 19, 2014 at 5:05 PM, Adam Baso  wrote:

> On Wed, Nov 19, 2014 at 4:44 PM, Jon Robson  wrote:
>
>> Thanks for this Adam. A few questions.
>> ...
>> >
>> https://trello.com/c/blWoHdk8/1-improve-special-search-for-lower-end-device-users
>> > Incidentally, there's currently a regression making it impossible to
>> enter
>> > searches, at least on the Android and iOS Opera Mini clients I tested.
>>
>> Please can you track this regression on bugzilla with replication
>> instructions? I haven't heard about this bug and it sounds like
>> something that could easily be taken care of. A trello card seems
>> overkill.
>>
>
> Done. https://bugzilla.wikimedia.org/show_bug.cgi?id=73632
>
> The Trello card is more focused on visible outlining of the search input
> field should the device width exceed the CSS min width, and what to do when
> the magnifying glass is tapped but no results are turned up (e.g.,
> unintentional or mistyped search).
>
>
>
>> >
>> https://trello.com/c/0kKBcmoD/2-improve-login-and-account-creation-experience-for-lower-end-device-users
>> > Note: On non-HTML5 browsers, the "placeholder" attribute is not
>> supported.
>> >
>> > [4] https://www.mediawiki.org/wiki/Wikipedia_Zero#Tools
>>
>> Yeh there is a bug [1] and it's fixed in alpha. We'll have to find a
>> way of accelerating the alpha login form into stable for opera mini
>> users as unfortunately we hit some unexpected roadblocks around the
>> login form.
>>
>> [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=68758
>
>
>
> Please do let me know if/how I can assist. If the roadblock is expected to
> persist, I would like to get in some sort of interim fix at least.
>
> Thanks!
> -Adam
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>


-- 
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend

[Jon Robson]

Follow up
If I run `make jsbeautify` now
then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 is the result.

Outstanding actions:
* Need input on rest of the team about which of delete
this.cache[title]; or delete this.cache[ title ]; is the preferred
standard.
* You'll notice jsbeautify and inlne comments need to be ironed out.
For example:
https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-L257

Apart from the above 2 jsbeautify makes some adjustments to our
whitspace which I guess we'll just have to live with.

Please can everyone else let me know how they think we should proceed?



On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov
 wrote:
> As for # Rule 4, it makes sense to add spaces inside square brackets. The 
> reasoning is the same as why we add spaces inside parenthesis.
>
>> On Nov 18, 2014, at 12:28 PM, Jon Robson  wrote:
>>
>> I explored running jsbeautify [1] on the MobileFrontend codebase and
>> looked at how the output differs from the current styling. It
>> introduces various rules that MobileFrontend is currently not adhering
>> too. MobileFrontend already uses jscs [2] so we want to make sure the
>> outputs of both are compatible. Here is my report on that with the
>> recommendation that we should use it.
>>
>> #Rule 1: object properties defined on a single line.
>> e.g.
>> {
>> foo: 2,
>> bar: 3
>> }
>> NOT { foo: 2, bar: 3 }
>>
>> I think this would be a good idea to adopt. I will explore if jscs can
>> enforce this.
>>
>> # Rule 2: variables that are initialised must be followed by a new
>> line (although I noted a few odd cases e.g. in Page.js after a "?:"
>> expression and /MobileWebClickTracking.js
>> e.g.
>> var Foo, bar = $( 'div' ),
>> Baz,
>> Bar;
>>
>> not:
>> var Foo, bar = $( 'div' ), Baz, Bar;
>>
>> This will be fixed if I implement https://trello.com/c/0dkx0ldL
>>
>> # Rule 3: All chained events should be indented
>> e.g.
>> foo()
>> .bar();
>>
>> not
>> foo().
>> bar();
>>
>> Seems like a no brainer. One that happens naturally most of the time.
>>
>> # Rule 4: Spacing in object parameters
>> e.g.
>> foo[ 1 ]
>> [ 1, 2, 3, 4 ]
>>
>> not:
>> foo[1]
>> [1, 2, 3, 4]
>>
>> This is different to MediaWiki coding conventions but I can implement
>> https://github.com/beautify-web/js-beautify/issues/424 to give us
>> this.
>> We seem a bit inconsistent ourselves with this convention - let me
>> know how you think this rule should work in our codebase...
>>
>> # Rule 5: New line after variable declarations
>>
>> var x, y, z;
>>
>> z();
>>
>> not:
>> var x, y, z;
>> z();
>>
>> Also:
>> function foo() {}
>>
>> function bar() {}
>>
>> not:
>> function foo() {}
>> function bar() {}
>>
>> Seems like a no brainer and shouldn't introduce any major issues with
>> code review.
>>
>> # Rule 6: Comments must respect the current indentation level
>>
>> if () {
>> ...
>> // If i is 5 we do something special
>> } else if ( i === 5 ){
>>
>> }
>> becomes
>> if () {
>> ...
>> // If i is 5 we do something special
>> } else if ( i === 5 ){
>>
>> }
>> We'll have to think about what to do with these comments but I don't
>> think this should be a blocker to using jsbeautify. It will only pop
>> up occasionally.
>>
>> # Rule 7: On long if statements the curly brace must be indented.
>> And the first condition should be on the same line
>>
>> if ( enableToc || ...
>> 
>> && baz ) {
>>
>>
>> not:
>> if (
>> enableToc || ...
>> 
>> && baz ) {
>>
>> Again I'm not sure if this will happen too often. This to me is a sign
>> that we should be using functions rather than long if statements
>> personally. Again not a blocker.
>>
>> Actions:
>> * Implement https://github.com/beautify-web/js-beautify/issues/424
>> * You guys need to advise me on how we should handle square brackets
>> in our codebase in such a way we respect MediaWiki coding conventions
>> and come up with a consistent style we are happy with and can adhere
>> to.
>> * I'll implement https://trello.com/c/0dkx0ldL in some form
>> * I'll explore if jscs can support objects defined on new line
>> * When the above are done I recommend we turn on jsbeautify for the project.
>>
>> I've setup a tracking card for the above work:
>> https://trello.com/c/5btWf2JN/90-snakes-on-a-plane
>> and will be looking at these problems today.
>>
>> [1] https://github.com/beautify-web/js-beautify
>> [2] https://github.com/jscs-dev/node-jscs
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend

[Bahodir Mansurov]

I honestly think that we should do away with spaces inside () and []. It puts 
an end to ugly code like this:

if ( $viewportMeta[ 0 ] && ( isIPhone4 || isIPhone5 ) ) {

compare with this (so much nicer)
if ($viewportMeta[0] && (isIPhone4 || isIPhone5)) {

By removing space we are no longer stressing () and [], the focus shifts to 
other parts of code for easier reading.


> On Nov 20, 2014, at 3:19 PM, Jon Robson  wrote:
> 
> Follow up
> If I run `make jsbeautify` now
> then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 is the result.
> 
> Outstanding actions:
> * Need input on rest of the team about which of delete
> this.cache[title]; or delete this.cache[ title ]; is the preferred
> standard.
> * You'll notice jsbeautify and inlne comments need to be ironed out.
> For example:
> https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-L257
> 
> Apart from the above 2 jsbeautify makes some adjustments to our
> whitspace which I guess we'll just have to live with.
> 
> Please can everyone else let me know how they think we should proceed?
> 
> 
> 
> On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov
>  wrote:
>> As for # Rule 4, it makes sense to add spaces inside square brackets. The 
>> reasoning is the same as why we add spaces inside parenthesis.
>> 
>>> On Nov 18, 2014, at 12:28 PM, Jon Robson  wrote:
>>> 
>>> I explored running jsbeautify [1] on the MobileFrontend codebase and
>>> looked at how the output differs from the current styling. It
>>> introduces various rules that MobileFrontend is currently not adhering
>>> too. MobileFrontend already uses jscs [2] so we want to make sure the
>>> outputs of both are compatible. Here is my report on that with the
>>> recommendation that we should use it.
>>> 
>>> #Rule 1: object properties defined on a single line.
>>> e.g.
>>> {
>>> foo: 2,
>>> bar: 3
>>> }
>>> NOT { foo: 2, bar: 3 }
>>> 
>>> I think this would be a good idea to adopt. I will explore if jscs can
>>> enforce this.
>>> 
>>> # Rule 2: variables that are initialised must be followed by a new
>>> line (although I noted a few odd cases e.g. in Page.js after a "?:"
>>> expression and /MobileWebClickTracking.js
>>> e.g.
>>> var Foo, bar = $( 'div' ),
>>> Baz,
>>> Bar;
>>> 
>>> not:
>>> var Foo, bar = $( 'div' ), Baz, Bar;
>>> 
>>> This will be fixed if I implement https://trello.com/c/0dkx0ldL
>>> 
>>> # Rule 3: All chained events should be indented
>>> e.g.
>>> foo()
>>> .bar();
>>> 
>>> not
>>> foo().
>>> bar();
>>> 
>>> Seems like a no brainer. One that happens naturally most of the time.
>>> 
>>> # Rule 4: Spacing in object parameters
>>> e.g.
>>> foo[ 1 ]
>>> [ 1, 2, 3, 4 ]
>>> 
>>> not:
>>> foo[1]
>>> [1, 2, 3, 4]
>>> 
>>> This is different to MediaWiki coding conventions but I can implement
>>> https://github.com/beautify-web/js-beautify/issues/424 to give us
>>> this.
>>> We seem a bit inconsistent ourselves with this convention - let me
>>> know how you think this rule should work in our codebase...
>>> 
>>> # Rule 5: New line after variable declarations
>>> 
>>> var x, y, z;
>>> 
>>> z();
>>> 
>>> not:
>>> var x, y, z;
>>> z();
>>> 
>>> Also:
>>> function foo() {}
>>> 
>>> function bar() {}
>>> 
>>> not:
>>> function foo() {}
>>> function bar() {}
>>> 
>>> Seems like a no brainer and shouldn't introduce any major issues with
>>> code review.
>>> 
>>> # Rule 6: Comments must respect the current indentation level
>>> 
>>> if () {
>>> ...
>>> // If i is 5 we do something special
>>> } else if ( i === 5 ){
>>> 
>>> }
>>> becomes
>>> if () {
>>> ...
>>> // If i is 5 we do something special
>>> } else if ( i === 5 ){
>>> 
>>> }
>>> We'll have to think about what to do with these comments but I don't
>>> think this should be a blocker to using jsbeautify. It will only pop
>>> up occasionally.
>>> 
>>> # Rule 7: On long if statements the curly brace must be indented.
>>> And the first condition should be on the same line
>>> 
>>> if ( enableToc || ...
>>> 
>>> && baz ) {
>>> 
>>> 
>>> not:
>>> if (
>>> enableToc || ...
>>> 
>>> && baz ) {
>>> 
>>> Again I'm not sure if this will happen too often. This to me is a sign
>>> that we should be using functions rather than long if statements
>>> personally. Again not a blocker.
>>> 
>>> Actions:
>>> * Implement https://github.com/beautify-web/js-beautify/issues/424
>>> * You guys need to advise me on how we should handle square brackets
>>> in our codebase in such a way we respect MediaWiki coding conventions
>>> and come up with a consistent style we are happy with and can adhere
>>> to.
>>> * I'll implement https://trello.com/c/0dkx0ldL in some form
>>> * I'll explore if jscs can support objects defined on new line
>>> * When the above are done I recommend we turn on jsbeautify for the project.
>>> 
>>> I've setup a tracking card for the above work:
>>> https://trello.com/c/5btWf2JN/90-snakes-on-a-plane
>>> and will be looking at these problems today.
>>> 
>>> [1] https://github.com/beautify-web/js-beautify
>>> [2

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend

[Max Semenik]

Spaces inside of () is the MW convention, inside of [] they're indeed
unneeded.

On Thu, Nov 20, 2014 at 4:03 PM, Bahodir Mansurov 
wrote:

> I honestly think that we should do away with spaces inside () and []. It
> puts an end to ugly code like this:
>
> if ( $viewportMeta[ 0 ] && ( isIPhone4 || isIPhone5 ) ) {
>
> compare with this (so much nicer)
> if ($viewportMeta[0] && (isIPhone4 || isIPhone5)) {
>
> By removing space we are no longer stressing () and [], the focus shifts
> to other parts of code for easier reading.
>
>
> On Nov 20, 2014, at 3:19 PM, Jon Robson  wrote:
>
> Follow up
> If I run `make jsbeautify` now
> then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 is the result.
>
> Outstanding actions:
> * Need input on rest of the team about which of delete
> this.cache[title]; or delete this.cache[ title ]; is the preferred
> standard.
> * You'll notice jsbeautify and inlne comments need to be ironed out.
> For example:
>
> https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-L257
>
> Apart from the above 2 jsbeautify makes some adjustments to our
> whitspace which I guess we'll just have to live with.
>
> Please can everyone else let me know how they think we should proceed?
>
>
>
> On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov
>  wrote:
>
> As for # Rule 4, it makes sense to add spaces inside square brackets. The
> reasoning is the same as why we add spaces inside parenthesis.
>
> On Nov 18, 2014, at 12:28 PM, Jon Robson  wrote:
>
> I explored running jsbeautify [1] on the MobileFrontend codebase and
> looked at how the output differs from the current styling. It
> introduces various rules that MobileFrontend is currently not adhering
> too. MobileFrontend already uses jscs [2] so we want to make sure the
> outputs of both are compatible. Here is my report on that with the
> recommendation that we should use it.
>
> #Rule 1: object properties defined on a single line.
> e.g.
> {
> foo: 2,
> bar: 3
> }
> NOT { foo: 2, bar: 3 }
>
> I think this would be a good idea to adopt. I will explore if jscs can
> enforce this.
>
> # Rule 2: variables that are initialised must be followed by a new
> line (although I noted a few odd cases e.g. in Page.js after a "?:"
> expression and /MobileWebClickTracking.js
> e.g.
> var Foo, bar = $( 'div' ),
> Baz,
> Bar;
>
> not:
> var Foo, bar = $( 'div' ), Baz, Bar;
>
> This will be fixed if I implement https://trello.com/c/0dkx0ldL
>
> # Rule 3: All chained events should be indented
> e.g.
> foo()
> .bar();
>
> not
> foo().
> bar();
>
> Seems like a no brainer. One that happens naturally most of the time.
>
> # Rule 4: Spacing in object parameters
> e.g.
> foo[ 1 ]
> [ 1, 2, 3, 4 ]
>
> not:
> foo[1]
> [1, 2, 3, 4]
>
> This is different to MediaWiki coding conventions but I can implement
> https://github.com/beautify-web/js-beautify/issues/424 to give us
> this.
> We seem a bit inconsistent ourselves with this convention - let me
> know how you think this rule should work in our codebase...
>
> # Rule 5: New line after variable declarations
>
> var x, y, z;
>
> z();
>
> not:
> var x, y, z;
> z();
>
> Also:
> function foo() {}
>
> function bar() {}
>
> not:
> function foo() {}
> function bar() {}
>
> Seems like a no brainer and shouldn't introduce any major issues with
> code review.
>
> # Rule 6: Comments must respect the current indentation level
>
> if () {
> ...
> // If i is 5 we do something special
> } else if ( i === 5 ){
>
> }
> becomes
> if () {
> ...
> // If i is 5 we do something special
> } else if ( i === 5 ){
>
> }
> We'll have to think about what to do with these comments but I don't
> think this should be a blocker to using jsbeautify. It will only pop
> up occasionally.
>
> # Rule 7: On long if statements the curly brace must be indented.
> And the first condition should be on the same line
>
> if ( enableToc || ...
> 
> && baz ) {
>
>
> not:
> if (
> enableToc || ...
> 
> && baz ) {
>
> Again I'm not sure if this will happen too often. This to me is a sign
> that we should be using functions rather than long if statements
> personally. Again not a blocker.
>
> Actions:
> * Implement https://github.com/beautify-web/js-beautify/issues/424
> * You guys need to advise me on how we should handle square brackets
> in our codebase in such a way we respect MediaWiki coding conventions
> and come up with a consistent style we are happy with and can adhere
> to.
> * I'll implement https://trello.com/c/0dkx0ldL in some form
> * I'll explore if jscs can support objects defined on new line
> * When the above are done I recommend we turn on jsbeautify for the
> project.
>
> I've setup a tracking card for the above work:
> https://trello.com/c/5btWf2JN/90-snakes-on-a-plane
> and will be looking at these problems today.
>
> [1] https://github.com/beautify-web/js-beautify
> [2] https://github.com/jscs-dev/node-jscs
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> 

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend

[Bahodir Mansurov]

Do you know why there are spaces inside () but not inside []. Just curious.

> On Nov 20, 2014, at 7:07 PM, Max Semenik  wrote:
> 
> Spaces inside of () is the MW convention, inside of [] they're indeed 
> unneeded.
> 
> On Thu, Nov 20, 2014 at 4:03 PM, Bahodir Mansurov  > wrote:
> I honestly think that we should do away with spaces inside () and []. It puts 
> an end to ugly code like this:
> 
> if ( $viewportMeta[ 0 ] && ( isIPhone4 || isIPhone5 ) ) {
> 
> compare with this (so much nicer)
> if ($viewportMeta[0] && (isIPhone4 || isIPhone5)) {
> 
> By removing space we are no longer stressing () and [], the focus shifts to 
> other parts of code for easier reading.
> 
> 
>> On Nov 20, 2014, at 3:19 PM, Jon Robson > > wrote:
>> 
>> Follow up
>> If I run `make jsbeautify` now
>> then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 
>>  is the result.
>> 
>> Outstanding actions:
>> * Need input on rest of the team about which of delete
>> this.cache[title]; or delete this.cache[ title ]; is the preferred
>> standard.
>> * You'll notice jsbeautify and inlne comments need to be ironed out.
>> For example:
>> https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-L257
>>  
>> 
>> 
>> Apart from the above 2 jsbeautify makes some adjustments to our
>> whitspace which I guess we'll just have to live with.
>> 
>> Please can everyone else let me know how they think we should proceed?
>> 
>> 
>> 
>> On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov
>> mailto:bmansu...@wikimedia.org>> wrote:
>>> As for # Rule 4, it makes sense to add spaces inside square brackets. The 
>>> reasoning is the same as why we add spaces inside parenthesis.
>>> 
 On Nov 18, 2014, at 12:28 PM, Jon Robson >>> > wrote:
 
 I explored running jsbeautify [1] on the MobileFrontend codebase and
 looked at how the output differs from the current styling. It
 introduces various rules that MobileFrontend is currently not adhering
 too. MobileFrontend already uses jscs [2] so we want to make sure the
 outputs of both are compatible. Here is my report on that with the
 recommendation that we should use it.
 
 #Rule 1: object properties defined on a single line.
 e.g.
 {
 foo: 2,
 bar: 3
 }
 NOT { foo: 2, bar: 3 }
 
 I think this would be a good idea to adopt. I will explore if jscs can
 enforce this.
 
 # Rule 2: variables that are initialised must be followed by a new
 line (although I noted a few odd cases e.g. in Page.js after a "?:"
 expression and /MobileWebClickTracking.js
 e.g.
 var Foo, bar = $( 'div' ),
 Baz,
 Bar;
 
 not:
 var Foo, bar = $( 'div' ), Baz, Bar;
 
 This will be fixed if I implement https://trello.com/c/0dkx0ldL 
 
 
 # Rule 3: All chained events should be indented
 e.g.
 foo()
 .bar();
 
 not
 foo().
 bar();
 
 Seems like a no brainer. One that happens naturally most of the time.
 
 # Rule 4: Spacing in object parameters
 e.g.
 foo[ 1 ]
 [ 1, 2, 3, 4 ]
 
 not:
 foo[1]
 [1, 2, 3, 4]
 
 This is different to MediaWiki coding conventions but I can implement
 https://github.com/beautify-web/js-beautify/issues/424 
  to give us
 this.
 We seem a bit inconsistent ourselves with this convention - let me
 know how you think this rule should work in our codebase...
 
 # Rule 5: New line after variable declarations
 
 var x, y, z;
 
 z();
 
 not:
 var x, y, z;
 z();
 
 Also:
 function foo() {}
 
 function bar() {}
 
 not:
 function foo() {}
 function bar() {}
 
 Seems like a no brainer and shouldn't introduce any major issues with
 code review.
 
 # Rule 6: Comments must respect the current indentation level
 
 if () {
 ...
 // If i is 5 we do something special
 } else if ( i === 5 ){
 
 }
 becomes
 if () {
 ...
 // If i is 5 we do something special
 } else if ( i === 5 ){
 
 }
 We'll have to think about what to do with these comments but I don't
 think this should be a blocker to using jsbeautify. It will only pop
 up occasionally.
 
 # Rule 7: On long if statements the curly brace must be indented.
 And the first condition should be on the same line
 
 if ( enableToc || ...
 
 && baz ) {
 
 
 not:
 if (
 enableToc || ...
 
 && baz ) {
 
 Again I'm not sure if this will happen too often. This to me is a sign
 that we should be using

[WikimediaMobile] [Web] Spike: Explore using CSSLint/LessLint in mobile

[Bahodir Mansurov]

After reading benefits of CSSLint there is no doubt in my mind that we should 
use it. Here [1] are some of the benefits. They range from possible errors to 
compatibility to performance, etc. With grunt we can use grunt-lesslint [2], 
which employs CSSLint under the hood so we can also tweak it using CSSLint 
rules.

What do you guys think?

[1] https://github.com/CSSLint/csslint/wiki/Rules 
.
[2] https://github.com/jgable/grunt-lesslint 
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Web] Spike: Explore using CSSLint/LessLint in mobile

[Jon Robson]

Which rules would MobileFrontend be able to use from the start?
Which rules might be controversial to adopt?


On Fri, Nov 21, 2014 at 9:00 AM, Bahodir Mansurov
 wrote:
> After reading benefits of CSSLint there is no doubt in my mind that we
> should use it. Here [1] are some of the benefits. They range from possible
> errors to compatibility to performance, etc. With grunt we can use
> grunt-lesslint [2], which employs CSSLint under the hood so we can also
> tweak it using CSSLint rules.
>
> What do you guys think?
>
> [1] https://github.com/CSSLint/csslint/wiki/Rules.
> [2] https://github.com/jgable/grunt-lesslint
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l