microsoft / vscode-edge-devtools

A VSCode extension that allows you to use browser devtools from within the editor. The devtools will connect to an instance of Microsoft Edge giving you the ability to alter CSS styling, perform diagnostics, and debugging. Get it now at http://aka.ms/devtools-for-code
https://docs.microsoft.com/microsoft-edge/visual-studio-code/microsoft-edge-devtools-extension
MIT License
753 stars 256 forks source link

'grid-template-columns' is not supported by Internet Explorer. Add '-ms-grid-columns' to support Internet Explorer 10+. #663

Open Hydrair opened 2 years ago

Hydrair commented 2 years ago

Environment (please complete the following information):

Describe the bug: When using a grid layout with grid-template-columns in a CSS file, the extension suggests to use -ms-grid-columns. When added, the error does not disappear.

Repro steps: Write CSS

  display: -ms-grid;
  display: grid;
  -ms-grid-columns: 1fr 1fr 1fr; 
  grid-template-columns: 1fr 1fr 1fr;
}

Expected behavior: Do not show an error anymore

Additional context:

codepo8 commented 2 years ago

Good catch, this seems to be a webhint issue.

mavigozler commented 2 years ago

Not sure of the status of work to fix. Another has indicated that the extension is almost unusable as corrected "errors" regarding CSS generate another error actually regarding the correction (errors that contradict each other in how code is used).

I would suggest that the extension add a setting/option in VS Code also to suppress all errors and warning related to Internet Explorer-compatible CSS styling, since the use of Internet Explorer except perhaps for very strictly controlled intranets is now a security issue.

codepo8 commented 2 years ago

Hello there, we have a new issues preset being rolled out soon that should be in the next version of the extension that will only report issues in the two latest versions of browsers and help with more detail filtering what you want to see.

For now if the experience is too annoying to you, you can disable the automatic check in the setttings:

image

codepo8 commented 2 years ago

@antross this might be interesting for the bug sprint, too.

antross commented 2 years ago

@mavigozler FYI if you also want to just turn off feedback for Internet Explorer, you can update your target browsers either in your package.json or .hintrc file.

E.g. this package.json will do the trick (you may have to restart VS Code after updating it for the change to take effect, though)

{
  "browserslist": "defaults, not IE 11"
}
antross commented 2 years ago

@codepo8 I dug into this a bit more on the webhint side and the issue for the persistent error when pairing grid-template-columns with -ms-grid-columns is that webhint is able to find -ms-grid-columns as an "alternate name" in the MDN browser-compat-data for grid-template-columns (to make the suggestion) but no reverse lookup currently exists (to resolve the error).

Unfortunately, this isn't likely to be a trivial fix given how the lookup routine in webhint currently works, but the fix will need to be somewhere in the walk routine for de-duping vendor-prefixed CSS properties: https://github.com/webhintio/hint/blob/0717f6afc9687d22a993436d958c7c5b86e8b4c7/packages/hint-compat-api/src/css.ts#L187

codepo8 commented 2 years ago

Well, fixing might be hard, but allowing a wildcard filter of things not to report could be an option?

antross commented 2 years ago

Yes, the .hintrc can be configured to ignore reports for specific CSS properties (and we have a set of defaults we can add to). But that would fully eliminate the report in all cases. Webhint doesn't currently have a mechanism to filter reports by message.

codepo8 commented 2 years ago

So to help this user and close the bug, giving a proper hintrc configuration is the best move right now.

antross commented 2 years ago

I assume they picked up the suggested .hintrc to exclude IE earlier in the thread. We'll be making this better for all users shortly by excluding IE by default in webhint: https://github.com/webhintio/hint/pull/5136

But I think we should still track a (albeit non-trivial) fix to webhint's handling of "alternate names" as this isn't the only case where such a setup is used in the MDN data. Whether that is this issue or a separate one I'll leave up to you.