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.
Related
The HTML below specifies a button and a div that have identical class and contents.
<div class="root"><!--
--><button class="outer"><div class="middle"><div class="inner">label</div></div></button><!--
--><div class="outer"><div class="middle"><div class="inner">label</div></div></div ><!--
--></div>
In this example, I have explicitly set every CSS property1 for the classes outer, middle, and inner2.
This means that both the button.outer and div.outer sub-trees of the DOM should have completely identical CSS settings. Presumably, as well, no CSS properties for these elements are getting their values from anywhere else besides the provided stylesheet.
As the example shows, the side-by-side button and div look quite different. Specifically, in the button, the label appears at the bottom of the element, whereas in the div it is vertically centered. (The label is centered horizontally in both cases. Also, note that all the classes have the setting vertical-align: middle.)
I have observed this difference with all the browsers I've tested so far (Chrome and Firefox).
Since there is no difference in the stylesheet settings for the button.outer and div.outer elements, and their descendants, I figure that the difference in their appearance is due to some CSS property with a value (such as auto or normal) that gets interpreted differently by the browser depending on the whether the context is a button or a div element.
My immediate goal here is to understand sufficiently well why the button and the div are being rendered differently so that I can adjust the CSS intelligently.
My longer term goal is to make CSS coding more predictable. Currently I find that my CSS is completely unstable due to gross inconsistencies like the one shown in the example.
My question is:
how can the difference in appearance between the button and the div be explained?
1 As reported by Chrome's devtool.
2 I took the vast majority of the values for these settings from Chrome's devtool's listings. The point was to ensure that both the button and the div elements had the same setting (whatever it may be) for each CSS property.
This is likely due to different meanings for the value of auto for the position of elements inside of a button. If you expand the size of a div, the content by default will be in the top-left corner. If you do the same for a button, the content will be centered horizontally and vertically.
Since the button's top and left values for auto is to be centered and not in the top left corner, you can reset top and left to always act like a typical div would. These are the properties to change on .middle:
.middle {
top: 0;
left: 0;
}
Here's the forked JSFiddle with those changes to .middle.
Different elements have different default settings. There is an enormous amount of CSS in your demos, and it's largely overkill and very hard to determine where exactly the differences in rendering are coming from.
Have you tried a CSS reset instead? These will resolve most of the discrepancies between elements and browsers, giving you a blank slate to add your own styles.
how can I determine the property (or properties) that account for the difference in appearance between the button and the div?
By clicking through them one by one and toggling them on and off in Dev Tools. If you turn off position:absolute on the middle class, you'll see what you're probably expecting in layout. I found this by clicking through all the properties in the Elements > Styles panel. See:
https://jsfiddle.net/vfdd9p8L/
This is probably a bug that you're encountering. Browsers have lots of them! By layering on so many styles at once, you're probably backing into a weird corner case with respect to the layout algorithms. To isolate the bug for help and/or reporting, try to create a reduced test case, which creates an unexpected discrepancy, but using the minimal number of elements and declarations.
(Also note that your fiddle is including jQuery CSS, which includes Normalize, which is a whole other layer of styling.)
I am seeking some advice regarding unnecessary scrollbars appearing on certain form items. A screenshot of the issue appears below. Note it is the right-most scrollbar that is unnecessary.
bad_scrollbars http://img21.imageshack.us/img21/9307/scrollfu.png
The culprit appears to be the following css, adding overflow: auto; to form items within windows in gecko-based browsers (the problem appears on Firefox):
.ext-gecko .x-window-body .x-form-item {
outline: medium none;
overflow: auto;
}
Removing this style solves the problem, but I am wary of possible side effects - though I haven't noticed any as yet, this style was obviously included for a reason.
Does anyone who knows more about Ext styling know if overriding this css to remove the overflow: auto; style will cause other problems?
As an aside, this is only an issue (so far) with a certain component - a custom extension of the Ext.ux.form.MultiSelect component - even though other components use more vertical space. Does anyone know of a possible reason for this?
Thanks for any help.
overflow: auto tells the browser to add a scrollbar to the element if the content of the element is larger than the elements client area minus any padding. Getting rid of the scrollbars in CSS does exactly that. It makes the scrollbars go away, no matter what.
The side effect of your work around is if there is content outside of the client, the use will not be able to see it. Additionally, this will not only happen with this form but every form in your application unless you apply your workaround in a custom class.
The right fix is to figure out why your content area is larger than the form's client area. Firebug can be a big help with this as you can inspect the DOM and see the size of the container as well as the size of all the child items.
I suspect that your clear selections control (is this a custom control?) is not properly sizing itself (i.e in your form layout you're telling it to be x pixels high but it's actually sizing itself x+1 (remember margins and padding). The form layout is doing all the work to decide how big to make the wrapper area (the area with the scroll bar) and the control must fit within that area.
I want to use iconography in a web UI, while retaining the context language of what clicking on the link will achieve, but possibly not displaying the text and crowding UI space. For example using CRUD screens, I want to display a plus icon for adding an item, a minus icon for deleting, it, a pencil icon for editing it, and a magnifying glass to search for a different item. There are a couple of ways to achieve this.
Render an img element inside of the anchor. The img alt attribute will describe what the icon represents (alt="pencil icon"), and the title attribute will describe the intended consequence (i.e. "Click here to edit this widget").
Render an anchor tag only, and use css to display the image as a background. In this case, the anchor's content should describe the intended consequence, however it needs to be wrapped in a span element so that its display style can be set to none. The anchor should also contain a title attribute matching the content (without a surrounding span of course).
It seems to me like option #2 is easier to implement in an asp.net mvc app. Since the icon is a design concern and not a markup concern, it makes sense to define the image in CSS. It also makes things easier from a code maintenance perspective... changing the img src location would only necessitate changes in the CSS file and no view files. Removing the CSS would cause the application to fall back to full text accessibility too.
What smells funny to me is the part about nesting the link content into a span so that it can have disply: none; set in the css. Another thing is, if I use the :hover selector to swap the image and provide a rollover / rollout effect, the images seem to take longer to swap out than when done with javascript.
Am I missing anything here?
We frequently use option #2, but in a different fashion. Instead of wrapping the anchor content in a span, use CSS to style the anchor as display: block or inline-block, then set its text-indent to -1000em (or similar, just pick a big value). I think you also have to set overflow to hidden.
If you do the background image as a sprite (a single image with both the non-hover and hover states in it) and use :hover to reposition the background, you should avoid the flicker/delay that you might be seeing now. That also results in one less separate request hitting your web server.
Note that this also requires explicitly setting the width and height of the anchor in your CSS to match your icon size.
If the icon conveys information that does not duplicate information already in the document, then it should be a real <img>.
However, the alt attribute should contain an alternative to the image, not a description of it.
alt="Edit this widget"
The title attribute should only be used to provide advisory information (think "optional extras") and you should avoid using implementation specific terminology (such as "Click here").
What smells funny to me is the part about nesting the link content into a span so that it can have disply: none; set in the css
If you do go down the route of putting content in background images and hiding real text, at least negative text-indent it out of sight instead of display: noneing it and making it invisible to screen readers.
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.
I have an editable iframe and I want to insert two DIVs at the [b]top [/b]and [b]bottom [/b]part(as header/footer) of iframe body respectively. Now, the question is : how to insert a div [b]at the top of iframe body[/b] and fix it there? (Will insertFirst() work?)
Also, how to fix the footer div always [b]at the bottom of the iframe body[/b]? I tried make its position absolute and gave a margin top/bottom, but the problem comes when the body height of the iframe increases and footer DIV position does not change.
I want the same thing google docs does, i.e. fixing separate part for header/footer (though google docs page is not an iframe).
Any work around?
I assume by "fixed" you don't mean position: fixed but "not editable"?
I don't know of a native way to do that, the only thing I do know is CKEditor's protectedSource configuration setting. It allows to specify regular expressions; content matching those expressions cannot be removed by the user.
If you mean "fixed" as in "position", the position: fixed CSS property should work for you (Doesn't work in IE6 though).