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.

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

Custom font size creates in-line CSS, which breaks responsiveness. #46970

Closed
scosgro opened this issue Oct 30, 2020 · 3 comments
Closed

Custom font size creates in-line CSS, which breaks responsiveness. #46970

scosgro opened this issue Oct 30, 2020 · 3 comments
Labels
[Closed] Won't Fix No intention to address issue. [Status] Stale [Type] Bug When a feature is broken and / or not performing as intended

Comments

@scosgro
Copy link

scosgro commented Oct 30, 2020

Steps to reproduce

  1. Activate a newer theme, like Maywood (all of the themes use different font sizes here, so let's go with Maywood, for testing).
  2. Create a page, and add a Paragraph Block at the top with some content. Give it a font size of HUGE (34.56px).
  3. Add a separator, and add a new Paragraph Block with some more content. Give it a font size of 35, which is just larger than the default HUGE (these numbers are Maywood specific - other themes will require other numbers to replicate).
  4. Publish the page. Adjust the page so it's mobile width, or view the page on mobile.
  5. The HUGE font size uses the CSS class has-huge-font-size, which adjusts to 28.8px on mobile, making it a bit more mobile friendly.
  6. The Custom font size is written in-line, so it stays 35, regardless of the size of the screen viewing it. This can cause issues on mobile sites when a user is developing looking specifically at the desktop screen size.

What I expected

I'm not sure what the best way to manage this is, but custom font sizes are not mobile responsive.

What happened instead

Default predefined font sizes are responsive, but custom font sizes are added in as in-line CSS, and are not responsive.

Browser / OS version

All

Screenshot / Video

image

image

Context / Source

#user-report

@scosgro scosgro added [Type] Bug When a feature is broken and / or not performing as intended Involves Happiness labels Oct 30, 2020
@yansern
Copy link
Contributor

yansern commented Nov 4, 2020

There is an ongoing PR to add relative units to font sizes on gutenberg core.
WordPress/gutenberg#25825
WordPress/gutenberg#23323

Moving this to "Being Fixed Elsewhere" column.

@github-actions
Copy link

github-actions bot commented May 3, 2021

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

@worldomonation
Copy link
Contributor

Hi! I'm performing triage on older bugs as part of Quality Squad's efforts to cut down on backlog issue counts.

Currently, one of the mentioned issue in Gutenberg has been closed while the other remains open.
I think there is no need to hold this issue open in our repository and so I am closing this with the label Closed - Won't Fix.
If this issue should remain open, please feel free to re-open this bug.

@worldomonation worldomonation added the [Closed] Won't Fix No intention to address issue. label May 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Closed] Won't Fix No intention to address issue. [Status] Stale [Type] Bug When a feature is broken and / or not performing as intended
Projects
None yet
Development

No branches or pull requests

3 participants