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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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

Subject: Re: DOCBOOK: Issues with processing expectations of the proposedannotation element

Paul Grosso <pgrosso@arbortext.com> writes:

> 5.  If the contents of the annotation element can include complex
> substructure (e.g., tables and lists), how can it be of use for the 
> HTML title attribute?  I think we should give up on hoping we can use
> this annotation element for HTML title attributes.

I'm willing to give up on it and maybe have the processing-
expectations documentation for Annotation include a statement like:
  Processing applications should not be expected to convert contents
  of Annotation elements to any form that is restricted to plain text
  in rendered output, such as the contents of HTML title attributes.

But it seems like we'd need to also recognize that'd mean giving up on
having *any* element at all to use for HTML title attributes, because
my guess is that none of us would want an additional for-HTML-titles
only element whose content was restricted to character data.

I hesitate to say this, but it seems like the best way to have
something to use for HTML title attributes would be to add a new
global common attribute -- an annotation attribute -- in addition to
an annotation element (if we decide to add one), not in place of it.

We've had an open RFE for a while now -- RFE 522552, "Add title
attribute to element":


The text of that RFE requests a new attribute specifically for
annotations on Ulinks, to generate title attributes on HTML
hyperlinks. But it seems like if we were to decide to do that, the new
attribute should just be made a common attribute -- I think the HTML
title attribute is valid on any element that can appear in the body of
an HTML page, so things like <p> and <span> can have titles also.

I think personally that an attribute is a far-less-than-ideal place to
put annotative text -- I like the rule of trying to keep attribute
contents restricted just to stuff to be read by machines/processing
appls, element contents for humans. But this would be a practical
solution to the need to create annotations whose contents wouldn't
need to be stripped of markup before being converted to HTML titles.


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

Powered by eList eXpress LLC