Normally, to keep any body content from rendering underneath the fixed nav, I will add padding-top to the body element.
I do not like this because I have to either specify a hard unit value on the body padding, the height of the header, or both in order to be confident they will match up. I despise giving a header a hard-coded height, and then styling for each breakpoint becomes even more cumbersome, especially when I am building for a corporate site with lots of constantly changing business rules for their header with different conditions across different breakpoints.
How can I have a dynamically size fixed header that does not overlap with the body content without using hard unit values? I am not interested in using JavaScript, CSS only.
Here is a overly simplified example of what I am referring to: https://www.w3schools.com/howto/tryit.asp?filename=tryhow_css_fixed_menu
In future CSS standard, you are able to set the height of the header as a variable and use it in padding-top of body.
At this moment, you may use different CSS preprocessors like SCSS, SASS, PostCSS-cssnext to achieve this goal.
Reference:
https://drafts.csswg.org/css-variables/
Related
I have an HTML source code content which comes from a WYSIWYG editor.
I need to display that content, but spiting the result on multiple div elements (pages).
For example:
One A4 page (a div tag) has aprox width: 798px and height: 1128.6px
If the html content inside that page is bigger in height than 1128.6px, the "overflow" should be displayed on another page.
I am sure is possible to do this programmatically, but i am hoping for a css property, similar to columns property
This is coming with CSS Regions-
With Regions, you can use CSS properties to flow content into existing
styled containers, specifying any container order you choose,
regardless of their position on the page. Create visually stunning
responsive layouts for mobile and desktop content today.
See http://html.adobe.com/webplatform/layout/regions/
Support remains limited though, and this probably doesn't solve your requirements given dynamic content lengths.
This is almost certainly going to require either a server side or client side scripted (JavaScript) solution.
I am still puzzled about a few certain aspects in the application of Singularity. I wonder for example about one thing. In the following gist i have set up a few simple elements. The blue at the bottom is the footer, the yellow in the middle the content and the upper three cells (red, green fuchsia - built by grid-span) build the header. All three parts are build by the same container.
http://sassmeister.com/gist/8010028
I wonder what would be the cleanest approach to make the header broader than the other two.
By defining a width in percentage just for the wrapping header element?
By applying the layout mixin to the header element and set a whole new context?
Or is it even impossible to have different width for one of the three if they all rely onto the same container settings and context? Best regards Ralf
Singularity is container-agnostic, so you can position your header container in any way that you prefer.
There are many ways to make one of containers larger, and this problem is not related to Singularity.
My favorite method is negative margins. It is not applicable to your styles because you set margin: 0 auto on your containers. I suggest that you use margin: 0 auto on body instead. This will require some refactoring.
What does relate to Singularity though is the problem of maintaining a consistent grid throughout containers of different widths. You'll need to do some math and spend some time fiddling with values.
Here's what i managed to achieve: http://sassbin.com/gist/8030219/
Note that i'm not using the layout mixin but simply redefine $grids. This method is not recommended but is acceptable when there are several different grids and none of them can be called the main one.
PS Note that SassMeister is on Sass 3.3 whereas Singularity and Breakpoint aren't behaving properly on Sass 3.3. Use SassBin.com instead which stays on Sass 3.2.
The div is the quintessential block level element, and the span is the inline counterpart. They are the simplest possible form of that display type, with no other properties. In a great many cases I will give either of them the style:
display: inline-block;
This makes them behave in a very handy way. For div it means boxes that will easily sit next to each-other, while maintaining their width and height as defined. For the span I can use this to make colorful rectangles. The inline-block display is great for so many things, but I have never seen an element that starts as an inline-block without anything else going on.
Images (img) are, but they are obviously not suited for the same things as a div, they have that style, but they fulfill a different purpose.
So is there an element that I don't know of that is the quintessential inline-block, or is this left out?
And if not, why? The uses of inline-block are numerous, so it seems like there should be some element that takes that basic form.
There's no such element, and there are some good reasons why not.
inline-block has several uses in contemporary web design. However it is not part of the original design, which only includes block and inline elements. Instead it derives from <img> as added by NSCA Mosaic. (Which uses the wrong markup and helped defeat the original "responsive design". I think we've only just started to fix the problems with img).
Further down the timeline, inline-block still wasn't part of IE4 or 5, or any version of Netscape. It wasn't part of the early HTML4 era. So we wouldn't expect to find your hypothetical element in that version of the standard. inline-block only appears in CSS2, which came after HTML4. (Look at the reference section in each standard).
Unlike block, inline-block is affected by whitespace in the markup. It's implied by the name, and it's what you'd expect from looking at <img> in the middle of some text (aka wordprocessor object anchored "as character"). But beyond its origins there, the whitespace-dependent markup soon becomes very troublesome. I wouldn't expect W3C HTML5 to enshrine this in a new element.
Specifying it would certainly involve argument about "semantics", separation of content and presentation etc. (As well as what to call it :). And if the default rendering makes whitespace significant - is that not part of the semantics of that element? Consider using images to represent words - or individual letters of a word (with appropriate alt text). This illustrates that the presence of whitespace (or not) around this element would be semantically significant, just like the presenceofwhitespaceseparatingwordsissemanticallysignificant. That seems like a big problem to me.
inline-block is often promoted as a modern alternative to using float everywhere. But neither is genuinely suitable. This is why CSS3 will standardize new layout modes: "flexbox" and "grid", to support modern responsive designs with genuine, clean markup. No dummy markup (or dummy generated content). No hacking around whitespace-dependence.
The only elements I can think of that have an in-line appearance, but allow for a width and height to be set, are:
img,
input,
textarea
select, and
button
The only element here, though, that can take HTML content is the button element; which is not an ideal use of the button since it's intended to be an element with which the user might/should interact; rather than simply a container element.
While you may have multiple uses for such an element, there's no convincing reason, given the ease with which the display property might be changed, that the W3C, or any other authority, should explicitly define one; especially given that the only difference between inline and inline-block is the ability to assign dimensions and margin.
The img tag is inline-block by default:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img
Edit: You can check this SO question: Is <img> element block level or inline level?
I'm just geting started with twitter bootstrap and wanted to know what the best approach for changing the default width from 940px to 864px is. I tried using the customize page to change the #gridColumnWidth variable to 50px. which should make the total width 820px but the default width is just adjusted to 1170px after downloading. Should I just leave the default at 940px and nest a div with a width of 864px inside my .row>.span12 divs?
I also tried using the less files but when I try to compile them as css files I get errors that say classes, id's, and variable are undefined.
Thanks for any help,
Jason
It's working fine for me using the customize page.
Make sure to modify #gridColumnWidth, #gridColumnWidth1200, and #gridColumnWidth768 (and optionally #gridGutterWidth*).
The 1170px width you're seeing corresponds to #gridColumnWidth1200.
You can override the default styles by placing another CSS file with the same selectors and desired formatting after bootstrap.css. Optionally you can also just use selectors with higher specificity and then the order of the files will be irrelevant. Using !important should be a last resort as it complicates further use.
So I'm inspecting this site: http://www.grittirollo.it/ and it appears that the content that slides out has a fixed height. Is there no way to set this dynamically?
It appears as though the developer measured out how tall each portion of the sliders' box model would be when rendered, and then multiplied it by how many rows there were. From there, he/she set it manually in the CSS.
Elements on a webpage can typically be measured with their scrollHeight JavaScript property (element.scrollHeight) however some browsers don't have this and some browsers do it differently from others. (I believe Firefox's has to be done recursively down the tree of elements and Safari just uses the outermost element.) This should be possible without manually setting the height using JavaScript, you just may have to conditionally code it to work with all the browsers you want to support.
I don't see why it's necessary to set it dynamically. If the stuff is float:left; and they put a <div class="clear"> at the bottom of a hide-able section, you would be able to see the contents of that section when it was un-hidden with JavaScript. You could then adjust the layout with padding and margin to make it look pretty.
Or, they could have also used position:relative; and position:absolute; to layout the hide-able sections. It comes down to preference.