/l/ - The Lounge

Non board-specific discussion

[Make a Post]
[X]





@Asukafag Nanonymous No.15739 [D][U][F][S][L][A][C] >>15740
File: e754af193bf6eeaaa8ede07c71f68c2e0f6b49a476a45717ba0a1e4aa76fd3da.jpg (dl) (328.57 KiB)
Asuka, where the FUCK is picochan? Get it running pronto, we have some business to discuss (picochan development related).

Mods pls don't remove/autosage until Asuka responds or until picochan is up.

Nanonymous No.15740 [D][U][F] >>15741
File: a133e12cb76864851fd177c5deb7f9c27abcaecf917319c15a15b208347ad102.jpg (dl) (26.01 KiB)
>>15739
This is why happas are inferior to whites.

Nanonymous No.15741 [D] >>15742 >>15743
That was a testing instance, you fool. I already told you when it went up that it'd be down by next week (which is now).
I don't think there will be any further testing instance until the opening of Hapachan on Jan 1 2020, which is hapas only and admitting to being white outside of dedotated boards will get your posts deleted.
>>15740
reminder that nanochan is proprietary software now. the source code link doesn't match up with what is actually running.

Nanonymous No.15742 [D][U][F]
File: 234b2f09ee2abe48b2c6921768bbe987b6f4a97406236af487b8119339735d4d.jpg (dl) (301.29 KiB)
>>15741
OK, I will post it here then. Mods/Asuka, wait a bit.

Nanonymous No.15743 [D] >>15744
>>15741
>which is hapas only and admitting to being white outside of dedotated boards will get your posts deleted
oh boy, what happened to you saying that there should be no rules and people should be able to post whatever you want without getting deleted?
you are such and hypocrite faggot

Nanonymous No.15744 [D]
>>15743
whatever they want

Nanonymous No.15747 [D] >>15748
Oh did those internment camps trigger you? Poor hapa.

If only the average normie could see the racial identity of /r/hapas manifesting such as yourself, then they would realize that racial consciousness does not make your IQ lower or place you at an intellectual disadvantage. The real reason whites fear "racism".

By all means. Fag it up in public. Hapa.

Nanonymous No.15748 [D][U][F] >>15749 >>15754
File: 9f92fef202132fb2ec4224736139573bbc1a188fd7aeec55b007230b1f67d715.jpg (dl) (1.32 MiB)
>>15747
>Hah you better be scared of me.
>I'm a big strong aryan man!

Nanonymous No.15749 [D]
>>15748
Add your portrait in that collage, billy.

Post link insertion Nanonymous No.15750 [D][U][F] >>15751 >>15752
File: 42ffa37fee65df6c60da484c5c50d4b80cbbccdefb1ba01b33ea7ebf75658b31.jpg (dl) (376.72 KiB)
I will start with the simple demonstration instance.

https://pastebin.com/GdbF8bL7 (789.html)
https://pastebin.com/A1kVj1sC (crap.css - do note that it has to sit in 789_files directory, sorry about that)

I've been thinking about how to make the no-JS post link insertion into a comment field real, and I have come up with this. It works via the old checkbox+label trick, where we can check the boxes corresponding to already-made textareas with text in them. This was chosen as the way because ::after and ::before pseudo-elements do not work with textareas.

The intended behavior:
- a user clicks on a link (1 2 3 4) and it brings out the postform
- a user clicks on a "No." and the respecting textarea with text becomes visible; repeated clicks will make it hide/show again; clicks on different "No."s will bring up different textareas (you can have more than one visible)
- as a curious effect: you can click on a "No." and then on a link, and the textarea will be already visible
- other than those, it just works normally

Report if you have any problems with the intended behavior.

Now, I understand that it looks kinda silly, but I personally find it a usable way to make such posting. True, it will require changes in the HTML-generating code and it will bloat the pages a little bit. Also true, something needs to be done about those multiple comment fields. If you want to accept the demonstrated idea, I suggest these textareas be concatenated into one post by the server or something, though we'll have to nuke the empty textareas then since they will not be really empty.

Personally, I think it's too crude to propose as an idea for a solution, but maybe you can think of something better. Thank you for your interest.

