Why that strict table structure?

[RoSk0]

I need to test tables which has headers as a first column , so no thead element.

I went on reading HTML specs to understand if my project produces bad markup , but no, thead is optional as the tbody . Found also very interesting examples of perfectly valid tables here https://www.w3.org/WAI/tutorials/tables/two-headers/.

So my main question is why this project limits the table structure ?

I've done some hackery and I can see that even plain <table><tr><td>Series offered</td><td></td></tr><tr><td></td><td></td></tr></table> is perfectly parsable with minor logic change in HTMLStringTableParser::parseTable().

I understand that comparators are focused on columns at the moment , but that could be change or rather extended.

Extending this project with this type of functionality would rather big task and I want to make sure it is going to be considered/accepted before starting work.

Are there any issues with removing those hard requirements on table structure?

[acoulton]

I think there were two reasons:

• Although it's not required, my understanding is it's considered good practice to put the header in a <thead> especially if there are multiple rows making up the header e.g. https://www.w3.org/WAI/tutorials/tables/irregular/ - it can also make it easier to apply CSS to style <th> that are column headers vs <th> that are row headers.
• As we always use the <thead>, it made sense to look for that to robustly parse the header / data rows.

We'd be open to a change that made that a soft requirement. I think it's still important that the markup is explicit about what we should count as the header.

How about looking for:

• A thead with a single tr (as now)
• Or, optionally, any single tr with a data-behat-table="header" attribute - that uses the existing pattern we have for marking rows that should be treated in some particular way.

What do you think?

[RoSk0]

It looks like my timeframes are not allowing me to work further on this.

I believe that imposing restrictions on the mark up is not in scope for testing libraries like this. Configuration should describe existing mark up to the library to help diffing . Any valid HTML should be supported, without additional attributes.