Been playing around with @sidvishnoi xref implementation, and it's simply amazeballs. Some things I thought of as I was playing around - we should extend the configuration:
• xref: true //enable it, what we have today.
• or, xref: ["list", "of", "specs"] (get automatically added to <body data-cite=""> )
• or xref: "w3c" (defaults for w3c..., which would include "html, infra, url, promises-guide, webidl, dom, fetch" to
We could come up with other cool little profiles based on different communities.
Eventually, all w3c specs would get xref: w3c by default. 😍😍😍😍
marcoscaceres
All 8 comments
@sidvishnoi If you are not working on this, I would like to work on it.
Swapnilr1
on 20 Mar 2019
@Swapnilr1, feel free to take it. However, we are still beta testing xref... but I guess it will be fine to set up some defaults and implement the array.
marcoscaceres
on 20 Mar 2019
@marcoscaceres A question about the plan:
xref: ["spec1", "spec2", "spec3"]would result in<body data-cite="spec1 spec2 spec3">.xref: truestill applies for the rest of the document? Or restricted to just occurrences of["spec1", "spec2", "spec3"]in the document?About the profiles, where do we store the profile? Do we hard-code the list of specifications in w3c profile (I am most likely wrong)?
Swapnilr1
on 23 Mar 2019
Question 1: xref true still applies, it’s not restricted to that set.
Question 2: it’s ok to hard code them into xref for now. We can figure out where to put them later.
marcoscaceres
on 23 Mar 2019
@marcoscaceres Hmm, one more doubt, currently we use Xref as either,
Case 1: xref: true or
Case 2: xref: { url: apiURL }.
Already clarified for Case 1, but for Case 2, is the following OK:
xref: { url: apiURL } - same current implementation.
xref: { url: apiURL, specs: ["spec1", spec2"] } (add to <body data-cite="">)
xref: { url: apiURL, specs: "w3c" } (add all of the specs in the profile to <body data-cite="">)
?
Swapnilr1
on 23 Mar 2019
Good observation. I think what should happen is, for example:
xref: [“spec”]
Becomes internally {specs: [“spec”] }
Similarly:
xref: “w3c”
Becomes internally represented as:
{ specs: hardCodedArrayOfW3CSpecs }
And so on. Users can also use the object, as a long hand solution. However, having the declarative array of string should still be supported, with the fallback being using the detailed object structure. Hope that makes sense!
marcoscaceres
on 23 Mar 2019
@marcoscaceres OK, just to make sure I understood,
xref: true-> convert internally toxref: { }. (conf.xrefevaluates to true, and that's it)xref: [“spec1”, "spec2"]-> convert internally toxref: { specs: ["spec1", spec2"] }xref: "w3c"-> convert internally toxref: { specs: ["hardcoded"," specs"]xref: { url: apiURL }- leave as is.xref: { url: apiURL, specs: ["spec1", spec2"] }- leave as is.xref: { url: apiURL, specs: "w3c" }-> convert internally toxref: { url: apiURL, specs: ["hardcoded", "specs"]}
Swapnilr1
on 23 Mar 2019
You got it. But for consistency, no matter what user gives us (true, "w3c", or [...specs]) we would like the final conf.xref to look like
{
specs: null or [...specs],
apiURL: userProvidedTestApiUrl or DEFAULT_API_URL,
}
sidvishnoi
on 23 Mar 2019
Related issues
saschanaz
·
5Comments
sidvishnoi
·
4Comments
saschanaz
·
6Comments
andrea-perego
·
3Comments
marcoscaceres
·
3Comments
Most helpful comment
You got it. But for consistency, no matter what user gives us (true, "w3c", or [...specs]) we would like the final
conf.xrefto look like