Inject styles in the head #252
Comments
|
Adding the style after the closing body tag ensures that the style is always last and thus overrides selectors with the same specificity. It's especially needed with the increase use of I think your best bet to get around this is to overwrite the // ==UserScript==
// @name Allow Stylus
// @namespace http://tampermonkey.net/
// @version 0.1.0
// @description Disable style tag removal
// @author Rob Garrison
// @match http://*/*
// @grant none
// ==/UserScript==
(() => {
"use strict";
const scrpt = document.querySelector("script[src*='thehiveworks.com/jumpbar.js']");
if (scrpt && window.breakbadtoys2) {
window.breakbadtoys2 = () => false;
}
})(); |
|
Hm. I would be content to artificially increase my selectors’ specificity (by prefixing with |
|
The problem actually is that the original Stylish extension behaved the same way, so moving the styles back to the head would likely break many existing userstyles... either way, I'll let @tophf chime in here. |
|
I do believe the original Stylish for Firefox, which I believe was the original Stylish, did not. In fact, I do not remember it ever injecting styles into the actual DOM. It used the loadAndRegisterSheet method of the browser’s Stylesheet Service to add userstyles to the same collection that had the user agent stylesheet (browser defaults) and the userChrome.css and userContent.css overrides. It did register styles as author sheets, though, so yes, existing styles would probably rely on having ties broken in their favor. |
|
@yurikhan original Stylish for Firefox used XPCOM, which has been taken out. Not sure there's an alternative to doing it this way with webExtensions (which is similar to how Stylish for Chrome would have to work, which is what Stylus is forked from). You might be ok with increasing specificity, but it's not just existing styles that would break, it's also that the behavior would be surprising to userstyle authors in general. Not sure there's a way to wrap an existing style in a way that would work around the higher specificity needs (and if there is, that site's function would be pointless). I think most userstyle authors would reasonably consider behavior like this from a userstyle manager to be a bug, not a feature. Adding a style at the end of the |
|
We need control over the css to allow enabling & disabling when the user changes the state in the popup; |
|
Lots of sites and frameworks put stuff directly under the root element so it's not a problem for the browsers. The only thing worth discussing here is whether it's worth adding a style protector that would restore the styles immediately. |
|
Also, DOM specification doesn't restrict |
There is this webcomic network called Hiveworks. At least some of the comics published there include this script: http://www.thehiveworks.com/jumpbar.js
Its last line is:
window.addEventListener("load",breakbadtoys2,true);where the referenced function contains, among other things:
Incidentally, they are right —
styleis only valid underhead.Stylus injects user styles after the
body, which gets them removed by the above script.What are the consequences of injecting styles at the end of
head? One is that user style rules with specificity equal to those in the page body will no longer win by position tiebreaker; are there others?The text was updated successfully, but these errors were encountered: