MiniHTML: Borders around scrollable popups #1701
Comments
|
You can actually add a border on the actual window element via a theme instead of a border via CSS. The boxy theme has a configurable option for popup window element. That works like you would want. You can't really get that via CSS. |
|
So adding borders to any of the minihtml entities does not make sense at all and visibility of a popup depends on the theme. And theme must care about adapting the color to the active color scheme or not?
If I can add a border around a html entity which is scrolled off the screen, I would like to be able how and where borders are added. |
I wouldn't say that. I think there is a good use for borders, but maybe you just mean in this case. In general, I think Sublime is rendering the webpage in a borderless web view like window. Something like an iframe could give you what you want, or the ability to control overflow of elements, but I don't think that is really the big issue. The issue is how popups are visually represented across OSs. On Mac, popups have a shadow making the contrast a non-issue. Even Ubuntu seems to do something similar, but I doubt all Linux variants do and Windows doesn't. Sublime tries to curb the contrast issue on other systems by making the background color lighter to give contrast if a color scheme is not controlling the background, but that falls apart on on themes close to white. I personally feel it would be better to darken themes over luminance or brightness 50% and lighten with luminance or brightness under 50%. I also think Sublime should standardize that color as a CSS variable so color schemes could just override it if they wanted to provide a different one and plugins could access and use it to keep elements consistent. I think if Sublime just provided a good contrast solution for light and dark themes and made that color available as a CSS variable, I'd be happy. Borders could be left to themes and backgrounds could be left to Sublime if a color scheme doesn't specify one. That's just my opinion. |
Yes I do. It doesn't make sense to draw a border with the intend to increase contrast and scroll it off the viewport then.
I already thought about something like that, too. A light shadow would really help here. Just like the shadow used to separate the minimap, would be pretty cool. Even for auto-complete. Contrast and good adaption to the active color scheme are my concerns and the reason to file this issue. So I am absolutely with you @facelessuser. |
|
If they gave me html {
--adjusted-background: /*some color*/;
}Then plugins would know what it is no matter what as well. For me, this would be perfect. |
|
Borders on popup windows are part of the theme, not minihtml document. However, both themes and minihtml have access to the foreground and background colors of the global color scheme. In the situation that a color scheme is dark, the In the themes, see Derived Colors for how to get the foreground or background and how to blend them with other colors. The By default the new Default theme lightens the background of the color scheme for popups and auto complete to try and provide a little contrast. It is likely that we need to special-case light color schemes and slightly darken the background. However, color schemes can override the default It is possible I missed part of the intent of the bug report, so please let me know if my response doesn't directly address your primary concern. |
|
BTW, here is the current default html {
background-color: color(var(--background) blend(#fff 95%));
} |
|
@wbond, this is great to know! But what about white themes? Current background convention provides no contrast for very bright themes. |
|
I should say scheme. |
|
Yes, I think we need to add a rule for |
|
@wbond: are the |
|
They've been present since build 3119 |
|
I think that the Recent addition of borders have also really helped with a way to ensure contrast for situations you are uncertain of. As an aside. I still think it would be nice if the HTML foreground and background for popups/phantoms where assigned a CSS variable by Sublime (I understand we already have Plugins have no way of knowing what the actual set background and foreground is, they only know what the color scheme foreground and background is. The only reason this is important is if you are trying to create a popup that matches all the other popups generated by Sublime. If a color scheme sets Obviously color schemes would have to pick up this convention, but I think it would solve most issues people have with trying to create consistent looking popups across plugins. Anyways, what ever you guys decide, I definitely support the addition of |
|
Personally, I probably prefer that color schemes stop trying to set the background and foreground and just let Sublime do it. |
|
If the color scheme default CSS, then the default CSS is ignored, so I don't think we'll be able to layer them as you suggested. I think a possible case moving forward is to set |
Can we find this somewhere in the docs? Had a quick look into minihtml but didn't find it. |
That'd be perfect. The end result is the same. And if your favorite color scheme isn't playing nice, you can just create an issue there. |
It looks like I need to get that added. |
The contrast of popups is all this issue is about. I started learning who and how colors of popups are defined and was faced with some edge cases especially with MarkdownEditing package, which provides absolutely no contrast for popups. White popup on white background is just not optimal. So we came around with several ideas how to solve this issue. Borders were one of them. The big question is how to ensure a popup is clearly visible and who is responsible for it and how. In the end I find the color adapting strategy a good solution even for color schemes not supporting CSS. I've played a bit with the default settings, you've suggested @wbond and personally find 90% blended colors a bit better. They still don't differ too much from the background, but are a bit better to see especially with some text around. html.light {
background-color: color(var(--background) blend(#000 90%));
}
html.dark {
background-color: color(var(--background) blend(#fff 90%));
}@facelessuser: Maybe using the |
|
Oh, @wbond, also |
|
@facelessuser Is there a use case for |
|
@wbond Maybe if a color scheme is meant to provide complementary colored popups? A dark theme might want to provide a very light popup with dark text? |
|
I think in that case they can just override |
|
I forgot only background is modified and handled differently, |
|
That's basically right not to bloat things up, too much. As far as I understand, But that's just a quick thought on that. Another one is consistency. If we have |
|
@deathaxe, as far as mdpopups using |
|
The L channel of the HSL representation being < 0.5 is considered "dark", otherwise "light". I can add this to the docs when I document the light and dark classes. There is documentation for Themes that define the exact implementation of |
|
Nice. Thanks @wbond. I will probably migrate to that then. I think I was using a calculation for perceived luminance, so I can switch using HSL. Well hopefully there won't be any rounding differences between Sublime's and doing it in Python, and if there are, it probably wouldn't be too bad if you mistake one way or the other as you are in the middle 🙂. |
|
Tweaks have been made to the default CSS that is generated to cause the background color of popups with light color schemes a little darker, and I've documented the |
|
I removed the borders of GitGutter Popup to let the theme decide whether to add one around or not. I added such a border rule to my local /User/Adaptive.sublime-theme file which already overrides some defaults. So we may close the issue. |
Summary
In some situations it might be helpful to draw a border around a popup to increase contrast, which makes a popup stand out from the background a little bit better.
Expected behavior
Would like to see the ability to create a kind of fixed border, which is not scrolled and thus is always visible on all 4 sides even if content is too large.
This might be accomplished by defining a custom scrolling area just like a kind of
<iframe> ... </iframe>? This would even help to fix the position of some of the elements (toolbar) and avoid them being scrolled out of the viewport.Actual behavior
Unfortunately all the borders are scrolled with the content, if it exceeds the maximum size of a popup.
Environment
The text was updated successfully, but these errors were encountered: