You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 6, 2025. It is now read-only.
@wasserholz - Our SSR solution (with flex-layout) does use css classes, but the runtime version of the application uses inline-styling. The primary reason for inlining: inline-styles have the highest css specificity.
The only performance issue with inline-styling is using the Flex-Layout directives within a *ngFor with 100s or 1000s of rows. In this scenario, classnames are better and highly performant... but must be done manually.
In later versions of Flex-Layout, we can review using classnames for ALL styling. Please note that for specificity these classnames would be dynamically named...
Bug, feature request, or proposal:
Request: Use classes to provide styling
What is the expected behavior?
class attribute is added, which assigns the necessary styling
What is the current behavior?
Inline styles are used to provide the styling
What are the steps to reproduce?
Use the directives and checkout the Dev Tools. Inline styles add lots of extra text to the HTML inspection view.
What is the use-case or motivation for changing an existing behavior?
The motivation is, to provide more easily readable code. By using classes, the Dev Tools are kept free of long strings of inline styles.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Is there anything else we should know?
Is there a specific reason, inline styles were chosen over classes ?
The text was updated successfully, but these errors were encountered: