[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] object name attribute
Hi Paul, Well, I don't have a use case for the name attribute. I wasn't around when the object element was added to DITA, so I guess I'm not clear on what purpose it serves. I presumed that since it was such a good match for the HTML object element that it was intended to support the production of such elements in HTML output. It did seem a bit unusual to have such an HTML-centric element in a markup language intended for multiple output formats. Perhaps someone with more history could explain the rationale for object. Is it there just to support Flash in the output? Are there any processing expectations for object when it is output to PDF and other non-HTML formats? Is it expected to be filtered out when generating non-HTML output? Bob Stayton Sagehill Enterprises DocBook Consulting bobs@sagehill.net ----- Original Message ----- From: "Paul Prescod" <paul.prescod@blastradius.com> To: "Bob Stayton" <bobs@sagehill.net>; "DITA TC" <dita@lists.oasis-open.org> Sent: Tuesday, March 28, 2006 12:39 PM Subject: RE: [dita] object name attribute > -----Original Message----- > From: Bob Stayton [mailto:bobs@sagehill.net] > Sent: Tuesday, March 28, 2006 11:41 AM > To: DITA TC > Subject: [dita] object name attribute > > I was asked during the TC telecon to describe why the name > attribute should continue to be supported on the DITA object > element. The object element in DITA is essentially a copy of > the object element in XHTML 1.0 Strict. I understand the > idea is to allow the creation of such objects in DITA for > passthrough. The name attribute on an HTML object is how it > is addressed in the DOM programming model, for example to > identify a component of a form. Of course, DITA does not > directly support HTML forms, but a stylesheet can generate a > form from a DITA document and include the DITA object in the > form for some purpose. So it is likely that if someone is > using object, they may be programming to access its name > attribute in the HTML. I disagree with the statement that it is "likely". I would bet that 99% of all object tags are used to include flash, SVG and other media formats, unrelated to a forms. Are there any examples of DITA XSLTs generating content-embedding forms (as opposed to boilerplate forms) out there? Do you have examples from the Docbook universe? I have a hard time envisioning a situation where the XSLT generates a whole form and the only thing it gets from the input XML is an object element. No buttons, no input fields, no radio buttons. Just an object. Everything else is auto-generated. > The id attribute is another way of addressing a particular > object, at least in the W3C DOM, but it cannot always replace > the name attribute. An id attribute must be unique within an > HTML document. The same HTML document could have several > form elements, each with their own submit buttons, and each > with identical object elements. All those object elements > may need to have the same name attribute because they serve > the same purpose in the program. Let's imagine that someone has a specialization called "SVG Review" that shows an SVG and generates a form. If the "name" attribute is predictable, then the XSLT that processes the specialization could add it. If it is unpredictable, then the ID attribute is probably appropriate. In addition, the name attribute could be added in the specialization (using DITA 1.1 features). > If the intent is to support XHTML objects in DITA, then I > believe all the attributes from the XHTML side must be > supported in the DITA object. I think that we should have a clear use-case in mind for every attribute we use in DITA. If XHTML needs it but DITA does not then we should dump it. If someone wants to add it in XSLT or specialization then they are welcome to. Even in the pure XHTML case, can you give some examples of forms that embed objects and describe how they are used? As long as we are going to have this debate, we should amortize our costs by dumping some other cruft: * tabindex - DITA has no notion of tab index. It makes no sense to manually set the tab index for a single element and leave the rest to XSLT. * usemap - DITA has no notion of image maps. Why should <object> have a usemap attribute when <image> doesn't. There are other attributes that are probably quite rarely used even in the HTML world, but I'll stop my war on cruft with those three. Paul Prescod
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]