Definitions, references, and tooltips

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Definitions, references, and tooltips

Shane McCarron
Question for the crowd:  ReSpec today allows you to define terms.  When you do, you can set a 'title' on the term as a way of telling the system what the real referencable term should be (e.g., <dfn title="screenshot">Screenshots</dfn> would define the term Screenshots, but you would reference it as screenshot).  In bikeshed you can also define aliases (e.g., <dfn title="screenshot|screenshots|something else">Screenshots</dfn> would define the term Screenshots, but you would reference it as screenshot, or screenshots, or 'something else').

Today if there is a 'title' attribute, then ReSpec leaves that on the dfn element, which in turn means it shows up as a tooltip when you are mousing around the generated document.  

Does anyone think this is a useful feature?  Or it just an accident?  I was thinking of removing the title attribute during generation - especially as we introduce the bikeshed syntax.

--
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Tab Atkins Jr.
On Sat, Nov 1, 2014 at 9:48 AM, Shane McCarron <[hidden email]> wrote:

> Question for the crowd:  ReSpec today allows you to define terms.  When you
> do, you can set a 'title' on the term as a way of telling the system what
> the real referencable term should be (e.g., <dfn
> title="screenshot">Screenshots</dfn> would define the term Screenshots, but
> you would reference it as screenshot).  In bikeshed you can also define
> aliases (e.g., <dfn title="screenshot|screenshots|something
> else">Screenshots</dfn> would define the term Screenshots, but you would
> reference it as screenshot, or screenshots, or 'something else').
>
> Today if there is a 'title' attribute, then ReSpec leaves that on the dfn
> element, which in turn means it shows up as a tooltip when you are mousing
> around the generated document.
>
> Does anyone think this is a useful feature?  Or it just an accident?  I was
> thinking of removing the title attribute during generation - especially as
> we introduce the bikeshed syntax.

You need to maintain the linking text in the generated document; it's
used by scrapers like Shepherd to build the cross-spec linking
database.  For ReSpec, the document looked at by scrapers is the
source doc, so feel free to remove from the post-JS document.

That said, I plan to have Bikeshed move away from using title as a
linking text source
<https://github.com/tabatkins/bikeshed/issues/230>, and use a `data-x`
attribute instead.  Using title in this way is an abuse, and makes it
impossible to provide useful tooltips.  (For example, Bikeshed
autolinks the CSS grammar combinators. I want the tooltip to summarize
their meaning, so you don't have to follow the link and read the
grammar specification most of the time.)

