I'm working on a JavaScript (using HTML as display tech) widget framework for an embedded device where memory consumption is a big deal.
Recently I tried to create a table-layout using only DIVs. But to mimic the colspan and rowspan functionality it became quite complicated, adding extra logic to make it all dynamic.
The result came out quite good layout-wise, but at the cost of too much memory consumption (had to have several JS objects representing each cell and then a DIV as presentation)
Wouldn't it be better to just use the TABLE element instead, getting the col- and rowspans and layout for free? Especially since all markup is crated by the framework and that the user (of the framework) never actually touches the HTML itself.
Or am I missing something here?
well tables are perfectly fine for tabular data if you want to do it right semantically.
And imo, you have to go for the best solution in your situation. Performance is more important than using div's or not in this case i guess.
If you start out with the mentality of "I need a table-layout", it's inevitable that you'll end up deciding that you need to use a <table>, because CSS cannot deliver on the subtleties of colspans and rowspans. But do you need a table-layout? You don't describe the underlying layout requirements, so it's impossible for us to steer you either to or from <table> except in broad generalities.
Go ahead and use a table. One of the main reasons that CSS layouts are encouraged is accessibility (probably you don't care about). Another reason is separating content from layout - you are probably creating both. So, the disadvantages of tables are of very low importance compared to the advantages in your case.
Related
I've made some code (tool? framework? Not sure what to call it) that is intended to make it possible to style CSS with Javascript but not jump when reloading or changing pages (so for use in traditional multi-page sites... not sure the conventional term for that). I'm no web expert so am unsure if it's worth developing this further or if there's better solutions to what I'm trying to solve (more than likely).
The basic structure is
A. Under certain client-side conditions (e.g. browser resolution, but could be anything, like a certain user using the site), CSS is generated by client-side JS, written to a file on the server under the appropriate heading relative to scenario (e.g., 1024x768.css, 102400x76800.css).
B. The server code checks (via cookies) if client-side condition is met, checks if css file pertaining to condition exists, uses it, otherwise generates it (A.)
Potential uses
You inherit a legacy site or clients insist on a certain template (Wordpress theme), with predetermined HTML structure, such that it's difficult to achieve a custom look just modifying the CSS. It might be much quicker to make calculations and adjustments with Javascript than refactor the HTML or figure out the solution in CSS (time permitting the ideal solutions, arguably). On the other hand, you don't want the style to jump every time you load the page since that looks tacky.
Edit: example of the above
As noted below in the comments, I can't think of a great example off the top of the ol' noggin. Right now my test is modifying a navigation menu of the type <div class="menu"><ul><li><a>Section 1</a></li><li><a>Section n</a></li></ul></div> such that the <a>'s have just enough padding on both sides that the menu <div> fully fills up the width of the browser.
I imagine there's a conventional solution to this, so if you're feeling in the mood, please let me know.
You want particularly complicated sizing, positioning based on complex calculations (dependent on screen size, or not), but, again don't want things jumping around.
Edit: example of the above
Positioning elements in a spiral pattern (say this kind) with diminishing size. This seems to be nontrivial in CSS, perhaps done by calculating the positions beforehand and placing with absolute positioning. But then there's the problem of having everything scale depending on screen resolution.
Alternately Javascript could calculate positions and sizes dynamically. Of course writing the method to correspond to the mathematical spiral function would be a challenge (though an interesting one).
There could be other solutions like using .svg, but if written generically it would be possible to position according to other mathematical functions (e.g., sine wave), or complex ratios (golden mean) fairly easily.
You want a site where the user can customize the look (reposition or even resize elements) and you want the customization to automatically get remembered and generated in the server-side code (perhaps even without a login). I'm sure this is facilitated by many frameworks, but this kind of divests the process from a specific framework.
I was wondering if other folks had thoughts on whether:
A. There's a better solution to all this I've missed.
B. The system I described of pushing CSS from JS to be written on server sounds sound, or if the same thing could be achieved another way entirely client-side.
C. And I guess since it's not a specific technical question whether this is the right place to ask this question, and if not, where I should.
Like I said, I'm no expert, so would greatly appreciate any feedback or other things that might help me to learn.
Thanks
Apologies if this is a repeated question about ui-grid but I could do with being clear on the options for my particular use case. Other similar questions don't conclusively answer my problem.
We are attempting to use ui-grid in a fairly unusual web application where the number of tables on the page is effectively limitless. They get added the more activity the user does. Not ideal but that is what is required.
When using ui-grid, even with a fairly small simple table, it is adding around 1000 watches for each table. And the digest cycle increases significantly with each table being added too. This leads to poor performance when the number of tables increases, as you might expect.
My question is then, is there anything that can be done with ui-grid to reduce these number of watches? i.e. without delving in to the source code to make changes. We are passing our data in to the ui-grid directive using one-time binding notation, but that makes no difference. From looking at other similar questions, it would seem to me that there is nothing else that can be done, which might well imply that ui-grid is not suitable for us.
Alternatively, is there a way within AngularJs to prevent two way binding within a directive? I'm not aware of such a method, but perhaps someone knows a trick to make this happen?!
Finally, can anyone suggest an alternative grid that would be a better fit for our use case? We are trialling ui-grid due to the functionality it provides, such as column selection, cell formatting, ordering, filtering and so on. Are there better performing AngularJS or other JS grids out there that would cover this functionality? Preferably free to use? Others we've considered checking out are Kendo UI, jqxGrid, ag-grid (though perhaps this needs to be paid for).
Any help is massively appreciated.
My company has run into similar issues though not with ui-grid specifically. You've probably already considered this but the fix for us was horizontal and vertical paging. I don't know much about your use case, but we realized that horizontal and vertical scrolling with a huge grid had the same issues you are running into, but it wasn't really any more functional for the user to use a scroll bar than to use page controls to move between blocks of the grid. At most 500 cells would fit on a single screen at a time and it was very easy to lose your place trying to use a scroll bar.
By doing this we're able to use 1 way bindings (probably with bind-once but I would have to dig into the code to be sure). Even with two way binding the same technique should work for you too if it works with your use case.
if you us ag-Grid, there will be no watches. ag-Grid doesn't use Angular at it's core, so doesn't have watches internally.
ag-Grid has two versions, free and enterprise. if you don't need the enterprise features, then use the free versions.
I'm building a browser based game in JavaScript.
It contains a lot of Information visualized via tables.
The game is turn-based, so whenever a turn is completed, I need to adjust a lot of innerHTML of those tables.
My question is:
Is it smarter to give IDs to all the <td> and update the innerHTML or is it smarter to wrap the tables inside a div, clear the div and rebuild all tables from scratch, then append them?
It depends on how long a view stays active, if the view is shared, how many cells change and how frequently.
If you have a high number users looking at different views/pages that stay active for a long time, then it might produce less load on your servers if you can make infrequent updates to individual cells.
If the changes happen less frequent and a high proportion of cells change, then it may be best to refresh the whole table. This would be 'less chatty' and use less network bandwidth overall.
However if you have a high number of users, all looking at the same view/page, you may wish to look into CQRS and caching your views or view data.
Rather replace the innerHTML, the code will look nicer and it will be a lot more effortless, because instead of recreating the whole thing you would just be replacing a string in an object, which is obviously a lighter task. So in most cases it makes sense to do that.
Consider using a framework or templates, though.
I want to create a web-based board game like reversi. I created a similar game in python before but now I want to try to implement it using javascript/jquery/html/css.
The main thing I'm wondering about is how to set up the GUI for the board game in the browser? I have two ideas. One, create an html table structure containing 64 cells. Second, create 64 floating divs.
I realize that for the layout of a website, tables are unreliable and inconsistent across browsers but in the case of a game like this, would a tabular setup be easier to work with?
For something like reversi, I think a table is appropriate — beyond the visuals, it’s a decent semantic representation of the content, i.e. the state of the game board. (<div>s wouldn’t perform the same job, as they don’t represent the relationship between rows and columns.)
I’d expect a table to be as easy to work with as <div>s: possibly slightly easier, as you don’t have to write any CSS to get the two-dimensional layout, although you might have to use slightly more code to generate the HTML, depending on how you’ve got the game modelled in code. (E.g. If you’ve already modelled the game as cells within rows, it’s easy. If not, you’ll have to keep track of that in code when generating the HTML.)
I would use divs because they seem neater to me but you'll probably find that jQuery is SO flexible it wouldn't matter too much if you did use tables.
Imagine your grid structure like this:
<div id="#grid">
<div class="row1 column1"></div>
<div class="row1 column2"></div>
<div class="row1 column3"></div>
... (and so on) ...
</div>
Cells could then be selected uniquely using jQuery like:
$(".row1 .column2").css("background-color","#ccc")
CSS might look like:
#grid div{
display:inline;
float:left;
height:100px;
width:100px;
... and so on ...
}
Simple decision, if layout is tabular then use a table. There's no absolute insistence on not using tables. Just because they have just been overused in the past does not mean there aren't good, justifiable uses today.
Floats can mimic a table but will not handle overflow conditions well. A table will automatically reflow to accommodate the contents of its cells. If overflow isn't an issue, then by all means consider floats.
You could take a mathematical approach based off the available dimensions of the user screen and such. I would create a js object based off basic division and assign the pieces as position absolute elements with the proper offsets. It would be especially easy for a game like reversi and since you're using the jQuery library already it shouldn't be a problem to deal with the initial calculation and rewriting of game piece positions.
So I would have one div ('#container') that's width:100%; height:100%; or whatever is a logical game board.
Then divide the $('#container').width() and $('#container').height() by the applicable tiles and map out a js object to create a data grid and the expected width and height of each cell.
Then attach a click listener on the container element that records x and y and cross references it with the results of your board division results from the initial load.
Then define starting coordinates for your initial pieces, if any, and draw them.
That's vague, I know, but the general idea is to eliminate the literal concept of a grid at all and think of the whole thing as an empty piece of paper with floating boxes inside it.
Sorry for the longwinded response. I guess the end result for me is a suggestion to use divs. Since your board is a fixed proportion, there's no reason to think of it as tabular anymore.
I would go for divs over tables. Mainly because browser performance suffers (on some browsers like older versions of IE) when you manipulate table elements. Additionally using divs will give you much more layout and styling possibilities. It is a bit easier to generate a "div"-based board as you don't have to worry about inserting tr's.
Other than that it does not really matter which way you going to go
I've changed my mind from my earlier comment.
Use <div> with meaningful class names, and use the CSS display property as appropriate, using the values of table, table-row, and table-cell
The whole board would be display: table, each row display: table-row, and each space display: table-cell
See my example fiddle at http://jsfiddle.net/XyK7s/
Pretty simple question.
Its just some advice based on personal opinion and best practice.
It's difficult to explain so I'll draw the best image I can.
Try to imagine that I have any old website and at the very top I have a navigation bar which is broken into 3 rows.
Top is application: Settings, Profile, Login/Out
Second is notification: Error, new message
Third is part navigation part functional.
So we have 3 rows supporting different functionality and obviously different color schemes. Each on is no more than about 5% of the total pages height.
I supposed the question I'm asking is whats the best way to do this.
First guess was to use tables to format the data and space them out:
This worked, but It looks sloppy.
{
border-collapse: collapse;
border-spacing: 0;
}
seems to fill in any gaps in the table but it doesn't look right
Second guess was to use frame sets:
Shot myself a dirty look for even thinking of it
Third guess was to keep everything css and Html
Which seems like the most sensible one next to tables but keeping content organized with the multiple buttons and such sounds like it could be trouble.
Lastly
was use a JQuery or javascript UI library. This presents It's own set of problems but could be the prettiest if done right.
So if it was you, how would you go about doing this simple task and why?
picture of view as requested. Part in question is top nav
http://s1180.photobucket.com/albums/x406/0vertone/?action=view¤t=globalview.jpg
Don't use tables for this purpose.
Only use tables for tabular data (which this isn't).
Just use divs for the containers and lis for the menus.
EDIT
This is somewhat like I would do:
http://jsfiddle.net/uf2zU/1/
This uses elements what they are meant for.
And can be easily controlled using CSS.
EDIT 2
http://jsfiddle.net/uf2zU/4/
I would go about this using sets of HTML uls and CSS, because that's the most forward thinking, plus it uses HTML the way it should be. However, if you want to use tables, try border: none; and border-collapse: collapse;
I would go with the third guess for the presentation part, because that's the most flexible part, at least for me. If you split up all the sections correctly, then the task of managing the content will become quite easy, because you will be able to target the section and style anything with it.
In addition, I would go with the last option (i.e. vanilla JavaScript and jQuery), for client side functionality, because that's the Swiss Army Knife of DOM manipulation.
A horizontal nav bar just that -- a horizontal entity. Therefore, I wouldn't "stack" elements as rows, rather as columns. It's the difference between a huge header and something that's visually much easier to comprehend. Stretch your elements out, use icons, whatever. If you have the need to be really verbose, go with a giant menu
I personally use JQuery UI Tabs whenever possible because they're a well-established UI pattern, are easy to deploy, and automatically "Ajax Load" my pages. Sure, you get a few "gotchas" but they're nothing for a competent jQuery user to overcome.
In situations where I can't use UI Tabs, I will do a pure CSS bar across the top, "floating" via absolute positioning if that is what the client specs. Layout is no place for Tables (they are for tabular content elements) and you're right that frames have no place, period. This shouldn't be any more difficult than basic page layout, so it's a no-brainer to go this route.
For notification, there are other options that are more obvious and timely. Try the Notification Widget or StackOverflow style notifications All other small, basic info could be contained on your horizontal bar.