Do we care about features behind browser flags?

[Mouvedia]

concrete example

<selectmenu> is not part of html-tags which is used by selector-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

• Fix function-no-unknown false positive for scroll() #6537
• text-decoration-width
• selector-pseudo-class-no-unknown
  • :open and :closed
  • :top-layer
  • :popup-open
• Fix function-no-unknown false positives for anchor and anchor-size #7566

[ybiquitous]

Should we have a policy that states that we have to wait for the experimentation to end before we add support for such features?

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.

[Mouvedia]

@ybiquitous are you advocating for a case by case approach?

[ybiquitous]

No. My concern is how we can achieve this goal. It would be great if there was a nice solution.

[Mouvedia]

Let's review the other examples that I have added.

• 4 pseudo-classes that are missing

The additions can be argued either way. If it's not resolved here I will eventually have to open an issue.

• text-decoration-width requires just one if
• scroll() has already been added

If we had a policy, the ready to implement status could be added without much discussion.
Something as simple as if it has ever been implemented in any spec-conformant browser it can be added would do.

[ybiquitous]

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

	A rule must be:
	- for standard CSS syntax only
	- generally useful; not tied to idiosyncratic patterns

[Mouvedia]

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.
But requiring the experimental phase to be finished to be added would also be acceptable.
e.g. if a pseudo-class gets renamed in the experimental phase, only the final name would be supported
The CON in that case would be that you have to define what constitutes an experimental phase.
It also has the drawback that implementors/testers won't be using stylelint during that phase without explicit exceptions.

[ybiquitous]

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 👍🏼

[Mouvedia]

If we can resolve the downsides

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.

[Mouvedia]

@mattxwang @romainmenke do you have an opinion?
Should it remain blurry/undocumented?
Should I add the documentation label?

[alexander-akait]

Technically, some rules may use browserslist and correct allowed values

[Mouvedia]

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.
i.e. whether we are modifying the whitelists based on browserslist or not is not relevant to the policy itself

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.

[romainmenke]

I think it really depends.

For rules that enforce "no unknown X" I think it is fine to add experimental features.
I even think that removing them again, if the experimental features is removed from browsers, is a non-breaking change. But this is a controversial opinion ;)

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 selector-specificity. I don't want tooling to be the reason users cannot adopt new features.

---

For rules that promote best practices and modern CSS I think the bar is much much higher.
At least all major vendors should have implemented the feature and there must be no major interop issues.

[Mouvedia]

I even think that removing them again, if the experimental features is removed from browsers, is a non-breaking change. But this is a controversial opinion ;)

Indeed.

I don't want to add excessive friction for users who want to try out bleeding edge features.

👍