https://bugzilla.wikimedia.org/show_bug.cgi?id=52718
--- Comment #2 from Krinkle <[email protected]> --- I won't close this bug yet to allow for elaboration in case I misunderstood the use case. From what I can this bug is simply invalid and acting on wrong premises. Loading a module, especially if the module contains both javascript and CSS, means both are acting in conjunction and one is useless if not problematic without the other. If you have stylesheets that apply to content generated and output server-side and those stylesheets are critical for basic consumption of the content, those stylesheets should be put in a separate module and that module loaded through addModuleStyles. The reason you don't want to use addModuleStyles is probably because you want to have what addModules does, which is dependency resolution and max cache urls. The reason addModuleStyles can't give you that is because there is no way to both output html that is max cachable and also have that url contain the dependencies and timestamps. So we can only have: 1) mw.loader.load calls that then (through data from the startup module) grab dependencies and construct max cache urls (30 days+) with timestamps). aka addModules. or: 2) <link modules=...> without dependencies or timestamps, cached for a relatively short duration (1 day, 1 hour, 30 min, 5 min, whatever your RL cache maxage config is for unversioned load.php requests. aka addModuleStyles. The only option I see here would be if we use ESI, which right now doesn't seem to be on the horizon just yet, And even then we probably shouldn't use it to something that has no fallback (e.g. with ESI dependencies and without ESI no dependencies is unacceptable, afaik we should only use ESI to enhance, not make things possible). By fallback I mean when ESI is unavailable, misconfigured or simply not installed on the third party web server. A possible enhancement would be to at least give the addModuleStyles urls a timestamp, that would make them perform much better. Also note that you should be aware of something else: We do not actively care even the tiniest bit (aside from regular access to information and reading pages) about clients without javascript. Get over it, it's 2013. If it wasn't for Opera 11 (or Opera 12) not supporting <noscript><link/></noscript> we would've dropped non-JS support entirely and even load addModuleStyles with javascript. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
