HTML tag problem with story submission

[BeechLeaf]

So to summarize (as far as I know), page 1 is always correct: titles, Star Wars scrolling, and centred scene breaks whatever they consist of. And beyond page 1, any kind of content, centred by any means, is likely to be randomly omitted. No-one's found any way of forcing it to render correctly on the first view.

Edit 1: See EmilyMiller's #54 below for amendment.
Edit 2: And WaxPhilosophic's ingenious #55 for how to make it go wrong on page 1.

 

[IWroteThis]

Run it through a validator like https://validator.w3.org. Tons of errors and warnings. Many on stray closing a tags.

I still don't understand why refresh works as a fix.

Because the bug appears to be triggered by mousedown, mouseup, and/or onclick actions, as a direct mouse click is the only way you get the buggy version.

In my testing, there is nothing random about it. If you directly click on a link that ends in ?page=# you will get the buggy version of the page. If you reload the page, View Source, Open Link in New Tab, Open Link in New Window, or copy and paste the address into the URL bar, you get the correct page. I think the only thing I didn't test was opening it from a bookmark, but I suspect it will give you the correct version.

The centering bug was explained in a thread about it in the tech support forum. Summarizing, it's from the way browsers load style tables (or their equivalent) and the timing related to the content. Apparently the code is loaded with the first page and the content uses that code, while subsequent pages clear (or do something to) the function calls, invalidating the definitions. Or something like that.

The "correct" style tables are in fact loaded... but after the > Page 1 content has been sent. That's why an F5 refresh fixes everything.

It came with a site software update last November that was trying to improve overall site performance. It did, but this hands-crossed thing came with it.

When I was a multi-site sysadmin, if I didn't back-out this kind of repeatable failure with an upgrade, the clients would hang me up by my... well, they'd be really, really unhappy.

I find that explanation rather lacking, and even more questionable, mainly because you can see that the HTML code itself is different by using the debug tools. Styles change how the HTML code is rendered, not the HTML code itself.

 

[EmilyMiller]

The centering bug was explained in a thread about it in the tech support forum. Summarizing, it's from the way browsers load style tables (or their equivalent) and the timing related to the content. Apparently the code is loaded with the first page and the content uses that code, while subsequent pages clear (or do something to) the function calls, invalidating the definitions. Or something like that.

The "correct" style tables are in fact loaded... but after the > Page 1 content has been sent. That's why an F5 refresh fixes everything.

It came with a site software update last November that was trying to improve overall site performance. It did, but this hands-crossed thing came with it.

When I was a multi-site sysadmin, if I didn't back-out this kind of repeatable failure with an upgrade, the clients would hang me up by my... well, they'd be really, really unhappy.

Woosh…

That’s the sound of most of that going over my head.

Then when you’re my height, that happens a lot .

 

[EmilyMiller]

So to summarize (as far as I know), page 1 is always correct: titles, Star Wars scrolling, and centred scene breaks whatever they consist of. And beyond page 1, any kind of content, centred by any means, is likely to be randomly omitted. No-one's found any way of forcing it to render correctly on the first view.

Not quite.

Looking at my own stories, and echoing what others have said, my centered titles (which could be on page six if that’s where a section starts) seem to always load fine. My centered section breaks (which are often just text or emojis) always fail on page 2 onwards and always succeed on refresh.

 

[WaxPhilosophic]

Because the bug appears to be triggered by mousedown, mouseup, and/or onclick actions, as a direct mouse click is the only way you get the buggy version.

To test this theory, I loaded page 2 of my story directly. It rendered correctly. So far it appears the page navigation click is the cause.

Then, I clicked the arrow to go back to page one, and this is where it got trippy. In the first half or so of page one, I got the buggy behavior. No centered * * * breaks. After about the halfway point the * * * breaks appeared where they should.

Bug and no bug...in the same HTML page.

No refreshing or anything on my part. It just decided to start behaving in the middle of rendering.

If you want to try, the story I tested is: https://www.literotica.com/s/honeys-rizz-quest Just tack a ?page=2 on the end of the link to start on the second page.

 

