26335 2014-07-14 23:18:20 +0000 Add "data-noexport" to local dfns that just point to other specs 2015-09-16 09:26:23 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED tools P3 normal Unsorted 1 jackalmage ian annevk ian mike contributor oldest_to_newest 108928 0 jackalmage 2014-07-14 23:18:20 +0000 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. 108955 1 ian 2014-07-15 18:31:21 +0000 Isn't that just redundant with looking at whether the <dfn> has a link inside it that points to another spec? 108970 2 jackalmage 2014-07-15 20:09:52 +0000 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. 109019 3 ian 2014-07-16 19:50:04 +0000 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. 109696 4 ian 2014-07-31 19:32:50 +0000 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? 109712 5 jackalmage 2014-07-31 21:27:26 +0000 (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. 109714 6 jackalmage 2014-07-31 22:24:35 +0000 (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). 109719 7 ian 2014-07-31 22:47:30 +0000 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? 109722 8 jackalmage 2014-07-31 23:13:31 +0000 (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. 122964 9 annevk 2015-09-01 09:37:58 +0000 See https://github.com/whatwg/html/pull/60 for a simple attempt at doing this. PRs for more such changes will be accepted. 123221 10 annevk 2015-09-16 09:26:23 +0000 https://github.com/whatwg/html/pull/150