Skip to content

Conversation

@VitaliiDC8
Copy link
Contributor

No description provided.

@gravity-ui-bot
Copy link
Contributor

Preview is ready.

>
<Col sizes={titleSizes} className={b('content-inner')}>
{overtitle && (
<p className={b('overtitle')}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why it's a div and not p?

Copy link
Contributor Author

@VitaliiDC8 VitaliiDC8 Jul 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the < p > tag in HTML cannot contain block-level elements, like < div >, according to the HTML5 content model. When an HTML parser encounters this scenario, it implicitly closes the < p > tag before the < div > starts and re-opens a new one after the < div > ends, resulting in the observed behavior.

In simple words: browsers automatically closed the p tag when they met div inside, cause they considered div not as a content of p, but rather as the next node after the p.

The description node looked like this:


<p class="pc-header-block__description">
    <div class="yfm">
        <!-- Typographed content started, this is not a part of any component -->
        <p>Text...</p>
        <!-- End of the content -->
    </div>
</p>

In fact, browser renders it this way:


<p class="pc-header-block__description">
    </p><div class="yfm">
        <!-- Typographed content started, this is not a part of any component -->
        <p>Text...</p>
        <!-- End of the content -->
    </div>
<p></p>

<HTML block={hasBlockTag(title)}>{title}</HTML>
</h1>
{description && (
<p className={b('description')}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why should we have a div here instead of p?

{itemTitle && (
<h5 className={b('item-title')}>
<HTML>{itemTitle}</HTML>
<HTML block={hasBlockTag(itemTitle)}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we relocate block check inside HTML-component?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could do, but HTML component is used by YFMWrapper and YFMWrapper has prop to change flag 'block', so we have to extend type to 'undefined' for this flag to not override value from YFMWrapper in HTML component. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, check moved into HTML component

@VitaliiDC8 VitaliiDC8 requested a review from yuberdysheva July 11, 2023 15:31
yuberdysheva
yuberdysheva previously approved these changes Jul 12, 2023
@yuberdysheva yuberdysheva dismissed their stale review July 12, 2023 13:16

2 failing checks

gorgeousvlad
gorgeousvlad previously approved these changes Jul 12, 2023
@VitaliiDC8 VitaliiDC8 merged commit 3b46ff4 into main Jul 12, 2023
@VitaliiDC8 VitaliiDC8 deleted the fix/html-semantic branch July 12, 2023 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants