browser-compat-data icon indicating copy to clipboard operation
browser-compat-data copied to clipboard

Adding subfeatures guidance

Open hamishwillee opened this issue 2 years ago • 6 comments

The current guidance explains how you add subfeatures, but omits how you decide when a subfeature is required.

My understanding is that you only add subfeatures for compatibility differences. So someone seeing that an interface is supported knows that all the browsers implement that subfeature in the same way in those particular versions.

BUT they don't know exactly what methods, properties etc are exactly implemented from that data. While they might "hope" that everything in the spec is implemented, what they actually know is that they are all the same implementation in those indicated versions.

I wanted to check this because the use case [ImageData] used widely in the doc does not comply with these rules - I'll comment below.

This comes out of the discussion here: https://github.com/mdn/browser-compat-data/issues/7849#issuecomment-1211067916

FYI @queengooborg @foolip

hamishwillee avatar Aug 15 '22 02:08 hamishwillee

This pull request has merge conflicts that must be resolved before it can be merged.

github-actions[bot] avatar Aug 22 '22 20:08 github-actions[bot]

@foolip Thanks for reviewing this.

I'm a bit frustrated with how this ended up - mostly because we previously had no definitions of our terminology (i.e. for subfeature), and now we have ones that I think are annoying.

How about you and Vinyl fight this out and just make the edits you need. I understand the rules now, so not so concerned :-)

hamishwillee avatar Sep 16 '22 00:09 hamishwillee

@hamishwillee I hope we can land on some definitions that make sense to everyone.

@queengooborg It looks like we are invited to duel. Given your beat saber skills I think I'd be quickly shredded if we do it with swords, but let's see if we can work it out in comments instead 😄

foolip avatar Sep 19 '22 13:09 foolip

@foolip Yes, you two must duel; let the gods of clarity prevail.

Apologies that I am taking my grumps out on you two. This seemed like this task should be so easy and it has not been.

I'm OK with everything being a feature, and using "behavioral features" to mean what it means.

The problem is that for this to work we need to explain the conditions when you need to create a sub-node for a new feature -and when you do not. So we create a sub node by default for methods and properties of an interface but we do not for the arguments of a function or constructor.

I wanted to use the name "subfeature" to refer to any subnode of the method. If we can't do that, then find an acceptable substitute you'll be happy with and this should not end up being hard.

hamishwillee avatar Sep 19 '22 23:09 hamishwillee

This PR is the oldest PR currently open, and I don't see us coming to a resolution any time soon (this is unfortunately a low priority for us right now). What should we do with this PR?

queengooborg avatar Jan 07 '24 15:01 queengooborg

I still want to review this. Recently, there were discussions about features, subfeatures, behavioral features in the context of groups.

Elchi3 avatar Jan 17 '24 09:01 Elchi3