Last modified: 2014-09-01 15:38:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T63099, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 61099 - Vector: Remove use of raster graphics in the layout styles
Vector: Remove use of raster graphics in the layout styles
Status: NEW
Product: MediaWiki skins
Classification: Unclassified
Vector (Other open bugs)
unspecified
All All
: Low enhancement
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 61010
Blocks: 44881 51912 60317
  Show dependency treegraph
 
Reported: 2014-02-08 22:05 UTC by Bartosz Dziewoński
Modified: 2014-09-01 15:38 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bartosz Dziewoński 2014-02-08 22:05:11 UTC
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.
Comment 1 Erwin Dokter 2014-02-08 23:59:32 UTC
I can find the following:

Normal pages
* page-fade.png for #base-page (top of page)
* tab-normal-fade.png for tabs in .vectorTabs
  (tab-current-fade.png is plain white bg image)
* tab-break.png for tab dividers
* portal-break.png for navigation dividers
  (there are also two ltr/rtl version)
* search-fade.png in the serach box

Preferences page:
* fade.png for the active tab in Preferences page
  (other tabs use only background-color)
* break.png for tab dividers

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.
Comment 2 Bartosz Dziewoński 2014-02-09 00:44:10 UTC
(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.
Comment 3 Erwin Dokter 2014-02-09 12:42:24 UTC
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.
Comment 4 Isarra 2014-02-09 17:07:53 UTC
(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.
Comment 5 Erwin Dokter 2014-02-19 14:04:34 UTC
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?
Comment 6 Erwin Dokter 2014-02-19 14:23:05 UTC
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;
}
Comment 7 Erwin Dokter 2014-02-19 16:48:18 UTC
Correcting my first question; it's just .background-image-svg that lacks the -moz-prefix in mixins.less. Does Firefox <16 not support SVG?
Comment 8 Bartosz Dziewoński 2014-02-19 17:07:24 UTC
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.
Comment 9 Erwin Dokter 2014-02-19 17:33:43 UTC
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.
Comment 10 Erwin Dokter 2014-02-19 19:54:00 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links