Rewrite / Redux / Version 2 / etc

[zixaphir]

Rewrite AppChan from scratch starting with a clean state.

This issue is to discuss what should be changed, what should be kept, and various other discussions related to a possible Version 2 of AppChan.

[zixaphir]

@MayhemYDG, @disappoint, @seaweedchan, @aeosynth, @shadertest, @kupaka, @ferongr

If I missed anyone, I apologize.

[aeosynth]

one cool thing to decide, is if instead of writing straight css, we write in a language that compiles into it, and if so, which language to use - less and stylus are big ones, and there are more here, including one that I wrote, ccss (which I don't really like).

[zixaphir]

@aeosynth: I would like to move to a metalanguage in the next version of AppChan, so I am fine with this. I am leaning more towards less right now, simply because I prefer the name and don't really see too much of a difference between Stylus and Less at a glance.

[nstepien]

what should be changed, what should be kept

Support only 4chan X, drop support for anything else along with default 4chan.

[zixaphir]

Meh. I like how it is now. Anything new can be added into it or replace existing portions of AppChan. Its not like a program or an OS where it can benefit from being completely redone for resource usage.

However, it is an unorganized mess. I would like to move towards it being organized in a way that is at least a bit more rational.

[aeosynth]

stylus has significant indentation, less doesn't.

[zixaphir]

Support only 4chan X, drop support for anything else along with default 4chan.

A possibility, though I would like to keep 4sight supported, simply because I find it to be pretty cool, though the archives accomplish this much cleaner.

[zixaphir]

Organizing isn't really about removing or changing, though.

I can guarantee you that AppChan has a lot of CSS that I don't rightly remember the reasons for adding. That, and a lot of things that are accomplished with the current CSS could be accomplished better, especially CSS related to the postform.

[zixaphir]

Also,

Anyone got any criticism of the current side bar? I was thinking of making it a bit wider.

[nstepien]

As long as it's compatible together.

[nstepien]

I was thinking of making it a bit wider.

Make a responsive userstyle; when the screen is too small, turn AppChan compact.

[aeosynth]

I don't use appchan specifically b/c it has a sidebar which takes up space my expand images could be filling.

[zixaphir]

I don't use appchan specifically b/c it has a sidebar which takes up space my expand images could be filling.

Margin: No?

Still doesn't leave much to discuss. If in organizing you find lines that don't actually do anything, delete them. That's pretty simple. Even the postform redesign you want to do doesn't require a rewrite of the style as a whole.

It's more like a milestone than an actual new version. I am just using the word version because it's well understood to mean "better".

[zixaphir]

I just had an idea, actually. If we can find an element that AppChan plain doesn't use in 4chan that is above everything (like table[width=100%] in replies), we could overlay it over the sidebar and then make the sidebar hide except when hovered. It would have to be an option, of course, because it would work hackish at best, but it would be interesting.

Actually, I could even use something like body::before and have it alter the padding of body as well, thereby completely removing the sidebar when not in use. I imagine that would be finicky, though.

And that would work until focusin or whatever is supported by Fx.

[zixaphir]

@seaweedchan: Right now I just wish to discuss the possibility of redoing/reworking AppChan. When I/we get to the point of actually writing, I'll start a new branch for it.

[aeosynth]

you don't need a new repo, just a new branch. 4chan x currently has 4 code branches, plus the gh-pages documentation branch.

[nstepien]

And that would work until focusin or whatever is supported by Fx

Uh... focusin is like :focus, except it sends the event to all of its parents one by one. So when the #qr receives that event, we can apply the class we want.

What you want here is to apply a class when one random element is hovered. Which can be done with mouseover, but it gets complicated. We can stop the event to bubble (send to its parent) when you hover the delform for example, but it gets too specific when you use the QR fixed or static. You're better off making your own userscript at that point, since it's AppChan only.

[zixaphir]

Well, you obviously knew what I meant. Anyways, it's hover and it's on a psuedo element that sits above the document tree. I'd just have to do something like

body::before:hover ~ * ... { ... }

[zixaphir]

Actually, now that I think about that, that probably wouldn't work, since pseudo elements are more or less considered extensions of the original element. It would probably set off whenever you hover over any part of the body. Eek, never mind.

[nstepien]

I'm afraid so, yeah.

[aeosynth]

merge http://userstyles.org/styles/48538/4chan-4chan-x-css-defaults into appchan plz

[zixaphir]

merge http://userstyles.org/styles/48538/4chan-4chan-x-css-defaults into appchan plz

...why?

[aeosynth]

just to have everything in one place. isn't appchan essentially just a collection of css tweaks, plus some color schemes?

[ferongr]

Eh... A resizable (in width) sidebar, textbox and slideout threadwatcher would be cool, but I don't see any reason to re-invent the wheel, just perfect what you already have.

[zixaphir]

A resizable textbox would be guaranteed to break all slideout options.

I don't understand the point of a slideout threadwatcher, but I could go for a bubble-y layout and turn the sidebar into a group of slideout elements with tabs, similar to how Tabbed Slideout works and change from a sidebar to a slideout menu. Another cool thing this would allow is complete integration of navigation, top and pages, into the "side tabs"

[ferongr]

a group of slideout elements with tabs

Just no, performance is killed when you have a bunch of elements getting animated around. A slideout threadwatcher makes sense because after a number of threads it eats into the head of my beloved Tenshi.

If you could make the message textbox proportional, you could have a way to resize it if you can make the sidebar itself resizable. As you drag the whole sidebar, the textbox would grow both in width and height.

[aeosynth]

couldn't you just add a fade gradient to the thread watcher, which disappears on hover?

edit: and give it a low z-index so it doesn't cover up the form

[zixaphir]

Just no, performance is killed when you have a bunch of elements getting animated around

They don't have to be animated. Moreso, even if animated, they would only be as such if you hovered over them to begin with.

[ferongr]

But fixed is better. Slideouts and shit are not good except when you have elements that grow in size with their contents (e.g. threadwatcher that can even overlap/underlap the fixed QR when I have 6 browser window tiled 3x2 column x rows)

[zixaphir]

I use slideout navigation on my own install of AppChan. In fact, really the only thing that would change is that pages and the thread watcher would be slideout. I'd probably move the logo text around a bit and make it less big.

Edit: I mean on my AppChan.

[ferongr]

but I could go for a bubble-y layout and turn the sidebar into a group of slideout elements with tabs In fact, really the only thing that would change is that pages and the thread

What exactly do you want to do?

[zixaphir]

Each element would be hidden offscreen and you could hover over a tab on the side of the screen that would slide it out. Each element would have it's own tab, similar to the one used by tabbed slideout, except that the tab wouldn't slide out with the element (because I decided I didn't like that) but would just hide itself instead.

[ferongr]

So there will be no sidebar? Meh.

[zixaphir]

Yes, it would deprecate the sidebar

[zixaphir]

Mind you, I am just tossing ideas around. This entire discussion is meant to be a thinktank for anything that could be added to AppChan to differentiate it from the current revision. I'm up for any ideas, and nothing is final.

[ferongr]

I'm not interested then, you can do whatever you want.

[zixaphir]

you can do whatever you want.

I cannot guarantee that you will like the results of that statement.

[ferongr]

I've already said that i like (mostly) fixed stuff in a sidebar. That's the reason I use AppChan (and the nicely tuned Yotsuba B style). Since v2 is about to take a different direction, what more can I say? If the sidebar is deprecated, as well as the fixed elements (mostly the QR I care about), I simply won't use it.

[zixaphir]

Again, I'm just throwing ideas out there. Intelligent discussion relies on both sides being able to state their reasoning without getting feelings hurt. Your opinion has not been disregarded and now I'd like to see what others have to say about it.

[zixaphir]

Pretty sure it would just be implemented as an option, no?

More or less exactly what I had in mind.

[ferongr]

Right, take the following ideas

If you could make the message textbox proportional, you could have a way to resize it if you can make the sidebar itself resizable. As you drag the whole sidebar, the textbox would grow both in width and height.

plus the

Do not deprecate the sidebar and fixed QR

idea as my contribution for now then. I'll just lurk for a while.

[zixaphir]

The problem with the sidebar idea is that the sidebar itself is neither an element nor do I have any reliable method of making it resizable.

Seriously, the sidebar is literally just some padding on the body element with various UI fixed positioned over it.

[ferongr]

Well, I don't have any ideas, though I still like the current state best.

[zixaphir]

Would you be ok with making the side bar some ~50px wider?

[ferongr]

Sure, there's plenty of horizontal space on my monitor.

[zixaphir]

Awesome.

One thing I could most likely include would be sizing options for the side bar. The current is around 250px wide, and we could add one for 300px. The only realistic problem would be the mascots, but with the new mascot implementation, I'm fairly certain we can resize them dynamically now.

[ferongr]

Uh... Center them? Why resize (I assume scale) them?

[zixaphir]

http://css-tricks.com/766-how-to-resizeable-background-image/

Probably something like

body::after { width: /*[[SideBarSize]]*/; }

Height should take care of itself.

Uh... Center them? Why resize (I assume scale) them? With most current mascots, we have full size images that are big enough to fill your entire browser window. As long as the browser's resize algorithm is decent, there shouldn't be any problem outside of concerns of wasted resources.

Besides, mascots look weird when they're off center. Centering them may work, but first I'd have to figure out how to go about that one (would be easy if CSS supported math, but it doesn't). May be able to, uh... cheat, though.

Something like

body::after { width: /*[[SideBarSize]]*/;
top: 0;
bottom: 312px;
right: 0;
left: auto;
background-image: /*[[background]]/*;
background-attachment: fixed;
background-position: bottom center;
background-repeat: no-repeat; }

[ferongr]

I'd just scale the mascots in Photoshop (or GIMP or any program with decent interpolation) to fit the width of the smaller sidebar option and be done with them. Saves memory too.

On 29 September 2011 04:57, Zixaphir < reply@reply.github.com>wrote:

http://css-tricks.com/766-how-to-resizeable-background-image/

Probably something like

body::after { width: /[[SideBarSize]]/; }

Height should take care of itself.

Uh... Center them? Why resize (I assume scale) them? With most current mascots, we have full size images that are big enough to fill your entire browser window. As long as the browser's resize algorithm is decent, there shouldn't be any problem outside of concerns of wasted resources.

Besides, mascots look weird when they're off center. Centering them may work, but first I'd have to figure out how to go about that one (would be easy if CSS supported math, but it doesn't). May be able to, uh... cheat, though.

Something like

body::after { width: /*[[SideBarSize]]*/;
top: 0;
bottom: 312px
background-image: /*[[background]]/*;
background-attachment: fixed;
background-position: bottom center;
background-repeat: no-repeat; }

Reply to this email directly or view it on GitHub: https://github.com/zixaphir/AppChan/issues/79#issuecomment-2233235

[nstepien]

http://slides.html5rocks.com/#css-background ?

would be easy if CSS supported math, but it doesn't

It does. width (or any size): -moz-calc(); -vendor-transform: scale(.8);