Re: Various respec enhancements ...

On Tue, Sep 16, 2014 at 8:01 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Tue, Sep 16, 2014 at 3:55 AM, Robin Berjon <robin@w3.org> wrote:
> > On 25/08/2014 02:56 , Steve Glaser wrote:
> >> 2.Lots of <dfn> classes. I wanted to be able to have a bunch of <dfn>
> >> types that were formatted differently by CSS. If you include <dfn
> >> class=”field”>foo</dfn>, then any <a>foo</a> fields will automatically
> >> get the right class (assuming no ambiguity – if it’s ambiguous, you get
> >> a message and have to put the class attribute on the <a> tag).
> >
> > That's cool, and I think it makes sense. One notion that I've thought of
> > previously is to have dfn-namespacing as well as alternatives.
> >
> > Namespacing would work basically like this. Say you have a markup
> attribute
> > and a DOM attribute both called 'unicorn'. You could have
> > <dfn>dom:unicorn</dfn> and <dfn>attr:unicorn</dfn>, and
> <a>dom:unicorn</a>
> > would link to the right one (and drop the namespace on render of
> course). If
> > you need a : in your dfn, \-escaping works.
> >
> > Alternatives would solve the common problem of referring to the same dfn
> > with variants (typically, plurals) for which today one has to annoyingly
> > resort to @title. For that, just use <dfn>unicorn|unicorns|long-toothed
> > horse</dfn>.
>
> We've already solved this problem in Bikeshed/Shepherd, and it would
> be a crying shame to have ReSpec try to solve it in an incompatible
> way, as it would mean the two types of specs couldn't talk to each
> other.
>
> Bikeshed's relevant documention is here:
> <
> https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md
> >.
> We've got a taxonomy of dfn types, which can also be applied to
> autolinks to disambiguate.  There are multiple ways to specify what
> type a dfn is - an explicit data-dfn-type attribute, an id matching a
> particular pattern, a class (on the element or an ancestor) matching a
> particular pattern, or the text of the dfn itself matching certain
> patterns.  Bikeshed makes this all pretty trivial and turns it
> explicit in the source for you, but ReSpec specs obviously would need
> to be a little more explicit about things, so that the correct
> information shows up in the source html.
>
> I'd *really* like ReSpec and Bikeshed to agree on this stuff, so that
> I can autolink into ReSpec specs.


So looking into this is on my todo list for Q4 this year.

Would love to find a solution that simplifies cross-referencing between
specs and searching for definitions within the whole platform, e.g. what's
a browsing context, what the event loop, etc.

Will look into the documentation you provided. Happy to chat more about
this in a bit.

--tobie