Sublime Forum

Mdpopups 1.9.0

#21

Please be aware that color schemes support named colors, but they are NOT the same as CSS named colors. Colors in color schemes are based on named colors from TextMate. green is very different between the two.

Some of the work that is going to be part of the next dev build fixes the bug that currently minihtml is using TextMate color scheme named colors for CSS named colors. This current behavior is considered a bug since we strive to follow the CSS standards, even if we don’t implement all features.

2 Likes
#22

@wbond, So color schemes will always use TextMate named colors, but the CSS will soon use CSS named colors? Just making sure I understand.

Where can I find a list of TextMate named colors?

0 Likes
#23

So apparently I misattributed the color names to TextMate. While TextMate uses them, and we support them since we support .tmTheme, they are technically X11 color names. You can see on that wikipedia page a summary of the conflicts between X11 and CSS. They appear to be a number of different versions of the color names with different capitalization and spacing. The page http://www.graphviz.org/doc/info/colors.html seems to have the same list as we support.

When I get around to documenting color schemes, I’ll be sure to list these, although generally the RGB hex colors seem more portable.

5 Likes
#24

Thanks @wbond. This is exactly what I am looking for.

I agree that hex is more portable, and I would prefer everyone stick to those, but I have to be aware of them anyways as they are valid and when they are used by others it breaks stuff in some of my plugins.

0 Likes
#25

Alright now using X11 color names:

MdPopups 1.12.1

Released Nov 28, 2016

FIX: Use X11 named colors and not CSS named colors in color schemes

0 Likes
#26

Originally, mdpopups configured a lot of the colors of the popups and phantoms itself, but then Sublime added the ability for themes to specify colors for popups/phantoms and Sublime will autogen basic colors for themes that don’t supply popup and phantom CSS. It has become less important for Mdpopups to enforce color scheme colors, and instead let the color scheme and Sublime handle it. Because of this, some changes in how mdpopup CSS is handled have been made.

Plugins have a bit more power in overriding CSS (when they absolutely have to), but they should still use content wrapper classes and/or classes very unique to the plugin to allow a user to override any changes if they desire. Mdpopups won’t block plugins from behaving poorly, people will just have to file issues to the offending plugin’s issue tracker that has made it difficult to override their changes.

Mdpopups 1.13.0

Released Nov 29, 2016

  • Adding user CSS does not replace default.css anymore. User CSS rules just override default style rules.
  • All the style rules in default.css can be disabled by setting mdpopups.default_style in Preference.sublime-settings to true.
  • New CSS loading order: base.css (formatting), default.css (color styles), autogen (classes for sublime
    scopes etc.), plugin (plugin specific CSS), user (user overrides). This gives plugins a little more power in overriding (but they should still use wrapper classes and/or unique classes), but user CSS still can override anything.
0 Likes
#27

Finally pinned down something that’s been bothering. It appears that the default line-height (particularly on Mac) would cause odd things like periodic gaps between lines that were bigger than normal, and I believe slight image stretching. Default font was 1rem and line-height was 1.2rem. Reducing default line height to 1.1rem seemed to make these issues go away.

Mdpopups 1.13.1

Released Dec 3, 2016

  • Adjust default line-height in CSS to 1.1 to minimize image distortion.
0 Likes