stylus
stylus copied to clipboard
openstyles
[Feature Request] PWA Titlebar Header Color
As far as I can tell this extension is limited to css injection only. Unfortunately this means we can't change the color of the title bar for pages installed as apps.
What I'm proposing:
A special tag or selector that would be parsed by stylus & used to overwrite the <head> ... <meta name="theme-color" content="#XXXXX"> ... </head> tag.
I've been able to set this in another extension (custom style script) as js:
var metaThemeColor = document.querySelector("meta[name=theme-color]");
metaThemeColor.setAttribute("content", "#28536B");
but I think allowing unchecked js is definitely a bad idea.
Some sort of controlled access though would be very helpful!
We definitely won't add JS injections.
A special meta tag for UserCSS seems reasonable e.g. @set-page-attribute "meta[name=theme-color]" "content" "#28536B". @eight04, any ideas on the syntax?
@set-page-attribute "meta[name=theme-color]" "content" "#28536B"
Isn't this a big change considering the security?
How about collecting a list of use-cases that require modifying DOM, then support them via usercss meta individually? e.g. #674
What security implications are here? Setting src/href to a URL that can be used for tracking the user? If that's the only one we can forbid setting a URL and/or src/href.
We can start by allowing just this one case i.e. setting a meta to a non-URL value. Then people would report new use cases. I thought there will be more, which is why I don't want to add a specialized tag to change this particular meta.
@set-page-attribute "meta[name=theme-color]" "content" "#28536B" What security implications are here?
According to the syntax, I thought the author will be able to set/create any property on any element.
Well, yes, that was the plan. I just realized that we'll need to exclude all on attributes like onclick in addition to src on script elements and frames.
Yeah, so there is some potential for abuse which we may overlook, so what about this:
We can start by allowing just this one case i.e. setting a meta to a non-URL value. Then people would report new use cases. I thought there will be more, which is why I don't want to add a specialized tag to change this particular meta.
One pro of using individual API is that we can provide clear and precise messages to users when installing a style. For example: This style wants to style titlebar, This style wants to know if it runs in an iframe. It is more user-friendly.
Otherwise, it will be This style wants to set a property of an element: "meta[name=theme-color].content=#28536B"
I don't think setting the color property needs a confirmation.
I tried to think of other use cases and I remembered just one: overriding !important in a style attribute, but that requires a global MutationObserver, which slightly slows down all DOM operations, so I don't want that. To change the meta in document.head we can reuse our existing observer.
I don't think setting the color property needs a confirmation.
I would argue that modifying DOM is a big change that needs a confirmation.
CSS, userstyles, and usercss has never been able to modify DOM. Authors have to go for userscript if they need to. That's also why CSS is considered harmless (well, until the css key loger).
Even we only modify <meta> with simple string, or add an empty classname to DOM. These behaviors are not expected from a userstyle.
One use case from me: the viewport meta tag https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_meta_tag
You need this to build styles for mobile.
BTW, if we change the injection method in the future, we will have to implement these metadata API separately.
Injector refs: https://github.com/openstyles/stylus/issues/248 https://github.com/openstyles/stylus/issues/739