Make WordPress Core

Opened 11 years ago

Closed 10 years ago

Last modified 9 years ago

#25008 closed defect (bug) (fixed)

Twenty Fourteen: Add word-wrap to title, avoid overflows

Reported by: nofearinc's profile nofearinc Owned by:
Milestone: 3.8 Priority: low
Severity: normal Version: 3.8
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

Testing with a large title with underscores, Twenty Fourteen got the title overlapping over the sidebar on a small width screen.

Screenshots attached, suggesting the addition of a word-wrap to the title tag.

Attachments (3)

title-no-wrap.png (39.3 KB) - added by nofearinc 11 years ago.
Title without wrap
title-wrap.png (38.1 KB) - added by nofearinc 11 years ago.
Title with wrap
25008.patch (419 bytes) - added by nofearinc 11 years ago.

Download all attachments as: .zip

Change History (40)

@nofearinc
11 years ago

Title without wrap

@nofearinc
11 years ago

Title with wrap

@nofearinc
11 years ago

#1 @obenland
11 years ago

  • Component changed from Themes to Bundled Theme

#2 follow-up: @lancewillett
11 years ago

  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 3.8

We might want to look at an approach that breaks in a better way, like hyphens.

#3 in reply to: ↑ 2 @nofearinc
11 years ago

Replying to lancewillett:

We might want to look at an approach that breaks in a better way, like hyphens.

Not sure what is the best way to implement that without JavaScript hacks so that it works in various browsers.

I was thinking of something like this added to my patch:

 -ms-word-break: break-all;
     word-break: break-all;
     word-break: break-word;
-webkit-hyphens: auto;
   -moz-hyphens: auto;
    -ms-hyphens: auto;
        hyphens: auto;

As in this demo, but still not sure how compatible would it be everywhere.

#6 @iamtakashi
11 years ago

  • Cc takashi@… added

#7 follow-up: @lancewillett
11 years ago

Related to a Twenty Thirteen discussion and eventual "wontfix": #25232.

#8 in reply to: ↑ 7 @nofearinc
11 years ago

Replying to lancewillett:

Related to a Twenty Thirteen discussion and eventual "wontfix": #25232.

I saw the comment on Emil's ticket yesterday and I could eventually see some reason behind applying it for a previous theme, but any reason not to fix that for something that's about to be released and it's clear that is a problem?

From a theme reviewer's perspective, this is an issue and other authors would suggest that it hasn't been fixed in core themes either :\

#9 @lancewillett
11 years ago

  • Priority changed from normal to low

#10 follow-up: @lancewillett
10 years ago

Can you check all the other default themes? Twenty Ten through Thirteen. I don't think this is worth fixing -- and maybe should be removed from the Theme Unit Test also; I'm pretty sure we haven't addressed it in other themes so far.

#11 in reply to: ↑ 10 ; follow-up: @obenland
10 years ago

Replying to lancewillett:

I don't think this is worth fixing -- and maybe should be removed from the Theme Unit Test also;

Why would you want to have titles overflow?

#12 in reply to: ↑ 11 ; follow-up: @lancewillett
10 years ago

Replying to obenland:

Replying to lancewillett:

I don't think this is worth fixing -- and maybe should be removed from the Theme Unit Test also;

Why would you want to have titles overflow?

I think maybe I should be more clear: I don't think this is a problem that needs to be fixed.

If anyone has a real-life test case I'd love to see it. :)

#13 in reply to: ↑ 12 @nofearinc
10 years ago

Replying to lancewillett:

I think maybe I should be more clear: I don't think this is a problem that needs to be fixed.

If anyone has a real-life test case I'd love to see it. :)

I have several clients with WordPress websites providing tutorials/exams for different medical/biology/chemistry related areas. Occasionally there are terms like Pneumonoultramicroscopicsilicovolcanoconiosis (which is pretty legitimate word) that break the title. Few other projects use serial numbers for products or ISBN-alike unique numbers as post titles (for hardware store) with dozens of numbers and letters with no separator.

A test 2010-2013 prove 2011 and 2013 not handling them properly, 2010 and 2012 apply small font-size that was no problem with most long titles. Everything else was handled though (links in widgets and other areas) and additionally I don't see a reason to intentionally break titles for real world scenarios :)

#14 @lancewillett
10 years ago

  • Milestone 3.8 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Discussed again in #wordpress-themes IRC during Twenty Fourteen work chat and agreed that though a valid edge case, it could cause more problems than it's worth, and we'd prefer to wontfix.

Log: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-themes&day=2013-11-08&sort=asc#m75217

#15 @Otto42
10 years ago

Can we get a valid counter-example? What is a good reason to wontfix this? What problems will the proposed patches create?

The theme review guidelines specifically say that this should be handled appropriately. What will adding wrap here break?

#16 @chipbennett
10 years ago

Core-bundled Themes marking issues that fail the Theme Unit Tests as wontfix is rather problematic, and puts the Theme Review Team in the tenuous position of having to explain why core-bundled Themes aren't required to conform to the Theme Review guidelines.

#17 follow-up: @lancewillett
10 years ago

We should change the guidelines, probably.

#18 in reply to: ↑ 17 ; follow-ups: @chipbennett
10 years ago

Replying to lancewillett:

We should change the guidelines, probably.

On what grounds?

What would you change about this unit test, and why?

Last edited 10 years ago by chipbennett (previous) (diff)

#19 in reply to: ↑ 18 @lancewillett
10 years ago

Happy to explain more. It's been hashed out a bit before, but I can sum it up here.

Replying to chipbennett:

Replying to lancewillett:

We should change the guidelines, probably.

On what grounds?

  1. Too much of an edge case
  2. Titles aren't the reason for this rule in the first place
  3. Long words now run the risk of creating an uglier result than "overflowing the content"
  4. We've learned from past default themes that titles shouldn't have automatic breaks

What are the odds a website will have that long of a word in the title? Close to 0.

What are the odds it'll have a long URL that someone pastes into a widget or comment instead of using an anchor element? Very high.

I believe this Unit Test came about because of long URLs and not because of normal title words.

It's a common practice with long URLs in widgets and comments because they can be very long and have no break characters (word breaks, hyphens, punctuation, etc).

Titles are a bit different in that a break at the wrong place is less desirable than an overlap. Here's a visual example with a more common "really long" word, Antidisestablishmentarianism.

https://i.cloudup.com/03mBIrXUkB.png

The first result is much more desirable than the second.

Additionally, it's a design principle to have beautiful titles. Bringhurst (world-renowned expert on typography) says in his authoritative work The Elements of Typographical Style, "make the title of the page a symbol of dignity and presence of the text." In my interpretation of this design principle, forcing breaking for titles instead of letting the author decide to manually break is an ugly solution, and it adversely affects the entire design.

#20 in reply to: ↑ 18 @lancewillett
10 years ago

Replying to chipbennett:

What would you change about this unit test, and why?

We could change the text "Title should not overflow the content area" to a more accurate "Long content should have no adverse effects on layout or functionality" which leaves it up to interpretation of the designer.

Or, maybe remove it entirely. Not something theme designers can really control—it's up to authors to manually break really long words, like if they have a technical website with scientific terms or something.

Or, we could update the test with a more common long word, or combination of long words that's more likely to occur. I don't think themes should need to accommodate a word that has a low probability of occurring on a page. Something like "Sesquipedalian Loquaciousness" or "Antidisestablishmentarianism" a combination of 3-4 long English words that are a bit more common would actually be a useful test.

In real-world practice when something like this happens, a website author will most likely manually hyphenate or choose a different set of words.

A note on titles versus comments and sidebars

Themes should try to avoid long overflow content in comments or sidebars because they tend to be really narrow.

Titles are different because what often happens—the negative side effect—is that the word is one letter short of fitting and instead gets chopped, with one letter on the next line. That's worse than letting that letter overflow, in my opinion. See my visual example above.

Lastly, complaints have come in for past default themes where we tried to be too fancy with word breaking and hyphenation outside the comment and sidebar areas. Here's an example, here's a second, here's a third.

Ultimately as an author I'd prefer to have the control over titles versus have a bad break occur.

#21 @chipbennett
10 years ago

My concern here is that the disagreement stems from the recommended fix, rather than the underlying problem the guideline attempts to address. Using break-word is a design decision, and only one potential way to resolve overflowing titles.

(The next most-obvious solution: overflow:hidden.)

And I disagree that the edge case is one not worthy of being accounted for. Post Titles can be used for anything, especially in the context of post formats.

But the bigger problem is that the team developing a core-bundled Theme, when encountered with a Theme Unit Test with which it disagreed, just silently ignored it, instead of coming back to the Theme Review Team to express the concerns as you've done here in the ticket. This sort of thing would be ideal to bring up on the mail-list, to generate discussion and yield improved Guidelines/Theme Unit Tests.

#22 @lancewillett
10 years ago

I agree we should bring this discussion back to the community, but in reality it's not important in the grand scheme of things (a minor design decision) and we're in the middle of a stressful and urgent sprint to get this theme ready for 3.8.

#23 follow-up: @markoheijnen
10 years ago

I agree with Chip here. I also think this is important because ignoring guidelines in a core-bundled theme is wrong. In this situation the theme can be bundled in core but should be rejected on WordPress.org. What doesn't make sense.

#24 in reply to: ↑ 23 ; follow-up: @chipbennett
10 years ago

Replying to markoheijnen:

I agree with Chip here. I also think this is important because ignoring guidelines in a core-bundled theme is wrong. In this situation the theme can be bundled in core but should be rejected on WordPress.org. What doesn't make sense.

To be fair: this is an issue that almost certainly would fall under required, but can be addressed in the next revision. It is a minor - though, I argue, valid - edge case. I just want to ensure that we handle it properly.