Nanonymous No.15751 [D][U][F]
File: ae2799ef8238236c0ddf4aa0f726f10d749f266018e186b90902173f35dfa147.jpg (dl) (349.04 KiB)
>>15750
Also maybe you can <label> in such a way that we can click on a link and flip a checkbox. I wasn't able to do that, hence the "No.".

Nanonymous No.15752 [D] >>15753
>>15750
That's fucking gay. What if you
>click on a post number
>write something
>click on another post number
Then you will have two seperate textareas.
It won't work and it's gay. There is NO good way of doing this without JS and so your request is denied.
I've already thought about this a shit ton and all possible solutions are bad.
There is no way to modify the contents of a textarea without having them prefilled by the server, and that will add too much cruft to the HTML.

Nanonymous No.15753 [D][U][F] >>15758
File: 511e7a5aef80157e2ca03b9f0b62dc5304c4b3213d14bfb6b64c51aa41a06458.jpg (dl) (367.60 KiB)
>>15752
>Then you will have two seperate textareas.
I think it's usable TBPH. As I said, you just have to deal with it on server-side somehow.
> There is no way to modify the contents of a textarea without having them prefilled by the server, and that will add too much cruft to the HTML.
How much is too much? It's some numbers and some rules, probably comparative in size to a new post with all its markup and stuff (not counting content, which can be large). I understand that you can "prefill" the forms with more than post numbers, now that would be crazy (I know imageboard software that does this).

Though, as I said, I agree it's kinda silly.

Nanonymous No.15754 [D][U][F]
File: 0ac70b94464e2158708e046474be976c27d2bee4905c31527fb4951c445263c2.jpg (dl) (87.99 KiB)
>>15748
Those soyboys are still a head taller, weight 50lbs more, have a stronger jawline and 2" bigger dicks than the average Chink bitch.

Oh and they would get laid in Asia before hapas.

Nanonymous No.15755 [D][U][F]
File: cf8d66b35a5e4ab6fc8a381138803df474933e082284572f82d2585520342dad.jpg (dl) (331.69 KiB)
Though one thing that it WILL do (which is probably unacceptable) is that older browsers/not supporting the hiding of elements in such a way would just show ALL textareas, which would be absolutely crazy on long threads. Imagine scrolling past 200 textareas ROFLMAO.

Nanonymous No.15756 [D][U][F]
File: bf1fe08894957247c9d28d7a3abf92b30901e540f5a65b5baa5c1dd104631988.jpg (dl) (132.34 KiB)

Nanonymous No.15757 [D][U][F]
File: 50113ac3f225b536de63e28214adeb478cc1e63d4a832accd876b390ccb7967f.png (dl) (8.57 KiB)
No matter how much you shill your shitty website none of our users will go there.In the end you will still come here and run your filthy gook mouth

Nanonymous No.15758 [D] >>15759 >>15760
>>15753
You see, this is why white people shouldn't be designing shit. Sometimes you have good ideas, but then you come up with a total SHIT idea like that one.

Nanonymous No.15759 [D] >>15761
>>15758
This entire thread was a total SHIT idea tbh. What's wrong with emails?

Nanonymous No.15760 [D][U][F]
File: aba80767a3677d961df96ff7293ae98701ea5597b06b7a68ef24a82f3d9f2d49.jpg (dl) (399.75 KiB)
>>15758
I didn't DESIGN anything. I had an idea. If you think ANY idea involving some prefilling with server is bad you shouldn't have accepted my previous idea at all and your software should've been static HTML only. If you don't think so, you didn't really convince me why it's such a bad idea. Even 15755 is pretty weak TBH because if we don't utilize the power of modern CSS, we cannot have the advantage of a hidden floating form and we could design posting like "click->go to a separate page prefilled by a server with full quote of a post and everything->post from there". Arguably, replying to multiple posts in one isn't a good idea for a discussion anyway, though my idea even makes it somehow convenient.

Nanonymous No.15761 [D][U][F]
File: d9059ebe6d60576736eaca7d1f8f7d9b7fb0cced4ae63bb24af4afb57a32064a.jpg (dl) (325.51 KiB)
>>15759
I don't have Asuka's email.
Anyway discussing such stuff in public is probably better anyway. This isn't confidential at all and others might have something to add.

