Open eevee opened 11 years ago
Careful here. z-indexes are set rather arbitrarily across apps and this will likely be something that users are going to need to override frequently. Not using fixed positioning avoids this issue altogether, and would be more similar to the Ruby implementation.
That's true, which is why our z-index just needs to be the most biggest.
As I mentioned on IRC: the reason I went with fixed
was that I've more than once refreshed a page to get partial broken Sass, been scrolled down a ways, and not immediately realized what the problem was.
It might be possible to position the error in less invasive ways (position: sticky
?), but of course the fancier we get, the more likely we'll conflict with existing CSS.
Yeah, I do see the convenience in having it visible at every scroll position, I just don't see any elegant way of handling stacking. From what I recall, generally there is a split second after refreshing when you're at the top of the page before the browser positions you at your previous scroll position. But then again it doesn't really matter if we set it to some enormous z-index, since there's no reason for the page to look nice in this case and who care if it's interfering with other UI. Overall I do think there's value in keeping these body::before styles minimal and not worry about things like changing opacity on hover.
Otherwise it can get lost under other parts of the page.
Might also be polite to have it fade slightly on mouseover or something, so it doesn't permanently cover important parts of the page? But then, why would you not want to immediately fix your Sass?