refactor: simplify auto header insertion logic #2578
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
I think the main.children[0] seems more reasonable/semantic to determine if there contains a Header (although other plugin may broken it, maybe we need distinguish docsify owned doms).
If we change to search h1 in whole content, it seems we breaks the behavior since we don't allow user to use autoHeader for those content which contains h1 for different purpose.
// # AutoHeader add from _sidebar.md
this is a summary for the whole content.
# There is a new section for the next content below
Should I never use the H1 in this content anymore? Maybe we need keep this behavior? or update the docs for the autoHeader, but it will constrict the users' content tho.
- Use querySelector instead of getElementsByTagName for clarity - Avoid redundant DOM wrapping by directly accessing firstElementChild - Add null check to prevent potential DOM insertion errors
sy-records
force-pushed
the
fix/autoHeader
branch
from
57c410c to
b3159b1
Compare
|
Searching for |
I understand that, since it's strict for the first item, which may exchanged by plugins. It's fine to change the behavior in v5 that we only support autoHeader in the content without any H1 heading presently. |
2 participants
Close #810