Nanonymous No.15762 [D] >>15765
CSS is supposed to be able to hide images and add new images after it, which is what was used for the inline images.
CSS is NOT supposed to insert random shit into textboxes, at all. No matter how far you bend the rules of what CSS is supposed to do. Neither should you try to get around that using an ugly nigger-ass solution like "hurr just make 1000 textboxes with random text in it and then somehow join those together server side later"
there are 100 reasons why this would be shit
>if you reply to multiple posts you can't easily edit them together
>if you reply to multiple posts with the same text the server has no way of knowing which posts you replied to
>document bloat which slows down rendering
>more complexity
and last of all
>it's fucking useless just type the number by yourself you lazy cumskin

Nanonymous No.15763 [D]
>>17562
>it's nearly 2020
>autistic webdevs are forcing posters to complete pseudo-captchas for the replies to be linked correctly
>the absolute state of society

なのにもうす No.15764 [D][U][F] >>15766 >>15767
File: 60965909334eb8ca2b524ba602012d9fdd932637a775666351c35669697ed50c.png (dl) (1.11 MiB)
If you want my opinion these kind of css hacks are not really worth it after a certain point, this is the reason to why i stopped developing the nanochan Dark userstyle and started developing the nanochan X userscript, if you want these kind of features and usability you need js, adding a bunch of textareas and bloating the html is a bad idea(it also breaks text only browsers), asuka-chan css image inlining trick is pretty neat cause it doesn't have any side effects, while the floating postform is a proper use of css, not really an hack.
Like if you care that much about post number insertion just use the small userscript i provided you(https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/Media/136aebd9976e2e9bdb1eba7177f83ae4295cedf52b18bd2cb900090a9d037694.txt), adapting it for picochan should be trivial.
Btw your solution doesn't allow to insert multiple quotes and doesn't allow you to insert a quote inside text as far as i understand.

Nanonymous No.15765 [D][U][F]
File: 0c6eed2edae4fb67ebfd7de9eee08a8f5b15a751d63113e1e892d1f465823ae2.jpg (dl) (273.33 KiB)
>>15762
>CSS is supposed to be able to hide images and add new images after it, which is what was used for the inline images.
That was a "generally accepted" hack, CSS messing with layout that much is pretty crazy if you ask me. I mean, CSS can alter what is and what is not loaded, and that's not good. CSS can fuck with layout so much the page may become unreadable.
Also you not having <a> elements on top of those pics actually makes your usability quite bad, and I stated it as soon as I saw it.
> CSS is NOT supposed to insert random shit into textboxes, at all.
My guess is they will add something allowing this into CSS eventually.
>Neither should you try to get around that using an ugly nigger-ass solution like "hurr just make 1000 textboxes with random text in it and then somehow join those together server side later"
You could also drop every textarea with a length lower than expected. It shouldn't be much of a concern how it's done IMO.
>if you reply to multiple posts you can't easily edit them together
You can, in separate textareas.
>if you reply to multiple posts with the same text the server has no way of knowing which posts you replied to
Well, maybe something can be done about this case. Like quickly cut-pasting from one textarea to another by a user. I agree that it's worse than having a JS for this regarding usability.
>document bloat which slows down rendering
Go static pal, your rendering will be awesomely fast. Right now you add some custom CSS rules for every picture posted inline.
>more complexity
"Worse is better" is not a consistent ideology. It's bad to have overly complex software, but introducing complexity per se isn't bad.
>it's fucking useless just type the number by yourself you lazy cumskin
I think it's worse than my proposed idea usability-wise, that's all about it.

sakamoto ## Nanochan Administrator No.15766 [D][U][F]
File: 149cd1cc69179f6b48ff194e47b5053b28d11fea91932c8a08db2944e5a62841.png (dl) (114.97 KiB)
>>15764
>asukafag's perfect design works everywhere with backwards compatibility from the shittiest text browsers to the newest firefox
>coding and planning done with precision and elegance
>speed, simplicity, security: all implemented to a high standard of quality and dedication
As a fellow (((white man))), I believe it is time to acknowledge hapa superiority. I will be handing over the nanochan keys to asukafag because he is muy gebaseerd und akapirudo.

