I'm building a 2-column layout using CSS multi-columns, and I want to give a hint as to where to break the columns.
So I say: columns: 2 on the container, and break-before: column on the child where I want the break.
IE (11 in my case) decides to split my content into 3 columns and overflows to the right of its box :-(
Chrome (using the prefixed alternatives -webkit-columns:2 and -webkit-column-break-before: always) behaves nicely.
Am I doing something wrong here ?
Is this a misbehavior of IE ?
Any workaround suggestions ?
As I am myself very interested in this question I studied the spec and some examples of multi-column layouts.
First I have to say that the spec is horribly "imprecise"!
But it seems that any break definition has precedence over the column-count value (though I could not find it explicitly in the spec or anywhere else).
This only happens if, according to the multi-column pseudo-algorithm, the respective element, which sets the break point, is already part of the last column (as in your example fiddle).
The example given by #GCyrillus (see comments on question) just works, because the height setting forces the algorithm to first fill the given height before additional column boxes are created in the inline direction.
You can see the "original" effect, if you change the height from 20em to 10em!
So after all, I tend to say that it is not a bug and IE behaves correctly.
At least it might be an error or shortcoming of the multi-column algorithm to not recalculate or refill the columns so that despite any breaks the column-count value is respected. Logically this can only be done as long as the number of defined break points is one less than the column-count value.
As actually IE 10+ is the only browser supporting the multi-column module including the break-xy properties, it is hard to tell if the behaviour is right or wrong and how other browsers will handle this in the future!
For now, I would recommend to not use these properties at all.
Related
This behavior is somewhat confusing to me, so I would appreciate some external help to understand what is happening.
I have prepared a fiddle to illustrate the behaviour http://jsfiddle.net/cseignc/mfoejqum/
I have an html table whose header is maintained fixed by absolute-positioning a second header via some CSS.
The table is generated thanks to the ng-repeat directive that loops through the array of columns and rows.
In order to provide horizontal scrolling, while maintaining the first column and the header fixed, I am filtering the array of columns to ng-repeat on by using the startFrom and LimitTo filters.
I am providing navigation buttons (left and right chevrons) to allow the user to scroll horizontally through the table. Those buttons increment/decrement the value passed to the startFrom filter.
This is working as expected for the table body but the second header fails to render properly. I am even finding it impossible to detect consistency in how the second header is rendering - or not.
I initially thought this was to do with $scope.$apply() not being called for, but all my code is within AngularJs, so I do not believe that there is a need for calling it...Correct me please if I am wrong.
I have found that resizing the screen will cause the header to render properly.
Any insight on this will be greatly appreciated.
Thanks !
EDIT:
The above issues appears to be Chrome specific. I have tested the behaviour in IE and Firefox and the header is rendering correctly in those browsers.
I made some changes to your fiddle that should give you a bit of a start in achieving exactly what you want:
http://jsfiddle.net/a06uvkr3/
The gist is that I:
1) initialized $scope.skip to 0 in the controller
2) Ditched the ng-repeat filters and used ng-show with some logic based on $index
3) tweaked the CSS so that the header's .tr-inner container is absolute rather than the things inside it and gave the header a fixed height. Also tweaked a bit of padding to account for the header items being thrown out a little
Obviously I can't verify that it fits your exact use cases, but you can see the result is much more promising.
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
What bug does zoom:1; fix in CSS?
If I am not incorrect, the default value for the CSS property zoom is 1. And in about the last 6 or 7 online code files regarding CSS, I have seen somewhere in the code this mysterious line of code:
zoom: 1;
Is there a semantic meaning to this piece of markup? Is there a reason why they include it?
Using this rule is the fastest (and - usually - the cleanest) way to activate hasLayout property for an HTML element. This, in turn, affects (usually in positive way) its rendering in older versions of Internet Explorer:
In Internet Explorer, an element is either responsible for sizing and
arranging its own contents, or relies on a parent element to size and
arrange its contents.
In order to accommodate these two different concepts, the rendering
engine makes use of a property called hasLayout that can have the
values true or false for the element concerned. We say an element
gains a layout or has a layout when the hasLayout property has the
value true.1
When an element has a layout, it is responsible for sizing and
positioning itself and possibly any descendant elements. In simple
terms, this means that the element takes more care of itself and its
contents, instead of relying on an ancestor element to do all the
work. Therefore, some elements will have a layout by default, though
the majority do not.
I'd recommend reading this article as well (the quote is from there actually).
I need to freze several rows on the top and several columns on the left of a huge table. Can this be done with pure CSS (and retaining a single large table), or must I split the table into three tables and use JavaScript to keep them in sync? Luckily all the cells have fixed width/height and I don't need to accommodate flexible cells.
Oh, as for browser support - IE7+ must be supported; preferably IE6 too (not sure if I'll need it or not); the others can be the latest version.
Here is an incomplete, kludgy solution that solves the column problem. But I thought someone may find it valuable. Several people have pointed out that "thead" might work for the headers, but no one has offered a solution on the columns:
http://jsfiddle.net/C8Dtf/20/
It works by one div to handle horizontal and another to handle vertical scrolling. The main problem is you can't see the horizontal scrollbar until navigating to the bottom (but mouse wheel scrolling works just fine). It works in IE7 and I used some display:inline hacks to pull that off. Note: I am only using javascript to create the tables.
My intuition after struggling with this for a bit is that there is no pure CSS solution. I simply can't imagine a way to sync scrolling in both directions.
I have a layout in which two divs appear stacked vertically inside a parent div which will be a specific height (due to containing a left hand menu). I wish the two divs to take up all the available vertical space. However, they must resize depending on their content. The easiest way to explain is with a diagram:
Reading the diagrams from top to bottom, this is the scenario:
both divs take up 50% of available height as this is sufficient to contain their content (this is the default).
there is a lot of content in top div and less content in bottom div. Top div expands to fit content and squashes bottom div.
reverse situation of (2).
both divs must expand to fit their content. Containing div must expand to accomadate.
I think I could figure out how to do this with a table, see the example here which is almost correct (in chrome anyway) except the outer div doesn't expand properly.
Is there a better CSS solution to this without using a table?
I cannot use JavaScript and solution must work in all browsers... including IE6 :(
.
This can be done using CSS, with a feature called the flexible box model. It's an extension to the box model that's been in use in CSS since the begining, and allows you to do stuff like vertical stacking, etc, which wasn't possible before.
You would start off with display: flexbox;, and then use other related styles to define the characteristics of the layout you want. It is very powerful. You can read the full W3C spec for it here: http://www.w3.org/TR/css3-flexbox/
Now the bad news: It's a very recent addition to CSS. It actually has reasonably good browser support (albeit with vendor prefixes), but the problem you'll always hit is that it isn't supported in IE, not even IE9 (though it is planned for IE10)
Other browsers require vendor prefixes, so even for supported browsers you'll need to write your styles in four or five versions.
In addition - and this is the real killer - there isn't a good fall-back solution for browsers that don't support it. If you design your page using flexbox layouts, and load it into a browser that doesn't support them, it will be a disaster.
For this reason, it is hasn't really seen much use in the real world yet. It's time will come, but as long as IE9 and earlier are in use, it won't become mainstream.
You can see a full browser compatibility chart for the feature here: http://caniuse.com/#search=Flexible%20Box%20Layout%20Module
In the meanwhile, you're going to have to use a Javascript solution.
My recommendation is the JQuery Masonry plugin. I think this will be your best solution for now.
You could fake it using a 100% height wrapping div and a white border like so:
http://jsfiddle.net/cBV88/2/
You can also remove the fixed height and it will still work.
SuperStretch might get you part of the way there.
I've recently come across a problem in CSS where I set the min-width property to a certain value that works in Firefox but breaks in Webkit. While playing around a little bit with the Chrome inspector, I discovered the property -webkit-min-logical-width that, when set to a different value than the min-width, fixes my layout issues in Chrome! Does anyone know exactly what this property is supposed to do? I googled for it and didn't come up with anything, even on webkit's website.
EDIT Here's a fiddle demonstrating this in action. View in both Chrome and FF to see the difference. It appears that it may be a min-width override?
-webkit-min-logical-width only overrides min-width when it's placed after it. When in front, min-width is chosen.
This basically makes them equal and my guess would be that -webkit-min-logical-width was the first webkit implementation of min-width. It was a temporary name that still has to work to avoid breaking older websites :).
just my cup of tea :)
EDIT:
this might be it: http://dev.w3.org/csswg/css3-writing-modes/#abstract-dimensions
measure or logical width
A measurement in the inline dimension: refers to the physical
width (horizontal dimension) in
horizontal writing modes, and to the
physical height (vertical dimension)
in vertical writing modes. (The term
measure derives from its use in
typography.)
Do not use it. Non standard and probably deprecated or soon to be removed (see below). Here is the simple definition -
min-logical-width is min-width when the writing mode is horizontal.
min-logical-width is min-height when the writing mode is vertical.
I found the original draft specification revision. If you scroll down a bit, you will find a table that maps the properties to the known properties according to the writing mode.
Also, I believe it is going away soon and will render it completely useless for hacking your CSS for Chrome.