 |
| ||
|
| Author | Message | Page: 9 8 7 6 5 4 3 2 1 [all][bottom] |
It's the same for a table: by default, it should only put stuff in cells. Everything at the top of the cell, with the text left aligned, the cells just as big as their content, etc. But if you want, you can center things, resize the cells, have some span multiple columns or rows...or have borders. Which is exactly the case for the tables on wikis for examples. The fact that on the main site you have borders by default is the problem, not the other way around. It may come from the fact that it's not easy to define what the border is supposed to be, so a choice had to be made between border or no border. And maybe it's a choice that will have to be made again. And there are arguments to go both ways. | |||||||||
HTML-based tables should work the way they always have. Easy Tables and Grids are a technology unique to RPoL. Two different things.
Not really. The whole point of Easy Tables was to make it easier to make tables without having to learn HTML. As I said before, anything you can do in HTML elsewhere you should still be able to do here. The standard in use, by the way, is XHTML 1.0.
I would respectfully submit the above assertion to jase for evaluation. We disagree. | |||||||||
Character sheets should now scroll rather than force the content wide. Individual elements within the sheet or the entire sheet might have a scrollbar left/right depending on the element. Easy tables and grids should also now side-scroll in messages and grids shouldn't reduce their width to try and fit in with the content Speaking of, I appreciate the enthusiasm around easy tables and grids. The simple fact of the situation is that the main website currently renders borders and I'm not about to change how they work. I can't make such a wide retroactive change and exclaim "surprise, all your old tables no longer have borders!". With that in mind you should now find your easy things now have borders. | |||||||||
| |||||||||
Thank you, jase. Is there a trick to getting a new color scheme to render in the responsive site? I've changed mine a number of times (I prefer a dark red scheme for use at night), but I seem to be stuck with the same old default pale blue set. (Flashpeak Slimjet Version 23.0.9.0 (based on Chromium 74.0.3729.108) (Official Build) (64-bit) under PCLinuxOS 2019.02...) | |||||||||
I think we've previously discussed schemes in this thread, they aren't working as I don't want to constantly update 16 themes. It's all fluid at the moment so I'm just sticking with the one theme. You can however create your own custom theme, just be aware that it might quickly get outdated (but I'm ok with that as now you have to edit it rather than me! :) | |||||||||
Thanks. Just to be clear, <table border="0"><tr><td>blah</td></tr></table> means to wrap the Easy Table/Grid content with the table border tags to control display width of border lines, as in: <table border="3"> <tr> <td> | Some quick Easy Table Content here | | </td> </tr> </table> would yield: and replacing the "3" in the above with "0" would not draw border lines at all. Neat! I'll add this to my articles. | |||||||||
| |||||||||
I'm going to venture a guess here: perhaps this is theme-related? The background for headers chooses the color for header backgrounds from the "header background" attribute of the theme in use. We know, from what jase told us, that themes, per se, don't yet work on the responsive site. This problem may fix itself given time? | |||||||||
| |||||||||
| |||||||||
I've deployed a rather large update to the layout for the informational boxes and tables, a lot have now been converted to the newer format (but not everything at this stage). You should notice that most of the informational boxes now take up the available page width but no more. This may result in some being wider than the text itself dictates, which I can worry about as a minor improvement going forward. There were about 100 old tables that have been converted to divs so I've undoubtedly messed up a few so please do let me know if anything's wrong. I did some other tweaks/changes along the way and though it was good stuff when I did it, however I don't have a clue what it was anymore! (c; I also made all the textarea (i.e. the area you use when submitting a message) as wide as the screen can cope. Lastly, and fairly importantly, I've changed the responsive points. Previously as the viewport width shrunk the content would rewrap and then if it went even narrower the menu would collapse, however now it's the other way around (and the way it should have been all alone). Content has the priority so the first thing to give way is the menu and then the content will wrap. If you want to see what I'm on about then go to the main menu or game menu and start reducing the browser width. First the content will squeeze up a bit and once it starts to get a bit too cramped the menu will collapse up to the top. Keep on going then the rows will change and you'll have the game/thread information over two lines rather than one. Enjoy (I hope!). | |||||||||
Which reminds me - is setting up the fixed header still on the to do list ? I think there was some suggestion that it might not be possible in the responsive format, but disabling fixed headers is still there as a user preference, so I live in hope. ;> The collapsed menus would work better with a fixed header ... currently there's a bit of scrolling required to find a menu (ie to move screen back to top or bottom as the case may be), but with a fixed header and menu icons they'd always be just be one click away. | |||||||||
I realise the menus do get left behind with all the scrolling which is why there's a "top" link (as well as main and game links). If there's other links that would be good in the footer then that's exactly what this thread is for! | |||||||||
I see the reasoning that I'm most likely down at the bottom of the thread, having read all the new posts and then I hit post reply ... and on the reply screen the menus are at the top with the compose message box, so I can easily open up say character sheet, game map and dice roller in separate tabs, so all the functionality is there. On the old site I open everything I'm going to need including the post reply screen from the game thread and then switch to whichever open window I need to go to first. So responsive layout is just a different way of working for me that'll take some getting used to. :> Main menu, game menu, top, post reply ... that probably covers most things. Unless we have collapsed menu icons in both header AND footer, which would give us everything at both ends of the page ! But that might be greedy. ;> | |||||||||
That kind of stuff I'd probably wait until after the responsive site is finished in its first form. Then all the outstanding feature requests before looking at any layout tweaks. Have tweaked a more more things. Input boxes should now use the site's font besides the "textarea" inputs (what I be using now) as that's normally better off with a fixed-width font. Should just make the prompts for subject, bios, character name, dice roll information etc etc just a little nicer. Slightly larger font too and increased the padding so it's not so squished. Also changed the game search on the main menu from an old table to a div/responsive friendly layout. Mostly the same look though as I didn't think it needed much tweaking otherwise. As (well, rather if) I get feedback on areas that need fixing I'll concentrate on them otherwise I'm now at the stage where I'm just working my way through the site to check each screen and fix them as I go. Main menu is obviously the first and then the signup/logon pages, create a game, game itself, viewing a thread and so on. | |||||||||
| |||||||||
| |||||||||
But that has meant an opportunity to find new bugs and other issues. I'm now using a device running Android 9.0 (Pie) and it's currently using Chrome 75.0.3770.143. I also tested this particular issue in Firefox 68.0. Bug Report: Chrome for Android doesn't play quite right with the "post message" screen. When you first enter the page everything is fine. Then when you press in the text box and begin entering text, the box expands slightly in size and covers most of the "preview/delay post" and "post message" buttons. As seen here: https://i.imgur.com/moyz7v4.jpg You can type normally. The buttons themselves still work, if you press the "preview" button either the small bit that's still showing or the area of the text entry box where the button is, it will work as intended. It does not work correctly if you have typed enough that the text entry area that covers the button now has text in it. In that case pressing the screen just puts the cursor where you pressed, you must instead press the small bit of button poking out the bottom to make it work. Once you have reached the "preview" screen the text box behaves normally, and the buttons are fully accessible. Entering/deleting/etc text in the box does not seem to trigger the issue, nor does subsequent presses of the "preview" button. When I tried to replicate this issue in Firefox I could not. Of the two browsers only Chrome seems to have this issue. I was running an old Windows Mobile 10 handset for the past few weeks in the interim, so I don't know if it's strictly a software/browser issue or something due to one of the updates to the site made in that time period. | |||||||||
- it's impossible to directly access private messages from The Cast menu, - on the Cast page the link for The Cast disappeared, but on the Character Details page, the link for that page is still there. | |||||||||
Menus certainly need a little tweaking, Imladir. Will see if I can do a little more. | |||||||||
Nothing urgent there obviously. | |||||||||
| |||||||||
... Have changed a the way the HTML/CSS works a bit, hopefully not much/any difference. HTML has this lovely way of calculating widths (and heights, but it's the width that's the kicker). An area has margin, border, padding and finally the actual content. If I set something to take up the page width (by making it's width 100%) then that's calculated according to the content and padding around it. Only those two. If I add a 1px border around this content then it's width is left border + 100% + right border. Horray, it's width is now 100% + 2 pixels.. i.e. it's wider than the screen and we have a scrollbar or overlapping sections. Even more fun when I try to make two boxes sit side-by-side by making their width 50% each. If I have a border then they're actually both over 50% so they're rendered one above the other. It's crazy and doesn't make sense. The way around it was to use a "calc" entry in CSS which has about 98% browser compatibility. You'd figure your border and margin and then set your width with "width: calc(100% - 2px);" or whatever you needed to shrink it by. Change the border or margin? Go back and edit the width as well. Painful and for me has never been intuitive. Anyhoo there's a CSS setting which is "box-sizing: border-box;". Knew and forgot about it until recently. This makes the box size calculations include the margin and border... oddly enough this is how IE6 used to do it. The nice thing about this option is the browser compatibility is about 99%. So... I've gone through all my horrible "calc" entries and removed them whenever possible, setting nice sensible widths of 100%, 50%, 33.3% and so on. Now it's all much easier. ... In amongst doing all that I fixed a bunch of other stuff. Honest. Problem is I can't remember what I've done... Added Earthdawn: Age of Legend and Zombie World to the dice roller. If you're using the responsive site you can now use these systems on the roller. People on the traditional site can see the entries in the log file but can't use the system to make their own rolls unless they switch to r.rpol.net. Stuff.. things, tweaked stuff. Have had a cold for over a week so it's hard to remember! See how stuff 'n' things are now, hopefully haven't made anything worse! | |||||||||
|
admin post | [top] |