Skip to content
This repository was archived by the owner on Jan 6, 2025. It is now read-only.

Inline Styles clutter dev tools for HTML Inspection #632

Open
wasserholz opened this issue Feb 27, 2018 · 3 comments
Open

Inline Styles clutter dev tools for HTML Inspection #632

wasserholz opened this issue Feb 27, 2018 · 3 comments
Labels
P4 Low-priority issue that needs to be resolved performance rfc
Milestone

Comments

@wasserholz
Copy link

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 ?

@ThomasBurleson
Copy link
Contributor

@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...

@ThomasBurleson ThomasBurleson added this to the Backlog milestone Feb 27, 2018
@ThomasBurleson
Copy link
Contributor

@wasserholz - This issue will not be closed because it is worthy of investigation AFTER the 1.0 release.

@ThomasBurleson ThomasBurleson added performance P4 Low-priority issue that needs to be resolved labels Feb 27, 2018
@naveedahmed1
Copy link

Any progress on this?

@CaerusKaru CaerusKaru added the rfc label May 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P4 Low-priority issue that needs to be resolved performance rfc
Projects
None yet
Development

No branches or pull requests

4 participants