Re: [dita] Proposal 13011: Add line-through and overline to highlight domain

[Eliot Kimber <ekimber@rsicms.com>]

I will also echo what Paul Grosso said, which was that you quickly get into
the realm of style-driven formatting. I think the TC is clear that our goal
is not to remove the need for styling, but to simply make some very common
cases appropriately convenient.

If you really need something like "blink" or "none", you can use
@outputclass and CSS or simple FO extensions to get it, or define your own
vocabulary modules, as I did for D4P.

Cheers,

E.

On 9/30/12 11:55 AM, "Eliot Kimber" <ekimber@rsicms.com> wrote:

> I have posted this proposal, along with a working version of the hi-d DTD
> declarations.
> 
> I have implemented the minimum expression of the proposal. However,
> reviewing the email discussion, there are two possible enhancements:
> 
> 1. Add <blink>, so that DITA is complete with respect to CSS/XSL-FO
> text-decoration values (other than "none", but see (2)). I know there is
> serious distaste for blink as an effect and I have no love for it myself.
> But there is a completeness argument to be made.
> 
> 2. Provide some form of "format none" element, which would correspond to the
> text-decoration value "none". Nancy Harrison suggested this addition.
> 
> My main concern with "none" is be the potential utility and implementation
> complexity. You can always get the same effect by breaking a string into
> multiple sets of nested formatting elements, so at best it would count as a
> convenience.
> 
> I do have a requirement for a "turn formatting off" element in my Publishing
> work, and I have accommodated it through the <roman> element in the D4P
> formatting domain. The name "roman" makes sense to publishers but it's not
> really a good general name. The primary use case for Publishing is to get
> roman text in a context that is otherwise italic. It's a pretty weak
> solution to the general problem and I included it primarily as an expedient
> for going from Word and to InDesign.
> 
> In a more general context, there can be quite a bit of potential complexity
> in mapping a nested "no formatting" element into the correct rendition
> stuff, as not all output formatters have a direct way to represent it. That
> could lead to complex logic to convert a single set of nested formatting
> requests into sequences of formatting requests.
> 
> My instinct is to leave the "none" value of text-decoration unprovided for
> in the absence of a stronger argument for it.
> 
> On the other hand, there is also a completeness argument to be made for
> including the "none" text-decoration value as well.
> 
> Cheers,
> 
> Eliot
> 
> --
> Eliot Kimber
> Senior Solutions Architect, RSI Content Solutions
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.rsicms.com
> www.rsuitecms.com
> Book: DITA For Practitioners, from XML Press,
> http://xmlpress.net/publications/dita/practitioners-1/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dita-help@lists.oasis-open.org
> 

-- 
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/