Basically: skins style the interface, extensions add new interface. Compatibility then needs to be added to the skins for the extensions, so they can style the new interface too, but we don't want to load the extension-specific styles unless the extensions is actually used. Thus we use $wgResourceModuleSkinStyles to add the skin styles to the extension modules.
Simple, right?
The problem arises when you're making a fully-responsive skin with multiple stylesheets for different view modes (say, a common stylesheet for desktop and mobile, a mobile stylesheet, a desktop stylesheet with specifics for smaller screens, and a desktop stylesheet for gigantic monitors). Each of these is a separate file, with its target screen sizes specified in the module definition in skin.json. For many extensions, proper compatibility will also require specific styles for several of these.
Unfortunately $wgResourceModuleSkinStyles cannot be defined the usual way in skin.json, and lacks support for @media queries, so the only way to even do this is to set the @media sizes inside the files themselves.
What I'm wondering:
1. Is there any good way to parametrise the @media sizes so we only have to define them once, and then just have the main skin styles, and all the extension ones, inherit those values? Or is setting a series of less variables and then keeping those up-to-date with the values in skin.json probably the best approach? 2. What are best practices for organising this when you have many sizes and many extensions? Should each extension have one file? Even if the @media sizes are all in-line in the same file, that is still a separate file for each extension. Where should these files be kept? 3. Who would be the folks to go to about making this less bad?
-I
Hi Isarra,
You might try the design@ email list if you don't get a satisfactory reply here within a day or two. Also pinging Quiddity in case he has ideas.
HTH,
Pine
On Sat, Mar 25, 2017 at 11:40 AM, Isarra Yos zhorishna@gmail.com wrote:
Basically: skins style the interface, extensions add new interface. Compatibility then needs to be added to the skins for the extensions, so they can style the new interface too, but we don't want to load the extension-specific styles unless the extensions is actually used. Thus we use $wgResourceModuleSkinStyles to add the skin styles to the extension modules.
Simple, right?
The problem arises when you're making a fully-responsive skin with multiple stylesheets for different view modes (say, a common stylesheet for desktop and mobile, a mobile stylesheet, a desktop stylesheet with specifics for smaller screens, and a desktop stylesheet for gigantic monitors). Each of these is a separate file, with its target screen sizes specified in the module definition in skin.json. For many extensions, proper compatibility will also require specific styles for several of these.
Unfortunately $wgResourceModuleSkinStyles cannot be defined the usual way in skin.json, and lacks support for @media queries, so the only way to even do this is to set the @media sizes inside the files themselves.
What I'm wondering:
- Is there any good way to parametrise the @media sizes so we only have
to define them once, and then just have the main skin styles, and all the extension ones, inherit those values? Or is setting a series of less variables and then keeping those up-to-date with the values in skin.json probably the best approach? 2. What are best practices for organising this when you have many sizes and many extensions? Should each extension have one file? Even if the @media sizes are all in-line in the same file, that is still a separate file for each extension. Where should these files be kept? 3. Who would be the folks to go to about making this less bad?
-I
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If I don't get a satisfactory reply I'll just decide something arbitrarily and then declare that standard practice moving forward, and look down on anyone doing anything different disappointedly.
Well, not really, since if anyone's doing anything related at all, that would actually be quite interesting. But you know.
-I
On 27/03/17 01:54, Pine W wrote:
Hi Isarra,
You might try the design@ email list if you don't get a satisfactory reply here within a day or two. Also pinging Quiddity in case he has ideas.
HTH,
Pine
On Sat, Mar 25, 2017 at 11:40 AM, Isarra Yos zhorishna@gmail.com wrote:
Basically: skins style the interface, extensions add new interface. Compatibility then needs to be added to the skins for the extensions, so they can style the new interface too, but we don't want to load the extension-specific styles unless the extensions is actually used. Thus we use $wgResourceModuleSkinStyles to add the skin styles to the extension modules.
Simple, right?
The problem arises when you're making a fully-responsive skin with multiple stylesheets for different view modes (say, a common stylesheet for desktop and mobile, a mobile stylesheet, a desktop stylesheet with specifics for smaller screens, and a desktop stylesheet for gigantic monitors). Each of these is a separate file, with its target screen sizes specified in the module definition in skin.json. For many extensions, proper compatibility will also require specific styles for several of these.
Unfortunately $wgResourceModuleSkinStyles cannot be defined the usual way in skin.json, and lacks support for @media queries, so the only way to even do this is to set the @media sizes inside the files themselves.
What I'm wondering:
- Is there any good way to parametrise the @media sizes so we only have
to define them once, and then just have the main skin styles, and all the extension ones, inherit those values? Or is setting a series of less variables and then keeping those up-to-date with the values in skin.json probably the best approach? 2. What are best practices for organising this when you have many sizes and many extensions? Should each extension have one file? Even if the @media sizes are all in-line in the same file, that is still a separate file for each extension. Where should these files be kept? 3. Who would be the folks to go to about making this less bad?
-I
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@lists.wikimedia.org