### Problem to solve Static site generators rely on markdown pages to organize content, but the content is almost never exclusively written in markdown. Many generators rely on additional markup to provide additional options not provided by Markdown and it is completely valid to write raw HTML alongside markdown content. The problem is that when the Static Site Editor loads the markdown page contents, it expects to be able to render markdown into HTML for rich text formatting. If that content is not valid markdown, the editor can get tripped up and will attempt to format the code as standard paragraph content. ### Intended users * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) ### User experience goal The user should be able to edit content in the Static Site Editor that has been identified as something other than markdown and have it render appropriately. ### Proposal Building off of https://gitlab.com/gitlab-org/gitlab/-/issues/216836, we should allow a user to edit the non-markdown content inline with the WYSIWYG editor. A user should see a clear distinction between the rich-text formatting of markdown content in the WYSIWYG editor and the non-markdown content. ### Further details Ideas, no necessarily direction: * We could format this as a kind of in-line code block and make the format feel like a code editor? Use a mono-spaced font and a dark background to make it clear that this rendering is of "code" and not what it will look like in the end. * We would have to make a very clear distinction between this and an _actual_ code block in markdown. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? #### Acceptance criteria 1. User can edit non-markdown content such as HTML, Ruby, or page includes using the WYSIWYG mode of the Static Site Editor.