#25 in reply to: ↑ 24 @lancewillett
10 years ago

Replying to chipbennett:

To be fair: this is an issue that almost certainly would fall under required, but can be addressed in the next revision. It is a minor - though, I argue, valid - edge case. I just want to ensure that we handle it properly.

Guidelines are ways to suggest how we think a theme should work for the best possible user experience. The best way to handle themes that don't enact each guideline exactly the same is ... to let it be.

Guidelines as recommendations should never fail a theme. I think this points to a needed change in philosophy for theme reviews (myself included in the WordPress.com system where we're just as strict — or stricter — than WP.org).

Let's discuss on make/themes rather than Trac, though. ;)

#27 @lancewillett
10 years ago

#26126 was marked as a duplicate.

#28 follow-up: @senlin
10 years ago

To be honest, I find the whole argument for "ignoring" the theme guidelines quite strange.

What I find even stranger is that the people most active in this discussion only seem to care for words in the English language...

There are plenty of languages that have much longer common words than the "extreme" long English words on the unit tests.

Seemingly once again other languages are completely ignored when it comes to this.

So now it is ok for a default theme to completely fail a theme unit test? And the reason is because common English titles will hardly ever be that long?

Wow, way to go for WordPress i18n!

fwiw: just plain laziness imho

Last edited 10 years ago by senlin (previous) (diff)

#29 in reply to: ↑ 28 ; follow-up: @lancewillett
10 years ago

Replying to senlin:

So now it is ok for a default theme to completely fail a theme unit test? And the reason is because common English titles will hardly ever be that long?

Much, much discussion happening on Make Themes blog: http://make.wordpress.org/themes/2013/11/10/guidelines-shouldnt-fail-a-theme/ and http://make.wordpress.org/themes/2013/11/12/theme-unit-tests-recommended/.

#30 in reply to: ↑ 29 @senlin
10 years ago

Replying to lancewillett:

Much, much discussion happening on Make Themes blog: http://make.wordpress.org/themes/2013/11/10/guidelines-shouldnt-fail-a-theme/ and http://make.wordpress.org/themes/2013/11/12/theme-unit-tests-recommended/.

Discussion is good, but it should happen before.

I don't think it is very good practice to first label a ticket (or tickets) as "wontfix" and then starting a discussion about it.

First link (to discussion) doesn't say anything about internationalization

Neither anything on i18n in the 2nd discussion.

So what about a fairly common Dutch words, such as:

  • aandeelhoudersvergadering
  • luchtvaartmaatschappijen
  • telecommunicatiebedrijven
  • meervoudigepersoonlijkheidsstoornis

Simply wontfix for the currently broken Twenty Fourteen WordPress default theme?!

Last edited 10 years ago by senlin (previous) (diff)

#31 @senlin
10 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

#32 @chellycat
10 years ago

Just my two cents: I think it makes sense to fix this for smaller screens only. On mobile devices, large titles break the layout significantly and it's not a good experience. I personally feel that it's OK to force break titles on mobile screens, which are designed for reading. The point about some languages having longer words on average than English makes sense to me, too.

Example of layout breaking on an iPhone due to large title: http://core.trac.wordpress.org/ticket/26189#comment:2

Last edited 10 years ago by chellycat (previous) (diff)

#33 @SergeyBiryukov
10 years ago

  • Milestone set to Awaiting Review

#34 @lancewillett
10 years ago

  • Keywords has-patch needs-testing removed
  • Milestone changed from Awaiting Review to 3.8
  • Resolution set to fixed
  • Status changed from reopened to closed

#35 in reply to: ↑ description @gregrickaby
10 years ago

Just wanted to leave a comment with a real world issue:

Client is uploading images (which have ridiculously long file names) and choosing "Link to attachment page". Guess what? The title extends outside the theme.

A case can be made that long, "regular old post titles" are indeed an "Edge Case" - but long filenames are probably a more common scenario.


Time for me to go on a tangent: There are like 4 or 5 similar tickets (with patches!) that have also been closed. It even failed a unit test (and was ignored!) It's obviously broken, and is fixable with one line of code. Why are we still "talking" about this?

This thread represents the very best AND worst of WordPress. Seriously.

.entry-title {
     word-break: break-all;
}
Last edited 10 years ago by gregrickaby (previous) (diff)

#36 @pauldewouters
9 years ago

Ultimately as an author I'd prefer to have the control over titles versus have a bad break occur.

In an ideal world where you are designing all the content ever to be published with the theme, yes. But I think bundled themes should be as robust as possible and account for the most edge cases possible as we don't know how the theme will be used. The user could always override the default CSS in the event there really long title shouldn't be broken. Which in my opinion would be less common than the opposite.

This ticket was mentioned in Slack in #core-themes by ocean90. View the logs.


9 years ago

Note: See TracTickets for help on using tickets.