Lightweight DITA SC

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 name Example 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 specializations Cons: - nothing will happen remotely resembling fallback processing (like rendering these as an ordered list) without a bunch of _javascript_ - for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks Example for customized built-in elements <ol is="simple-steps">         <li is="simple-step">...</li> </ol> Pros: - they process automatically as list items - they can be registered using _javascript_ as special nodes, for extra behavior, but you only need to identify the delta stuff Cons: - looks less like XML Net My 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 around IBM. Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com

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 --  Carlos Evia, Ph.D. Director of Professional and Technical Writing Associate Professor of Technical Communication Department of English Center for Human-Computer Interaction Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 On Jun 26, 2016, at 8:56 PM, Michael Priestley < mpriestl@ca.ibm.com > wrote: 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 name Example 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 specializations Cons: - nothing will happen remotely resembling fallback processing (like rendering these as an ordered list) without a bunch of _javascript_ - for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks Example for customized built-in elements <ol is= simple-steps >         <li is= simple-step >...</li> </ol> Pros: - they process automatically as list items - they can be registered using _javascript_ as special nodes, for extra behavior, but you only need to identify the delta stuff Cons: - looks less like XML Net My 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 around IBM. Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com

Re simple-steps - I was just making up an example off the top of my head. I haven't really gone back to look at the original specializations we did for task/concept/reference since they're not part of the current scope - but we do need to at some point. The rationale for steps-informal was to use an element that already existed in full DITA, and was at the section level - that was important back in earlier iterations of Lightweight DITA because we had a specialization architecture built around reusable section specializations. But now we've gone away from that, so we've got some flexibility/choices to make. So - outside the spec, we can have a task specialization available as an example - how do we want to handle steps? - we could bring in <steps> from full DITA as-is - but that brings in a lot of extra elements and baggage. But it would be outside the spec, and if it's useful then why not - or we could bring in <steps> but simplified - we'd still need to have <cmd> in there, but we could ditch a bunch of the optional elements. - or we could base off <steps-informal> instead, but rename it to be friendlier - like <simple-steps> - but it would still need to be a specialization of section, not of <ol> like in my example Any thoughts? Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com http://dita.xml.org/blog/michael-priestley From:         Carlos Evia <cevia@vt.edu> To:         Michael Priestley/Toronto/IBM@IBMCA Cc:         dita-lightweight-dita@lists.oasis-open.org Date:         06/26/2016 09:15 PM Subject:         Re: [dita-lightweight-dita] DITA and HTML5 Sent by:         <dita-lightweight-dita@lists.oasis-open.org> 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 -- Carlos Evia, Ph.D. Director of Professional and Technical Writing Associate Professor of Technical Communication Department of English Center for Human-Computer Interaction Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 On Jun 26, 2016, at 8:56 PM, Michael Priestley < mpriestl@ca.ibm.com > wrote: 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 name Example 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 specializations Cons: - nothing will happen remotely resembling fallback processing (like rendering these as an ordered list) without a bunch of _javascript_ - for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks Example for customized built-in elements <ol is="simple-steps">        <li is="simple-step">...</li> </ol> Pros: - they process automatically as list items - they can be registered using _javascript_ as special nodes, for extra behavior, but you only need to identify the delta stuff Cons: - looks less like XML Net My 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 around IBM. Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com

