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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-adoption message

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


Subject: RE: [dita-adoption] List of elements requiring styling




> -----Original Message-----
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Thursday, 2011 February 10 19:39
> To: dita-adoption@lists.oasis-open.org
> Subject: [dita-adoption] List of elements requiring styling
> 
> Hi everyone,
> I've done some thinking about how to move forward on this perpetual
> item:
> 
> ITEM: DITA 1.2 elements needing styling and translatable strings (Yeo)
> *       http://www.oasis-open.org/apps/org/workgroup/dita-
> adoption/email/archives/201008/msg00016.html
> 
> There are a few challenges in getting out an official document that
> lists all the elements needing styling:
> 
> 1) There is a need for a list like this for the 1.1  elements, as well
> as for the new elements.
> 
> 2) Most elements that are visible in output should be styled
> distinctively from other types of elements, or we wouldn't have
> invented them.

I'm not sure what it means for an element to be "visible in
output", but there could certainly be elements we invented
for its semantic meaning that don't necessarily need 
distinctive styling.

But more importantly, whether they get distinctive styling
and what that styling is should be a decision for the user
or document type designer, not us.  Styling is not something
we should be determining.

My understanding (though I'm still not sure I have a clear
one) of this issue is that some people think there are some
aspects of the presentation of some elements that need to be
explained to users rather then letting users decide how they
want to style things themselves.  Su-Laine's example in her
above quoted email is that <note="warning"> implies the need
for a new string which needs to be translated.  But I don't
see that.  Maybe I want warnings to be in red, or maybe I
want to collect all note="warning" elements into a sort of
appendix of warnings [probably not a smart move in the case
of warnings, but the point is that it's not up to us to say
how to style things].

So I remain unclear on what we're really trying to do and why,
and insofar as I understand it, I'm not sure I agree.

> 
> 3) Reviewers would need a thorough knowledge of all parts of the DITA
> vocabulary in order to properly review a full list of which elements
> should be styled distinctively.
> 
> I did some work on the draft page here:
> http://wiki.oasis-open.org/dita-
> adoption/DITA%201.2%20Elements%20which%20Need%20Styling#preview

I have a problem with all the "must be styled..." statements.
I didn't think DITA was a formatting standard, and I believe
that styling of DITA content is the purview of the application 
writers or end users, not OASIS.

I understand that some people want to make clear whether a user
should author a particular string (e.g., title) or not, but it's
the decision of the document type creator (the person tasked with
developing the stylesheet) what should be authored and what should
be generated, and it's their job to make clear to their users what
should be authored or not.  That's not something for us to decide
beyond what we've decided by virtue of what the DTD allows for a
given element.

> It occurred to me when writing it that the main issue that needs inter-
> organization consensus is the question of whether authors should write
> something to indicate the element semantic, or whether the stylesheet
> should make the semantic obvious enough that the author doesn't have to
> write anything to convey the semantic. E.g. if stylesheets don't style
> task <prereq> sections distinctively, then authors feels they must
> write "Prerequisites: " at the beginning of the element.
> 
> Question 1:
> 
> I think it would be reasonable for the Adoption TC to publish a short
> document covering this question as a general guideline for stylesheet
> developers. DITA TC subcommittees that deal with domain specific
> vocabulary sets could then, if and when they choose, create their own
> documents interpreting the guidelines for their own vocabulary sets.
> Does this sound reasonable?

If we could come up with guidelines of the form "the value of xxx
for the yyy attribute on element zzz is generally meant to be an 
indication that mmmmmmm" where mmmmmm is a semantic/operational
statement, not a statement about styling, then I think that would
be fine and useful.  (And as far as I can tell, that's exactly
what the DITA spec already says in the "Using type in a note element"
section at
http://docs.oasis-open.org/dita/v1.2/os/spec/common/thetypeattribute.html
so at least in this case, I don't see the need for anything.)

But insofar as we start making statements about styling, I have
problems.

By way of example, if we want to say that note/@type="warning" 
indicates that the note in question is a warning, fine, but if 
we want to say that such an element must be styled so that it 
generates the word "Warning" or even that it must be styled 
differently than note/@type="caution", then I don't agree.

> 
> Question 2:
> 
> As a proposal to get the discussion going, I suggest that our
> guidelines say that all elements should be styled distinctively-enough
> that the author does not have to write anything to convey the semantic.
> E.g. for the <prereq> element, stylesheets could insert generated text
> such as "Prerequisites." A set of stylesheets that styles <prereq>
> elements as if they are ordinary sections would not be in conformance
> with this guideline.

I don't think I can agree to that.

paul



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