[BeechLeaf]

Actually that makes sense, given the explanation that it loads the mumble mumble correctly on the 'first' page. If the first page is page 2, then it'll go wrong when you go to a 'subsequent' page, even by back-arrow.

 

[WaxPhilosophic]

Actually that makes sense, given the explanation that it loads the mumble mumble correctly on the 'first' page. If the first page is page 2, then it'll go wrong when you go to a 'subsequent' page, even by back-arrow.

Yes, but it only mis-rendered the top half of the page. That's what's weird.

 

[BeechLeaf]

As far as I can recall, the problem is that they're sporadically dropped, not that all such text is dropped. FrancesScott above found the first four were dropped. I don't recall anyone else coming up with a specific number, but that would be consistent with your finding: errors up to a certain point.

 

[old_prof]

For my stories, it was never as consistent as the first four on a page or something. I had some appearing in the middle of a run of missing ones.
But it was 100% reproducible. The same ones appeared (or not) each time you go to a page from the next or page number button.
Reloading always fixed it. And it started a few days into the Winter Holiday 2025 contest.

But a reproducible case and pointing it when the change happened was not enough to get Manu to fix it.

 

[IWroteThis]

To test this theory, I loaded page 2 of my story directly. It rendered correctly. So far it appears the page navigation click is the cause.

Then, I clicked the arrow to go back to page one, and this is where it got trippy. In the first half or so of page one, I got the buggy behavior. No centered * * * breaks. After about the halfway point the * * * breaks appeared where they should.

Bug and no bug...in the same HTML page.

No refreshing or anything on my part. It just decided to start behaving in the middle of rendering.

If you want to try, the story I tested is: https://www.literotica.com/s/honeys-rizz-quest Just tack a ?page=2 on the end of the link to start on the second page.

I tried in two different browsers and was unable to replicate the behavior. The first page loaded fine in both cases.

 

[WaxPhilosophic]

I tried in two different browsers and was unable to replicate the behavior. The first page loaded fine in both cases.

Inconsistent bugs are the best bugs!

 

[HelenL]

The centering bug was explained in a thread about it in the tech support forum. Summarizing, it's from the way browsers load style tables (or their equivalent) and the timing related to the content. Apparently the code is loaded with the first page and the content uses that code, while subsequent pages clear (or do something to) the function calls, invalidating the definitions. Or something like that.

I'm not sure I believe that. If the styles were missing, it would affect the whole page, not the first four occurrences. Unless the style is loaded asynchronously (and there is a page loading or loaded even in the script, I don't recall which), but even if that's the case, a style screwup would mean that the HTML would still appear, even if the browser can't render it. It doesn't appear at all, so I'm convinced that the problem is in the HTML generation, not the browser.

 

[HelenL]

I tried in two different browsers and was unable to replicate the behavior. The first page loaded fine in both cases.

Probably because the caching of whatever the issue is is server-side. Once anyone has loaded the page, it will render correctly until the cache expires. (No idea how long that is, but it looks like a couple of days.)

 

[old_prof]

Probably because the caching of whatever the issue is is server-side. Once anyone has loaded the page, it will render correctly until the cache expires. (No idea how long that is, but it looks like a couple of days.)

This is not true. If you reload the page, it loads correctly. But it you navigate away to the previous and come back via the next button, it will be broken again.

It is also not a timing bug because it is 100% reproducible (and does not impact every occurrence on a page)l

 

[HelenL]

This is not true. If you reload the page, it loads correctly. But it you navigate away to the previous and come back via the next button, it will be broken again.

It is also not a timing bug because it is 100% reproducible (and does not impact every occurrence on a page)l

Well... now it's failing every time for me. I tried the previous/next and you're right, the bug is back, but now if I click to another page and back to 5 of the story in question it's still buggy, which I swear I've done before and couldn't reproduce the bug.

 

[HelenL]

This is not true. If you reload the page, it loads correctly. But it you navigate away to the previous and come back via the next button, it will be broken again.

