Is "text-align: center" really deprecated and non-standard?!?

[Hexstream]

I noticed that the MDN page for text-align claims that text-align: left, text-align: right and text-align: center are all deprecated and non-standard.

I can understand in the case of text-align: left and text-align: right, since text-align: start and text-align: end seem like better alternatives anyway, but I think text-align: center is obviously the best option in many cases, with no universal replacement. Even that page itself uses text-align: center as an example, and I couldn't find any authoritative source explaining why text-align: center is or should be deprecated.

I think this is a bug in the MDN documentation and text-align: center is not in any way deprecated or non-standard.

(I don't think any of these 3 values are "non-standard" either, since they have been specified and universally supported for decades, and I am quite sure no sane browser is going to drop support for them anytime soon.)

[francescorn]

The latest editor's draft includes text-align: center: css-text-4. In: css-writing-modes-4 it says left to right features are not recommended because HTML UAs can turn off CSS styling. I think text-align: left and text-align: right are included.

[Hexstream]

In: css-writing-modes-4 it says left to right features are not recommended because HTML UAs can turn off CSS styling. I think text-align: left and text-align: right are included.

I think you are misinterpreting the note, which just says you should use the html dir attribute rather than change the direction property directly with CSS.

[francescorn]

Thank you @Hexstream

[caugner]

Thanks for flagging, I will move this to the content repo, as the deprecated/non-standard badges are declared there:

content/files/en-us/web/css/text-align/index.md

Lines 51 to 56 in 7889bb9

	- `left` {{deprecated_inline}} {{non-standard_inline}}
	- : The inline contents are aligned to the left edge of the line box.
	- `right` {{deprecated_inline}} {{non-standard_inline}}
	- : The inline contents are aligned to the right edge of the line box.
	- `center` {{deprecated_inline}} {{non-standard_inline}}
	- : The inline contents are centered within the line box.

[Hexstream]

Thanks!

(Bizarrely, I did not get a notification for your message, first time this happens...)

(edit: Might have something to do with the transfer? Weird coincidence that the only time my issue gets transferred is the only time I don't get a notification...)

(edit 2: I am happily getting notifications for subsequent messages! 🎉 I was getting worried there, as GitHub without email notifications would be completely unusable...)

[hamishwillee]

I suspect this was the result of an earlier update from BCD that went wrong #32371.
The BCD doesn't match this.

@OnkarRuikar What's the status of the update script for BCD at the moment? Should we manually fix this up to match BCD?

[OnkarRuikar]

I suspect this was the result of an earlier update from BCD that went wrong #32371.

Nope. Actually, it was a bug in BCD that was fixed on 6th March. On 7th March it was supposed to be corrected in mdn/content by Synchronize with BCD v5.5.14, but the PR got stalled due to other issues in BCD.

@OnkarRuikar What's the status of the update script for BCD at the moment?

• The BCD to mdn/content synchronisation bot has been paused: Synchronize with BCD v5.5.14 #32594
  In weekly meeting on 12th I proposed to merge the sync PR as it is and when BCD issues get fixed it would auto correct. But we decided not to continue with buggy stuff.

The bot is waiting on following issues to be fixed:

• Update Safari data for css.properties.initial-letter.normal browser-compat-data#22596
• all the BCD issues mentioned in Synchronize with BCD v5.5.14 #32594
• the discussion https://github.com/orgs/mdn/discussions/654

Should we manually fix this up to match BCD?

We should escalate this and get the bot running. Otherwise we'll start seeing multiple issues for each missed sync page. I was hoping to discuss these with BCD maintainers in the meeting. But they refuse to join the meetings until we stop using Jitsi and OWD doen't want to use anything else. 🙅
There is no harm in running the bot because:

1. We can always update all the docs in one go when we conclude the https://github.com/orgs/mdn/discussions/654 discussion.
2. For BCD related issues, raise the issues in BCD repo and track there. When those issues get fixed it'll be auto corrected in mdn/content.
   If we do manual fixes now then I fear the core issue is not going to get fixed soon.

[hamishwillee]

@Hexstream So there you are, trust the BCD over MDN.

If we do manual fixes now then I fear the core issue is not going to get fixed soon.

@OnkarRuikar I understand your point - the best way to fix this would be to be able to run the script. But if this is not converging in any way to a result and there is no sign of it doing so, we'd be dumb not to fix these as we find them. So how are the issues progressing really - are we in "never going to fix" land or stalled, or what?

[hamishwillee]

PS @OnkarRuikar W.r.t. to the bot, I understand that the issue is around presentation of "CSS Values". If that is the blocker, then IMO that specific functionality should be separated from the bot actions so the bot can run. We should not block other updates.

[Hexstream]

@Hexstream So there you are, trust the BCD over MDN.

???

[hamishwillee]

@Hexstream So there you are, trust the BCD over MDN.

???

I'm just saying you're right, its a bug in the docs. For now, if the BCD shows something different than the docs I would trust the compatibility data.

[OnkarRuikar]

@Hexstream So there you are, trust the BCD over MDN.

:O that is why I am in favour of the sync bot being transparent and it to mimic BCD as it is no matter what. Those who feel the same please vote for Christmas tree 🎄 option in https://github.com/orgs/mdn/discussions/654 poll.

If that is the blocker, then IMO that specific functionality should be separated from the bot actions so the bot can run. We should not block other updates.

I could ignore those pages in the script and resume the bot. May I do that?

[wbamberg]

There is some history to this issue in mdn/browser-compat-data#22524 (comment). Actually it's been wrong in BCD since June 2023, but people only started noticing when the bot started adding the labels to items in "Values" (which is an interesting user-test of how much people look at the icons in BCD tables, versus the page text). As Onkar says, it got fixed in BCD a couple of weeks ago, but the fix hasn't propagated to MDN because the bot isn't running, because of issues I raised in #32594.

I don't think these issues are going to be resolved any time soon. I do think we should fix these pages. I think it would be fine to:

1. remove the flags that the bot has added to CSS values
2. stop the bot adding flags to CSS values, until we have resolved Synchronize with BCD v5.5.14 #32594.

About the issues in #32594. I've said this elsewhere but for the record.

I think if we are not to get in a mess here, we need to know what should be listed in the "Values" section. When a property's values are just taken from a list of keywords, it's easy. But take, say, https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-rows or https://developer.mozilla.org/en-US/docs/Web/CSS/grid-area. In these pages, what should "Values" list? Are the "Values" sections in these pages correct? How can we tell?

Look at it like this. For Web/API methods, we know pretty much what gets listed in "Parameters". We can look at a page, compare it with the IDL, and know if they are listed correctly. But for CSS...say https://developer.mozilla.org/en-US/docs/Web/CSS/grid-area . It lists span && [ <integer> || <custom-ident> ] as one of the values. Is this right? What are the rules, basically, for mapping from the formal syntax, which is the definitive description, to the list of "Values"?

(I can tell you what the answer to this used to be. But practice has diverged over the years, and there is no clear answer to this any more.)

And then, whatever we do decide they should be, will they map cleanly onto things we want to make compat statements about?

Like, say we want to make "Values" entries be the granular CSS data types that participate in a formal syntax definition. So for grid-area one of the entries might be <custom-ident>. But <custom-ident> appears in the formal syntax in three different places. So what would it mean if we said it was experimental? Does it have limited support in all three places, or only some, and if in some, which ones? What are we expecting readers to understand by this?

[OnkarRuikar]

Actually it's been wrong in BCD since June 2023, but people only started noticing when the bot started adding the labels to items in "Values" (which is an interesting user-test of how much people look at the icons in BCD tables, versus the page text).

This feels so good. Clearly closer the info quickly it gets consumed thus being more useful. This makes strong case for Christmas tree 🎄 strategy in https://github.com/orgs/mdn/discussions/654 poll.

Like, say we want to make "Values" entries be the granular CSS data types that participate in a formal syntax definition. So for grid-area one of the entries might be . But appears in the formal syntax in three different places. So what would it mean if we said it was experimental? Does it have limited support in all three places, or only some, and if in some, which ones? What are we expecting readers to understand by this?

In this case, if the value <custom-ident> is experimental then it's not necessary for <integer> && <custom-ident>? to be experimental. Cos implementation of certain combination could be new. So if, hypothetically, if span && [ <integer> || <custom-ident> ] is experimental then BCD need to track it as it is. If a property is not in BCD then it needs to be treated as non-experimental, non-deprecated, and on standard track.

[hamishwillee]

OK, so I'm not entering that discussion ^^^. But this issue is fixed by #32756

[Hexstream]

Awesome, thanks!