← Prev in month
← Prev in 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