(Note as well that Bikeshed has significant support for English
conjugation in "dfn" type definitions, so you don't have to supply
plurals/possessives/etc as alternates unless it's an irregular form.)

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Shane McCarron
obviously we want shepherd to be able to scrape the respec source documents, so we want the syntax to be as similar as possible.  There are some things we just cannot do, like <<foo>> being detected as whatever type that is - because the browser would eat that before we got to it.  

I don't mind also supporting data-title or whatever.  Not sure we can ever remove support for title though (in the source document) because of backward compatibility.  

Other opinions?

On Sat, Nov 1, 2014 at 2:08 PM, Tab Atkins Jr. <[hidden email]> wrote:
On Sat, Nov 1, 2014 at 9:48 AM, Shane McCarron <[hidden email]> wrote:
> Question for the crowd:  ReSpec today allows you to define terms.  When you
> do, you can set a 'title' on the term as a way of telling the system what
> the real referencable term should be (e.g., <dfn
> title="screenshot">Screenshots</dfn> would define the term Screenshots, but
> you would reference it as screenshot).  In bikeshed you can also define
> aliases (e.g., <dfn title="screenshot|screenshots|something
> else">Screenshots</dfn> would define the term Screenshots, but you would
> reference it as screenshot, or screenshots, or 'something else').
>
> Today if there is a 'title' attribute, then ReSpec leaves that on the dfn
> element, which in turn means it shows up as a tooltip when you are mousing
> around the generated document.
>
> Does anyone think this is a useful feature?  Or it just an accident?  I was
> thinking of removing the title attribute during generation - especially as
> we introduce the bikeshed syntax.

You need to maintain the linking text in the generated document; it's
used by scrapers like Shepherd to build the cross-spec linking
database.  For ReSpec, the document looked at by scrapers is the
source doc, so feel free to remove from the post-JS document.

That said, I plan to have Bikeshed move away from using title as a
linking text source
<https://github.com/tabatkins/bikeshed/issues/230>, and use a `data-x`
attribute instead.  Using title in this way is an abuse, and makes it
impossible to provide useful tooltips.  (For example, Bikeshed
autolinks the CSS grammar combinators. I want the tooltip to summarize
their meaning, so you don't have to follow the link and read the
grammar specification most of the time.)

(Note as well that Bikeshed has significant support for English
conjugation in "dfn" type definitions, so you don't have to supply
plurals/possessives/etc as alternates unless it's an irregular form.)

~TJ



--
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Tab Atkins Jr.
On Sat, Nov 1, 2014 at 12:16 PM, Shane McCarron <[hidden email]> wrote:
> obviously we want shepherd to be able to scrape the respec source documents,
> so we want the syntax to be as similar as possible.  There are some things
> we just cannot do, like <<foo>> being detected as whatever type that is -
> because the browser would eat that before we got to it.

Sorry, you misunderstand.  All of the shorthand syntaxes - <<foo>> for
grammar nonterminals, {{Foo}} for IDL terms, etc - are transformed
into plain HTML before Shepherd sees them, because Shepherd only
scrapes the output documents, not the input.

I'm discussing this with you separately in
<https://github.com/tabatkins/bikeshed/issues/257>, so I'll leave
further discussion in this vein to that issue, where I've already gone
into more detail.

> I don't mind also supporting data-title or whatever.  Not sure we can ever
> remove support for title though (in the source document) because of backward
> compatibility.

Note that the local-title attribute (which is translated into
data-local-title in the output document) does something special: it
provides linking text that is only valid within that spec, and is not
exported to the global autolinking database.  This is useful when, for
example, you want to use a short, easy term to refer to something, but
it's too generic to reasonably use cross-spec.  You can provide a
normal linking text that has enough context in its name to be clear
and avoid collisions, while providing a "local" linking text that is
short and easy to type, and understandable because it has the context
of the surrounding spec to provide meaning.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Shane McCarron

No, I got that the shorthand syntaxes are expanded. And I understood the purpose of the local-title attribute. I will keep and other comments for the github discussion.

On Nov 1, 2014 2:50 PM, "Tab Atkins Jr." <[hidden email]> wrote:
On Sat, Nov 1, 2014 at 12:16 PM, Shane McCarron <[hidden email]> wrote:
> obviously we want shepherd to be able to scrape the respec source documents,
> so we want the syntax to be as similar as possible.  There are some things
> we just cannot do, like <<foo>> being detected as whatever type that is -
> because the browser would eat that before we got to it.

Sorry, you misunderstand.  All of the shorthand syntaxes - <<foo>> for
grammar nonterminals, {{Foo}} for IDL terms, etc - are transformed
into plain HTML before Shepherd sees them, because Shepherd only
scrapes the output documents, not the input.

I'm discussing this with you separately in
<https://github.com/tabatkins/bikeshed/issues/257>, so I'll leave
further discussion in this vein to that issue, where I've already gone
into more detail.

> I don't mind also supporting data-title or whatever.  Not sure we can ever
> remove support for title though (in the source document) because of backward
> compatibility.

Note that the local-title attribute (which is translated into
data-local-title in the output document) does something special: it
provides linking text that is only valid within that spec, and is not
exported to the global autolinking database.  This is useful when, for
example, you want to use a short, easy term to refer to something, but
it's too generic to reasonably use cross-spec.  You can provide a
normal linking text that has enough context in its name to be clear
and avoid collisions, while providing a "local" linking text that is
short and easy to type, and understandable because it has the context
of the surrounding spec to provide meaning.

~TJ
Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Tobie Langel-3
In reply to this post by Tab Atkins Jr.
> On Nov 1, 2014, at 20:09, "Tab Atkins Jr." <[hidden email]> wrote:
>
> For ReSpec, the document looked at by scrapers is the
> source doc, so feel free to remove from the post-JS document.

Actually, I'm also writing a scrapper right now, and I look at the
rendered output, not the raw one. So please don't do anything that
would prevent that.

--tobie

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Shane McCarron

To the extent possible. Obviously the rendered output should be valid. Or at least very close to valid.

On Nov 2, 2014 1:11 AM, "Tobie Langel" <[hidden email]> wrote:
> On Nov 1, 2014, at 20:09, "Tab Atkins Jr." <[hidden email]> wrote:
>
> For ReSpec, the document looked at by scrapers is the
> source doc, so feel free to remove from the post-JS document.

Actually, I'm also writing a scrapper right now, and I look at the
rendered output, not the raw one. So please don't do anything that
would prevent that.

--tobie
Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Tab Atkins Jr.
On Sun, Nov 2, 2014 at 3:05 AM, Shane McCarron <[hidden email]> wrote:

> On Nov 2, 2014 1:11 AM, "Tobie Langel" <[hidden email]> wrote:
>> > On Nov 1, 2014, at 20:09, "Tab Atkins Jr." <[hidden email]> wrote:
>> > For ReSpec, the document looked at by scrapers is the
>> > source doc, so feel free to remove from the post-JS document.
>>
>> Actually, I'm also writing a scrapper right now, and I look at the
>> rendered output, not the raw one. So please don't do anything that
>> would prevent that.
>
> To the extent possible. Obviously the rendered output should be valid. Or at
> least very close to valid.

Bikeshed's output is valid HTML, so if you just copy its output format
(which, per your request, I'm documenting), you'll be fine.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Shane McCarron
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.  

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.



On Sunday, November 2, 2014, Tab Atkins Jr. <[hidden email]> wrote:
On Sun, Nov 2, 2014 at 3:05 AM, Shane McCarron <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;shane@aptest.com&#39;)">shane@...> wrote:
> On Nov 2, 2014 1:11 AM, "Tobie Langel" <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;tobie.langel@gmail.com&#39;)">tobie.langel@...> wrote:
>> > On Nov 1, 2014, at 20:09, "Tab Atkins Jr." <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;jackalmage@gmail.com&#39;)">jackalmage@...> wrote:
>> > For ReSpec, the document looked at by scrapers is the
>> > source doc, so feel free to remove from the post-JS document.
>>
>> Actually, I'm also writing a scrapper right now, and I look at the
>> rendered output, not the raw one. So please don't do anything that
>> would prevent that.
>
> To the extent possible. Obviously the rendered output should be valid. Or at
> least very close to valid.

Bikeshed's output is valid HTML, so if you just copy its output format
(which, per your request, I'm documenting), you'll be fine.

~TJ


--
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Tab Atkins Jr.
On Tue, Nov 11, 2014 at 6:18 AM, Shane McCarron <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Shane McCarron
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. <[hidden email]> wrote:
On Tue, Nov 11, 2014 at 6:18 AM, Shane McCarron <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;shane@aptest.com&#39;)">shane@...> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Tab Atkins Jr.
On Tue, Nov 11, 2014 at 10:13 AM, Shane McCarron <[hidden email]> wrote:
> 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.

No, you misunderstand.  Bikeshed uses "title" in both its input and
output forms.  That's why I corrected you with "Bikeshed just uses
'title'.".

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

As noted, there's no such thing as "data-title".

> data-local-title works as it does in Bikeshed.  It is NOT retained in the
> output.

Sounds good.

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

Hmm, can you tell me what's unclear in the docs about this?  "type"
gives the definition's type - is it a property def, an interface def,
etc.  "for" gives another definition that namespaces the current
definition - there can be a lot of methods named "foo()", so you use
"for" to specify that this is the foo() method of the Bar interface,
like <dfn method for=Bar>foo()</dfn>.

That way autolinks can specify which foo() they want, like
{{Bar/foo()}} in the Bikeshed shorthand syntax (or <a method
for=Bar>foo()</a> in the longhand, or <a data-link-type=method
data-link-for=Bar>foo()</a> in the output syntax, which is also
accepted in the input format), and get pointed to the correct
definition.

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

Cool. I'll be writing the documentation today; I've been on vacation
for several days. ^_^

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Shane McCarron


On Tuesday, November 11, 2014, Tab Atkins Jr. <[hidden email]> wrote:
On Tue, Nov 11, 2014 at 10:13 AM, Shane McCarron <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;shane@aptest.com&#39;)">shane@...> wrote:
> 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.

No, you misunderstand.  Bikeshed uses "title" in both its input and
output forms.  That's why I corrected you with "Bikeshed just uses
'title'.".

Oh - I thought there was some additional tranform that happened for Shepherd.  Thanks
 


As noted, there's no such thing as "data-title".

Understood.  But using @title in this way in the OUTPUT form means that the resulting tooltip and potentially things like ARIA names could end up as something like 'foo|bar|bat', right?  That feels bad to me.  

 

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

Hmm, can you tell me what's unclear in the docs about this?  "type"
gives the definition's type - is it a property def, an interface def,
etc.  "for" gives another definition that namespaces the current
definition - there can be a lot of methods named "foo()", so you use
"for" to specify that this is the foo() method of the Bar interface,
like <dfn method for=Bar>foo()</dfn>.

I think it is phrases like "gives another definition that namespaces the current definition" that throws me.  Let me try to say it back.  If I have a definition 'foo' somewhere that is of type 'interface', I can say that the definition of 'bar' is of type 'method' and that it is a method "FOR" 'foo'.  What is unclear is how I say that it is "for" the 'foo' that is of type 'interface', as opposed to the 'foo' that is of type 'attribute' or something.  And yes, I get that it is possible to put the 'for' at a higher level so that all of the declared definitions within that level get automatically bound.  

How does this effect the generated IDs?  The pattern I was trying to use was something like 'dfn-TYPE-TERM'.  So in the example above I would have 'dfn-interface-foo' and 'dfn-method-bar'.  If the bar in question is actually "FOR" interface foo, then the generated ID should be something like 'dfn-interface-foo-method-bar'?  

Can this nest any further?  Can I have an interface that has methods that are FOR it, and then those methods have parameters that are FOR them?  E.g., dfn-interface-foo-method-bar-parameter-bat ?



Cool. I'll be writing the documentation today; I've been on vacation
for several days. ^_^


Great!  Thanks again.
 


--
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Tab Atkins Jr.
On Tue, Nov 11, 2014 at 11:32 AM, Shane McCarron <[hidden email]> wrote:
> On Tuesday, November 11, 2014, Tab Atkins Jr. <[hidden email]> wrote:
>> As noted, there's no such thing as "data-title".
>
> Understood.  But using @title in this way in the OUTPUT form means that the
> resulting tooltip and potentially things like ARIA names could end up as
> something like 'foo|bar|bat', right?  That feels bad to me.

Yes, it is bad, which is why I'm moving over to a different attribute
for linking text <https://github.com/tabatkins/bikeshed/issues/230>.
The use of "title" is a legacy thing from Bert's preprocessor; it's
sometimes good to have the tooltip display the linking text, when
you're providing something more explicit; it just gets bad when you
start using the microsyntax for multiple linking texts.

>> > 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.
>>
>> Hmm, can you tell me what's unclear in the docs about this?  "type"
>> gives the definition's type - is it a property def, an interface def,
>> etc.  "for" gives another definition that namespaces the current
>> definition - there can be a lot of methods named "foo()", so you use
>> "for" to specify that this is the foo() method of the Bar interface,
>> like <dfn method for=Bar>foo()</dfn>.
>
> I think it is phrases like "gives another definition that namespaces the
> current definition" that throws me.  Let me try to say it back.  If I have a
> definition 'foo' somewhere that is of type 'interface', I can say that the
> definition of 'bar' is of type 'method' and that it is a method "FOR" 'foo'.
> What is unclear is how I say that it is "for" the 'foo' that is of type
> 'interface', as opposed to the 'foo' that is of type 'attribute' or
> something.  And yes, I get that it is possible to put the 'for' at a higher
> level so that all of the declared definitions within that level get
> automatically bound.

Ah, so far there hasn't been any need to clarify the type of the "for"
reference.  Every dfn type either has a unique "for" type, or the
chance of a clash is small enough to be insignificant.  (An example of
the latter is the "value" type (for CSS values), which can be for a
"property" or a "type".  However, properties and types have completely
different syntaxes, so there's no chance of a clash.)

> How does this effect the generated IDs?  The pattern I was trying to use was
> something like 'dfn-TYPE-TERM'.  So in the example above I would have
> 'dfn-interface-foo' and 'dfn-method-bar'.  If the bar in question is
> actually "FOR" interface foo, then the generated ID should be something like
> 'dfn-interface-foo-method-bar'?

For the definition types that *require* a "for" value
<https://github.com/tabatkins/bikeshed/blob/master/bikeshed/config.py#L72>,
the auto-generated IDs do indeed include the for value in the ID, to
make clashes within a document less common.  For compat with a common
IDL id scheme, IDL things use a slightly different pattern as well.
All of the auto-generated ID code is at
<https://github.com/tabatkins/bikeshed/blob/master/bikeshed/__init__.py#L871>.
ID generation isn't actually important, though, unless you're
converting between spec preprocessors and want the IDs to be stable
without manually specifying them.

> Can this nest any further?  Can I have an interface that has methods that
> are FOR it, and then those methods have parameters that are FOR them?  E.g.,
> dfn-interface-foo-method-bar-parameter-bat ?

for values can indeed nest, and it does indeed show up in the auto-generated ID.

(I don't yet produce the transitive closure of for values, which is
something I need to fix eventually.  That way you'll be able to, say,
define that "foo" is a value dfn for "<bar>", and "<bar>" is a value
for the property 'baz', then ref "foo" as "baz/foo".)

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Definitions, references, and tooltips

Robin Berjon-6
In reply to this post by Shane McCarron
On 11/11/2014 19:13 , Shane McCarron wrote:
> 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.

As a rule of thumb I don't see the value in requiring people to type
data- prefixes in something that is a source document. It is meant to be
easy to edit, not to conform to anything. Making it valid is the
processor's job.

--
Robin Berjon - http://berjon.com/ - @robinberjon