OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] With multimedia coming, what happens to the object element?


I had forgotten that the audio- and video-specific attributes are not part of the HTML object element, but of course that makes sense.

So Robert is correct--modifying <object> wouldn't really help and we can't really add attributes to <audio> and <video> if they are specializations of <object>

So that seems to argue strongly for them being base elements in DITA 2.0 *if* we want the convenience of attributes and a closer alignment to HTML5, both of which seem like good things.

Cheers,

E. 

--
Eliot Kimber
http://contrext.com
 

ïOn 8/5/19, 1:06 PM, "Robert D Anderson" <robander@us.ibm.com> wrote:

    Our current definition of the object element is a near-match for the object element as defined (15 years ago) in HTML.
    
    Looking at the latest HTML5 recommendation, it looks like object has not changed much - it's added some attributes we might want to consider, but is otherwise about the same, with the same attributes / nested param elements. If we are changing object around, I think we'd probably just want to modify it so that it more closely matches the latest HTML5 version.
    
    I don't think it really makes sense to add the audio/video attributes to object just to enable easier specialization of audio/video, unless those same attributes are also valid on the latest HTML5 object element. Otherwise we're overloading object with stuff that only makes sense for two specialized elements, at which point I'd be more inclined to treat them as base elements and let object do its own thing.
    Robert D. Anderson
    DITA-OT <https://dita-ot.org/> lead and Co-editor DITA 1.3 specification
    Marketing Services Center________________________________________
    E-mail: robander@us.ibm.com
    
    11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA
    
    
    
    Eliot Kimber ---08/05/2019 09:26:25 AM---I think keeping <object> in the base is a given. But for 2.0 it could make sense for <object> to mov
    
    From:        Eliot Kimber <ekimber@contrext.com>
    To:        Michael Priestley <mpriestl@ca.ibm.com>, Chris Nitchie <chris.nitchie@oberontech.com>
    Cc:        Alan Houser <arh@groupwellesley.com>, Carlos Evia <cevia@vt.edu>, "ligh >> dita-lightweight-dita@lists.oasis-open.org" <dita@lists.oasis-open.org>, Robert D Anderson <robander@us.ibm.com>
    Date:        08/05/2019 09:26 AM
    Subject:        [EXTERNAL] Re: [dita] With multimedia coming, what happens to the object element?
    
    ________________________________________
    
    
    
    I think keeping <object> in the base is a given.
    
    But for 2.0 it could make sense for <object> to move to attributes things that are attributes in HTML5 and are on subelements today. That would then allow <audio> and <video> to do the same but as proper specializations of <object>.
    
    I've certainly had clients in the past who used <object> (or specializations of it) for things like custom browser plugins, back when that was a thing people did.
    
    The Web world has definitely evolved to a place where audio and video are the primary embedded media types with other things being handled in the browser using JavasScript and canvas rather than plug-ins, so the need for <object> is definitely lower but it's still needed, as others have pointed out.
    
    Cheers,
    
    E.
    
    
    --
    Eliot Kimber
    http://contrext.com 
     
    
    ïOn 8/5/19, 9:15 AM, "Michael Priestley" <dita@lists.oasis-open.org on behalf of mpriestl@ca.ibm.com> wrote:
    
        I think the first
        question is: do we keep object? If we don't then it forces a rebasing discussion,
        if we don't then it changes the question.
        
        I think it does
        make sense to keep object available in full DITA, just like it's still
        available in HTML5. It handles more cases than audio and video, and the
        description would need to be changed to reflect that.
        
        If we do keep
        object then the question changes to: what is the value of making audio/video
        peers rather than specializations? What are the specialization limitations
        we're currently encountering, and are there other ways we could address
        them, other than ditching object as a parent?
        
        Michael Priestley, Senior Technical Staff Member (STSM)
        Taxonomy Specialist, Marketing Analytics
        mpriestl@ca.ibm.com
        
        
        
        From:
               Chris
        Nitchie <chris.nitchie@oberontech.com>
        To:
               Carlos
        Evia <cevia@vt.edu>
        Cc:
               Robert
        D Anderson <robander@us.ibm.com>, Alan Houser <arh@groupwellesley.com>,
        "ligh >> dita-lightweight-dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
        Date:
               2019/08/04
        02:00 PM
        Subject:
               [EXTERNAL]
        Re: [dita] With multimedia coming, what happens to the object element?
        Sent
        by:        <dita@lists.oasis-open.org>
        ________________________________________
        
        
        
        If we have no 1.3 domain, then LwDITA
        will not be interoperable with DITA 1.3. If itâs different between 1.3
        and 2.0 itâll involve migration costs. The genesis of all this was the
        desire to make LwDITA interoperable with official, TC-provided DITA 1.3.
        
        Best, 
        
        Chris
        
        On Aug 4, 2019, at 1:24 PM, Carlos Evia <cevia@vt.edu>
        wrote:
        
        This is an interesting and scary conversation.
        Scary particularly for me:
        If we redesign the multimedia domain
        to be 2.0 compatible and look more like HTML5 (with properties as attributes
        instead of elements), the LwDITA committee note and my book on LwDITA will
        be obsolete/inaccurate. However, I wonder if that is the right thing to
        do if there isn't a real need for a 1.3-compatible multimedia domain.
        So... the question is: with the LwDITA
        spec not really being released months/years before 2.0, do we need a 1.3-compatible
        multimedia domain to make LwDITA 1.3-compliant? Should we just aim for
        LwDITA-2.0 congruence?
        If we need a small taskforce to explore
        what a new multimedia domain would look like if we don't need 1.3 compatibility,
        count me in.
        
        Carlos
        
        -- 
        Carlos Evia, Ph.D.
        Associate Professor of Communication
        Virginia Tech
        Blacksburg, VA 24061-0112
        (540)200-8201
        
        
        
        On Sat, Aug 3, 2019 at 7:55 PM Robert
        D Anderson <robander@us.ibm.com>
        wrote:
        Thanks Alan.
        
        About this:
        > I experienced whiplash
        when I learned that the review target was DITA 2.0, not the DITA 1.3 multimedia
        domain that we had long planned. But if 2.0 is the target, ...
        
        The original goal for this markup was definitely a DITA 1.3 compatible
        domain that would 1) be usable by LwDITA, and 2) carry forward more or
        less unchanged into DITA 2.0. LwDITA was the driver behind that -- having
        a 1.3 compatible domain is of course a nice thing to have, but the domain
        design was driven by the desire to have a LwDITA that is compatible with
        DITA 1.3 and (ideally) DITA 2.0.
        
        If we make them base elements, then it's of course still possible to write
        a DITA 1.3 domain using the current model, but audio/video content marked
        up using that domain would need to be migrated before it could become DITA
        2.0. 
        
        All of this is why I was a little hesitant to raise the idea...
        Robert
        D. Anderson
        DITA-OT <https://dita-ot.org/ >lead and Co-editor DITA 1.3 specification
        Marketing Services Center________________________________________
        E-mail:robander@us.ibm.com
        
        11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA<15838691.gif>
        
        
        
        <graycol.gif>Alan
        Houser ---08/02/2019 05:50:14 PM---Thanks, Robert ... good observations
        and comments. I experienced whiplash when I learned that the re
        
        From: Alan Houser <arh@groupwellesley.com>
        To: dita@lists.oasis-open.org
        Date: 08/02/2019 05:50 PM
        Subject: [EXTERNAL] Re: [dita] With
        multimedia coming, what happens to the object element?
        Sent by: <dita@lists.oasis-open.org>
        ________________________________________
        
        
        
        Thanks, Robert ... good observations and comments. 
        I experienced whiplash when I learned
        that the review target was DITA 2.0, not the DITA 1.3 multimedia domain
        that we had long planned. But if 2.0 is the target, I don't believe we
        would have designed the multimedia support in the way that we did. Using
        child elements to specify properties makes the vocabulary much more verbose
        than otherwise (9 element types instead of 2), and is especially awkward
        for Lightweight DITA. 
        I like the idea of adding audio and video
        to the DITA 2.0 base. I would favor defining attributes to specify properties,
        as does HTML5. 
        We can still release a DITA 1.3 multimedia
        domain as currently designed, if it's the will of the TC to do so. 
        I'll note that this approach would have
        ramifications for Lightweight DITA, which I have barely begun to think
        through. 
        -Alan 
        On 8/2/19 4:52 PM, Robert D Anderson
        wrote: 
        Keith had a fascinating comment in the
        multi-media review that got me thinking - does the presence of audio and
        video supersede the need for the object element?
        
        My gut reaction was - maybe so, but only if we make audio/video part of
        the base vocabulary (they can't be based on object and still mean object
        is unnecessary). But digging further, it's clear other uses are possible,
        so I don't think we can say the new elements supersede it. I've only used
        objects for audio/video, but here's a good HTML5 example of using the element
        to embed a PDF: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object 
        
        At a minimum, Keith's comment points out that we need to clean up our reference
        topic for <object> so that it no longer talks about audio/video.
        
        Beyond that, this comment -- and other chatter on the list during the review
        -- has me wondering about how much simpler things would be if audio/video
        were just base elements, rather than specializations of object. I know
        why we didn't consider that initially, and I probably risk the wrath of
        Kris or Chris in asking, but I wonder if at this point it's worth reconsidering?
        It would give us more flexibility in the definition to address some of
        the review comments that have come in. The down side is that it would rule
        out a backwards-compatible domain that works with DITA 1.3 and DITA 2.0.
        That said, the currently-defined domain markup would have a simple migration
        path into a DITA 2.0 model that uses base elements.
        
        I don't want to go too far down that path without more discussion though...Robert
        D. Anderson
        DITA-OT <https://dita-ot.org/ >lead and Co-editor DITA 1.3 specification
        Marketing Services Center________________________________________
        E-mail:robander@us.ibm.com
        
        11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA<15838691.gif>
        
        
        -- 
        Alan Houser
        Group Wellesley, Inc.
        Consultant and Trainer, Technical Publishing
        arh on Twitter
        412-450-0532 
        
        The content of this email and any attached
        files are intended for the recipient specified in this message only. It
        may contain information that is confidential, proprietary, privileged,
        and/or exempt from disclosure under applicable law. It is strictly forbidden
        to share any part of this message with any third party or rely on any of
        its contents, without the written consent of the sender. If you received
        this message by mistake, please reply to this message and follow with deletion
        of the original message, any copies and all attachments, so that Oberon
        Technologies can ensure such a mistake does not occur in the future. [attachment
        "15838691.gif" deleted by Michael Priestley/Toronto/IBM] [attachment
        "graycol.gif" deleted by Michael Priestley/Toronto/IBM] 
        
        
        
    
    
    
    
    
    
    




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]