![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 8 years ago
Closed 8 years ago
#45421 closed defect (bug) (fixed)
Twenty Eleven: Font size used in error instead of font weight, in editor-blocks.css
| Reported by: | laurelfulford | Owned by: | laurelfulford |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.0.2 |
| Component: | Bundled Theme | Version: | 5.0 |
| Severity: | normal | Keywords: | has-patch commit fixed-5.0 |
| Cc: | Focuses: |
Description
In editor-blocks.css on line 26, the styles incorrectly set font-size: 300 where it should be font-weight: 300. This can effect font size in some browsers (will follow up with further details!).
Copied over from this comment: https://core.trac.wordpress.org/ticket/45039#comment:10; thanks to @gonzomir for the report!
Attachments (1)
Change History (13)
#2
@
8 years ago
I just tested with Chrome 59 and it behaves the same, the error output being the trigger of the issue.
#4
@
8 years ago
- Keywords commit added; needs-testing removed
Even though this is an edge case in terms of the bug showing, it's still good to fix it soon. So, @laurelfulford, looks good to me.
#6
@
8 years ago
Thank you for this.
However the default block appender recently (around 4.3 or 4.4 IIRC) changed from being an input field, to be a textarea.
So this:
.editor-default-block-appender input[type="text"].editor-default-block-appender__content {
should be this:
.editor-default-block-appender textarea.editor-default-block-appender__content {
Before: https://cloudup.com/cKJ8nafl9XI
After: https://cloudup.com/cIgMjCLRCJv
Sorry to note that this change (from specifying input to specifying the textarea instead) is also necessary for the other Twenty themes, excluding 2019.
#7
@
8 years ago
the default block appender recently (around 4.3 or 4.4 IIRC) changed from being an input field, to be a textarea.
Thanks @joen! This issue has been trac'd and patched in #45450!
#10
@
8 years ago
- Keywords fixed-5.0 added
Reopening and marking fixed-5.0 so that this can be properly merged into trunk.
The problem is visible only when there's some output from error reposting. When
WP_DEBUGisfalseeverything looks fine, but when it'strueand there is error reporting output in the page the browser switches to quirks mode and interprets the rule differently. I tested with Firefox 63.0 on Ubuntu.Screenshots:
with
WP_DEBUG = falsehttps://screenshots.firefox.com/c5wQbrTHfw4HQlaZ/kaksepishe.wp.local
with
WP_DEBUG = truehttps://screenshots.firefox.com/7u9sllgs3lN4VNxn/kaksepishe.wp.local