-
Notifications
You must be signed in to change notification settings - Fork 36
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
Append a self-link to each heading #30
Conversation
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.
This isn't quite right, although I'm excited you started on it.
All the TOC entries have a section symbol in them now.
The DOM structure here:
<h4 id="dom-trees">2.1.3 DOM trees <a href="#dom-trees">§</a></h4>
is not equivalent to the DOM structure used in our Bikeshed-based specs:
<h3 class="heading settled" data-level="3.5" id="defining-event-interfaces"><span class="secno">3.5. </span><span class="content">Defining event interfaces</span><a class="self-link" href="#defining-event-interfaces"></a></h3>
which will make styling difficult.
I'm going to try to push a series of commits that get our DOM structure closer to the Bikeshed one. We'll need to update the standard.css file as well I think. |
in <span class="secno">
Bikeshed doesn't include it in the TOC, but does in the document, so don't even bother trying to be consistent with Bikeshed, since it's inconsistent with itself.
With the latest commits we have <h4 id="dom-trees" class="heading"><span class="secno">2.1.3 </span>DOM trees<a href="#dom-trees" class="self-link"></a></h4> which is pretty close to Bikeshed. I didn't create the We'd merge this and then transfer some stuff from https://resources.whatwg.org/bikeshed.css to https://resources.whatwg.org/standard.css. I've tested that this works locally. \o/ |
The secno fix also helps with #27 |
It seems you now overwrite |
Ah dang yeah no-num is probably broken. The class=heading is used by a bunch of the styles in our two stylesheets, but technically we could replace it with a bunch of selectors targeting the individual tag names. |
Okay, I guess we can keep |
I guess we should poke around Wattsi to see if there's some kind of classList abstraction in use, but otherwise that sounds reasonable... Hmm or we could find the place that currently sets it to "no-num" and change it to set to either "heading" or "heading no-num". |
As far as I can tell Wattsi just uses literal comparison on classes. Which is also why changing them can be potentially problematic since things like |
It doesn't seem like there's too much class manipulation (in wattsi.pas) so whatever way we go seems doable. Still a little hesitant to add |
Sure, we don't have to add heading; we just have to be careful to update all the CSS. Do you want to take this over now perchance? :) |
It seems the equivalent of |
I don't really understand why you added |
Scratch.Append('#'); | ||
ExtractedData := Element.GetAttribute('id'); | ||
Assert(not ExtractedData.IsEmpty); | ||
Scratch.AppendDestructively(ExtractedData); // appending LastSeenHeadingID does not work |
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.
@Hixie could you explain why simply appending LastSeenHeadingID does not work here? I don't understand how it can be different from GetAttribute('id'). Thanks!
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.
What does it do instead?
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.
Oh, I see. It's because you're using AppendDestructively, which takes a Rope or CutRope, not a string.
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 you can't use LastSeenHeadingID is that it's a local variable, so if you appended it, you would end up having the DOM tree contain a pointer to the stack (rather than the heap). The solution is to not use AsString on the output of EnsureID. Instead, get back a CutRope, which contains pointers to the heap.
Note that EnsureID is itself just going GetAttribute, so it wouldn't make much difference in practice. Also be aware that you can only use AppendDestructively once per reference (hence the name), so if you use LastSeenHeadingID again you'd have to get it back out of the DOM anyway.
I think this is ready to be merged now, though it would be nice to hear from @Hixie why the obvious code is wrong. |
secno is needed for #27 |
Shall we add that as part of fixing that, then? Could even only output it in that mode as that doesn't have single-page. Would save about 700 nodes for normal HTML single-page. |
Sure, works for me. In that case I'll review/probably merge this PR later today. |
Thanks @Hixie, made some changes based on that. I'm not sure I totally follow with regards to stack/heap, but enough to remove a redundant GetAttribute call (although I guess those must be very cheap). |
@@ -637,7 +636,6 @@ TCrossReferences = record | |||
begin | |||
SecondLI := NewLI.CloneNode(True); | |||
ExtractedData := EnsureID(NewLI, 'toc-' + LastSeenHeadingID); | |||
Assert(not ExtractedData.IsEmpty); |
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.
Why did you remove this assert?
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.
EnsureID has it, no?
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 point of the assert here is to make sure EnsureID doesn't break without you noticing. :-)
@@ -504,9 +505,7 @@ TCrossReferences = record | |||
|
|||
Scratch := Default(Rope); | |||
Scratch.Append('#'); | |||
ExtractedData := Element.GetAttribute('id'); | |||
Assert(not ExtractedData.IsEmpty); |
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.
this assert also seems like an important one to keep...
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.
Same as above. EnsureID already asserts.
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.
EnsureID is verifying that things within EnsureID are acting as expected.
But here you're outside EnsureID, so you can't trust that EnsureID is correct. Hence the assert.
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.
So should we add more asserts then? These were the only two places that did that.
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.
Add asserts anywhere you have an invariant and you're not confident the rest of the code will keep it, for example when someone breaks the code elsewhere. :-)
|
||
Element.AppendChild(HeadingSelfLink); | ||
end; | ||
|
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 would add a comment here saying ExtractedData is no longer valid past this point
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.
But it can be assigned again, right? You did not add such comments for other AppendDestructively. Should we comment all of them?
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.
It's only non-obvious here because you only destroy in one branch of the if block.
Added the asserts back and added a comment about the validity of ExtractedData. I think this should be good to now. Corresponding stylesheet PR: whatwg/resources.whatwg.org#21 |
Fixes whatwg/html#46.