This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If you have any local "definitions" that are actually just local anchors that point to the real definitions in other specs, they should be marked with a "data-noexport" boolean attribute. This ensures that Shepherd won't pick them up when parsing the spec, and they won't cause accidental dfn conflicts with the spec that actually defines them when a Bikeshedded spec uses the term.
Isn't that just redundant with looking at whether the <dfn> has a link inside it that points to another spec?
Possibly, but that feels too magical to me. You definitely can't test just for the presence of a link (Bikeshed puts permalink anchors inside of <dfn>s, for example), and once you're actually examining the href of a link to see if it disqualifies a <dfn> from being "export-worthy", I feel like you're a few steps past reasonable.
I don't understand why that's magical. An attribute is redundant. The question is "is this a definition of a term in another spec", and the answer is in the DOM already, since it's a <dfn> with a <a href=""> link to another spec. It's not magical, it's just looking at the semantics, which is the whole point of having semantics.
Sounds like Anne's pipeline uses the fragment-links.js file currently. Would it make sense for me to just export a data file that you can both parse more easily rather than having y'all try to parse the HTML or JS files? What information are you actually looking for?
(In reply to Ian 'Hixie' Hickson from comment #4) > Sounds like Anne's pipeline uses the fragment-links.js file currently. Would > it make sense for me to just export a data file that you can both parse more > easily rather than having y'all try to parse the HTML or JS files? > > What information are you actually looking for? I don't parse anything, Shepherd (the tool maintained by Peter Linss) does. It already does HTML parsing for all this stuff, so it would be more work to do a special data file than to just parse the spec as it is.
(In reply to Ian 'Hixie' Hickson from comment #4) > What information are you actually looking for? Oh, I didn't answer this part. What I'm looking for is all the terms that HTML defines, in a machine-extractable format, but none of the terms that HTML doesn't define (in other words, no collisions with the *real* definitions in other specs; collisions are nowhere near fatal in Bikeshed, but they're annoying and should be limited).
Where a definition is a human-readable string, a cross-reference keyword ("concept-foo-bar", "attr-quux-book", or whatever), a spec identifier (the equivalent of "[HTML]"), and a URL with fragment identifier pointing to the <dfn> where that term is defined?
(In reply to Ian 'Hixie' Hickson from comment #7) > Where a definition is a human-readable string, a cross-reference keyword > ("concept-foo-bar", "attr-quux-book", or whatever), a spec identifier (the > equivalent of "[HTML]"), and a URL with fragment identifier pointing to the > <dfn> where that term is defined? No need for cross-ref keyword; that's what the human-readable string is for. No need for a spec identifier either; that's implied by the fact that the definitions appear in the spec. Shepherd just looks for: * the term being defined; this defaults to the text content of the <dfn>, but can be overridden by the title='' attribute. * the id of the <dfn> * the type of the definition; Bikeshed's type hierarchy is at <https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md#definition-types>. This is specified in markup via the data-dfn-type='' attribute. * for the definition types that are namespaced to some other object (like element attributes, or interface methods), the name of the thing they're namespaced to. This is specified in markup via the data-dfn-for='' attribute.
See https://github.com/whatwg/html/pull/60 for a simple attempt at doing this. PRs for more such changes will be accepted.
https://github.com/whatwg/html/pull/150