W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2014

Re: Definitions, references, and tooltips

From: Shane McCarron <shane@aptest.com>
Date: Tue, 11 Nov 2014 12:13:13 -0600
Message-ID: <CAOk_reFV+ONufX8uK5cscNaYe7V_yxmdwrgyp=exS0h8oF4GpQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Tobie Langel <tobie.langel@gmail.com>, "spec-prod@w3.org Prod" <spec-prod@w3.org>
Yes - I am aware of what Bikeshed uses as its source form.  In the case of
ReSpec, I am more inclined to use the Bikeshed "output" form of the
attributes as the source form.  I could be persuaded to change my mind.

Here is what I have implemented so far:

   - title works as it always did in ReSpec for backward compatibility.  If
   there is a title attribute, it defines the linking text that can be used to
   reference the definition.  In the output data-title is supplied as well.
   - data-title works as it does in Bikeshed.  You can define aliases.
   Using any of these will result in a reference to the defintiion.  It is
   retained in the output.
   - data-local-title works as it does in Bikeshed.  It is NOT retained in
   the output.
   - export and noexport work as in Bikeshed.  In the output these are
   captured as data-export and data-noexport.
   - data-dfn-type can be used to specify the scope of a definition (it's
   type).  I did not do anything with data-dfn-for.  Frankly I am confused
   about when you would use which of these.

During processing ReSpec builds up a collection of defined terms.  It also
keeps track of what should be 'exported'.  At some point I plan on allowing
ReSpec to connect to an end point to push the exported terms.  For now it
is sitting there, waiting.

The upshot of this is that, once I check it in and get it reviewed, ReSpec
users will be able to use aliases for definitions within the current
document.  And, once I completely understand what Shepherd expects, it
should be able to scrape the static versions of ReSpec documents and
incorporate the exported references into that database.

On Tuesday, November 11, 2014, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Nov 11, 2014 at 6:18 AM, Shane McCarron <shane@aptest.com
> <javascript:;>> wrote:
> > I realized this thread got sort of off topic.  What I was really trying
> to
> > determine was if anyone wanted ReSpec to continue to leave the 'title'
> > attribute on dfn elements.  Here is what I have decided:
> >
> > For legacy purposes, title will continue to work as it always has in
> ReSpec.
> > It influences the way that the definition is referenced, and is left in
> > place to act as a tooltip.
> >
> > ReSpec will also support data-dfn-title (or whatever Bikeshed actually
> uses)
> > as a way of naming the way the definition can be referenced.  This will
> > support the Bikeshed syntax that includes 'aliases' for the definition.
> Bikeshed just uses "title".  It also has a "local-title" attribute in
> its source format (translated to "data-local-title" in its output)
> which gives "local" linking text which is only usable from within the
> spec, and is never exported into the autolinking database.  (This is
> used when you want to use a short term to ref something, but it's too
> generic for general use, so you don't want to pollute the linking
> database.)
> > I will also add support for the related data-dfn attributes to ReSpec so
> > that you can scope your terms, mark them for export or not, and have
> local
> > aliases.
> Cool.
> ~TJ

Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
Received on Tuesday, 11 November 2014 18:13:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:20 UTC