Maybe we should just fully replace the white circle emoji with the red X emoji?
3 Likes
My thought is that the uniform use of circle emojis more closely resembles the square Wordle score, which I rather like.
Then again, the use of circles is already a departure from the Wordle squares (presumably to resemble the circular stones?) so maybe the further departure by not bothering with uniformity wouldnât be a big deal.
Maybe the instructions donât have to specify both, since the emojis are primarily there to share the score afterwards and not to guide gameplay, right?
3 Likes
Iâve sent a pull request with the new layout, and I bumped the minimum panels height and width up to 350 pixels. These are options that can be specified as attributes of the div in index.html, making it easier to tweak these further, if needed.
1 Like
I realized when considering some different variations for the Fusekle game that I donât actually know how to apply the âPolite triangleâ convention in all positions.
My understanding is that this is the polite triangle where you should place your first move:
(though Iâm not sure how many people think like this on 9x9, the original logic for picking the upper right corner on 19x19 doesnât really apply here)
But how should black choose between A and B in positions like these?
If I was picking a canonical orientation from scratch, I would use lexicographic order on the coordinates: A1, A2, A3 ⌠J9, but that gives a whole different polite triangle.
So does it make sense to just use the lexicographic order reversed? J9, J8, J7 ⌠A1.
(not to be confused with reverse lexicographic order, which is A1, B1, C1 ⌠J9)
(edit: actually donât cite me on that, there seems to be some disagreement about this definition)
This would make A the canonical choice in both diagrams above. Iâm not sure this feels ârightâ to me, but I could see myself playing either one so it doesnât really matter. Does anyone else have an opinion on this important issue? 
2 Likes
For this image:
I would think that B would be more natural, if fall back on the âlower triangle is preferred in cases of symmetryâ.
For this image:
Iâm less sure, but maybe we could prefer the bottom or right half in other cases of symmetry.
Loosely speaking, for a move where there are other symmetrically equivalent moves, prefer (in the following order):
- Polite triangle (if possible)
- Lower-triangle (if possible)
- Lower-half (if possible)
- Right-half (if possible)
Otherwise, it is not a symmetric move (I think?)
However, these rules are completely arbitrary. For the purposes of presenting puzzles, you might want to have the software rotate and flip solutions, but the canonical orientation might help you better organize your curation of solutions.
2 Likes
Yeah I think having the program flip and rotate sounds much better than having to keep something like
while trying to solve it. It sounds like too much a headache for the person trying to solve it.
1 Like
Going clockwise starting on the line from E5 to J9?
Right, the rules arenât necessarily conventions for presenting the solutions on a 9x9 board, but rather for helping to maintain a curated list of solutions, while ensuring that one does not accidentally reenter a symmetric sequence in a different orientation.
However, for the 19x19 joseki dictionaries, I think they might follow at least a subset of such conventions, and so far, I believe our solutions in josekle have followed these conventions.
1 Like
I canât see the share buttons on my phone, the address bar is in the way. And I canât scroll down. I set up remote debugging and I fixed the issue by removing the overflow-y: "hidden" rule from the body. Is there any reason why that rule is in place?
1 Like
Can you share a screenshot? What platform (browser / OS) are you on? Itâs interesting that the address bar gets in the way of the share buttons.
The rule was added to avoid having a scroll bar show up at all, with the goal of having the entire interface fit within the viewport. I guess there remains some flaws, and maybe that CSS rule could be removed as fall back for some platforms where it is not working as intended.
Interesting, Firefox has a bottom address bar, and I guess the â100vhâ computation includes that as well, so I guess it would always block the bottom of the interface, given the current way of laying it out.
So, I guess removing the overflow-y: "hidden" rule (or replacing it with auto) from the body would fix your issue of the inaccessible share buttons, but would still require you to scroll the entire page just to access them. Ideally, Iâd want to interface to properly fit on all platforms while avoiding the need to scroll the entire page.
Iâll download Firefox for Android to debug future changes.
In principle there shouldnât be a scroll bar anyway, if the content fits the viewport. But I know itâs not always that easy when it comes to CSS. 
I hope thatâs not just a Firefox feature with the ever-growing mobile phones.
2 Likes
By the way, check out the âInstallâ feature on Firefox for the Josekle page. It basically puts a shortcut on your homescreen to launch the page like an app. The address bar is removed in that view, so thatâs at least workaround for now.
Maybe Iâm not doing this correctly then. It seems that the viewport calculation method that Iâm using (via the height: 100vh CSS rule added to body) is also counting the area including the address bar (and thatâs the case on other browsers too). However, on Firefox, since you cannot dismiss the address bar, the 100vh calculation is overselling how much vertical real estate is actually available.
On other mobile browsers, I found that with such a page, you can dismiss the address bar by âscrollingâ the entire page just enough to hide the address bar, while leaving the page properly filling the entire browser app area (basically the entire screen besides the OS notification line, and maybe the bottom OS âback/homeâ navigation buttons). This works currently for Chrome, Brave, and Opera (see @Groinâs posts above), even thought the overflow-y: "hidden" rule is present, since one is not really scrolling the page, but rather just shifting the view to hide the address bar.
I wonder is there is just some way to get mobile Firefox to hide the address bar, but Iâm not familiar with that app.
That works on Firefox too, if the page can be scrolled at all.
2 Likes
some recent version of ios too. the share buttons are hidden on my phone too. I can kind of scroll around to find them
I wonder if itâs easier to just put all the post solve stuff in a pop up
2 Likes
That would be better, but pop ups are at least not trivial.
On another note: I think thereâs just not enough space for the buttons, the tree and the hints on mobile to fit it all on the screen. Maybe we should make use of scrolling the panels-panel as a whole or even the whole page. Or implement an accordion panel to allow switching between hints and tree.
1 Like
Yes.
Main problem then is to make a screenshot for posting here. So i favorize the full page scrolling which allow a long screenshot. Till now i was lucky to solve quickly too.
I dunno, seems easier than trying to get CSS to play nice with all screen sizes⌠I feel like the board &tree are enough to play, then the hints list and buttons are visible after solving would be a good compromise
Currently the hints list contains the infos about sequence length, that would maybe need to change.