|Michael (and all),|
Oh but autonomous custom elements look sooo good.
I agree: customized built-in elements could work. If anything, they look less complicate than the original HDITA data attributes (did we give up on those?), which my students did not find very difficult to use.
We could try a complete-ish HDITA mapping in built-in elements and see how it looks and what creates conflict.
Your examples in this message, by the way, remind me of a question I was saving for the future. Whenever I show Lightweight DITA examples to people (MDITA, HDITA, XDITA), more than once they have asked about “steps-informal.” For someone who has never seen/used DITA XML, steps informal sounds strange because they have never seen steps. I see that you are using “simple-steps” here, which sounds better and friendlier than steps-informal.
Is this a change in our Lightweight DITA plans? If so, I like it…
Carlos Evia, Ph.D.
Director of Professional and Technical Writing
Associate Professor of Technical Communication
Department of English
Center for Human-Computer Interaction
Blacksburg, VA 24061-0112
I talked a bit more about it with Don,
and this is where my thinking is right now, based on the descriptions of
custom elements here:https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks- our two main alternatives are autonomous
custom elements, which we could give custom element names to- or customized built-in elements, which
would retain the name of an existing HTML element plus the "is"
attribute giving a custom element nameExample for autonomous custom elements:<simple-steps> <simple-step>...</simple-step></simple-steps>Pros: - they have easily understandable semantic
names- they look like XML, and can more closely
mimic XML specializationsCons:- nothing will happen remotely resembling
fallback processing (like rendering these as an ordered list) without a
sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacksExample for customized built-in elements<ol is="simple-steps"> <li
is="simple-step">...</li></ol>Pros:- they process automatically as list
as special nodes, for extra behavior, but you only need to identify the
delta stuffCons:- looks less like XMLNetMy clear preference is now for customized
built-in elements, given the warnings of the spec against using autonomous
custom elements when extending an existing element type.But the open question for me is whether
the "is" attribute can take multiple values. If it can, it could
map really cleanly to specializations. Even the requirement for hyphenation
in the element name could be a mirror for the "/" in the XML
class attribute.Otherwise we'd be looking again at limiting
ourselves to one level of specialization, which may still be on the page
anyway - nobody has said they want it yet.So... does anyone have a contact on
the Web Platform Working Group? I couldn't find a simple answer to my question
anywhere, including here:https://lists.w3.org/Archives/Public/public-webapps/If no one else has a contact I'll poke
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist