Re: [dita-lightweight-dita] DITA and HTML5

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

        

      http://dita.xml.org/blog/michael-priestley

      

      

      

      From:      
         Carlos Evia
        <>

      To:      
         Michael
        Priestley/Toronto/IBM@IBMCA

      Cc:      
         

      Date:      
         06/26/2016 09:15 PM

      Subject:    
           Re:
        [dita-lightweight-dita]
        DITA and HTML5

      Sent by:    
           <>

      

      

      

      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 <>
        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