Nanonymous No.15767 [D][U][F] >>15768 >>15771
File: a8367e62e4a7e458cefad06b09e2df73e54c87ba63180457b0cc1ec486fa8c00.jpg (dl) (368.52 KiB)
>>15764
Don't repeat after Asuka.
>asuka-chan css image inlining trick
Is bad. It doesn't allow <a> references to be put on top of it.
>it doesn't have any side effects
It does. Loading on-click is a side-effect if I ever saw one, although a desirable one.
>Like if you care that much about post number insertion just use the small userscript
The sole fact that you have too loop over already loaded document disgusts me on deeper levels of my existence. xD
Anyway if I cared more I would develop a better solution. I just think it's good enough™. I would totally make an imageboard like this. xD
> Btw your solution doesn't allow to insert multiple quotes and doesn't allow you to insert a quote inside text as far as i understand.
I don't need it. Simple JS for numbers only doesn't do it either.

Nanonymous No.15768 [D] >>15769
>>15767
>HURR IMAGE INLINING BAAAAAAD
Click the link if you want to open the image in a new tab.
Not even 4chan or 8chan puts the <a> tag over the expanding image, because it's impossible. How can the browser tell whether you're clicking it to expand or clicking it to open in a new tab?
Listen here faggot. You CLICK THE LINK to open in a new tab. You CLICK THE OTHER LINK to download. And you CLICK THE IMAGE to make the image bigger. Understand?

Nanonymous No.15769 [D][U][F] >>15770
File: 4c47009cbaed078da80222bee504d3ee7be6fc3878bdcaf25062f94b49a39ca0.jpg (dl) (340.05 KiB)
>>15768
>How can the browser tell whether you're clicking it to expand or clicking it to open in a new tab?
Left click to expand, middle click to a new tab.
>You CLICK THE OTHER LINK to download.
It's too smol, too much effort pixelhunting. xD
>And you CLICK THE IMAGE to make the image bigger.
Took me 30+ seconds to load the image over Tor, thanks.

Nanonymous No.15770 [D] >>15773
>>15769
>Left click to expand, middle click to a new tab.
You think the browser is really smart enough to do that? That requires javascript at least, and as other imageboard software even cancerous shit like 4cucks doesn't do that, I don't think it's really possible.

なのにもうす No.15771 [D][U][F] >>15772 >>15773
File: 2a51a7e31d1a0b3fc90b814cfa3a488dd46490ea5b0985bd2a3d4a25e3cef917.png (dl) (859.34 KiB)
>>15767
>Is bad. It doesn't allow <a> references to be put on top of it
I think you can still do right click and "View Image", i'm not completely sure actually but even if you can't it's not a big deal. future picochan X will not have this problem
>The sole fact that you have too loop over already loaded document disgusts me
Lol are seriously implying that rendering one textarea and one checkbox per EACH post, remember that those are really heavy html elements and they come with all sort of events embedded in them, and bloating the html is more performant than running that small and elegant script? Think again. What that script does is just adding a simple event listener and handler to each post number click event, this means that no extra events are added, and the event handler function runs only when you click, both the initialization and post number adding runs in few milliseconds without breaking or adding anything.

