sideshowbarker

To clarify one thing: the _Bad value “number” for attribute “type” on element “input”_ error message that the CLI reports is essentially saying that the `type` attribute for an `input`...

@mtrootyy > css was added. appearance: base-select Does that affect the validator? In other words, does it affect any document-conformance requirements?

OK, I see now — but I think the CSS conformance would be better raised as a separate new issue, in the https://github.com/w3c/css-validator/issues issue tracker

I will mess around a bit with trying to add support for this — but I think it’s possible we might get hung up on the validator.nu HTML parser (which...

> [@sideshowbarker](https://github.com/sideshowbarker) do you know how to do this? Probably by changing what we're passing to the conformance checker in [whatwg/html-build@`a0a6276`/ci-build/inside-container.sh#L14](https://github.com/whatwg/html-build/blob/a0a6276f117cfb11ee271e5956c032535885632c/ci-build/inside-container.sh#L14) ? For the record here: We can do something...

> I think just like the Encoding standard we can use a `.htmlcheckerfilter` file to suppress these info warnings, but I'd like to first understand this better. Ah yeah, if...

The suggestions in the issue description sound great to me. But the npm package was put together by another contributor, and I don’t personally plan on ever doing any more...

Note: I’ve updated the issue description to describe a workaround I’m using for now (calling out to `gh pr view`). But of course it would be much better for us...

Related: https://github.com/Textualize/textual/discussions/3555

The discrepancy appears to be due to https://github.com/whatwg/dom/commit/eb96fb7d2c91c7f4dcaf4e55670d29b12c60b0b0 from earlier this year — which changed the requirements to allow the colon and probably some (many?) other characters that weren’t allowed...