Re: Not using "non-breaking hyphen" U+8209 in timestamps (thanks)

Yeah, I've been contemplating making that same change. There are several places where dates are displayed in tables and my experience was that browsers were pretty stupid and frequently chose to make the date column too narrow such that every single row became two lines high. Preventing browsers from making this choice mostly lead to better presentation where the widest column (usually 'title') was made narrower and most rows would be single lines and only the rows with the longest titles took up two lines. And wrapping of titles is less of a problem than wrapping something regular like a date -- where you lose having the years lined and now have numbers lined up vertically but only every other one is a year, making the information much harder to scan.

But that improvement isn't worth the ugliness that shows up in many contexts. I was thinking that this change was a change I had made only to my personal settings. But I think we lack a personal setting for "how to format dates compactly" so there are several tables that just hard-code the formatting of dates.

- tye

Comment on Re: Not using "non-breaking hyphen" U+8209 in timestamps (thanks)

Replies are listed 'Best First'.
Re^2: Not using "non-breaking hyphen" U+8209 in timestamps (thanks) by jdporter (Paladin) on Jan 16, 2011 at 03:52 UTC
Ok, thanks. Yes, we do have a "compact" time format setting as well; the variable is shorttimeformat. Some places where this format is used are: Recent Janitorial Edits Saints in our Book Perl Monks User Search (results) Past Polls Monks Last Here As you'd expect, all of these are tables. If we see the old problem crop up again, maybe we could post-process the result of parseTimeInString(short) by `s/-/‑/g` in just those places. What is the sound of Windows? Is it not the sound of a wall upon which people have smashed their heads... all the way through?	[reply] [d/l]
Re^3: Not using "non-breaking hyphen" U+8209 in timestamps (future) by tye (Sage) on Jan 16, 2011 at 06:53 UTC
No, we don't want to `s/-/‑/g` for everybody, as some people have environments where that character doesn't render properly (the Wii browser for one, it seems). Frankly, most people don't have this problem because they are used to the age of CSS when at least a near majority of web pages are at least inconvenient to read if you don't maximize your browser and also have a fairly modern-sized monitor. I find that most computer users I meet either only use maximized windows or hardly ever use maximized windows. The latter group is in the minority but counts me as a member. So I find myself constantly disabling CSS just so I can frickin' read the dang text on a stupid web page. So I likely have my browser window about 1/2 the width of the majority of people and so I see wrapped text in tables at PerlMonks more than most. So, the few of us who actually still make use of a windowing system should be enabled to set our 'shorttimeformat' to "`%Y‑%m‑%d %H:%M`" or "`<nobr>%Y-%m-%d %H:%M</nobr>`" but then have that transformed into something for the non-HTML contexts (like 'title' attributes), perhaps via things like `s/‑/-/g` and `s/ / /g` and `s/<[^>]+>//g`. So we need to teach the code to ask for an HTML compact date or a text compact date. But probably better would be to allow for each time format to specify separate formats for HTML vs. text. I'd probably just stuff that into the existing format settings. I'd be tempted to use "`</html>`" as the separator so we don't have allow for escaping the separator. For example, "`<nobr>%Y-%m-%d🕑%H:%M</nobr></html>%Y-%m-%d %H:%M`". - tye	[reply] [d/l] [select]