-
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
Popouts: Sometimes stylesheets don't get copied over correctly to new window #893
Comments
Related issue: iTwin/iTwinUI#1584 |
I was looking into this issue, and it's wild that this is considered to be "working as intended" by the spec and by browsers. I'm not sure that there is even a way around it. @Juliakas What components have you faced this issue in? Is it only in your own custom CSS? We can at least use the longhands in library code. |
I guess the explanation could be that css variables could be anything (either color, number of pixels, border style keyword) and when converting to longhands it is not clear how to parse them, shorthands are very lenient on what order you write your properties like So far only noticed in my own component, I needed different border stylings to achieve effect I wanted. The only other idea I have is instead of parsing |
Yeah I was thinking this too; we would need to ensure there is no extra network request happening when cloning a
There is |
Discussed a two-pronged approach with @GerardasB today after looking at
|
For I was reading and playing around with What actually happens with shadow dom styles when its dom gets transferred? Did you figure out why they disappear? |
Just to clarify, I'm talking about For shadow DOM we also use |
Describe the bug
Sometimes when styling components and combining shorthand properties with css variables and adding other related longhand properties to override something, document.stylesheet produces unexpected results that are then copied over to popout window and wrong styles are getting applied.
One example being:
In main window it looks like so:
And when popping out to new window, this gets produced upon inspecting:
One interesting thing is that it works correctly when I use static value instead of variable or when I remove
border-bottom
.This seems to be intended spec behavior that serializes
cssText
property like that. I found this chromium rejected issue:https://issues.chromium.org/issues/40804066 and spec was linked to indicate intended behavior: https://drafts.csswg.org/css-variables/#pending-substitution-value
To Reproduce
Expected Behavior
It is expected that when popping out widgets to a new window, all styles should be preserved as is and should not lose information. In this case it is expected that all borders retain same css properties as it had in main window.
Screenshots
No response
Desktop (please complete the applicable information)
OS: Windows 11
Browser: Microsoft Edge
Browser version: Version 126.0.2592.68 (Official build) (64-bit)
Appui version: 4.15.0 (reproduced on source)
Additional context
I debugged source at
CopyStyles.ts
and noticed deformation was happening there. In my case I worked around this issue by being very verbose with longhand css properties and it seemed to work, but it can still cause issues as we just haven't discovered problems in other areas, maybe even in external code that we can't control.The text was updated successfully, but these errors were encountered: