Listing enumerated values for deprecated attributes

[estelle]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table

What specific section or headline is this issue about?

Deprecated attributes

What information was incorrect, unhelpful, or incomplete?

In some deprecated attributes we list the enumerated values. In others we don't. @EzioMercer made a very valid point in a PR to add the enumerated values for the deprecated frame attribute.

See mdn/content#28399 (comment)

This discussion stems from mdn/content#28684

Section: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table#deprecated_attributes

What did you expect to see?

consistency

should we list all the deprecated values? Should we omit them all. If some and not others, do we have a rationale?

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

[EzioMercer]

In my opinion, if something is deprecated but still widely supported, it should be described as if it weren't deprecated, but if something is deprecated and not widely supported, it should be removed or described very shortly for historic reasons

[bsmth]

This could be converted to a discussion, but adding new content about deprecated features doesn't seem useful beyond historical reasons, so from an editorial perspective I would freeze any additions to these, even for the sake of consistency. I'd lean more towards what we're doing with others ('described very shortly for historic reasons'):

- `deprecated_attr` {{Deprecated_inline}}

  - : Description of this attr. To achieve a similar effect, use the {non-deprecated alternative}.

[hamishwillee]

Yes, I would move to a discussion. FWIW I don't think it makes sense to invest in deprecated content. So yes, you might add a short description to the non-deprecated alternative but I wouldn't pad out a full document.

Content removal has a policy that derives from BCD. Essentially it happens 2 years after a deprecated feature is removed from all browsers in our supported set.

[EzioMercer]

@hamishwillee How can I found the discussion of this issue?

[estelle]

moved to discussion: https://github.com/mdn/content/discussions/28811

[EzioMercer]

@estelle Can you please add new link for discussion into closed issue? Because at this moment there are no way to come here from closed issue to discuss this question. I found link to this discussion in an old email and it redirects me here

[hamishwillee]

@EzioMercer It hasn't been moved. If it had, it the issue would "become" a discussion. I think it would be up to @estelle to do so if she thinks it worthwhile.

I would not feel forced to put much effort into something that was deprecated, for consistency or otherwise.

1. I would ensure there was a BCD entry and possibly also an interface entry so that there is some record on MDN that people shouldn't use the property/method/class.
2. Note that BCD removes things when they are considered "irrelevant" - i.e. deprecated and no longer in any platform for more than 2 years. At this point we remove information from both BCD and content.
3. I wouldn't create a full page, for a property though. It is valid to do so, but simply not a priority.
4. For the same reason I wouldn't delete such a page. It does no harm to have and choosing to remove it would not be a priority.
5. Note that reviewers might take longer to review submissions for deprecated content, as said review would not be a priority.

[hamishwillee]

Yes, you would be "allowed" to document deprecated APIs if they were a priority for you.

There is a caveat though. The review team bandwidth is not unlimited and we will review according to our priorities. If you chose to document deprecated features it is quite possible that we would take longer to document them. If you created an enormous amount of documentation for deprecated features we would have to reconsider our policy.

[EzioMercer]

Hahaha, I don't think that I will able to force you to review your policy :) Then can I ask to reopen my PR and merge it? Also I think that your comment should be an answer for this discussion

[hamishwillee]

@estelle Are you OK to reopen it on the above basis - "you can document deprecated properties minimally, but there is no requirement to do so, and review is likely to be slow"

[estelle]

My take is that neither the frames nor rules attribute should be added to any code base. They can be listed for historical reasons because they're still supported. If a 'view sourcer' encounters the attribute, it's helpful for them to be able to find out what they mean hen they look it up, but we definitely don't want to encourage their use.

To discourage use, the enumerated values should be in paragraph, rather than list, format. The value definitions should be brief, or non-existent.

For example, rules should likely be reduced to:

This enumerated attribute defines where rules, i.e. lines, should appear in a table. Lines can be set to appear between `rows`, `cols` (for columns), or `groups` (between  `<thead>`, `<tbody>`, and `<tfoot>` elements, and between `<col>` and `<colgroup>` elements), or `all` or `none` of the above.

I've reopened the PR. Please shrink to a paragraph.

Now back to <dialog> accessibility concerns

[EzioMercer]

Any updates?

[hamishwillee]

Let's see what Estelle says. I added note "2" above as well - that's to catch the case that BCD will remove entries that are "no longer relevant", and in this case the action is to remove the content from MDN as well.

[Josh-Cena]

@estelle after the issue is transferred as a discussion, the issue automatically becomes locked and there does not seem to be an easy way to unlock it. Therefore I've closed the issue (you reopened a while ago) and we should move further discussions either to the PR or this thread.

[pepelsbey]

Thank you for starting the discussion. I’m closing this now due to inactivity, but if you think that’s a mistake, feel free to reply. You’re also welcome to join the MDN Discord if you’d prefer to chat with us more about it in sync.