squidfunk / mkdocs-material

Documentation that simply works

Home Page:https://squidfunk.github.io/mkdocs-material/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Search issue: tables

AlanMarsh99 opened this issue · comments

Contribution guidelines

I've found a bug and checked that ...

  • ... the problem doesn't occur with the mkdocs or readthedocs themes
  • ... the problem persists when all overrides are removed, i.e. custom_dir, extra_javascript and extra_css
  • ... the documentation does not mention anything about my problem
  • ... there are no open or closed issues that are related to my problem

Description

The search functionality doesn't correctly show tables in the search bar.

Expected behaviour

When searching for a keyword, if that keyword happens to be in a table, the row in which it appears in should be displayed in table format in the search bar.

Actual behaviour

When searching a keyword, if that keyword happens to be in a table, then the search displays the table like this:

image

This can be confusing and difficult to read, especially if that keyword appears multiple times in the table with large gaps in between.

Steps to reproduce

test.zip

Package versions

  • Python: 3.9.7
  • MkDocs: 1.3.0
  • Material: 8.2.9+insiders.4.12.0

Configuration

site_name: Test

nav:
  - index.md

System information

  • Operating system: Windows 10
  • Browser: Chrome

Thanks for reporting. I understand that tables (and some other elements) are currently not perfectly represented in the search. The new search already is a big improvement over the one MkDocs ships by default, but tables are particularly difficult, as they break the layout on smaller screens without accurate and special handling. Also, tables can be very, very large. I currently don't believe that we should preserve the markup for tables when indexing search results, as rendering is a very hard problem to get right.

I want to investigate better text summarization in the future, and will also try to improve rendering for additional types of elements, but I can't put an estimate on it and whether this problem is actually solvable with reasonable effort. For this reason, I'm closing the issue with "won't fix, but more research needed".