-
-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core/dfn): add data-defines
on some patterns of term/definition association
#4620
Conversation
As discussed in speced#4522 See also w3c/reffy#1444
Co-authored-by: François Daoust <[email protected]>
I'm not loving <p class="definition">
This is a <dfn>term</dfn> that is being defined.
</p>
<p>
This is some term <dfn>term</dfn> that is being defined.
And <span class="definition">this is some <dfn>other</dfn> that is being defined</span>
</p> We can still use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested some changes...
tests/spec/core/dfn-spec.js
Outdated
<dt><dfn>different convention</dfn></dt> | ||
<dd id="desc2">Different conventions can be applied to associate a term with its description</dd> | ||
</dl> | ||
<dl> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking out loud:
Do we want/need to handle the cases with multiple dt or multiple dd?
Multiple dt: as an alias.. sounds like job for data-lt
Multiple dd: why?
data-defines
on some patterns of term/definition association
src/core/dfn.js
Outdated
// A dl with class hasdefinitions marks all next siblings of dt with the class | ||
// definition | ||
/** @type NodeListOf<HTMLElement> */ | ||
const describedDTs = document.querySelectorAll("dl.hasdefinitions dt"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe dl.definitions
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reason I was liking "hasdefinitions" more than just "definitions" is that it is more easily distinguishable from the other pattern (it's easy to see that "hasdefinitions" is different from "definition", but it would really easy to confuse "definition" and "definitions" which generate quite different behavior).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, but still feels a little odd to me. Maybe I can get used to it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't loving hasdefinitions either tbh. I updated the PR to use "definitions".
src/core/dfn.js
Outdated
let curEl = el; | ||
let dfn; | ||
while (curEl) { | ||
dfn = curEl.querySelector("dfn[data-dfn-type]"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A comment explaining why [data-dfn-type]
would be be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🎉
Just one nit: dl.hasdefinitions
should probably become dl.definitions
.
src/core/dfn.js
Outdated
|
||
// - Sets data-defines on well-known definition content patterns | ||
function addDefinitionPointers() { | ||
// A dl with class hasdefinitions marks all next siblings of dt with the class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't dislike this (dl.definitions
), but I feel this is overstepping based on what we have previously discussed. I still think we should start with an extremely simple / basic system and build it up very incrementally (and eventually get to this, but I don't think we are there yet).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a <dl>
containing definitions is exactly what the VC spec (our initial customer) is using AFAICT; if we're not going to support that convention, I'm not sure we need a respec patch at all at the moment (since reffy recognizes data-defines
without any additional help).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, and that might be ok. But let's settle on the convention for:
- container (p, span) has .definition
- and multiple: dl.definitions
And explicitly marked as such.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good as a start.
We might need to deal with edge cases like:
<p class="definition">
<dfn>a</dfn> ... <dfn>b</dfn>
</p>
is there anything blocking this or should I go ahead and merge it at this point? |
OK by me. @marcoscaceres? |
Going ahead with the merge given Marcos approved already. |
As discussed in #4522
See also w3c/reffy#1444