From the documentation on the FooTable website, I had the impression that table 'breaking' depended on screen resolution (or browser window width). Thus, the browser width.
But in practice, it seems to 'break' tables depending on the width of the container element they're in, eg. a DIV element.
How are these breakpoints supposed to work?
I'm sorry, I did not read the docs well enough.
They state: "FooTable works with the concepts of "breakpoints", which are different table widths we care about."
Thus, breaking points are about table width, not window or screen width.
Duh...
Related
I don't understand the difference between using BACKSPACE+CMD and just BACKSPACE.
I see that when I use BACKSPACE+CMD on a element in the Storyboard, that element becomes opaque, and using just BACKSPACE it deletes the element. I can't find the answer in the documentation.
As far I know, when opaque, it means the component (constraint or UI element) has been unistalled for a particular size class. For me, the combination is Command + Delete.
From About Designing for Multiple Size Classes (in bold the key part).
With size classes, a storyboard or xib file can be used for any
available screen area. You build your interface as it will look in
most sizes, then update only the parts that need to change when the
available screen size changes.
A size class identifies a relative amount of display space for the
height and for the width. Each dimension can be either compact, for
example, the height of an iPhone in landscape orientation, or regular,
for example, the height or width of an iPad. Because much of the
layout of an app does not need to change for any available screen
size, there is an additional value, any.
Hope it helps.
P.S. Did you check the key binding for your Xcode?
I am not pro developer and have small knowledge of html and css only. I am trying to work on a joomla website. I tried to add Google charts to my page. Actually it's a module that I am inserting to an article through load module function. But there seems to have a conflict and the chart is not displayed correctly. It seems that there are some conflicts with the issues but I am not sure how to figure.
http://goo.gl/v1GVWk
if you go to above link and go to tabs and open trekking map tab you will see the bug. The width of chart is very small. I want to display 100% so that it can be responsive. I tried changing the width to px as well but no luck.
Please help me. ..
The width of elements that are hidden is zero. Therefore, the chart thinks your window has a width of zero and ends up using its smallest width.
Try triggering a resize event on the window when the tab is shown, this should cause the responsive code to run.
I never used Google charts, but what you are experiencing also happens on Google Maps.
You have two options, either you use opacity (or maybe visibility hidden) instead of display: none, this will make the chart to resize automatically when the page opens.
The other option is to trigger the resize event, something like this... Google chart redraw/scale with window resize
Hope it helps
Even though the outer wrapper div#ja-google-chart-wrapper-404 is set to 100% width, two child elements are fixed at 400px. Specifically, the <svg width="400"> element that sets the image at a fixed width, plus the div that wraps it has the width set to 400px. Even though you have their parent set to 100%, if the image itself has a fixed width it won't expand to fill the space.
Check to see if there's a setting in your module or in the Google Chart itself that lets you set a different width (or none at all) on the inserted image.
One solution would be to resize the SVG element when the a#tab1-trekking-map is clicked. I just tested this in the Chrome console and it worked to trigger the map to resize to the full width of the container:
jQuery("#ja-google-chart-wrapper-404 svg").resize();
Add this (or something like it) to your other scripts that are called when your tabs are clicked. If the ID of the chart wrapper is generated dynamically you may need to adjust a bit, but triggering resize() (as stated by Niet and miguelmpn) should do the trick nicely.
jqGrid offers a bunch of fantastic features, but there is one feature missing that my customer keeps on complaining about (OK, he is never really satisfied with what he gets ) and that's proper vertical and horizontal scrolling. The grid I had to set up contains about 20 columns with some columns containing longer text so the grid won't even fit a 24″ screen. To properly layout the grid and the rest of the visual components (i.e. additional search and filter functions above the grid) I moved the grid to a scrolling div being about 95% of the screen width with a horizontal scrollbar to scroll the oversized grid, the problem with that workaround is that you won't see the vertical scrollbar of the grid itself, it only becomes visible if you first scroll to the right and that's not really comfortable.
Hope my explanation is comprehendible? If someone knows a good workaround, I would be eager to know it! Otherwise a "dual scrolling grid" would be a nice feature in 4.5
Thanks a lot!
Video example http://screencast.com/t/gPdOVPQlRc
jqGrid have many many options. It could be a problem with usage of jqGrid. The grid with many columns could be displayed in different ways.
One way is just to display full grid on the page and to use scrollbars of the browser windows. If you have simple page layout then the way could be really the best.
Another way could be to use shrinkToFit: false option. In the case you should specify the exact width values for columns in colModel. If you use shrinkToFit: false option you can set width option of jqGrid. In the case horizontal scrollbars will be placed in jqGrid.
In many cases the grid with many columns contains not always really interesting information for every user. So it can be helpful if you would provide columnCooser in the grid. Additionally you can save the users preferences in localStorage (see the answer and another one). It could improve user experience.
You don't wrote about the height of the grid, but the usage of height: "auto" produced typically good results.
We want to use slickgrid to overlay clunky and inflexible tables of data on hundreds of existing web pages built from business forms. Some tables are for display only, others are for user input/update. Thus, the real estate (and column/row counts) is set in concrete. To avoid conflict with the parent page styles, the grid is placed in an iframe. The approach has to take into account a caption bar, optional filter bar on inquiry-only tables, column header bar, and footing pager bar (only if required). Getting the ovarall height correct is the most difficult. It looks like the available tools are:
the geometry of the iframe
the geometry of the grid-container div in the iframe
options.rowHeight
options.headerRowHeight (if inquiry)
line-height css style
Font-size css style.
It seems that there is some mysterious arithmetic going on to calculate the number of rows displayed, the canvas size and the viewport size; and setting some of these items directly with script breaks the grid.
As a simple example, assume the height available is H pixels and must contain R rows of data. Are there any formulas or guidelines that give values to the items listed above? Or must we struggle with trial and error to make a good fit?
When using a custom font via #font-face, it does render just as I think it should in Chrome. In Firefox, though, additional padding (top and bottom) is added to the font.
Here is my example page that outlines the problem.
Is there anything I can do about it?
FYI, this also happens in Firefox on Linux (and not in Chromium). I tried to load your font in FontForge and immediately got a warning:
The following table(s) in the font have been ignored by FontForge
Ignoring 'LTSH' linear threshold table
Ignoring 'VDMX' vertical device metrics table
Ignoring 'hdmx' horizontal device metrics table
I think the problem is that the VDMX (Vertical Device Metrics) table is defect:
In order to avoid grid fitting the
entire font to determine the correct
height, the VDMX table has been
defined.
This looks exactly like what happens in Firefox: somewhere the minimum and maximum height is incorrectly calculated. This is also clear when you select the text: the selection box extends to the utmost top and bottom of the line; if the h1 element really had padding, you would see a gap between the top and bottom of the line and the selection box.
Also, validation revealed that almost every glyph is “missing points at extrema”:
Both PostScript and TrueType would
like you to have points at the maxima
and minima (the extrema) of a path.
A quick search showed:
The only other problem I had was a
rather nasty condition called "Missing
Points at Extrema". With a font,
there needs to be a point (or node, as
they are called in Inkscape) at the
extreme left, right, top and bottom of
a glyph. Normally they are there
anyway simply because of the way your
glyph is built, but diagonal lines
with rounded ends often cause problems
[source, including picture (scroll down)]
Just Add:
line-height:1;
to your CSS rules