If we want to ever make Vector's design editable with some "wizard", the basic styles need to become image-independent (as we don't really want to generate images on the fly, do we?).
Basically we need to rip out image-based gradients and replace them with CSS. There's quite a few of them.
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T53912 Make Wikipedia distinct by styling of a prominent UI feature differently than the default | ||
| Resolved | Jdlrobson | T62317 Implement reasonably usable skin modification user interface in MediaWiki core | |||
| Resolved | Volker_E | T63099 Vector: Remove use of raster graphics in the layout styles | |||
| Declined | None | T63010 Add IE7-9 support to .vertical-gradient mixin | |||
| Invalid | None | T63008 ResourceLoader should make it possible to automatically expand #fff-style colours to #ffffff-style |
I can find the following:
Normal pages
Preferences page:
The tabs will be the hardest to find any suitable fallback methods for, as its design relies on the gradients. Choose one color, and there will be a hard edge either way. Degradation is very noticable.
Portal-break.png could be a solid line, which is just slightly less prettier, so essentially requires no fallback.
Search-fade.png is so subtle it is hardly noticable, so requires no fallback.
Just brainstorming now... Providing generated images on the fly is not that radical, or hard with any PHP graphics library. We already convert and scale images and generate math. All mixin would have to do is create an image url that contains the colors and stops in its filename and call upon that URL in the generated CSS. Then the libraly generates and caches that gradient background image.
(In reply to comment #1)
Just brainstorming now... Providing generated images on the fly is not that
radical, or hard with any PHP graphics library. We already convert and scale
images and generate math. All mixin would have to do is create an image url
that contains the colors and stops in its filename and call upon that URL in
the generated CSS. Then the libraly generates and caches that gradient
background image.
We could already embed SVGs in data: URIs directly in CSS and use whatever variables we wish in them, but the problem here is the old browsers which don't support neither data: URIs nor SVGs :) And this, as serving dynamic resources is a lot slower than static resources, would mean another layer of caching, and that would probably mean more cache invalidation mess on top of what we already have. It would also probably mean more pesky configuration for the kind of people and hosting setups who struggle with, say, getting MediaWiki to accept uploads.
Feel free to prove me wrong, but currently I think that dynamic generation of graphics for skins, while definitely possible, is not something we would want to do.
I can't find any other way if we are to maintain support for IE 6-9 (and all older browsers that lack gradient support). The IE filter is woefully inadequate as it does not support stops and degrades font rendering to an unacceptable level. Adding stops support for the IE filter would require injecting additional divs, which is not possible in CSS/LESS, and limiting mixin capabilities to match that of the EI filter is definitely not desirable. The IE filter is simply not a viable option (which is why I think bug 61010 should be WONTFIXed).
A proper background-color fallback is the most feasable option. One problem is that mixin assign the end color as the default background-color. When I wrote [[en:Template:Linear-gradient]], I did the same (using startcolor), but later removed it and required that a initial background-color be specified. I think mixin should do the same. Otherwise, there will be a lot of duplicate background-color declarations because the initial one will need to be overridden.
(In reply to comment #3)
I can't find any other way if we are to maintain support for IE 6-9 (and all
older browsers that lack gradient support). The IE filter is woefully
inadequate as it does not support stops and degrades font rendering to an
unacceptable level. Adding stops support for the IE filter would require
injecting additional divs, which is not possible in CSS/LESS, and limiting
mixin capabilities to match that of the EI filter is definitely not
desirable.
The IE filter is simply not a viable option (which is why I think bug 61010
should be WONTFIXed).
I don't think this is the case. The filter does work, even if it isn't always. Very few gradients need stops to render properly - the common use cases tend to be things like page backgrounds and buttons, which are already simple and where even if they do have non-default stops, the two colour, 0,100% gradients still get across the general idea and look just fine in IE.
The font issues also appears to be limited to IE7/8, and nor will they make text illegible there unless there is something else rather wrong with the design, though less such text is still generally better. But not all gradients will have text on them at all. Vector's do, but Vector is a single skin.
IE9 renders fonts normally, as does IE6, though this is probably because IE6 runs on a version of windows that doesn't actually have that fancy font stuff in the first place.
If you can make some sort of automatic image thing, that could be a lot cleaner, but I would argue that by IE standards, the filter is far from inadequate, falling back to a solid colour in the meantime would be wholly unnecessary for the majority of cases.
Perhaps off-topic, but I have to ask: Why does mixin only add the -webkit- prefix for linear-gradient, and not the -moz- prefix? Even weirder, why is the *legacy* -webkit- version there and not the -moz- prefix?
The prefix-less linear-gradient property was not introduced until Firefox 16. Older versions still require the -moz- prefix. Around the same time, the non-legacy -webkit- version was introduced. So it seems weird to have one but not the other. Also, Opera up until 11.6 still requires the -o- prefix. Is it worth adding that?
On-topic again... I have some CSS here to make the Vector tabs completely image-independent. There is a one-pixel discrepancie with active tabs, which i think is way too minor to fix (can you spot it?) There is no fallback (yet), just a proof of concept for the tabs.
Paste this in your vector.css:
div#content {
/* Reset -1px margin */
margin-top: inherit;
}
div.vectorMenu ul {
/* Reset top border for drop-down menu */
border-top: 1px solid #a7d7f9;
}
div.vectorTabs,
div.vectorTabs span {
/* Tab break */
background-image: -moz-linear-gradient(bottom, #a7d7f9 0%, #fff 100%);
background-image: -webkit-linear-gradient(bottom, #a7d7f9 0%, #fff 100%);
background-image: linear-gradient(to top, #a7d7f9 0%, #fff 100%);
background-size: 1px 100%;
}
div.vectorTabs ul li {
/* Tab background */
background-image: -moz-linear-gradient(bottom, #e8f2f8 0%, #fff 100%);
background-image: -webkit-linear-gradient(bottom, #e8f2f8 0%, #fff 100%);
background-image: linear-gradient(to top, #e8f2f8 0%, #fff 100%);
}
div.vectorTabs ul li.selected {
background-image: none;
background-color: #fff;
/* Fix bottom border for active tab */
border-bottom: 1px solid #fff;
}Correcting my first question; it's just .background-image-svg that lacks the -moz-prefix in mixins.less. Does Firefox <16 not support SVG?
Re .background-image-svg:
There's more about the technique on http://pauginer.tumblr.com/post/36614680636/invisible-gradient-technique (on a side note, that should be linked in code comments somewhere, let me do that), it mentions that:
The technique is restrictive on purpose to make sure that SVG is only
provided to SVG-capable browsers. As a consequence, we can be sure
that all users will see the image. The price to pay is that some
browser versions (such as IE9 or Firefox 3.5) that are also capable of
rendering SVG but do not support gradients will display the fallback
version.
Adding more vendor-specific prefixes would also mean a slightly bigger payload (as the embedded image data would be repeated a few times), this is luckily usually negligible thanks to gzip compression.
CC-ing Pau for his comments :)
Re Vector tabs: patches welcome :) I think there's no reason not to do this, it's just that nobody bothered yet.
I'll have to 'translate' it to LESS. And I have to have some form of fallback for IE, which will probably be just some well chosen background colors.
This may seem contradictary to my previous comments, but I just believe if background images are going out, do it proper the first time instead of breaking just one element at a time.
OK, forget the above code. I now have a test gadget up on test.wikipedia.org [[test:MediaWiki:Gadget-ImagelessTabs.css]]. It required some puzzling to simulate mixins, but it's there. Looks good in modern browsers, but I want to hear what you think of the IE fallback; it's the best I could do.
The biggest problem are the tab breaks; I cannot simulate a 1px-wide background image with a background color, so all tabs are connected. Input please.
For the record, I think the gradients proposed by @Edokter in comment T63099#653216 above and https://test.wikipedia.org/wiki/MediaWiki:Gadget-ImagelessTabs.css look like a good starting point. Perhaps someone would want to turn that into a patch.
Change 528499 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] Replace raster image gradients with CSS
Change 540005 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] Replace portal break image by SVG gradient
Change 540005 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Replace portal break image by SVG gradient
Change 540205 had a related patch set uploaded (by Krinkle; owner: VolkerE):
[mediawiki/skins/Vector@wmf/1.34.0-wmf.25] Replace portal break image by SVG gradient
Change 540205 merged by jenkins-bot:
[mediawiki/skins/Vector@wmf/1.34.0-wmf.25] Replace portal break image by SVG gradient
Change 540219 had a related patch set uploaded (by Krinkle; owner: VolkerE):
[mediawiki/skins/Vector@wmf/1.34.0-wmf.25] Replace raster image gradients with CSS where easily applicable
Change 528499 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Replace raster image gradients with CSS where easily applicable
Change 540219 merged by jenkins-bot:
[mediawiki/skins/Vector@wmf/1.34.0-wmf.25] Replace raster image gradients with CSS where easily applicable