Feature request: Semantic italics/spans

[noteon]

As accessibility standards become more pressing, I find myself having to change <i> to <em> or <cite> a lot more often, or to apply one of those where there currently isn't anything. We're also having to create spans with language tags when there's a second language in the ebook.

It's all on a word-by-word basis, per editorial judgment, so there's no way to do it with global operations. Is there a way the formatting bar at upper left (B I U ...) could be made to help with any of this?

Thank you!

[Doitsu]

You could use the clip bar for this. I explained how to do this in this old post.

[JSWolf]

Originally Posted by noteon

As accessibility standards become more pressing, I find myself having to change <i> to <em> or <cite> a lot more often, or to apply one of those where there currently isn't anything. We're also having to create spans with language tags when there's a second language in the ebook.

It's all on a word-by-word basis, per editorial judgment, so there's no way to do it with global operations. Is there a way the formatting bar at upper left (B I U ...) could be made to help with any of this?

Thank you!

If you are changing <i>, just add in <i> and you can search/replace the <i> to <em> or <span>.

As for <cite>, you could use <u> for that and then the the search/replace.

[noteon]

Originally Posted by Doitsu

You could use the clip bar for this. I explained how to do this in this old post.

Hey, look at that! Thank you.

[DNSB]

Jon, I think the problem is that the ePub he is editing used only <i> or <em> and they now need to use <i> for visual, <em> for emphasis and <cite> for citations, all of which render as italic by default.

I've done that dance a couple of times and it required a good chunk of manual effort since there other than some of the citations where I could do some automation, it required the mark one eyeball to distinguish which was needed. The actual typing of <em> or <cite> was not the issue as that was done using the clip bar.

[noteon]

If I want to start with

<i.*?>(.+?)</i>

and end up with

<em>\1</em>

is there a way to do it with the clip bar? Or do I need to end up with

<i><em>\1</em></i>

And then globally search/replace to get the <i> tags out of there?

[DNSB]

Your second example is what I used. It was quick and dirty which is what I was looking for. so the replacement string would be <i><em>\1</em></i> or <i><cite>\1</cite><i> and then global search/replace.

[DiapDealer]

Use my TagEditor plugin for bulk changing from one tag to another. Especially if the possibility of nested tags is real. That's specifically why I made it. You can drill down on matches from all naked tags (no attributes), to specific values for specific attributes, to matching the whole attribute string using regex. You can also choose to maintain the existing attribute string or modify it (or eliminate it).

[DNSB]

I was not aware of the existence of a TagEditor plugin. If this was a reference to TagMechanic, given the OP needs to choose which <i> tags stay as <i> or change to <em> or <cite>, I was not aware that TagMechanic could do more than a wholesale change.

[KevinH]

I typically use regular expression search to capture all i tags and then use the new replacement table find and replace tool the with a large context set. I can use a quick delete of table rows where I do not want the replacements to be made.

But using the clips bar and stepping through the searches one by one works to replace only where needed works too.

[DiapDealer]

Originally Posted by DNSB

I was not aware of the existence of a TagEditor plugin. If this was a reference to TagMechanic, given the OP needs to choose which <i> tags stay as <i> or change to <em> or <cite>, I was not aware that TagMechanic could do more than a wholesale change.

If there's no named attributes that can determine which i tags should stay as i tags, then yes, TagMechanic probably won't help much. But it's certainly possible to do less than a wholesale change with TagMechanic when the attribute strings--like the class name--offer delineating criteria.The plugin can operate on only naked tags (no attributes), or only on tags with particular attribute values, or only on tags whose attribute strings match a particular regexp. It's not a blunt, whammy-all-or-nothing instrument (though it certainly can be used that way too).

[DNSB]

What I meant was that when all the tags I'm interested are currently naked <i> tags or <i> tags with identical classes, TagMechanic does not allow to me step though one at time so I can decide if <i>, <em> or <cite> is the correct replacement. I ended searching for <i> and selecting the replacement which allowed the mark one eyeball to be used to make the choice. I considered this the price to pay for adding semantics after the fact.

[DiapDealer]

That is correct. TagMechanic won't let you step through and approve each replacement. But like Kevin, I find the new table-based replacement tool much more pleasant to use when deciding which--of many--possible replacements to skip.

[DiapDealer]

Originally Posted by DiapDealer

That is correct. TagMechanic won't let you step through and approve each replacement. But like Kevin, I find the new table-based replacement tool much more pleasant to use when deciding which--of many--possible replacements to skip.

Just in case any are unclear on this: that's holding the shift key down while clicking the Replace All button. That brings up a table of results that you can then choose (individually or in multiples ) to skip. Used in conjunction with the "Dry Run" feature (shift+count all button), it makes things a lot less menial and repetitive (for me anyway). As Kevin already mentioned, you can increase the context included before and after each instance to help decide what stays and what goes.

[DNSB]

And it has been a very handy feature for me on multiple occasions though I often use it on current or selected files just to keep the number of search results manageable.