fiji-flo / bikeshed-rs Goto Github PK

As I mentioned in #12, there's an unexpected <p> tag in the abstract section of tests/markdown001.html. It turns out that bikeshed would use a markdown-parser to turn text elements into block-level elements. This issue could be fixed by implementing the markdown module.

If we process Markdown text like this:

~~~
this code block has tildes,
```
and isn't closed by backticks
```
~~~

We will get something like this:

<pre>this code block has tildes,
<code>and isn't closed by backticks</code>
</pre>

But what we expect is:

<pre>this code block has tildes,
```
and isn't closed by backticks
```
</pre>

This is a known issue in bikeshed, which is caused by handling code spans after parsing Markdown.

Running it on WebGPU, I get:

[Line 7] Unknown metadata key "URL".

When we create an element from "<p hello></p>" or "<p hello=""></p>" with kuchiki and serialize it, we will get "<p hello=""></p>". But bikeshed would generate "<p hello></p>" in the output files. See https://github.com/tabatkins/bikeshed/blob/76c0936a72a830622de27fbabee0556ba1c4023a/bikeshed/html/serializer.py#L64.

That wouldn't affect the testing since we're doing DOM-based comparison, but I'm not sure if it's a big deal for users.

Now we use regexes to parse the metadata in the input file. Maybe there's a better way to do that without parsing HTML with regexes.

In tests/markdown011.bs, a test case for strong syntax fails: the text **High-light 1337! @twitter #hashtag ☃** couldn't be transformed into <strong>High-light 1337! @twitter #hashtag ☃</strong> since the regex ((?P<left>[^\\])|^)\*\*(?P<inner_text>[^\s][^*]*[^\s][^\\])\*\* couldn't match it.

But when the text is edited to **High-light 1337! @twitter #hashtag ☃[DELETE ME!]**, it could be transformed into <strong>High-light 1337! @twitter #hashtag ☃[DELETE ME!]</strong>.

Maybe it's about the charset or something.

We should figure out how do we want bikeshed-rs to be tested.

This probably involves:

• Looking into how upstream bikeshed is tested. If we can come up with a way to share the tests that'd be best.

• Decide whether we want to use regular #[test] functions, or something more like what cbindgen and bindgen use, where build.rs basically reads a tests/ folder and auto-generates the relevant cargo tests: https://github.com/eqrion/cbindgen/blob/master/build.rs