-
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safari: look of the extension in some sites #135
Comments
the same as for Different priority for extension styles. |
Ok, I have re-read the basic documentation and Apple Team defines priority this way (source):
So we are getting this terrible styles for Safari when someone defines there styles directly to tags. I think - may be we wil create an additional safary-style file with importants for tags inside our ID attributes? |
I think we can do that, but we should make sure that whatever we apply !important to is fully scoped to the alpheios namespace. |
I hate Maybe we could do away without importants by adding some id ( But if that will not work (I'm not very familiar with all variety of sites out there), then probably Or maybe I'm overcautious? Should we have the last word in how the page would look like? Who will need to be able to override our styles? Theme creators? But still, maybe it's better not to escalate to |
Yes I think maybe the first step is reviewing to make sure all of the elements we need to style in our UI are fully described by classes which can be traced back to the id of the parent alpheios ui component element? |
Unfortunately, It seems to me that this problem couldn't be solved using any ID attributes or classes. |
Wow! From reading Apple's docs where it was saying that
However, this seems not: it looks like Safari totally ignores CSS specificity and apply rules in its own Safari-specific order, combining both CSS specificity rules and "Safari-specific" ones. I think that's crazy! It's like Apple ignoring W3C specs and trying to come up with something of its own. That's clearly a "think different" way of things 🙂, and not in a good way, on my opinion ! So then, I guess, they forces us into an |
@irina060981, thanks for detailed clarification of how the rules are applied in Safari! |
@kirlat , yes, it was really surprising for me too :) I think all safari app extention technology is an original approach to creating webextensions. |
I think that even with Safari behaving the way it does we should not introduce any We definitely should use some script for that. I was thinking about PostCSS as it is a most widely accepted (as of now) way to post-process CSS files. There is even a PostCSS loader for Webpack: https://github.com/postcss/postcss-loader. Maybe we can use something like |
My suggestion is the same - produce two style files - for webextension and for safari, also I think we should
|
Agree with both points. We need to make sure all of our styles only apply to Alpheios ui elements and only use !important for Safari. I really like the idea of using postcss-important to add the !important flag when building for Safari. |
I have faced with problems while applying I was not able to find any working plugins for Postcss to add important flag. I will try to update it to use with our webpack/postcss version - I need to solve the following problems:
So the task becomes a little bigger than I expected and will take more time unfortunately. |
Ok. Maybe it's worth taking a step back to think about other approaches to this problem as alternatives to investing time in the post-css-important plugin? I'm coming up blank right now unfortunately. |
I will try to get with some alternative solutions in the next couple of days, maybe there is something somewhere. It would be a maintenance nightmare to keep two set of similar files for different browsers. |
There are really several problems here:
So I think may be custom PostCSS plugin is not a bad idea |
I think, unspecific to the Safari problem, we do still need additional specificity in some of our styles, because occasionally underlying page styles are still bleeding through. So, some additional cleanup and reorganization of styles generally might help with that . |
That's maybe not related to the topic directly, but since we're discussing CSS organization and processing I think it might be worth discussing here. The question I want to bring is whether a UIKit is an asset or a liability in our current design. I have a feeling we do not follow UIKit styles extensively throughout our apps because our custom styles (and our style requirements) are so different from what UIKit is now. So would there be any value of continuing using a UIKit? This is an extra dependency and extra CSS weight we have to carry. AFAIR we're using UIKit to style just a couple of elements such as buttons and for those we can copy out UIKit styles and make our own out of them. I also see no value in UIKit JS because we're using Vue.js instead (that's a change from before where UIKit JS interactions could be valubale). Dropping UIKit may also simplify some styling where we do override UIKit styles; we could remove unnecessary selectors if we won't have a UIKit on board. It's always better to make things simpler 🙂 I don't have any strong opinion on this, but I think it might be worth discussing here. So I'm wondering what do you think. @irina060981 - moved it to alpheios-project/documentation#4 (comment) |
I was wondering that too, as I looked at the styles today. I think it might be more of a liability right now. Simplification prior to implementing a design refresh in coming months is also probably a good idea. @irina060981 - moved it to alpheios-project/documentation#4 (comment) |
ready for testing in build 2.1.0.9 |
Hello Irina (@irina060981 ), |
@irina060981 I was thinking this was the removal of the flex styles, but I see that you are right that the class that you removed wasn't used so it must be something else |
Another fairly big issue that I didn't think of before (I'm so sorry!) with the use of alpheios-popup and alpheios-panel as IDs in the class hierarchy: the UI controller design intentionally allows us the enclosing application to define the ids of these elements. So for the embedded library, we use alpheios-popup-embedded and alpheios-panel-embedded. Originally this was to avoid conflicts between the installed extension and the embedded library. We handle this differently now, but I think maybe we still want to allow this level of flexibility. Also, an outstanding feature request is to allow for multiple popups on the page, and if we use a fixed ID we can't do that. So I think our choices are to make the top level of the hierarchy a class rather than an id, or maybe to do as Kirill was talking about, and use a custom element as the top level element of the popup or panel, rather than a div. According to the MDN though, I'm not sure how well Safari supports this standard (https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements). |
Hello, @monzug and @balmas !
The same here #136 (comment) |
About wrapping inside ID - yes, Bridget, I have forgotten about this flexibility too. |
There are custom elements that are part of webcomponents specification. Unfortunately, they are no go for Safari and MS Edge. Even in FF it is still in development: https://caniuse.com/#feat=custom-elements. But that's much more than we need because webcomponents also present a JS API that we're not going to use for this task. However, if I understand correctly, we can just use our own HTML tags, without any webcomponents functionality. It may be not valid HTML5 (not sure would it or wouldn't it be, but our injected code would probably never be validated according to HTML5 specs), but should work in any browse, as far as I know: The terminology is confusing as both terms are so close. We cannot use custom elements now, but can use custom tags. It we'll need this feature, we can do an easy test in Safari: add our own element to the page, style it with CSS, and check the result. |
If we can get Safari working well enough with a majority of sites without using a custom tag, I would prefer that for now. We will likely need to revisit this with the upcoming design refresh. |
merged and closed |
this can be tested in build 2.1.0.10 |
tested in Safari build 2.1.0.11 - looks good, checked several sites so far so good |
actually all buttons have the text in black and not white
The text was updated successfully, but these errors were encountered: