is there an equivalent to
ZendFrameWork's disableLayout and setNoLayout for javascript
where i can just print an object to the browser without the website rendering?
The reason i ask is simply convenience and easy of use (for me). it's much easier for me to quickly scan through data this way, than printing out objects to firebug's console. (finding it hard to click my way through massive sized objects).
Thanks in advance..
The layout or markup is rendered by Zend and is received by the browser as is. Now technically you can strip the markup out using jQuery if you know where the output starts, but you cannot per se disable the layout using javascript since the browser doesn't know what the layout is and what the content is.
If the content is contained inside a container with id "content" and evrything around it is the layout.
You could do jQuery("body").html(jQuery("#content")) and only that part will remain stripping everything else. The css etc will still remain. You can always replace html with a structured rendeition, or simply null the head tag to remove styling. $("head").remove();
Related
It's really hard to understand how Tinymce can be considered as WYSIWYG, because I cannot get what I see (visually exactly). So it is more likely "what you see is just what you see".
Currently I use getContent() to get the HTML. But it lacks embedded style and if we show that output html in some container, the visual rendering will look different.
I've tried implementing my own solution to help embed the current style (based on getComputedStyle) to each element. But that's not very efficient (many redundant styles can be included) and not always works (such as for embedded video, I'm not so sure why the <video> is not kept with getContent() and all <video>s disappear in the final output html).
The Tinymce team has done a lot of works, but really not sure why they did not even think about this feature? We need the exact HTML that renders what you see in the editor. We can sanitize the HTML after that by ourselves.
Here is a demo helping you imagine better what's so bothersome with this WYSISWYG editor:
https://jsfiddle.net/L83u5v0n/1/
Clicking on the Show HTML button shows this:
So you can clearly see it's just more likely to be WYSIWYS rather than WYSIWYG. Is there a solution to get the exact output HTML based on some hidden feature of Tinymce that I've not known of? If it's based on some custom script using getComputedStyle then really I do not need it (actually my solution is fairly good).
This is a function of demos that are set up to look good in the editor versus real world usage. The intention of the content_css configuration is to provide the CSS that will be used to render the content.
If you apply the content CSS elements to the page then "Show HTML" works perfectly.
https://jsfiddle.net/xzh8utbp/
Alternatively, delete the content_css configuration (but that won't quite work in your example because JSFiddle adds CSS to the result window).
Note that I've added mce-content-body to the view div because it turns out our codepen demo CSS leverages it. Normally that wouldn't be required, but then I don't think normal integrations use our codepen CSS.
I have a single page application, and I have different sections where I want to print out list of images each on it's own page.
I thought maybe to use iframe for this purpose, but I wanted to have an answer from someone experienced with this situation.
What is the best way to approach this problem?
You can use CSS media queries to direct CSS rules at print time as described in this answer: How do I hide an element when printing a web page?.
You can then set different classes on some high level part object before printing to control which CSS rules apply and thus what gets printed in a given operation.
You can also have a whole stylesheet withe the media type set to print so it applies only when printing.
Or, depending upon the specific situation, you can open a new window, put the content to be printed in that new window and print that window. Usually, it's better to avoid opening a new window if you don't have to.
There is a CSS Template Module in the works and there is a Javascript implementation while browsers catch up.
I've had fairly good results with it.
I am creating an ePub reader on IOS. Basically, I use uiwebview to load the xhtml files.
Every time page turn， I need to load the file with uiwebview then call javascript to scroll to the right offset. Here is a problem, some xhtml file is big (like > 2MB) that it cost too much time to load. Thus the page turn animation is not so smooth.
So I am thinking I could load the xhtml once with uiwebviewA , and each time page turn, I create another uiwebviewB and grab the needed html content(like second page) from uiwebviewA. In this way, I could limite the html into small size and the page turn animation should be smooth.
My question is that is there any open source javascript library can do the job?
Any comments is appreciated!!
There is no meaningful, well-defined way to split an HTML document in the way you seem to be describing. You are confusing two very different things: (1) splitting the rendering into page-sized chunks, and (2) splitting the HTML source. To put it a different way, there is no algorithm I can imagine that would split an HTML file into pieces, such that the sequential composition of the rendered pieces was identical to the rendering of the original HTML file. In other words, in order to figure out how to split the HTML, assuming it is even possible, you'd have to do much or all of the work involved in rendering the page, which would defeat the entire purpose.
You should abandon the notion of splitting the HTML. Ebook readers all paginate by essentially rendering the entire HTML document once, then "windowing" and "clipping" and "offsetting" or, in some cases, using CSS regions.
There are a couple of alternatives I can think of, if I understand what you are trying to do.
Reduce the size of the input HTML files by pre-splitting them earlier in the
workflow. For instance, in one project I know, the source (X)HTML files have bits of additional markup that tell a pre-processor where split them into individual files if desired, which in this case is a work-around for ebook readers that don't honor CSS page-break-* properties properly.
Pre-compute the rendering for next page as a graphic and
use it for the page turning.
As already discussed, rethink your architecture of reloading the entire HTML document for every page in your book. If it is merely page turning effects that
lead you to want to do that, then give them up.
Consider that many ebook readers provide a scrolling mode that does
not require pagination, and some (eg Himawari Reader) provide only
scrolling mode, which is actually something that some readers prefer.
You can put out your scrolling version, and then do pagination in version 2.
You should really check this:
http://cubiq.org/swipeview
And this demo that does exactly what you asked for:
http://cubiq.org/dropbox/SwipeView/demo/ereader/
It takes a text (book) and paginates the text to fit the screen size.
I tested the demo in Android and iOS and it works great!!
I am interested in extracting the text/string literals thats rendered in the web page during a workflow. I want to isolate the strings that are rendered from the ones that are hidden.
My intention is to find the strings which get rendered and map them against each workflow in my application. (I have a way to uniquely identify each string, so thats solved. No worry on that.)
Is there a way i could use preferably .net or in JScript or browser addons or using some trace options in a browser achieve it?
Any help is appreciated thanks!
How are you pulling the content? One way to only get the visible content is to use Jquery's visible selector. Simply add :visible to your jQuery selector (http://api.jquery.com/visible-selector/). For example on this page you could use $('.post-text:visible') to find the question text only if it is visible.
I'm for years using something like this in my HTML for elements which should be hidden:
<div style="display: none"></div>
It's ok, but I can't stand in-line styles anymore.
Hiding elements programatically in JavaScript window.onload event is too late -- it will flash on the screen.
I can create CSS class 'hidden', but with browser's aggressive loading strategies (like in Opera) the block may appear for a second (before CSS is loaded).
Is there any better way?
As far as I know the class="hidden" method is the best and most commonly used. I suggest you use class="hidden".
"but with browser's aggressive loading strategies (like in Opera) the block may appear for a second (before CSS is loaded)."
I don't use Opera, but if any browser loaded the page before applying styles then a lot would look wrong, not just your hidden elements. I don't know of any browser doing this.
I have recently started using node objects, and I like this approach more and more. This way you don't have to use hidden HTML elements, you just place, for example, an anchor:
<a name="some-anchor" id="some-anchor-id" />
and then replace it with a created node. This way you won't have to worry about elements flickering on load, because there won't be any.
Depending on what the element is, it might be acceptable to generate and insert the element using javascript after the page has loaded (rather than hiding it after page load). Just a thought, although it wouldn't degrade gracefully for users without javascript enabled...
You could add to the hidden style a fixed position which would bring it out of a browsers window. This may be a solution to avoid having the div blink in Opera.
For example:
.super_hide{
position:fixed;
top:-1000px; /* you would need to know how height the content is or put something huge*/
}
Hoping this will help!
If you have a HTML only page those elements would be shown?
These elements are shown to screen readers by default, that's not very nice or accessible is it?
If you have HTML+CSS only page you can't unhide these elements, then there's no point in them apart from black hat SEO tricks.
If you have a HTML+CSS+JS page then there is value in have them.
There is only value in having them when you have JS enabled. This means they should _exist in the javascript
Use javascript to create these elements and inject them in the DOM.
if your build your website from the ground up using HTML, HTML+CSS, HTML+CSS+JS then you would realize they belong in your javascript code. Feel free to read more about Progressive Enhancement
You could define the class in of the page. It's slightly cleaner than inline, but you would have to have that single class definition on all pages. But then again, I'd try to use a single dynamic footer/header anyway..