[Mvc] Add Razor compiler support for CSS isolation for Views and Razor pages #29899

javiercn · 2021-02-04T16:52:42Z

Applies the given cssscope to the HtmlElements on a given file. TagHelpers don't get the scope applied since they are not considered "part of the file" for the purpose of scoped CSS (equivalent to what we do for components).

javiercn · 2021-02-04T16:56:00Z

...osoft.AspNetCore.Mvc.Razor.Extensions/test/IntegrationTests/CodeGenerationIntegrationTest.cs

@@ -525,6 +525,49 @@ public void RazorPageWithNoLeadingPageDirective_Runtime()
            var diagnotics = compiled.CodeDocument.GetCSharpDocument().Diagnostics;
            Assert.Equal("RZ3906", Assert.Single(diagnotics).Id);
        }
+
+        [Fact]
+        public void View_WithCssScope()


The test is within the razor extensions project because otherwise is painful to write.

pranavkm · 2021-02-08T18:13:16Z

src/Razor/Microsoft.AspNetCore.Razor.Language/src/Extensions/ViewCssScopePass.cs

+
+namespace Microsoft.AspNetCore.Razor.Language.Extensions
+{
+    internal class ViewCssScopePass : IntermediateNodePassBase, IRazorOptimizationPass


In terms of code-organization, MVC specific types have typically existed in the .Extensions assembly. In addition, we probably want to put this behind a language version check (we don't want this running on older versions of MVC).

(cc @NTaylorMullen)

That's a fair point, but I don't think this is MVC specific, this is specifc to cshtml. Also, if that's the case, why is the components version of this (as well as A LOT of other stuff in this assembly instead of on its own Components assembly?)

pranavkm · 2021-02-08T18:14:17Z

src/Razor/Microsoft.AspNetCore.Razor.Language/src/Extensions/ViewCssScopePass.cs

+                if (child is IntermediateToken token && token.IsHtml)
+                {
+                    var content = token.Content;
+                    if (content.StartsWith("<") && !content.StartsWith("</"))


These should use StringComparison.Ordinal.

I don't think it matters, does it?

Might be beneficial to avoid any present or future linter warnings. But agreed it shouldn't affect behavior.

I've been trying to think of any other cases where we might find a < which isn't immediately preceding a tag name, and haven't thought of any. For example cases like < p > or <a href=< >...</a> but I think these are too invalid to get through the parser anyway. So as far as I can tell, this seems fine.

Yes, I had the same concern and experimented a bit with different syntaxes. Worst case scenario (unlikely) we get a "smalish" bug here, that has an easy workaround and is easy to fix.

SteveSandersonMS · 2021-02-15T15:32:56Z

src/Razor/Microsoft.AspNetCore.Razor.Language/src/Extensions/ViewCssScopePass.cs

+
+        private void ProcessElement(HtmlContentIntermediateNode node, string cssScope)
+        {
+            cssScope = " " + cssScope;


Nitpicky, but instead of allocating a new string for every node, we could construct the space-prefixed version just once and pass it into this method.

SteveSandersonMS

Looks great to me. Presumably there's also some MSBuild work needed to pass in the scope identifiers for .cshtml files, right?

SteveSandersonMS · 2021-02-15T15:42:29Z

TagHelpers don't get the scope applied since they are not considered "part of the file" for the purpose of scoped CSS (equivalent to what we do for components).

Just to check: this is only in the case where the whole tag is itself a tag helper, and not just one of its attributes, right?

That is, I recognize that <my-tag-helper> isn't going to emit the scope attribute (because we don't control what it emits), but if you have <a asp-for="...">, then this will emit the scope attribute, right?

javiercn · 2021-02-15T17:26:33Z

That is, I recognize that <my-tag-helper> isn't going to emit the scope attribute (because we don't control what it emits), but if you have <a asp-for="...">, then this will emit the scope attribute, right?

Nope.

That's also a tag helper (an attribute tag helper) and we don't have any control over the HTML emitted when you apply a tag helper.

SteveSandersonMS · 2021-02-15T17:29:10Z

That is a bit of a usability concern. People won’t think that adding an attribute to an element may break its scoped styles.

What stops us from rewriting it earlier in the process before the tag helper attribute gets involved?

javiercn · 2021-02-15T17:38:28Z

@SteveSandersonMS A few things:

When you apply an attribute tag helper for a tag, it gets colorized like any other tag helper.
Tag helpers have control over the entire output of the tag, independent of whether they are applied as elements or attributes. If we enable the scope for "attribute tag helpers", there is no guarantee that it will get applied in the final output and the experience can be confusing.
Applying the scope might break the isolation that an existing tag helper might have relied on.

I think the current experience is simpler in that the scope only applies to HTML elements in the file, and the moment an element has a tag helper on it, it stops being a regular element.

FYI, if in the future we want to enable something like this, I would be ok with an explicit @scope directive that allows the scope to be "materialized" at that point and passed down explicitly to some components.

SteveSandersonMS · 2021-02-15T18:22:22Z

It's extremely rare that I create .cshtml files and use any tag helpers, so I'm not a good person to make any pronouncements about what users would or wouldn't expect. All I can say is this one case does seem surprising to me.

My mental model is that attribute tag helpers normally play a role of adding or changing attributes, rather than replacing the entire element. As such I would not expect that changing <a href="/MyPage"> to <a asp-page="/MyPage"> would disable the scoped CSS for that element - it seems completely orthogonal. I would expect that the asp-page attribute is just a magic alternative to href (and isn't changing the containing tag). I know that strictly speaking an attribute tag helper can do whatever it wants.

Like I said, this area of the product isn't one I really use a lot, so my opinion is of limited relevance, and I'd defer to your judgement! The choice we make here is something we need to be happy with forever, as we couldn't later make scoped styles start appearing here by default without it being a breaking change.

javiercn · 2021-02-16T18:43:40Z

It's extremely rare that I create .cshtml files and use any tag helpers, so I'm not a good person to make any pronouncements about what users would or wouldn't expect. All I can say is this one case does seem surprising to me.

My mental model is that attribute tag helpers normally play a role of adding or changing attributes, rather than replacing the entire element. As such I would not expect that changing <a href="/MyPage"> to <a asp-page="/MyPage"> would disable the scoped CSS for that element - it seems completely orthogonal. I would expect that the asp-page attribute is just a magic alternative to href (and isn't changing the containing tag). I know that strictly speaking an attribute tag helper can do whatever it wants.

Like I said, this area of the product isn't one I really use a lot, so my opinion is of limited relevance, and I'd defer to your judgement! The choice we make here is something we need to be happy with forever, as we couldn't later make scoped styles start appearing here by default without it being a breaking change.

I understand your concerns. In the end is a balance between simplicity and least surprise. On the one side, folks might get surprised by this (the same thing happens with our NavLink or Input* components) if we don't apply it to tag helpers.

On the opposite end, we don't have a way to enforce a tag helper actually applies the attribute and that makes the experience highly variable. We might make it work for our own tag helpers, but it's not guaranteed that it will work for other tag helpers and that creates a somewhat inconsistent experience.

I think for the time being, I prefer we keep it simple and see what feedback we get (I'm anticipating we'll get a feedback similar to the one we receive in components). At that point, it's relatively easy for us to do something like what is described in dotnet/razor#7606 which would work for both regular tag helpers and components.

It's a bit more nuanced for TH since several can be applied to an element and an element can itself be a tag helper, but it's not that common to apply more than one outside of our own TH for which we can easily produce the right behavior.

ghost added the area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates label Feb 4, 2021

javiercn requested a review from a team February 4, 2021 16:55

javiercn commented Feb 4, 2021

View reviewed changes

javiercn requested a review from captainsafia February 4, 2021 17:07

pranavkm reviewed Feb 8, 2021

View reviewed changes

SteveSandersonMS reviewed Feb 15, 2021

View reviewed changes

SteveSandersonMS approved these changes Feb 15, 2021

View reviewed changes

javiercn added 8 commits February 16, 2021 10:05

tmp

6645b87

tmp

850a3a0

Undo unwanted changes

26bbc50

Cleanup

f9159b7

Fix test

fbc96ab

Add test for views

59c3649

remove unnecessary files

c77ebca

Fix broken test

bcc7437

javiercn added 2 commits February 16, 2021 10:44

PR feedback + cleanup

4fc281f

Activate feature only for 6.0 and onwards

79e1f8e

javiercn force-pushed the javiercn/mvc-css-isolation branch from ec02b96 to 79e1f8e Compare February 16, 2021 18:48

javiercn merged commit bab9671 into main Feb 16, 2021

javiercn deleted the javiercn/mvc-css-isolation branch February 16, 2021 20:25

guardrex mentioned this pull request Aug 25, 2021

RP/MVC CSS isolation coverage for 6.0 dotnet/AspNetCore.Docs#23120

Closed

guardrex mentioned this pull request Sep 27, 2021

Blazor 6.0 content tracking issue dotnet/AspNetCore.Docs#22045

Closed

41 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Mvc] Add Razor compiler support for CSS isolation for Views and Razor pages #29899

[Mvc] Add Razor compiler support for CSS isolation for Views and Razor pages #29899

Uh oh!

javiercn commented Feb 4, 2021 •

edited

Loading

Uh oh!

javiercn Feb 4, 2021

Uh oh!

pranavkm Feb 8, 2021

Uh oh!

javiercn Feb 8, 2021

Uh oh!

pranavkm Feb 8, 2021

Uh oh!

javiercn Feb 8, 2021

Uh oh!

SteveSandersonMS Feb 15, 2021

Uh oh!

javiercn Feb 16, 2021

Uh oh!

SteveSandersonMS Feb 15, 2021 •

edited

Loading

Uh oh!

SteveSandersonMS left a comment

Uh oh!

SteveSandersonMS commented Feb 15, 2021

Uh oh!

javiercn commented Feb 15, 2021

Uh oh!

SteveSandersonMS commented Feb 15, 2021

Uh oh!

javiercn commented Feb 15, 2021

Uh oh!

SteveSandersonMS commented Feb 15, 2021 •

edited

Loading

Uh oh!

javiercn commented Feb 16, 2021

Uh oh!

Uh oh!

[Mvc] Add Razor compiler support for CSS isolation for Views and Razor pages #29899

[Mvc] Add Razor compiler support for CSS isolation for Views and Razor pages #29899

Uh oh!

Conversation

javiercn commented Feb 4, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

javiercn Feb 4, 2021

Choose a reason for hiding this comment

Uh oh!

pranavkm Feb 8, 2021

Choose a reason for hiding this comment

Uh oh!

javiercn Feb 8, 2021

Choose a reason for hiding this comment

Uh oh!

pranavkm Feb 8, 2021

Choose a reason for hiding this comment

Uh oh!

javiercn Feb 8, 2021

Choose a reason for hiding this comment

Uh oh!

SteveSandersonMS Feb 15, 2021

Choose a reason for hiding this comment

Uh oh!

javiercn Feb 16, 2021

Choose a reason for hiding this comment

Uh oh!

SteveSandersonMS Feb 15, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveSandersonMS left a comment

Choose a reason for hiding this comment

Uh oh!

SteveSandersonMS commented Feb 15, 2021

Uh oh!

javiercn commented Feb 15, 2021

Uh oh!

SteveSandersonMS commented Feb 15, 2021

Uh oh!

javiercn commented Feb 15, 2021

Uh oh!

SteveSandersonMS commented Feb 15, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

javiercn commented Feb 16, 2021

Uh oh!

Uh oh!

javiercn commented Feb 4, 2021 •

edited

Loading

SteveSandersonMS Feb 15, 2021 •

edited

Loading

SteveSandersonMS commented Feb 15, 2021 •

edited

Loading