Restrict conversion of emphasis

[stesk]

Not all instances of <em> and <strong> should be converted to emphasis markers in braille.

I suggest we use a class value such as "braille_emphasis" to select those elements which should be converted. I would prefer to do this in CSS, but maybe XSLT is required for some reason.

The braille specification requires a single marker (d56) to be inserted before and after an emphasised phrase, word or letter. The markers must be closely attached at either end, so no space after the initial marker or before the final marker. If an emphasised phrase starts and/or ends with punctuation, the punctuation must be included within the markers. There is no mention of nested emphasis, so I assume that only the outermost element should count.

Obviously there is a markup issue here. I will look into current practice regarding whitespace/emphasis markup.

[bertfrees]

Regarding the emphasized text with spaces: the way you explain it is the way it is implemented already. Are you getting unexpected results?

Nested emphasis is currently handled by nesting the opening and closing marks.

I would prefer to do this in CSS, but maybe XSLT is required for some reason.

You mean that you would rather not "hard-code" the translator to look at the "braille_emphasis" class, but instead have a certain CSS property to enable/disable emphasis that you could set any way you want?

with a class selector

.braille_emphasis {
  <some-css-to-enable>
}

but also with any other rule, e.g.:

h1 {
  <some-css-to-disable>
}

In order to do this we need a CSS property for it of course, which we don't have yet. I suggest something like text-transform: em.

[stesk]

No, I'm not getting unexpected results. Apart from the nested markers (which haven't appeared in any tests yet) your implementation is fine; it just can't be applied to actual production titles as they are currently marked up.

An XSLT solution is fine by me, but having it in CSS makes it much easier to customise. I was imagining something like this:

em.braille_emphasis::before, strong.braille_emphasis::before,
em.braille_emphasis::after, strong.braille_emphasis::after {
    content: '<marker>';
    display: inline;
}

em em.braille_emphasis::before, em strong.braille_emphasis::before,
strong em.braille_emphasis::before, strong em.braille_emphasis::before,
em em.braille_emphasis::after, em strong.braille_emphasis::after,
strong em.braille_emphasis::after, strong strong.braille_emphasis::after {
    display: none;
}

You could probably make it cleaner in various ways by using :not or something to avoid selecting nested elements. The important thing is that I don't need the class to be generic and applicable to all elements: it's a simple matter of inserting a specific character before specific inline elements unless they are nested. It would be nice to have the extended text-transform property, but that goes beyond our needs at this stage.

[bertfrees]

I'm not so fond of this approach. In my opinion emphasis is really something that concerns the translator. In Danish it is indeed a simple matter of inserting characters before and after, but you can't generalize that to other languages, and for that reason I think you also shouldn't treat it like something trivial. Besides, even in Danish it's not totally trivial, take for example the whitespace/emphasis thing you mentioned. There is no existing feature in CSS I know of that can handle this.

[stesk]

Since the class value will have to be set manually by someone who knows what they're doing, I would trust them to adjust whitespace as well. But you're right that it's not a good generic solution.

[bertfrees]

@stesk What about this one? What is the preferred approach?

• Support class "braille_emphasis" in XSLT
• Support some CSS property such as text-transform: em in XSLT
• Do what you proposed in CSS

[stesk]

@bertfrees I will have to look into it more. I suspect the CSS solution is good enough for our purposes, but the XSLT approach is probably best. It depends on the possible existence of edge cases where the CSS may be insufficient. Implementing a generic text-transform: em seems like the most time-consuming solution to me. However, we should not forget that this is a bonus feature compared to what we currently have. Let's not spend too much time on it.

[bertfrees]

OK we'll give it less priority. text-transform: em wouldn't be a generic thing. It would just be something that the Nota translator recognizes. It wouldn't be very time-consuming either.