It is also not a timing bug because it is 100% reproducible (and does not impact every occurrence on a page)l

I tried previous and next of the link @WaxPhilosophic shared and I can't make the bug appear at all.

To test this theory, I loaded page 2 of my story directly. It rendered correctly. So far it appears the page navigation click is the cause.

Except then I loaded it in a new tab and the bug is back. I currently have two tabs with no bug and one with bug and the behavior is consistent within each tab. If I hit refresh it will go away and stay gone. (Chrome, BTW)

 

[MrPixel]

Unless the style is loaded asynchronously...

That's what I believe is happening.

 

[HelenL]

That's what I believe is happening.

Yeah, I can see how that would change page formatting partway through, but here the HTML doesn't exist, so it can't be a problem with it not having a loaded style.

 

[TheLobster]

I dug into this a little, up to a point where the only way to proceed would be to untangle the mess of obfuscated JS that's clearly a result of compiling TypeScript (i.e., good luck with that), and to me it seems most probable that this is a client-side rendering bug.

When you click on the page link in the navigator at the bottom of the story text, the site loads the story content as JSON alongside with metadata about the submission and the author. The actual story text within that JSON is very clean HTML, similar to what you'd write yourself if you submit your stories as text in the submission form. Here's the beginning of the first page of Honey's Rizz Quest:

<strong>Author's Note<\/strong>\r\n\r\n
I've written a couple recent cyberpunk stories on this site featuring Sara and her revolutionary compatriots. Both lean pretty hard into the dystopian aspect of cyberpunk. This one is a little more lighthearted. It stems from a line in <i>The Domestic<\/i>, where Sara says to her new cyborg friend, Honey: \"We're going to have to work on your rizz if you're going to start asking girls to kiss you.\"\r\n\r\n
You don't have to read <i>The Domestic<\/i>, or <i>The Courier<\/i>, or any of the other stories before this one. They're all standalone tales and each one provides enough background that you shouldn't feel lost. But, if you enjoy what you read here, you might put them on your reading list.\r\n\r\n
<p align=\"center\">* * *<\/p>\r\n\r\n
<strong>Prologue<\/strong>\r\n\r\nMy name is Honey, because that's what my girlfriend Sara named me.

(I added some line breaks for clarity; it is all one physical line in the actual JSON).

As you can see, the centered separator (three asterisks) is definitely there. You can also see, if you compare the above with the DOM of a rendered story:



that this content goes through pretty heavy processing before it is displayed. Most notably, all those \r\n (carriage return + line feed) sequences are translated into paragraph breaks client-side. This is eyebrow-rising to say the least, because it makes it quite obvious the whole submission processing pipeline has more or less unbroken history going back to the site's beginning 20+ years ago and hasn't been seriously refactored since. (It also reveals that if you upload a Word/RTF file, it is in fact converted internally into the same text+HTML format that the submission form expects).

But anyway, since there is some heavy client-side processing involved, I figured the code for that must be somewhere. This is where I got bounced, as the only relevant bit I managed to find was this:

const O = /(\r\n|\n\r|\r|\n)/g
  , rt = (t, s) => s ? String(t).replace(/&(?!(amp|lt|gt|quot|#39);)/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;").replace(/&lt;(\/?(strong|em|s)\b)&gt;/g, "<$1>").replace(/"/g, "&quot;").replace(/'/g, "&#39;") : String(t).replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;").replace(/"/g, "&quot;").replace(/'/g, "&#39;")
  , nt = t => {
    const s = () => t.text ? t.text.split(`\r
\r
`).filter(Boolean).map(a => {
        t.escapeHtml && (a = rt(a, t.forStoryGame || !1));
        let n = a.split(O).map(l => l.match(O) ? "<br>" : l).join("");
        return n.includes("<em") && (n = `${n}</em>`),
        n = `${n}</a>`,
        n
    }
    ) : null;
    return c(q, {
        get each() {
            return s()
        },
        children: a => ( () => {
            var _ = g(et)
              , n = t.ref;
            return typeof n == "function" ? M(n, _) : t.ref = _,
            E(_, "innerHTML", a),
            _
        }
        )()
    })
}

which, as far as I can tell, produces a sequence of paragraphs from the above "raw" story content which is then used somewhere to actually render the story (i.e., produce the DOM). As far as I can tell the separators should still be preserved at this point, but I'm not 100% sure and I didn't have the fortitude to chase the obfuscated symbols to figure out where this "somewhere" is where the sequence of paragraphs is used.

I'm pretty convinced, however, that it is not a styling issue, nor is it related to caching or anything server-side. It might still be something that messed up with the story content once it is actually rendered, of course, but so far it is IMO more probable that the centered paragraphs are lost in the parsing/rendering stage.

 

[old_prof]

I'm pretty convinced, however, that it is not a styling issue, nor is it related to caching or anything server-side. It might still be something that messed up with the story content once it is actually rendered, of course, but so far it is IMO more probable that the centered paragraphs are lost in the parsing/rendering stage.

My guess is that it is server side. I'm guessing (I have not made the analysis you have) is that the wrapper html/js that goes around the story text is actually slightly different for different loading paths. One of them has a buggy js function that screws some of this up. It is very dependent on using the next/prev button (or page number button) as opposed to having the correct url for the exact page. That's why reloading the page works.

 

[TheLobster]

My guess is that it is server side. I'm guessing (I have not made the analysis you have) is that the wrapper html/js that goes around the story text is actually slightly different for different loading paths. One of them has a buggy js function that screws some of this up. It is very dependent on using the next/prev button (or page number button) as opposed to having the correct url for the exact page. That's why reloading the page works.

There is a server-side rendering path, but I think it's only relevant if you disable JS entirely. If you dig into the page source, you will find the JSON I talked about above even for that initial page (i.e. page 1, if you didn't append ?page=X to the URL), before you've done any inter-page navigation. This makes me think that the story content is rendered through client-side JS every time, even on a fresh reload, which is why the bug is so elusive as it only happens after client-side navigation.

Alright, never mind; I double-checked, and the initial page load is indeed simply displaying the static HTML of the story page. (Which also means the story text is effectively embedded twice within that page...). That static HTML is obviously generated server-side, and is correct (the centered separators are present); but the client-side render is buggy. To me that pretty clearly suggests the client-side rendering is an issue, as the one path where everything works correctly generates the final, user-visible HTML on the server.

 

[pink_silk_glove]

But the visual impact of the typography and the typesetting does have an impact on the way readers react to a piece. It's important.

Absolutely it is. Considering that laurel herself disallows funky fonts to ensure uniform style readability for readers and that she will reject your submission if it walls of text or if the dialogue is not properly punctuated, then style tags and what little formatting allowed are damned important.

 

[MillieDynamite]

My mind on HTML

 

[HelenL]

Alright, never mind; I double-checked, and the initial page load is indeed simply displaying the static HTML of the story page. (Which also means the story text is effectively embedded twice within that page...). That static HTML is obviously generated server-side, and is correct (the centered separators are present); but the client-side render is buggy. To me that pretty clearly suggests the client-side rendering is an issue, as the one path where everything works correctly generates the final, user-visible HTML on the server.

I don't see that. If I load a page where the separators are missing, ^U, copy all, paste into text editor, the separators are not present in the HTML. Not until the fourth occurrence. Can the script modify the HTML rather than its effects?

 

[TheLobster]

I don't see that. If I load a page where the separators are missing, ^U, copy all, paste into text editor, the separators are not present in the HTML. Not until the fourth occurrence. Can the script modify the HTML rather than its effects?

I've never seen that. Just now I went to https://www.literotica.com/s/honeys-rizz-quest?page=2, clicked on page 1, and the separators were missing; opened the source (Ctrl+U), searched for "* ", and they were there as expected.

A (client-side JS) script cannot modify the initial HTTP response, only the rendered DOM (HTML elements) of the page as displayed in the browser.