OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] Proposal 13031: Add Line-Through

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Tuesday, 2011 July 26 11:15
> To: dita
> Subject: [dita] Proposal 13031: Add Line-Through
> Here are some use cases that I've run into:
> - Legal documents showing revisions where the revisions are not marked
> using
> @rev.,
> - More generally, in a data conversion context where the DITA encoding
> of
> the document is not itself being revised, but the content as captured
> in
> DITA needs to reflect strikethrough used for an unknowable purpose (at
> least
> as far as the agent doing the conversion is concerned).
> - Discourse where line-through is used for rhetorical effect.
> - Informal documents, such as business documents, where the overhead
> using full revision markup just to get strikethrough is prohibitive
> particular, the need to configure and use some form of DITAVAL
> facility).

I agree with adding strikethrough (by whatever name) to the highlight

> Other potential additions to highlight, as distinct from a separate
> "formatting" domain as represented in DITA for Publishers, include:
> - overline (as a complement to underline and line-through)
> - blink (obviously only useful for online presentations).

I think we need to be a bit cautious here.  I heard Don mention ebooks
as one of the user requirements, and I certainly appreciate that.

See http://idpf.org/epub/20/spec/OPS_2.0.1_draft.htm#Section3.3
to determine what CSS properties are allowed by the "ebook" spec
(though not all ebook viewers support all of them).  The supported
text-decoration values include line-through and underline, but do
not include overline or blink.  (In fact, the CSS spec says that
conforming user agents can ignore blink.)

Some testing indicates that overline is supported by iPad and
Adobe Digital Editions and a few ebook simulators, so I'm assuming 
it may have enough support to include, but I have found no such
support for blink in the ebook readers to which I have access,
so I would not want to include it.

> My reasoning for not suggesting more additions to highlight and thus
> having
> a separate, more expansive formatting domain, is to make it as easy as
> possible to not allow formatting requests that most, if not all,
> technical
> documentation users would absolutely not want.

I agree with not adding much more to the highlight domain.

> A separate formatting domain that essentially includes anything that
> any
> likely rendition target might support, then provides the option of
> allowing
> more where more is appropriate, as it is in most publishing contexts,
> where
> arbitrary, distinctive, and idiosyncratic formatting is the order of
> the day.

I will withhold judgement on this whole idea, not because I'm a purist
about format related markup, but because this may be getting too
far into the domain of the stylesheet which I do not think we should
be standarizing.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]