-
-
Notifications
You must be signed in to change notification settings - Fork 929
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
Do we care about features behind browser flags? #7510
Comments
It seems ideal to me, but indeed, I guess it's difficult because we have to care about dependency change details. At the same time, that work doesn't seem to be worth it. |
@ybiquitous are you advocating for a case by case approach? |
No. My concern is how we can achieve this goal. It would be great if there was a nice solution. |
Let's review the other examples that I have added.
The additions can be argued either way. If it's not resolved here I will eventually have to open an issue.
If we had a policy, the ready to implement status could be added without much discussion. |
Make sense. Then, do you assume such a new policy to document? For example, adding an item to "A rule must be:" etc. stylelint/docs/developer-guide/rules.md Lines 11 to 14 in f44de2e
|
I don't know where it should be added in the documentation. It would mainly be used to help with the ready to implement labelling. So I would expect to find it here: https://github.com/stylelint/stylelint/blob/main/docs/maintainer-guide/issues.md My proposal is uncomplicated: if a browser supported it, it's OK to add. That's a completist dream. |
I think the rule criteria are more suitable than the maintainer guide because this proposal is specific to the rule rather than triaging issues. If we can resolve the downsides and make the policy clear, I agree with documenting the browser support policy 👍🏼 |
Choosing to wait for the experimental phase to finish would require that all affected rules that are missing an ignore* option must have one added/planned. The if a browser supported it, it's OK to add approach is a bit extreme but wouldn't require such research/survey. If it's already the case either policy would be fine with me. |
@mattxwang @romainmenke do you have an opinion? |
Technically, some rules may use browserslist and correct allowed values |
That's down the line and would require a default browserslist for the users that don't have/provide one. What I am trying to get at is a policy to triage issues that revolve around addition of features that are, at the time of the request, only available behind a flag. If I had a strong opinion I wouldn't have opened an issue. |
I think it really depends. For rules that enforce "no unknown X" I think it is fine to add experimental features. I don't want to add excessive friction for users who want to try out bleeding edge features. I personally try to rather quickly add support for draft concepts in things like For rules that promote best practices and modern CSS I think the bar is much much higher. |
Indeed.
👍 |
concrete example
<selectmenu>
is not part of html-tags which is used byselector-type-no-unknown
rule.It already has been renamed
<selectlist>
and can have a<popup>
child.ref
https://chromestatus.com/feature/5737365999976448
https://hidde.blog/custom-select-with-selectlist/
https://bugs.chromium.org/p/chromium/issues/detail?id=1121840
https://github.com/luwes/selectlist-polyfill
question
Should we have a policy that states that we have to wait for the experimentation to end before we add support for such features?
If so we would have to give some pointers on what we mean by the experimentation phase.
other examples
function-no-unknown
false positive forscroll()
#6537text-decoration-width
selector-pseudo-class-no-unknown
:open
and:closed
:top-layer
:popup-open
Fixfunction-no-unknown
false positives foranchor
andanchor-size
#7566The text was updated successfully, but these errors were encountered: