-
-
Notifications
You must be signed in to change notification settings - Fork 1
Add Creole-style |= table header syntax #8
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
Draft
dereuromark
wants to merge
8
commits into
master
Choose a base branch
from
feature/table-header-equals-syntax
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8 +/- ##
============================================
+ Coverage 93.28% 93.36% +0.08%
- Complexity 1672 1695 +23
============================================
Files 59 59
Lines 4347 4434 +87
============================================
+ Hits 4055 4140 +85
- Misses 292 294 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Adds support for marking header cells with |= prefix instead of requiring a separator row. This is simpler and more intuitive, especially for users coming from wiki markup. Features: - |= Cell marks a header cell - |=< Left-aligned header - |=> Right-aligned header - |=~ Center-aligned header The traditional separator row syntax continues to work unchanged. See: jgm/djot#354
ad3e8ae to
09c86ed
Compare
When using |=< |=> |=~ alignment markers on header cells, the alignment now applies to the entire column (subsequent data rows), not just the header cell itself. Separator row alignment still takes precedence if present.
dereuromark
added a commit
that referenced
this pull request
Dec 5, 2025
Addresses TBD items from PR #8: - Row/column spans using || (colspan) and |^ (rowspan) - Multi-line cells using trailing \ continuation - Interaction between |= headers and spanning syntax All features are strictly opt-in and compatible with original djot specs.
7080f78 to
ea5d384
Compare
Implements cell spanning syntax for tables: - Colspan: || (empty cells) after content spans multiple columns - Rowspan: |^| continues a cell from the row above - Header rowspan: |=^ for header cells that span rows Features: - TableCell node now has colspan and rowspan properties - HtmlRenderer outputs colspan/rowspan attributes - Compatible with |= header syntax from PR #8 - Standard djot tables work unchanged (opt-in extension) Syntax examples: - |= Header || (colspan=2) - |^ | (rowspan continuation) - |=^ | (header rowspan)
Fixes false positives where spaces before markers would trigger special behavior: - | = text | now renders as literal "= text", not a header - | ^ | now renders as literal "^", not a rowspan marker - |= < text | now renders header with "< text", not left-aligned Markers must be directly attached: |=, |^, |=<, |=>, |=~
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds extended table features to djot-php, providing more flexible table authoring options while maintaining full backward compatibility with standard djot syntax.
Features
1. Creole-style Header Cells (
|=)Mark individual cells as headers using the
|=prefix (must be directly attached to pipe):Renders as:
2. Cell Alignment Markers
Alignment markers must be directly attached to
|=(no space):|=< text|=> text|=~ textExample:
3. Colspan Support
Empty cells merge with the previous cell:
The
Nameheader spans 2 columns.4. Rowspan Support
Use
|^(directly attached) to continue from the cell above:The
Fruitcell spans 3 rows.5. Header Rowspan
Combine header and rowspan with
|=^:Compatibility Notes
Important: All special markers must be directly attached to the pipe character:
|= text| = text|^| ^|=<|= <This prevents false positives when users want literal
=,^,<,>, or~characters in their cells.Additional compatibility:
|---|) continues to work as expected|=syntax can coexistTest Coverage
RFC Status
This extends beyond the standard djot specification. The syntax choices prioritize:
|=for headers)Future Considerations
Per-cell alignment for data cells (e.g.,
|< left |or|> right |) is not included in this PR. This would require a different syntax to avoid conflicts with literal<and>characters which are common in table data (comparisons like< 5,> 10, math expressions, etc.). This could be revisited in a future PR if there's demand, e.g.Both mixed
If both are defined, the header would only align itself, and the meta row would define for the cells below:
Related
TBD
|and^?\?This is also a more intensive change of the specs, while still being fully compliant, this does make documents that use this not working with other parsers.
So we would need a clear sign-off from the spec author(s) IMO before we go down this road - or it must be a clear feature flag.