CSS? Tabling the callins

[Pithikos]

Was wondering if the tag <style> is blocked. I am very sick of the navigation in the wiki. Takes just one hour to find a single function because there is no clean colorful distribution of the content.
I started embedding all functions(callins/callouts) into tables in wiki to make life easier but it's really hard for me to do so without CSS. Can I get I get access to some external CSS file? Styling every single td tag is a pain in the neck

Check http://springrts.com/wiki/Lua_SyncedRead
to see how easier it is to read if functions are inside tables.

[aegis]

especially when the table sticks out of the right side of the page...

[Pithikos]

especially when the table sticks out of the right side of the page...

That has not to do with the tables. It's due to the design of the website. Check this and you will see what I mean: http://springrts.com/wiki/Lua_FeatureDefs

The problem is that the whole div is in static pixels and probably it's set to hide overlapping text. Did anyone concider streching the whole thing a bit? We leave in the age of the 1080p screens. Having text squeezed to 1/3 of the screen is not productive. Or is anyone browsing the site by from a mobile?

As about the table I can't make it look clearer as it is limited by the external CSS.

[jK]

Please stop breaking existing pages!
You can create new ones if you want to experiment with different layouts.

Also a -1 from me for it, cause of what aegis said.
+0.5 for the explanation of the syntax, but it should be done in a separate page.

PS: We use Extension:CSS in the mediawiki.

[zwzsg]

Check http://springrts.com/wiki/Lua_SyncedRead
to see how easier it is to read if functions are inside tables.

No, it is not easier. In fact it is harder. Because the tables creates a lot and lot of extra lines, which is extra pixels, extra details, making it harder to concentrate on the content inside. Then there's the column titles, again extra noise making it harder to spot the useful info.

Having the function name in bold, the input/ouput in normal and nothing else, make it much easier to use.

Please revert asap!

[Pithikos]

Ok sorry for the mess. I now rolled back to the old page. Though I think a description/explanation MUST be present. Else a newcomer like me doesn't really know what each function does although most of you already know from years of experience.
Anyhow I think I will do my testing in wikibooks as just adding random pages in this wiki here is not so practical for the community I think.

Keep in mind that the table was just a suggestion. It didn't mean that tables should have borders or look at all like that. It was just a structure suggestion so that you can see the same attributes for each function in a clean row-colorful manner.

[Pithikos]

Check http://springrts.com/wiki/Lua_SyncedRead
to see how easier it is to read if functions are inside tables.

No, it is not easier. In fact it is harder. Because the tables creates a lot and lot of extra lines, which is extra pixels, extra details, making it harder to concentrate on the content inside. Then there's the column titles, again extra noise making it harder to spot the useful info.

Having the function name in bold, the input/ouput in normal and nothing else, make it much easier to use.

Please revert asap!

As about extra lines they are breakable intentionally for readability. It's possible to have everything like a junk but you have to consider readability VS page size. That's also a big controversial talk in programming. Instead of having the exact format of the output you could just have "table" instead of "{ [ruleIndex1] = {[ruleName1] = number value1}, [ruleIndex2] = {[ruleName2] =..". That would minimize a lot the text. Then you could either have a popup frame to popup when hovering over the "table" showing the exact format of that table or just having a link for each function that has all the information about the function.

Just because at the moment the layout looks minimal it doesn't mean it's optimal. It's lacking the description/explanation. So if I want to add that for each function there is no clear way to do that and in the long run the page is going to get messed up anyway.

Btw I noticed that many lines are sticking outside the frame still so someone should get their lousy arse up and fix it

[Pithikos]

Please stop breaking existing pages!
You can create new ones if you want to experiment with different layouts.

Also a -1 from me for it, cause of what aegis said.
+0.5 for the explanation of the syntax, but it should be done in a separate page.

PS: We use Extension:CSS in the mediawiki.

Thanks for that. First time I hear about it

[knorke]

Pithikos:
you can test formating and other stuff in http://springrts.com/wiki/Sandbox

And yes, I would like to see as much info on each function as can be digged up.

[Pithikos]

Pithikos:
you can test formating and other stuff in http://springrts.com/wiki/Sandbox

And yes, I would like to see as much info on each function as can be digged up.

Check this: http://en.wikibooks.org/wiki/Lua_in_SpringRTS/Callins

Doesn't it look AMAZINGLY practical? Plus it has Lua code coloring and you can sort the table on your own needs. And clicking on one function opens a new page devoted just to that function. Click on "UnitDestroyed()" to see what I mean.

[knorke]

looks good :)
my deepest respect and key to the cookie box if you make such examples and stuff for all functions and maybe other things (ie ceg effects)

[Pithikos]

You betcha I will!

Well at the moment I am making a script to batch-pass all functions from spring wiki into wikimedia tables(they use some special way for making tables). Kind of exhausting to copy and paste each function by hand.
But after that I will be adding more about each function on the fly when making widgets etc. But you can also add/change some things if you tested a function and saw that it works in a different way than described. It's wiki after all

[FLOZi]

I still prefer what we already have, and please revert all the crap at the top of http://springrts.com/wiki/Lua_SyncedRead, I have to keep scrolling past it. My wheel finger aches.

[Pithikos]

I still prefer what we already have, and please revert all the crap at the top of http://springrts.com/wiki/Lua_SyncedRead, I have to keep scrolling past it. My wheel finger aches.

You are free to delete what you want.. It's not like I have some copyrights or anything.
That "crap" is what is going to save time for some people.

[FLOZi]

It ought to be on a separate page.

[Pithikos]

Umm how? That text just explains the conventions used for each function in just that page.

[FLOZi]

The conventions are the same throughout the API wiki pages...

[zwzsg]

Oh to avoid the wrath of FLOZi (and me, and every other people who use those pages all the time), you should have two section in Spring's wiki:
- Lua command reference (for seasoned modders) = What we had on the wiki before you changed it. Condensed info.
- Lua command details (for beginners) = What you're doing, with comprenhensive explanation. Deiluted info, with enough redundancy to ensure n00b get it.

[Pithikos]

Well I changed it like it was before. Maybe someone should add a header to the page like "Reference.." because there is no way I could know that it was a reference page.

As about making a second page I think it will just add complexity. All functions(callouts) are already spred in 4 different pages(syncedCTRL, syncedRead, unsyncedCTRL, unsyncedRead). Adding a second page for each makes it 8 pages

I think it would be cleaner with just one callouts reference page and then maybe one more detailed page, but hey that's maybe just me . I will stick to wikibooks to avoid hammers. If someone likes the final look then it's just as easy as copy pasting the table as both are wikis and share the same rules.
I just find it a painful process for myself to find the functions I need and get how they work. That's why I started the whole discussion with tables.

[knorke]

For stuff like
http://springrts.com/wiki/Lua_SyncedCtrl#Give_Order
there should be a link to what cmdID can be it and I think an example would not hurt either.