Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

iframe: document needs language attributes #54150

Open
sabernhardt opened this issue Sep 4, 2023 · 5 comments
Open

iframe: document needs language attributes #54150

sabernhardt opened this issue Sep 4, 2023 · 5 comments
Labels
[Package] Editor /packages/editor [Type] Enhancement A suggestion for improvement.

Comments

@sabernhardt
Copy link
Contributor

Description

The iframe editor does not include a lang attribute, either for the site's language or for a post's language (which can be different from the main site language on multilingual sites).

gutenberg/packages/block-editor/src/components/iframe/index.js

Line 195 in c7ff22a

<html>

Accessibility Conformance rules may make an exception for embedded pages, but any styles for specific languages cannot be applied without the lang attribute inside the iframe. This includes font selection in themes such as Twenty Seventeen and Twenty Nineteen (Twenty Twenty's inline style still works, though).

Step-by-step reproduction instructions

  1. Go to the site's General Settings and select English as the language.
  2. Activate Twenty Nineteen (or Twenty Seventeen) as your theme.
  3. Open an existing post with text. If you do not have any, create a new post and add a paragraph.
  4. Use the browser's Inspect Element feature on an element within the post content area.
  5. Check the html element within the iframe. If you do not find an iframe, you may need to deactivate plugins. (And if you have the Custom Fields panel showing, you will need to hide that too.)
  6. Notice that the html does not have a lang attribute and the dir attribute is empty (instead of ltr).
  7. Go to the site's General Settings and choose a right-to-left language such as Persian, Hebrew or Arabic.
  8. Revisit the earlier post and refresh the browser.
  9. Inspect Element and check the html element within the iframe again. The html does not have a lang attribute in this case either, but the dir attribute can accurately be rtl if your profile is set to the site language.
  10. View/preview the post to see the theme's intended font for this language, and note that the editor does not match it.
  11. Activate Twenty Twenty-Three as your theme.
  12. If you would like, change the language.
  13. Go to the (site) editor and use the browser's Inspect Element feature to view the html element within the iframe there. As in the post editor, LTR languages have an empty dir attribute, RTL languages have dir="rtl" for the direction, and all lack the lang attribute.

Screenshots, screen recording, code snippet

With Twenty Nineteen, Arabic should be in Tahoma (sans-serif), but the iframe editor continues to use the serif typeface (shown in Garamond).

wrong font selection in the editor caused by missing language attribute

In left-to-right languages, the dir attribute is empty.

empty direction attribute

Environment info

WordPress 6.3.1 with Gutenberg 16.5.1

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes
@sabernhardt
Copy link
Contributor Author

#52777 describes a problem in the site editor when the profile language does not match the site language. The missing/inaccurate attributes in the iframe may be the root cause for that.

@jordesign jordesign added [Type] Enhancement A suggestion for improvement. [Package] Editor /packages/editor labels Sep 5, 2023
@sabernhardt
Copy link
Contributor Author

#52777 is a separate issue and Twenty Seventeen has additional issues (outdated classes). However, the non-latin language font styles for Twenty Nineteen worked in previous releases and the iframe editor created a new bug (regression).

@inc2734
Copy link
Contributor

inc2734 commented Oct 31, 2023

I am adding the following CSS to adjust the kerning according to the language.

:lang(ja){
	font-feature-settings: "palt" 0;
	font-kerning:none
}

This CSS will be applied on the frontend and on non iframe editor, but not on iframe editor.
I also hope the lang attribute will be added.

@sabernhardt
Copy link
Contributor Author

I started working on this in https://github.com/sabernhardt/gutenberg/pull/2/files

  1. Some themes rely on the .rtl class to override -rtl.css stylesheets from the editor, so that body class should be copied to the frame.
  2. Before setting the dir attribute within the iframe, the script needs to check whether the owner document has the attribute first.
  3. For the lang attribute, the simple addition in that draft PR seems incomplete. The PHP uses the profile language for the owner document. When that matches the Site Language, inheriting the language would be correct, and language-related styles should apply just as they would for the non-framed editor. If they do not match, the iframe might be more accurate in some situations right now.

I found one set of conditions in which the mismatch between the languages for the user profile and the site (or individual post) may need special consideration when setting the lang attribute:

  • The theme has one font (or other style) for latin characters and then uses the lang attribute to override those for specific languages (such as Twenty Nineteen).
  • The user profile is set to a non-latin language such as Greek.
  • The site (or post) is in English or another latin language.

If the lang attribute should wait for a better strategy, I still think the .rtl class and dir attribute corrections are worth making soon. If someone else could make a proper PR, I would appreciate it.

@sabernhardt sabernhardt mentioned this issue Jul 24, 2024
Draft
@sabernhardt
Copy link
Contributor Author

I'm reluctant to close this today as a duplicate of #52777, but the changes in #63883 hopefully will fix both issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Package] Editor /packages/editor [Type] Enhancement A suggestion for improvement.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@inc2734 @jordesign @sabernhardt