hey,boss,I have problem...the little image,the sample image and page number loading are slow while web page loading is all right (I mean the left and the top of page is normal,the right and the bottom is slow) ,what happened?
I use opera 12.02,my flash player and web speed are no problem,and three days ago everything is ok...
I use opera 12.02,my flash player and web speed are no problem,and three days ago everything is ok...
https://m.yande.re/ is online for testing.
Known issues:
Only 16 images
Firefox/IE doesn't work well with it
Chrome for Android seems to have some odd issues as well
Let me know if there's issues. Please note what browser/OS you are using when reporting.
Known issues:
Only 16 images
Firefox/IE doesn't work well with it
Chrome for Android seems to have some odd issues as well
Let me know if there's issues. Please note what browser/OS you are using when reporting.
With Firefox 16.0.2 (desktop browser) it seems completely broken.
The Error Console complains that Firefox doesn't support 'box-sizing'.
Did you remember to specify the prefixed 'moz-box-sizing' as well?
The Error Console complains that Firefox doesn't support 'box-sizing'.
Did you remember to specify the prefixed 'moz-box-sizing' as well?
box-sizing should already be taken care of by jquery...
"galleria-stage" "left:-10000px"
seems to be part of the issue in Firefox.
Firefox debug console says javascript exceptions were thrown on:
cloudflare-min.js:368
cloudflare-min.js:263
cloudflare-min.js:362
cloudflare-min.js:371
cloudflare-min.js:639
cloudflare-min.js:35
cloudflare-min.js:23
cloudflare-min.js:20
rocket.js:1
Error console now reports:
TypeError: i is undefined
Source File: ajax.cloudflare.com/cdn-cgi/nexp/aav=4114775854/cloudflare.min.js
Line: 36
seems to be part of the issue in Firefox.
Firefox debug console says javascript exceptions were thrown on:
cloudflare-min.js:368
cloudflare-min.js:263
cloudflare-min.js:362
cloudflare-min.js:371
cloudflare-min.js:639
cloudflare-min.js:35
cloudflare-min.js:23
cloudflare-min.js:20
rocket.js:1
Error console now reports:
TypeError: i is undefined
Source File: ajax.cloudflare.com/cdn-cgi/nexp/aav=4114775854/cloudflare.min.js
Line: 36
"infinite" scroll works...in a odd way, will figure out how to actually fix it later this week.
Scroll to last image, full screen it, then use arrow keys to navigate, it should load the other images not in thumbnail list.
Bugs...will be fixed one day...
Scroll to last image, full screen it, then use arrow keys to navigate, it should load the other images not in thumbnail list.
Bugs...will be fixed one day...
Just a question is it just me or anyone else is having issues with the "download" option from the pools neither Firefox (16.0.2) or IExplorer(9.0.10) let me download, Firefox says that they can't find the server at moe. Sorry if the question is not in the correct thread
there was a infinite redirect, it should be fixed.
Thanks a lot. Works fine right now.admin2 said:
there was a infinite redirect, it should be fixed.
The UI translations have been updated and considered complete.
https://yande.re/post?locale=zh_CN = Chinese interface *
https://yande.re/post?locale=ru = Russian interface
https://yande.re/post?locale=es = Spanish interface
switch back to
https://yande.re/post?locale=en = English interface
*Note Chinese UI URL changed.
Many thanks to the volunteers to translate the UI.
If you're interested in translating the UI to your native language, check out: https://www.transifex.com/projects/p/yande_re/
Thanks!
https://yande.re/post?locale=zh_CN = Chinese interface *
https://yande.re/post?locale=ru = Russian interface
https://yande.re/post?locale=es = Spanish interface
switch back to
https://yande.re/post?locale=en = English interface
*Note Chinese UI URL changed.
Many thanks to the volunteers to translate the UI.
If you're interested in translating the UI to your native language, check out: https://www.transifex.com/projects/p/yande_re/
Thanks!
Abusive bots was/is hammering the site, I've set a 2 request per second limit (with 3 request per second burst) on /post/* URIs.
I'm pretty sure no one /normally/ would go that fast.
I'm pretty sure no one /normally/ would go that fast.
We'd better make a discussion before changing user interface next time. The new menu is indeed annoying in some cases.
I don't even see any difference, unless you mean how the dropdown now auto opens rather than having to hold the mouse down on it and drag down, if so I actually like it.
I'm not particularly fond of this change either, mainly because the delay is much too short. The undesired sub-menu almost always opens when all I'm attempting to to is click and load one of the top links. That the sub-menu will open _after_ you click, just before the link loads, is yet another annoyance.
IMHO, the sub-menu shouldn't be appearing unless someone is purposefully stalling their mouse over a link from more than a couple seconds before they click. I'd suspect that if the hover delay was increased to at least 3 seconds, it would eliminate the majority of false positives. Currently the delay seems to be set to 1 second or less, making it near-impossible to _not_ see the sub-menu.
IMHO, the sub-menu shouldn't be appearing unless someone is purposefully stalling their mouse over a link from more than a couple seconds before they click. I'd suspect that if the hover delay was increased to at least 3 seconds, it would eliminate the majority of false positives. Currently the delay seems to be set to 1 second or less, making it near-impossible to _not_ see the sub-menu.
After edogawa changed it some I'm now ok with it. I don't care if it pops when I'm going to click the link because it won't block my operation at least, maybe still an annoyance for some people but just visually. Before it will indeed block images of first column when I'm just passing it..Cyberbeing said:
I'm not particularly fond of this change either, mainly because the delay is much too short. The undesired sub-menu almost always opens when all I'm attempting to to is click and load one of the top links. That the sub-menu will open _after_ you click, just before the link loads, is yet another annoyance.
IMHO, the sub-menu shouldn't be appearing unless someone is purposefully stalling their mouse over a link from more than a couple seconds before they click. I'd suspect that if the hover delay was increased to at least 3 seconds, it would eliminate the majority of false positives. Currently the delay seems to be set to 1 second or less, making it near-impossible to _not_ see the sub-menu.
3 seconds is too much of an annoyance for those who want to expand the menu.Cyberbeing said:
I'm not particularly fond of this change either, mainly because the delay is much too short. The undesired sub-menu almost always opens when all I'm attempting to to is click and load one of the top links. That the sub-menu will open _after_ you click, just before the link loads, is yet another annoyance.
IMHO, the sub-menu shouldn't be appearing unless someone is purposefully stalling their mouse over a link from more than a couple seconds before they click. I'd suspect that if the hover delay was increased to at least 3 seconds, it would eliminate the majority of false positives. Currently the delay seems to be set to 1 second or less, making it near-impossible to _not_ see the sub-menu.
Well whatever it's set to now is too much of annoyance for those who don't see any need to expand the menu except in rare cases. Considering the old sub-menu behavior, I'd say that applies to the majority of users. In all the thousands of clicks I've had on those links over the years, intentional clicks to open the sub-menu accounted for <0.01% of them.
At the moment the sub-menu has gone beyond just increasing accessibility, to the point that it gets in the way, and is generally an eyesore.
Other options:
1) If 3 seconds is too long, try a 2 second hover delay.
2) Instead make the hover delay configurable in user settings
3) Remove the hover functionality and instead add drop arrows which actually need to be clicked once to show the sub-menu, along with short delay auto hiding when the mouse is moved away.
4) Return the old click & hold behavior as an option.
Overall, either 2) or 3) would probably be the best compromise between accessibility, discoverability, and unobtrusiveness.
At the moment the sub-menu has gone beyond just increasing accessibility, to the point that it gets in the way, and is generally an eyesore.
Other options:
1) If 3 seconds is too long, try a 2 second hover delay.
2) Instead make the hover delay configurable in user settings
3) Remove the hover functionality and instead add drop arrows which actually need to be clicked once to show the sub-menu, along with short delay auto hiding when the mouse is moved away.
4) Return the old click & hold behavior as an option.
Overall, either 2) or 3) would probably be the best compromise between accessibility, discoverability, and unobtrusiveness.
About menu:
I'm one of those who actually like the "show on hover" function.
But why the background is white on mouse over? I mean, you are already using some kind of dark blue for highlighting tag suggestions (in the search).
So I vote for use that dark blue for menu hightlighting too. This also, thanks to the more armonic contrast will help to visually feel the menu less obtrusive.
@Cyberbeing:
#3 Removing hover behavior should be out of consideration, more than 1 click per seccond substracts fluency to navigation.
I'm one of those who actually like the "show on hover" function.
But why the background is white on mouse over? I mean, you are already using some kind of dark blue for highlighting tag suggestions (in the search).
So I vote for use that dark blue for menu hightlighting too. This also, thanks to the more armonic contrast will help to visually feel the menu less obtrusive.
@Cyberbeing:
#3 Removing hover behavior should be out of consideration, more than 1 click per seccond substracts fluency to navigation.
a kind reminder that having sub-menu shown doesn't prevent the link to be clicked.
Hover color has been adjusted to match overall site color palette (if such thing exist).
Hover color has been adjusted to match overall site color palette (if such thing exist).
nooooooooo it's like hell!edogawaconan said:
a kind reminder that having sub-menu shown doesn't prevent the link to be clicked.
Hover color has been adjusted to match overall site color palette (if such thing exist).
and edogawa, I think you should mention the reason to replace the old one (performance issue iirc?) then ppl would understand it more.
I don't like the new color, I'd really prefer the way it was.
It was requested by Shuugo iirc, who considered it not being 'intuitive' enough.fireattack said:
and edogawa, I think you should mention the reason to replace the old one (performance issue iirc?) then ppl would understand it more.
more like barely anyone knew about it.blooregardo said:
I don't like the new color, I'd really prefer the way it was.It was requested by Shuugo iirc, who considered it not being 'intuitive' enough.
There's alternative implementation to show the menu using dedicated button but I haven't figured how to style it without looking like shit.
It is, but I think edogawa also said about the performance issue in IRC i believe.blooregardo said:
t was requested by Shuugo
Ah, the interface is must better. The bullets for the drop down options along with standards. So far so good. The previous one was rather annoying.
With the recent change of the menus I also noticed a colour improvement across the entire site, the sort of salmon coloured text was always far too red in chrome (beta), but looked correct (or how I would assume to be correct) in Nightly.
The change with the clickable bullets for the sub-menu seems to work well. Though I do have to say that I preferred the aesthetics of the white background highlight it was using yesterday, but there is no significant problem with the current blended in color scheme either.
Thinking about this implementation a bit more, you could probably make the bullets only auto-hover, while keeping the text as normal links, like now. That would probably work well enough with minimal annoyance for people like myself who don't desire to access the menus often. Though I do see that menu drag 'n drop is once again supported, which eliminates the extra menu click, so maybe auto-hover is no longer needed?
Opinions?
Thinking about this implementation a bit more, you could probably make the bullets only auto-hover, while keeping the text as normal links, like now. That would probably work well enough with minimal annoyance for people like myself who don't desire to access the menus often. Though I do see that menu drag 'n drop is once again supported, which eliminates the extra menu click, so maybe auto-hover is no longer needed?
Opinions?
Excuse me, but I couldn't read all last news.
Is it possible to return hiding of explicit pictures if you are not logged?
Thanks.
Is it possible to return hiding of explicit pictures if you are not logged?
Thanks.
I think we should intercept direct links to images with the 'This is adult material' disclaimer if they are not logged in.Akio-sama said:
Excuse me, but I couldn't read all last news.
Is it possible to return hiding of explicit pictures if you are not logged?
Thanks.
Odd that when I'm logged out that I'm still getting explicit images blacklisted. Has it been changed?
admin2