Add tracking bugs for unimplemented CSS column-*

[saschanaz]

A checklist to help your pull request get merged faster:

• Summarize your changes
• Data: link to resources that verify support information (such as browser's docs, changelogs, source control, bug trackers, and tests)
• Data: if you tested something, describe how you tested with details like browser and version
• Review the results of the linter and fix problems reported (If you need help, please ask in a comment!)
• Link to related issues or pull requests, if any: Remove items that has never been supported #6854, Remove totally unimplemented things #6768

[rachelandrew]

I don't understand why these are being removed, they are part of the spec (I'm the co-editor of multicol) and it's generally useful for people to understand that something isn't implemented when we do have a partial implementation of a property like this.

https://drafts.csswg.org/css-multicol/#cf

Is there some MDN resolution to remove things like this?

[saschanaz]

#6768 is the tracking bug, and there is a guideline for removal: https://github.com/mdn/browser-compat-data/blob/master/docs/data-guidelines.md#removal-of-irrelevant-features

a feature was never implemented in any browser and the specification has been abandoned.

Per the rule it seems this can remain as the spec is not abandoned. But I think ideally the lack of BCD data could automatically mean there is no implementation, especially when mdn-bcd-collector is actively adding data. cc @ddbeck

[rachelandrew]

I think we need to be careful with these partial implementations as it could be confusing to authors who will reasonably believe that all the values are implemented.

I've actually got this very issue in a bug here mdn/sprints#3723

We've got a value which is implemented for flex and grid contexts but not elsewhere (in this instance for width). I think it is useful to convey to authors the lack of implementation. Same with the balance-all value I flagged in this issue.

If we say something is implemented and part of it is newer so is not, I'd like people to be able to see that. That to me has been one of the benefits over Can I Use where it takes a fairly broad approach and then squirrels things in the comments.

I could probably go through most of the CSS PRs reasonably quickly and say which are actually part of a viable, worked on spec and should be maintained (assuming @chrisdavidmills is happy for me to).

[saschanaz]

as it could be confusing to authors who will reasonably believe that all the values are implemented.

True, if we do this we should also remove those values from the corresponding MDN documents. (Or at least mark them as coming-soonish to prevent people from adding them back.) Describing nonimplemented features and then showing completely green table would be misleading.

If we want to keep it in BCD I might adjust the linter to exclude items with notes field, as sometimes such notes include tracking bugs for future implementations.

[ddbeck]

Summary: yes, let's keep these in BCD for now. Longer explanation below.

@rachelandrew can you confirm that both of the features in this PR are part of active specs?

@chrisdavidmills is it OK to ask @rachelandrew to look at all the CSS feature removals open right now to figure out their disposition? Suggested in #6962 (comment).

---

Yeah, I agree that we should not drop this data, if the spec is lively. While I like the idea of not tracking anything without an implementation, I'm not sure that it's realistic to do just yet (there's some other corners of this policy that present problems, like features gated to nightlies or stuff in Safari TPs, where we can't or don't record data, but there's a reasonable compat question to answer for web developers; there's also the question of spec_urls which might help resolve things better too). Let's start out somewhat conservatively and not remove this.

@saschanaz:

If we want to keep it in BCD I might adjust the linter to exclude items with notes field, as sometimes such notes include tracking bugs for future implementations.

Yeah, I like this idea. It's sort of self-documenting, too, for future re-reviews.

[ddbeck]

Oops, accidentally submitted too soon. I expect we'll close this one, but I'm leaving it open pending answers from Rachel and Chris.

[rachelandrew]

@ddbeck yes these are part of active specs. The balancing stuff has had a load of discussion recently which is presumably why it's not implemented pending resolutions as to how it works.

[rachelandrew]

and if @chrisdavidmills is happy it won't be a big job to go through the others, if I don't know off the top of my head it's going to be a case of a quick look on the CSSWG Github or at worst an email to the relevant spec editor.

[chrisdavidmills]

@ddbeck yup, I'm happy for @rachelandrew to help with going through these.

[saschanaz]

If we want to keep it in BCD I might adjust the linter to exclude items with notes field, as sometimes such notes include tracking bugs for future implementations.

Yeah, I like this idea. It's sort of self-documenting, too, for future re-reviews.

In that case the work item here probably is to add tracking bugs (or file one if not exists) rather than just closing this.

[ddbeck]

@saschanaz

In that case the work item here probably is to add tracking bugs (or file one if not exists) rather than just closing this.

Good point. Is this a detail of #6809? Or should we open a new issue, combining what we've learned from #6431 and #6768? I found this tougher to distill into an actual task than I first thought 😅

[saschanaz]

My current plan is to get some review for those no-rows, and if they need to be kept, then add some notes there and proceed.

[ddbeck]

Things seem to be proceeding well on the other removals (or bug link updates). And this PR itself looks good. Thanks folks! 🎉