← Prev in month ← Prev in thread

Class values in markdown and HTML

From
Michael Priestley <>
Date
2019-04-26T20:46:58+00:00
ID
Thread
Class values in markdown and HTML
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
← Prev in month ← Prev in thread