dita-lightweight-dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Class values in markdown and HTML
- From: "Michael Priestley" <mpriestl@ca.ibm.com>
- To: dita-lightweight-dita@lists.oasis-open.org
- Date: Fri, 26 Apr 2019 16:46:53 -0400
I went back and looked at the actual limits
on class values in HTML5, and they're pretty restrictive:
https://www.w3schools.com/tags/att_global_class.asp
To summarize:
- Must begin with a letter A-Z or a-z
- Can be followed by: letters (A-Za-z),
digits (0-9), hyphens ("-"), and underscores ("_")
- Multiple values separated by spaces
So just copying over the XML syntax
won't be valid, as I read it. It might work, in a forgiving browser, but
it wouldn't be valid (slashes, +/1 signs...)
So then: what's the minimum information
we need to have?
- the specialized element name
- ancestor element names, if there's
a possibility of multiple levels, and rules we want to fire on an element
based on ancestry
- a token to distinguish DITA class
values from others
So we might get something like:
/start of proposal
XDITA specialization:
<prologtitle class="- topic/title
mybook/prologtitle" outputclass="intro important">Header
1</prolog-title>
HDITA specialization:
<h1 class="intro important dita-prologtitle">Header
1</h1>
MDITA specialization:
# Header 1
{: .intro .important .dita-prologtitle}
If the prologtitle element I just invented
had an intermediate ancestor (let's say chaptertitle, instead of being
specialized directly from topic title), that could be expressed as another
"dita-" value:
XDITA:
<prologtitle class="- topic/title thisbook/chaptertitle mybook/prologtitle"
outputclass="intro important">Header 1</prolog-title>
HDITA:
<h1 class="intro important dita-chaptertitle dita-prologtitle">Header
1</h1>
MDITA:
# Header 1
{: .intro .important .dita-chaptertitle .dita-prologtitle}
The sequence of the dita- values (ignoring
any values that don't start with dita- ) gives us the specialization hierarchy
for the element, except for the base element (topic/title), which we get
from the HTML element name <h1> and the base-level mappings from
<h1> to <title>.
/end of proposal
So what are we losing?
We don't know if it's a domain or a
structural specialization, but do we care? That's only really useful for
full generalization rules.
We're also losing the module name part
of the specialization token - eg if prologtitle is specialized as part
of a mybook specialization, the token in XML would be mybook/prologtitle.
But I'm thinking the module name (the structural or domain specialization
label) is really only useful to prevent a naming collision if there's two
elements with the same name that somehow end up in the same document. That's
an extreme edge case at this point, and I don't think it's worth adding
complexity to the syntax in markdown and HTML5, especially since the /
isn't allowed and we'd need to use a hyphen or underscore.
So if people want to do full generalization,
they'd need to transform the document to an XML flavour first, and have
a DTD defined for it there that provided the appropriate specialization
syntax in defaulted attributes, the good old fashioned DITA way.
For simple generalization (like during
a conref pulling mybook/prologtitle into thisbook/chaptertitle), you'd
just compare the tokens and their sequence without the module names - in
other words an HDITA, Markdown, or XDITA specialized element "chaptertitle"
could pull in an HDITA or Markdown,specialized element "prologtitle"
because it has "dita-chaptertitle" as a value in its class
attribute, and we know it's an ancestor value because it's not the rightmost
"dita-" value in the attribute.
Michael Priestley, Senior Technical Staff Member (STSM)
Product Owner, Content AI and Classification Systems, IBM Marketing/IBM
Digital
mpriestl@ca.ibm.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]