Closed andrewpbray closed 4 months ago
A follow-up:
A downside of B (maybe?) is that in HTML (unlike the pandoc AST), an element can only have 1 id, so cr-pink
would be the id of that element, not just an id of that element.
I can't immediately think of anyway in which this would inconvenience the user, but figure I'd bring it up.
Another follow-up:
Turns out we do use pandoc ids to target spans for highlighting:
| {#longpoem .cr-poem cr-id="mypoem"}
| I was given a name, it came out of a book—
| I don’t know which. I’ve been told the Great Man
| could recite every title in order on its shelf.
| Well, [I was born]{#cr-born}, and that’s a good thing,
| although I arrived on the day of his passing,
|
| a day on which our country fell into mourning.
| This I heard over and over, from professors
| to farmers, even duel-scarred students;
| sometimes, in grand company, remarked upon
| in third person—a pretty way of saying
|
| more than two men in a room means the third
| can be ignored, as [I was when they spoke]{#cr-birth1}
| [of my birth]{#cr-birth2} and Mr. Jefferson’s death
| in one breath, voices [dusted with wonderment]{#cr-wonder},
| faint sunlight quivering on a hidden breeze.
So this guy would get redone as:
| {#cr-mypoem}
| I was given a name, it came out of a book—
| I don’t know which. I’ve been told the Great Man
| could recite every title in order on its shelf.
| Well, [I was born]{#cr-born}, and that’s a good thing,
| although I arrived on the day of his passing,
|
| a day on which our country fell into mourning.
| This I heard over and over, from professors
| to farmers, even duel-scarred students;
| sometimes, in grand company, remarked upon
| in third person—a pretty way of saying
|
| more than two men in a room means the third
| can be ignored, as [I was when they spoke]{#cr-birth1}
| [of my birth]{#cr-birth2} and Mr. Jefferson’s death
| in one breath, voices [dusted with wonderment]{#cr-wonder},
| faint sunlight quivering on a hidden breeze.
We wouldn't need to enforce the cr-
prefix for the spans (we're really only using them as normal ids), but might be a good idea to be consistent with the sticky items. Or maybe that makes it more confusing?
Haha, that makes me realize: we don't even need the cr-
prefix on the sticky ids. We could use normal ids and then make those elements sticky when there exists a step that wants to focus-on
them.
So many design decisions 🤪 ...
It's funny: I was revisiting our original Issues / excalidraw diagrams to figure out how we reasoned about this last summer when we started in on this. Looking back, we were kinda flailing around with how to get this thing implemented. It's satisfying to see how far it has come.
Sorry, I should've read all of these before diving into one of them 😅
I quite like moving to regular IDs! I really not confusing users with the difference between a DOM ID and one of our IDs.
In terms of targeting in JS and CSS, it should be fine; as you know, we can write selectors like span[id^="cr-"]
to target spans or blocks with the right prefix. There might be some specificity considerations with the CSS (that's on my list for today), but other than that I support it.
As you say, the prefixes have a pleasing symmetry with the crossref system! They may not necessarily be needed, but I think I prefer enforcing them. According to the Quarto docs, cr-
is not currently a recognised prefix. (We should maybe check with the team to see if there are plans for other prefixes, though, to avoid a clash! I'll file that question with them.)
An update here: I'm waiting to implement this shift to using ids for sticky elements until I have some clarification on Question 2 at the bottom of this issue.
#| label: cr-myplot
doesn't get passed turned into a pandoc id on that Div in the AST and in fact it gets stripped out as an attribute. We could pass it as another custom-named attribute (those don't get stripped out), then attach it as an id via our filter but that seems like a workaround to avoid unless there's a good reason that Quarto handle it this way.
Split off that question into a separate issue: https://github.com/quarto-dev/quarto-cli/discussions/10229
Have replied to you there in https://github.com/quarto-dev/quarto-cli/discussions/10229! I was hoping id
might work differently, but no dice. classes
does sit at the top-level .cell
, but that's not quite what we need :/
I'm trying to remember exactly where we use the IDs. In JS, we can travel up and down the DOM as we need, so we can still target the .cell
above a #cr-*
. But in Lua, it sounds like that'd be a real pain — I'm guessing you'd have to check every .cell
inside a .cr-section
to see if there's a #cr-*
inside.
Hmm, I think we can work around this if need be but it'd be fairly hacky. It seems like a reasonably general issue, so I'm optimistic they'll implement a fix! 🤞
Mostly added in https://github.com/qmd-lab/closeread/commit/ea632d8637a41bee23721afc0c7d5935a5fd7d67. We still need to figure out a workaround for code blocks.
As I'm working to target the appropriate sticky element in the DOM during a step, I'm revisiting one of our first design discussions: what's the best way to flag a sticky element? Two options:
A) Using an attribute:
B) Using a prefixed id: (in a code-cell this would use
label: cr-pink
presumably)Some advantages that I'm seeing in B:
Are there big advantages of A that we identified that I'm not recalling now?
I don't think this would require much changes. There is an
is_sticky
function in .lua that could be adapted.Thoughts @jimjam-slam ?