-
Notifications
You must be signed in to change notification settings - Fork 177
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
[css] Show multiple elements suggestions #249
Comments
@aeschli Could I look into this issue? I'm a bit familiar with the CSS Language service after working on a couple PRs. Also, if this is implemented, would the selector specificity necessarily be the same for multiple element suggestions? One might have a different specificity than the other, how would we handle that? |
@GauravB159 Of course, that would be reat. I think each variant would need its own specificity. Code is in https://github.com/microsoft/vscode-css-languageservice/blob/main/src/services/cssHover.ts The |
Awesome, I'll look into it, thank you! @aeschli For the specificity, would displaying them in the same order as the list of elements be enough context to understand which specificity maps to which element? |
@GauravB159 For you to experiment. Maybe it can look like that:
If they are the same, maybe one line (at the bottom) is enough. |
@aeschli Gotcha, I'll try it out, thank you. |
@aeschli I'm testing out the changes for this and I noticed MarkedString is supposed to be deprecated. Does that need to be replaced with something else? |
@aeschli Here's what I've got so far: The multiple suggestions seem to be working fine. The specificity probably has some bugs. Can you confirm what the values should be? Because I've cross checked them with the prod build of VSCode and they're the same but shouldn't ID and Class have different specificity values? My changes for multiple suggestions: Prod version with single suggestion: |
Hi @GauravB159, thanks for dealing with this issue. This looks cool already. ID should have 1.0.0 specificity according to MDN. :hover should add 0.1.0 to specificity. It looks like parent selector specificity doesn't count here. Here's a calculator to self check. Looks like it calculates all correct. |
Hi @m0ksem, no worries! I'm new to open source, but really having fun contributing. So for the specificity, I figured the values were wrong. But, there seems to be a bug in prod itself that causes the calculation to be wrong, if you check the screenshot. I'm not sure if I should address that bug in this issue, or create a separate issue for that. Also, if you check my PR, I have added a case that has not been handled in my fix. Do you think that case should be handled, or the way it is currently coded is fine? Edit: The issue seems to be in SCSS files only when nesting is used, CSS files work fine for specificity since there is no nesting. Can you try it out and let me know if you're facing the same issue?
|
Yes, let's deal with the specificity issue in a different issue. Thanks @m0ksem for bringing this to attention. |
For example show it as:
<input :hover ::placeholder> or <input :focus ::placeholder>
or
Codepen: https://codepen.io/m0ksem/pen/qBjxxzo
The text was updated successfully, but these errors were encountered: