Why is user-select: none and pointer-events: none applied to the content here? In the DOM it's perfectly serviceable content, even if the divs are absolutely positioned to achieve the editorial layout. If you disable these CSS properties the text is selectable and pastes in the right order as expected, since its based on the DOM ordering which matches the line order...
Additionally overflow is hidden, so you cannot read the entire text on desktop without using a very small zoom... and as others have noted, mobile is fully and completely broken. If the bubbles weren't so huge at least you could read a paragraph or two on mobile.
Full of emdashes and AI comparisons like "The performance improvement is not incremental -- it is categorical" too :-\
Presumably because the DOM order of the elements is not the actual order of the lines (you can see this with e.g. the blockquotes), so it would be confusing if the user tried to copy the text and saw that all the lines were jumbled up
It's only the blockquotes that are out of order. If this were a valid reason to disable user selection, then no website with a sidebar would have it enabled. Besides, you could just disable user selection on the blockquotes if that were the reason (not that I'd ever recommend that)
I'm sure this is really smart but boy is this a pain to read. I even tried holding the orbs in hopes of reading the text but it kept reflowing so much that I gave up after 5 minutes.
Edit: I just realized that clicking once freezes the orbs.
I was clicking and clicking hoping for the reflow madness to stop.
Thanks for this tip -- BTW we need to click _each_ orb.
Occationally a previously untamed orb will start making its presence known until it is stopped. OK I think I have been able to catch every orb now. Now onto read about the future of text layout.
I kmow all of the css/js hacks and tricks but the information i need is the screen size in real mm.
Currently i put up a visibility:hidden position:absolute left:-9000px div with nobr, put the first line of text in it, then get the width of it with computed style, calculate the root font size to make it the line exactly the screen width. Then the div is removed and the rest of the content is allowed on the page.
No idea how I'm supposed to read the end of this. But it seems kinda interesting? Not that like, require('fontmetrics') doesn't exist, but it's definitely true that most JS needs more font rendering then the browser seems capable of giving us these days.
This sound so smart, but yet falls so short on execution that the article itself adds display:none and overflow:hidden on the elements so I can't even read the article till its end
The demo itself is questionable, why would I want to mix moving elements with static text honestly why ? Break my reading flow + lose my interest in article.
The use case if there is ever one is a very niche that I can think of i.e. you actually want to render block of text on canvas and give all the text rendering properties of DOM to it or some subset of it.
Or some very weird use case where you want to know the exact position of previously rendered item and lay the next item relative to it
Hype to utility ratio is too high, may be he can do better demos, coz this orb shit is disorienting AF
I hesitate to even call this a solution in search of a problem because... Well come on.
A completely useless demo that can't operate on mobile of a way of displaying text that is less functional than every other way of displaying text. Table-based html layouts were better.
19 comments
Additionally overflow is hidden, so you cannot read the entire text on desktop without using a very small zoom... and as others have noted, mobile is fully and completely broken. If the bubbles weren't so huge at least you could read a paragraph or two on mobile.
Full of emdashes and AI comparisons like "The performance improvement is not incremental -- it is categorical" too :-\
Edit: I just realized that clicking once freezes the orbs.
Thanks for this tip -- BTW we need to click _each_ orb.
Occationally a previously untamed orb will start making its presence known until it is stopped. OK I think I have been able to catch every orb now. Now onto read about the future of text layout.
Currently i put up a visibility:hidden position:absolute left:-9000px div with nobr, put the first line of text in it, then get the width of it with computed style, calculate the root font size to make it the line exactly the screen width. Then the div is removed and the rest of the content is allowed on the page.
This is the only thing that works.
A shame there doesn’t seem to be any vertical text support yet
The demo itself is questionable, why would I want to mix moving elements with static text honestly why ? Break my reading flow + lose my interest in article.
The use case if there is ever one is a very niche that I can think of i.e. you actually want to render block of text on canvas and give all the text rendering properties of DOM to it or some subset of it.
Or some very weird use case where you want to know the exact position of previously rendered item and lay the next item relative to it
Hype to utility ratio is too high, may be he can do better demos, coz this orb shit is disorienting AF
Seems the entire “blog” is ai generated images. So I assume this is more slop.
A completely useless demo that can't operate on mobile of a way of displaying text that is less functional than every other way of displaying text. Table-based html layouts were better.
Just show the text, there's no problem here.
The website does not work on mobile. If you used CSS you wouldn't have this problem.