Skip to content
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

Table's width attribute throws type error on strings #471

Closed
TaylorKrusen opened this issue Nov 28, 2023 · 1 comment · Fixed by #472
Closed

Table's width attribute throws type error on strings #471

TaylorKrusen opened this issue Nov 28, 2023 · 1 comment · Fixed by #472
Assignees
Labels
bug Something isn't working

Comments

@TaylorKrusen
Copy link

What happened?

When working with Table tags, the width attribute throws a type error if the value is not a Number. However, the width attribute works (and is expected to work) with strings. In the Markdoc Attributes documentation, there's an example of using the width attribute inside a Table with a percentage value, which is a String. The syntax works, but throws an error.

To clarify:

  • Works as expected → a Table's width attribute accepts a String.
  • Unexpected behavior → passing a String (i.e. 25%) in a Table's width attribute throws the following error:
Attribute 'width' must be type of 'Number'

To reproduce

  1. Go to the official Markdoc try it sandbox
  2. Paste the following table in the bottom of the editor:
{% table %}
* Heading 1 {% width="20%" %}
* Heading 2
---
* Row 1 Cell 1
* Row 1 Cell 2
{% /table %}
  1. Hover over the Heading 1 line to see error

(Note that despite the error, the 20% syntax does work and limits the table's column to 20%.)

Version

No response

Additional context

Screenshot 2023-11-28 at 11 30 07 AM

@rpaul-stripe
Copy link
Contributor

Thanks for reporting! We'll push out a new version with the fix shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants