Reverse em/en-dash options for a more intuitive UI
Todd Nienkerk - March 22, 2009 - 01:26
| Project: | Typogrify |
| Version: | 6.x-1.0-beta4 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Todd Nienkerk |
| Status: | closed |
Description
The em-dash/en-dash support drop-down box is great, but it would be a bit more intuitive if the two-hyphen options for the em-dash were the first two options in the list.
I've attached a patch that reverses them.
| Attachment | Size |
|---|---|
| typogrify_dash_support_order.patch | 792 bytes |
#1
Okay. I'm silly. I just realized why you put these items in that order:
// Smartypants formatting.if (variable_get("marksmarty_is_smarty_on_$format", 1) == 1) {
global $smartypants_attr;
$smartypants_attr = variable_get("marksmarty_smarty_hyphens_$format", 0) + 1;
$text = SmartyPants($text);
}
...With an emphasis on:
$smartypants_attr = variable_get("marksmarty_smarty_hyphens_$format", 0) + 1;Obviously, the patch I attached doesn't actually work. I can't think of a quick way to fix this, so it's probably not worth figuring out.
#2
Figured it out. I simply set the values in the drop-down to the same numerical values that SmartyPants uses. Patch attached. "Pattached."
#3
Fixed a bug in the patch.
#4
Sigh. I just caught another reason for the order of the options: the impersonation of Marksmarty.
Perhaps this patch should be applied to another branch of Typogrify that does not try to impersonate Marksmarty? Moshe suggests on the Marksmarty project page that users discontinue Marksmarty and switch to Markdown Filter and Typogrify.
Obviously, if another branch is created, the impersonation behavior should be changed.
Sorry for the rapid-fire posts. This has probably been a waste of your time.
#5
Hi Todd,
I appreciate that you took the time to create this patch – sorry it didn't turn out the way you wanted it to.
I'm afraid that this module is a bit confusing with SmartyPants embedded within and everything.
Since I took over maintainership sometime early January, I've been trying to figure out a way to clean it up a bit. There's a lot of things that could be done. I have been looking for an alternative solution instead of all the (quite scary) RegEx stuff that's going on. I've been looking into DOM-parsing or alternative solutions to tokenize HTML. But so far nothing solid.
In any case, I agree that we should create a new branch for this. I've started out with creating a testing suite (I'm not comfortable with messing with those RegExes without having comprehensive regression testing first), but if you have any thoughts on this, feel free to chime in.
In any case, I'm not sure I agree with having the default ordering you suggested – "--" for em-dash and "---" for en-dash seems counter intuitive, since "---" would then produce a shorter dash than "--". Also, in some locales (like Denmark), we use en-dashes almost exclusively, with spaces around them – like this :)
#6
@mikl: Thanks for taking the time to respond. I'm certainly interested to see how the new branch will proceed.
Regarding the ordering of em- and en-dashes, I agree that two dashes (--) for em and three (---) for en is counterintuitive, but the history of American (and perhaps Canadian, British, and Australian?) publishing is to blame. Traditionally, news writers used two dashes (--) to indicate an em-dash and didn't use the en-dash at all. This led to more modern problems like Microsoft Word's "autocorrecting" of two dashes to an em-dash. Therefore, from an American (and Canadian/British/Australian?) perspective, two dashes equals an em-dash. Even the common usage on Drupal.org reflects the two-dash-equals-em-dash paradigm.
So the problem is: How do we create an en-dash when the two-dash convention is taken? The counter-intuitive convention of three dashes seems the least worst solution. I don't like it either, but this is how things have evolved.
That said, this is largely an American (and Canadian/British/Australian?) problem. I did not know, for example, that Denmark uses en-dashes more than ems. Drupal is an international CMS and should reflect international conventions. Therefore, I'll happily leave the ordering question for you to solve, as I am naturally biased towards American and English-speaking conventions.
PS. The "spaces around dashes" issue is also contentious in the States. Depending on which publishing style guide one follows -- say, AP or Chicago style -- em-dashes may or may not be surrounded with spaces. I prefer them with spaces.
#7
Alright, I ended up going along with your suggestions. triple-hypen for en-dash is now the second option and the default. I've also made an update hook, since we're juggling the numbers for the hyphen options.
I've tagged this and a few minor fixes into DRUPAL-6--1-0-BETA5, so there should be an updated tarball in a few hours.
All that remains is to port this to D5. I don't really have any D5 sites anymore, but I suppose I can un-mothball one for this exercise :)
#8
Backported to Drupal 5, going out in RC1.
#9
Automatically closed -- issue fixed for 2 weeks with no activity.