And if i really wanted to i could further optimize that script by using event delegation(https://javascript.info/event-delegation), which would mean using only one event listener and handler for the whole thing.

Nanonymous No.15772 [D] >>15775
>>15771
>running javascript is ok goy. it's only a little bit!
Fuck off moshe

Nanonymous No.15773 [D][U][F] >>15775
File: 582b7a08d49f37ac9e02d2c3fb1a0371a2e6c1982dfc5bc060a76fdf32442626.jpg (dl) (322.11 KiB)
>>15770
>That requires javascript at least
It probably does. The point I want to make is that between noJS image scaling and clickable-to-new-tab images I will choose the latter, especially on slower links.
>even cancerous shit like 4cucks doesn't do that
I don't know about 4chan, but there is/was imageboard software doing that.

>>15771
>I think you can still do right click and "View Image"
…to view a thumbnail, yea.
>implying that rendering one textarea and one checkbox per EACH post
I don't know how exactly heavy they are, though I suppose you're right about them taking more memory for the state saving and what not. Though that JS would also add a specific event to EACH post, so I really don't know what is more bloat.
>bloating the html
All that shit is basically hidden, so I dunno how much it's going to take visually. Anyway an uneducated guess that it slows the rendering 5% tops.
>both the initialization and post number adding runs in few milliseconds without breaking or adding anything.
You also have to load (well you don't have to if it's user JS) the script and execute that shit after all static rendering of the page is done. I dunno if it counts as DOM editing and how much it takes, but it is just disgusting if it can be done statically.

Nanonymous No.15774 [D]
I like how this got around being /meta/ by being off-site. Heckin autists.

なのにもうす No.15775 [D][U][F] >>15776
File: 68137af1adaac3fb2004311df1d3098111bbb7831631a0899efe7fbd64f00ffa.txt (dl) (2.13 KiB)
>>15772
404 argument not found, you can do better asuka-chan.
>>15773
>…to view a thumbnail, yea.
What i meant was: you inline the image, and then you do a right click and "View Image".
Anyway there is no way of doing what you want without using javascript or a userscript.
>I don't know how exactly heavy they are
Short answer: they are heavy.
Long answer: it depends on lot of stuff, form elements are not like any other html element, there is no standardized implementation of them so they're performance is browser implementation dependent, or in some cases, for example checkboxes and drop downs it's even operating system implementation dependent(crazy right?), anyway the consensus between webdevs is that it's not a good idea to use lots of them.
I'll give you a small personal anecdote to prove it.
Nanochan X has it's own configuration form and it has lot of configurations options, and by lot i mean a lot, there are 22 configurations categories and 269 configurations options, the way you configure nanochan X right now is just by modifying the underlying JSON object, but in a previous version i was autistic enough to try to add user friendly form controls for each configuration option, so that means that if the configuration option was a boolean i added a checkbox to the form, if it was a string i added an input or textarea to the form, if it was an enum(or the equivalent with strings in js) i added a drop-down to the form, i repeated this for all 250+ configurations options, needless to say at the end the performance of the configuration form was completely unacceptable so i changed it in the way it is now, which in my opinion is even more functional xD
To make it short don't use too many form elements it's bad for your rendering engine trust me, event if they are hidden the events and code that runs them are still there and depending on browser and os it migth be really slow.
>Though that JS would also add a specific event to EACH post, so I really don't know what is more bloat.
>You also have to load (well you don't have to if it's user JS) the script and execute that shit...
Ok just to end this debate i tested the script i gave you and it takes about 6 milliseconds or less to initialize the script and 1 millisecond or less to insert the quote post number, do you considert that bad?

This was tested on >>>/meta/8 with 500 posts and i made use to not use a cached version.

Also since i was there i went back and actually implemented event delegation in the quote insertion script, you can find it attached to this post.
This means that there is no loop anymore and no "querySelectorAll" function needs to be called(that's a cpu and memory intensive function cause it returns a live list of html elements). Now with the updated version it takes about 4 milliseconds or less to initialize the script and always less than 1 millisecond to insert the quote post number. Not bad at all, i should use event delegation more.

You guys are obsessed with being anti-javascript to the point that you would rather use more bloated solutions even when it's just better and faster to use js sometime and if it's a userscript also completely secure.

Nanonymous No.15776 [D][U][F] >>15783
File: 8eef27409e3b065ce027a04891ab1c46da584c74f3d027377ebe31536fc40a04.jpg (dl) (375.75 KiB)
>>15775
>there is no standardized implementation of them so they're performance is browser implementation dependent
This says nothing. For all we care, ALL graphic stack is OS-dependent. What is being standartized is layout and some behavior; implementation, on the other hand, could always be a mystery.
> I'll give you a small personal anecdote to prove it.
Well, I find that nojs pages load infinitely more fast than js ones even when they are arguably heavy (long, have a lot of elements, etc). What you do is dynamically generate some additional shit with expensive DOM elements insertions, probably, since it's a javascript, so…
>do you considert that bad?
…if a static checkbox alternative renders faster, then yes, I do.
>For star-chan
You are going to spoil me dude. xD
> You guys are obsessed with being anti-javascript to the point that you would rather use more bloated solutions even when it's just better and faster to use js sometime
The "Good Parts" of JS are too thin.

Nanonymous No.15779 [D][U][F] >>15780 >>15782 >>15783 >>15790
File: e64b474e4fb7b73962f3d43cda49a5ee7d29c1eab81f13f50b74d593dba83aa2.jpg (dl) (357.70 KiB)
OK I did in fact expanded my example to 500 links. Do you experience the slowdown?

https://pastebin.com/eYCV91jZ

Nanonymous No.15780 [D][U][F] >>15783
File: e1b762d169de28f7a222f9713b2ecf2945d980046c44868a0167c57122ca3056.jpg (dl) (335.74 KiB)
>>15779
*did expand
200 KiB of bloat looks like about 30% considering the meta thread taking 750 KiB right now.
I dunno, I still would take it. 750 KiB is too long of an HTML document anyway. I would like threads to be like 200 posts max personally.

Nanonymous No.15782 [D][U][F] >>15784 >>15786 >>16654
File: bae6c0192151cc838fa41c4563e2e01b4aa13a932ee48ab89bba6baca83fb767.jpg (dl) (363.01 KiB)
>>15779
OK, I think there is noticeable slowdown on 500, though very little, and I did test it on 5000, which was actually slow as balls. I imagine JS would perform better in similar circumstances, given the 4ms on 500 posts as reported by Lain.

My solution is officially too shit. Case closed.

なのにもうす No.15783 [D][U][F] >>15790
File: 343c2820e636d7bd523ab70a31b1b4d7de41119fb883972215cebb70d510bcb0.png (dl) (536.20 KiB)
>>15776
>What is being standartized is layout and some behavior; implementation, on the other hand, could always be a mystery.
Yeah ok, but what i meant is that unlike a <a> tag which is basically the same everywhere, a <textarea> can be implemented in really different ways, even with completely different features, as an example look at the autocapitalize non-standard attribute in webkit on iOS https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea#Attributes it's just an example ofc, then there are elements which are completely different between browsers/os like:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
Forms are a mess in HTML.
>>15779
>>15780
>Do you experience the slowdown?
Performance wise it's running fine on my machine.
>I dunno, I still would take it
It's too quirky for me tbh, if you click on multiple "No" it adds multiple textareas in the postform and yeah as i said before it bloats the html a lot.
BTW i tested your page on Lynx and it's completely unusable which is pretty mean to text only bros.
Also how is the form supposed to be submitted to the server?
There is no submit button as right now.
When you click submit is it supposed to send all the 500 textarea values to the server?
How is the server supposed to know what of those contains the actual post?
Other than the possible rendering problems, it's gonna make the http post request bigger and the server side code more complex. Or i don't know maybe i'm missing something?

All of these problems when my little script does in less than a millisecond in 10 lines without breaking anything uwu

なのにもうす No.15784 [D] >>15786
>>15782
To make you feel better i actually didn't know about the checkbox+label trick, could be useful for other neat css-only tricks ^^

Nanonymous No.15786 [D][U][F] >>15843
File: ce2987611001eb6c434c686aa4be56f1752cc778bab0cb8b223fb5ae4f828ffe.jpg (dl) (390.89 KiB)
>>15782
> When you click submit is it supposed to send all the 500 textarea values to the server?
Yes.
> it's gonna make the http post request bigger and the server side code more complex.
Yes to both.
> All of these problems when my little script does in less than a millisecond in 10 lines without breaking anything uwu
Not my fault that webmonkeys cannot have that feature. Like, we're not asking for much here. Just some association between two elements, like an <a> and a <textarea> or an <input>, and just add some text in. We're not asking for something crazy like an absolutely custom action on click. We could have some attribute for that 20 years ago, I bet.

>>15784
> To make you feel better
I'm not upset.

Nanonymous No.15790 [D][U][F] >>15843 >>16654
File: 58e18b078f6ce4885fb8fe11b7a4caef3b33d2230766f8eedcba3bab70962db0.txt (dl) (158.56 KiB)
>>15779
the 1500-line long style is uneeded. just do this:
<style>
input[type="checkbox"] {display: none}
a>input {display:initial;}
input:checked + label > textarea{display:inline;}
</style>
this saves about 58k.

>>15783
>i tested your page on Lynx and it's completely unusable
fixable, add a link to the comments at the top, a link back up the form at the comments. see txt related.
>How is the server supposed to know what of those contains the actual post?
The checkboxes get sent to the server as well. Whichever textareas are checked should be included.
>size concerns
the size doesn't even begin to compare to images. The (completely extraneous) image you uploaded is half a meg. the thumb is still 37 k, multiply that by half the posts in this thread and you lose on size concerns for download as well. We would save way more bandwidth by banning avatarfags like yourself.
Also, the size of >>>/meta/8 is 125k compressed (670k uncompressed). txt related is 12k compressed (160k uncompressed), so about 10% the size. This is neglible.


I'm not decided on this. post ids are slowly growing longer, we see newfags have trouble with them and sometimes don't bother, even people who have been here for months get them wrong star.
However the complexity increase is real, and it is a very ugly hack.

3.07 MiB ?!?!?! なのにもうす No.15843 [D][U][F]
File: e01cfd5a722c5dcb40066b88f13715498c4098a9f9743ffb4fec0233db8ee17a.png (dl) (3.07 MiB)
>>15786
>Not my fault that webmonkeys cannot have that feature
>We could have some attribute for that 20 years ago, I bet
Oh it's really doable to connect two elements, like how a <label> element is connected to an <input> element, or form elements can be linked to a specific form with the "form" attribute.
The problem is how to tell the target element what to do without making attributes for each single case, if you use an imperative programming paradigm you end up with javascript, basically you tell the target element change your text into X with a function, if you want to do it in a declarative way you need to come with some sort of query to send to the target element that it's gonna change its "textContent" property, it sounds really doable in theory tbh, idk in practice how complex it would be.
Basically this is the same exact conversation we had here:
https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/g/6059.html#post6212
https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/g/6059.html#post6218

>>15790
>fixable, add a link to the comments at the top, a link back up the form at the comments
Not very comfy.
>Whichever textareas are checked should be included.
So you concatenate all the values from different checked textareas toghether in one string server-side?
>the size doesn't even begin to compare to images
Yeah if a post has an image that's the biggest bottleneck.
>We would save way more bandwidth by banning avatarfags like yourself.
Lol this is an imageboard, you want to ban me for posting images? Lame.
>we see newfags have trouble with them and sometimes don't bother
I noticed too, but this solution is so convoluted that it's just gonna make it worse.

Nanonymous No.15861 [D]
Ladies and Gnetlemen. The reason we have to solve captchas. Give it up for ASUKAFAG!!!

>"BOOOOOOOOOOOOOOOO"
>"KILL IT!!!"

minor notes Nanonymous No.16654 [D][U][F]
File: 87b38bee97801bea1446488fe538f6912e7e003b94d1687eac44de6a82832f91.jpg (dl) (306.11 KiB)
>>15790
>the 1500-line long style is uneeded
Indeed it isn't. It may not look like it, but I'm extremely unaware of CSS possibilities. I don't know shit basically.
With that optimization of yours the insuferrable lag on 5000 mentioned in >>15782 becomes very much bearable actually. It goes from over 10 second to slightly over (maybe even under, it's feeling based) 1 second delay in worst cases of bringing a textarea up. Form comes up pretty much without a delay (or with a similar delay of about 1 second) as opposed to a "non-optimal" 5000-version. Given a sheer number of "posts" here, I think it's as optimal as it gets with this crazy solution and possibly comparable to JS performance. I mean, 5000-post thread will surely lag pretty much everything.

It is not a proposal to employ this though, it's just a note that apparently CSS implementation in my browser doesn't work well with a lot of CSS-ids employed, so it has nothing to do with a number of textareas as suggested earlier.