I'd vote against renaming elements. Let's keep them the same as in full DITA. Renaming to be friendlier adds an unnecessary layer of complexity. Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 6/27/2016 10:36 AM, Michael Priestley wrote: Re simple-steps - I was just making up an example off the top of my head. I haven't really gone back to look at the original specializations we did for task/concept/reference since they're not part of the current scope - but we do need to at some point. The rationale for steps-informal was to use an element that already existed in full DITA, and was at the section level - that was important back in earlier iterations of Lightweight DITA because we had a specialization architecture built around reusable section specializations. But now we've gone away from that, so we've got some flexibility/choices to make. So - outside the spec, we can have a task specialization available as an example - how do we want to handle steps? - we could bring in <steps> from full DITA as-is - but that brings in a lot of extra elements and baggage. But it would be outside the spec, and if it's useful then why not - or we could bring in <steps> but simplified - we'd still need to have <cmd> in there, but we could ditch a bunch of the optional elements. - or we could base off <steps-informal> instead, but rename it to be friendlier - like <simple-steps> - but it would still need to be a specialization of section, not of <ol> like in my example Any thoughts? Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com http://dita.xml.org/blog/michael-priestley From:         Carlos Evia <cevia@vt.edu> To:         Michael Priestley/Toronto/IBM@IBMCA Cc:         dita-lightweight-dita@lists.oasis-open.org Date:         06/26/2016 09:15 PM Subject:         Re: [dita-lightweight-dita] DITA and HTML5 Sent by:         <dita-lightweight-dita@lists.oasis-open.org> 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 -- Carlos Evia, Ph.D. Director of Professional and Technical Writing Associate Professor of Technical Communication Department of English Center for Human-Computer Interaction Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 On Jun 26, 2016, at 8:56 PM, Michael Priestley < mpriestl@ca.ibm.com > wrote: 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 name Example 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 specializations Cons: - nothing will happen remotely resembling fallback processing (like rendering these as an ordered list) without a bunch of _javascript_ - for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks Example for customized built-in elements <ol is= simple-steps >        <li is= simple-step >...</li> </ol> Pros: - they process automatically as list items - they can be registered using _javascript_ as special nodes, for extra behavior, but you only need to identify the delta stuff Cons: - looks less like XML Net My 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 around IBM. Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com

Michael, On using the is= syntax to base your new element on an existing HTML element: <ol is= simple-steps > I am almost positive that you cannot put more than one value in the is= . I know a couple people who were on the web components committee, I can try to get a definitive answer. It's probably in the spec somewhere too. Mark Giffin Mark Giffin Consulting, Inc. http://markgiffin.com/ On 6/26/2016 5:56 PM, Michael Priestley wrote: 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 name Example 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 specializations Cons: - nothing will happen remotely resembling fallback processing (like rendering these as an ordered list) without a bunch of _javascript_ - for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks Example for customized built-in elements <ol is= simple-steps >         <li is= simple-step >...</li> </ol> Pros: - they process automatically as list items - they can be registered using _javascript_ as special nodes, for extra behavior, but you only need to identify the delta stuff Cons: - looks less like XML Net My 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 around IBM. Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com

I've seen several mentions that the is= construct is now deprecated, which goes to show how early this process still is. We might really need the input from people on the inner circle if we go further with using webcomponents. -- Don On 6/27/2016 12:39 AM, Mark Giffin wrote: Michael, On using the is= syntax to base your new element on an existing HTML element: <ol is= simple-steps > I am almost positive that you cannot put more than one value in the is= . I know a couple people who were on the web components committee, I can try to get a definitive answer. It's probably in the spec somewhere too. Mark Giffin Mark Giffin Consulting, Inc. http://markgiffin.com/ On 6/26/2016 5:56 PM, Michael Priestley wrote: 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 name Example 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 specializations Cons: - nothing will happen remotely resembling fallback processing (like rendering these as an ordered list) without a bunch of _javascript_ - for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks Example for customized built-in elements <ol is= simple-steps >         <li is= simple-step >...</li> </ol> Pros: - they process automatically as list items - they can be registered using _javascript_ as special nodes, for extra behavior, but you only need to identify the delta stuff Cons: - looks less like XML Net My 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 around IBM. Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com -- Don R. Day Founding Chair, OASIS DITA Technical Committee (current version: DITA 1.3 ) LinkedIn: donrday    Twitter: @donrday About.me: Don R. Day    Skype: don.r.day Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? --T.S. Eliot Virus-free. www.avast.com