Josekle Development

I still need to fix this layout issue to avoid having some of the hints being cutoff as well.

I’ll mock up some alternatives to see how to fix.

crap I thought I had more time to filter out these really long ones

I really didn’t want folks playing in Discord etc who are not following these threads to think we’re trolling them, the difference is a huge jump from 11-12

3 Likes

Yep maybe it’s ok for someone who follow todays games, or classic games, and if this variation.is very popular or known. Otherwise even pros will give up.

2 Likes

I’m going to filter them right now, and actually change the #12 puzzle in the process. It’s early enough I assume most people haven’t seen it

thanks for the heads up @Groin !!

2 Likes

You can stop where i did it will be ok although i don’t think that tenuki is reasonable at this point :stuck_out_tongue_winking_eye:

2 Likes

I just removed anything that was longer than a basic joseki, for now. There’s a few repeats in there anyway, so I will get the code together to have the new collection this weekend. I’m scraping new OJE now and am up to 15 depth already, so should be ready with the data

spoiler for new #12

it got replaced with a takamoku one so people might think we are trolling anyway :joy:

4 Likes

I just tried dark mode for the first time and the text is basically illegible for me. Maybe light gray text on dark gray buttons would work, without the blue?

edit: wait am i insane? or did somebody just change it :joy:

1 Like

I just made a few tweaks that are live on my dev fork. Pull request sent to @okonomichiyaki.


So, I adjusted the CSS a bit to specifically address the Firefox clipping issue, while not having to enable scrolling for the page.

Further details

My approach actually involved setting Firefox specific CSS to set body height:100%, while retaining the body height: 100vh setting for other browsers, and avoiding enabling scrolling. The height:100% approach is used by several other page filling web apps (like Wordle), but has the slight drawback of always showing the address bar on most mobile browser. The height:100vh trick makes the page taller and allows the address bar to be dismissed on most mobile browsers, except for mobile Firefox. I wanted to keep scrolling disabled, since desktop Firefox was doing something a bit annoying by always showing the scrollbar (when in automode) and allowing the page to be scrolled by just a few pixels to show only empty white content.

Ok, this is now fixed with the buttons text being black. Apparently, iOS makes the button text blue by default. I didn’t realize this since most other browsers make the text black.

Ha! Yes, I changed it on my fork after your post, but I took some time before writing this post. To confirm that you are not just imagining it, you can see that the text is still blue on @okonomichiyaki’s main version (until @okonomichiyaki pulls the changes, at least).

3 Likes

Now the top is cut off. :grimacing:

1 Like

Huh, now that’s weird… So, I guess it’s not possible to scroll that into view, right?

How in the world is Firefox mobile choosing not to render the top? Which version of Firefox are you using? The odd thing is that works fine for me on Firefox mobile on Android.

Version 97.1.0. I’ll take a look with the debugger again.

2 Likes

What is going on? I’m using the same exact version? How do you debug the mobile version?

Do mobile browsers have a dev console for checking things under the hood like computed layout values?

I’m doing remote debugging to check what’s happening on my phone with my computer.

It looked like there was some problem with correctly recognizing/applying the Firefox specific code. I’ve deactivated the height rule and turned it back on, now it works even after I reload the page. :man_shrugging:t2:

2 Likes

So you just turned it off and back on again, and then it just worked…

Is the working now persistent across refreshes?

Sigh :green_circle::green_circle::green_circle::green_circle::green_circle::white_circle: good enough

2 Likes

Funny I also thought about this a couple of days ago. How to define if a sequence is “canonical”? Here’s what I came up with:

Given a symmetry line, we fix one side and demand that “the first move that does not lie on the line, must lie on the chosen side”.

The idea is to fix a side for each symmetry line, apply the resulting rule, and obtain a rigorous definition of which sequences are canonical and which not. However depending on the choice of sides, the set of canonical sequences might be empty.
One way to ensure that this is not the case makes use of the “polite triangle” you defined: For each symmetry line fix the unique side that intersects the polite triangle.
In this case i believe you end up with a minimal set of sequences with the property that any sequence can be transformed by rotation and mirroring into a canonical sequence.

2 Likes

Up to now it is. How often do you want me to refresh? :smile:

2 Likes

Well, just let me know if it ever breaks. Otherwise, I guess it was just a ghost momentarily passing by.

I think I understand your idea, but surely it’s much simpler to just fix an ordering on the intersections and always choose the first one among symmetrical choices?

(the particular ordering J9, J8, J7 … that corresponds to the traditional polite triangle could also be thought of as “play as far to the right as possible, and in a particular column, as far up as possible”)

But that prefers H9 over H1.

Perhaps there is some disagreement over what constitutes the polite triangle, I don’t think it makes sense to extend it to the lower half of the board. See for instance the diagram here:

1 Like