[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [dita-lightweight-dita] Class values in markdown and HTML
|
Forwarding to the TC. This was discussed at the LwDITA
subcommittee meeting today, and it will be on tomorrow's agenda. Best,
Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 622-1501; kriseberlein (skype) -------- Forwarded Message --------
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:
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]