I have a problem with a project that I have been working on for a while now. When I open an entry, the inputs all have data in them. However when I go to actually print the entry (using the print-mode, CTRL+P), I notice that the select, and textarea fields are missing the selected or input text on paper. What's going on here? I have googled for hours and can't come up with anything relevant... help! Thanks!
Link to Project (Click "Demo" to create a session - required)
Link to Entry (Click this after you click the 1st link)
Update : Before now I have just been using Google Chrome to test printing. However, when I tried FireFox, it printed alright, is there anything special I need to do to get Chrome to work??...
RESOLUTION : I am using jQuery and I found that by removing the ui-corner-all class from the inputs before printing, I could then print. Thanks anyways!
If you're using Internet Explorer, then this discussion thread may help you (summary: IE can get confused when printing malformed docs). Check your doctype tag matches your output (the w3c markup validator is very useful)
Edit - I see you're using chrome, but I suggest you still check your page is well formed :)
RESOLUTION: I'm using jQuery and I found that by removing the ui-corner-all class from the inputs before printing, I could then print. Thanks anyways!
Related
We used to be able to type ! inside an html document in vscode to get html boiler plate content completion as documented here.
However it no longer works. Thoughts?
I noticed that if we type ! and select Edit > Expand Abbreviation, the ! is replaced with boilerplate, but I no longer get the intellisense that was there before.
Update
Looks like we need to do ctrl+shift+p and search for User Settings. Filter for the emmet settings and select the Trigger expansion on tab then the ! is replaced with the corresponding emmet snippet.
I also selected Show suggestions as snippets, but the intellisense / snippet is still not showing up.
If you want to get html boilerplate with Emmet Abbreviation, you should type html:5 and hit tab.
I have faced this issue in visual studio.
Step-1:
try below steps in url. https://marketplace.visualstudio.com/items?itemName=sidthesloth.html5-boilerplate
Step-2:
if it worked : "cheers .!"
else:
it could be issue with select language mode. on the bottom of visual studio next to LF on your screenshot select language mode and change it to html.
Thanks & Regards, Surya kiran.
The issue was with Language mode only. You will get the option to select the Langauage mode on the bottom.
Been very annoyed for many, many long minutes by the boilerplate shortcut's suddenly, inexplicably not working (maugre much extension-de-installing and intalling and re-installing, even with VS Code uninstalls and re-installs, but what I'm come up with from mining various forums (what does seem to work and doesn't appear to be settings-dependent or peculiar to my laptop) is:
COMMAND+K plus COMMAND+L (one can just HOLD COMMAND and type K and then L sequentially).
In the Emmet Abbreviation window that comes up type ! as usual and then press Enter/Return.
Simply striking ! will bring up the boilerplate. One can then simply press Enter to return to the code.
The two-stroke process of ! + TAB is now replaced by the only marginally more involved five-stroke process of ⌘ + K + L + ! + Enter.
For me it was the "<" problem
this is not working: <html
this is working: html
After a recent update to VS Code the familiar why of getting a html boilerplate failed. You could add a index.html to the file explore and the window would open for its content.
Using Shift and the exclamation mark key would produce it. That is no longer the case instead create your file in the explore. When it opens the window type html, you will receive a dropdown to select from instead.
enter image description here
I experienced this issue after configuring my VS Code environment for an online course. In my case, the behavior was due to the following pair being added to my settings.json file:
"emmet.showExpandedAbbreviation": "never"
After I removed this, the shortcuts returned.
I have a page in XPages that I use to open and edit a document. There are two ways to open a document in edit-mode: first in read-mode then click a button to put it in edit-mode, or open it directly in edit-mode. Both work in all browsers, yet IE seems to handle both cases differently. We found this out when working with the SWING API.
Opening directly in edit-mode in IE (8/9/10) works, via read-mode to edit-mode doesn't. What we found is that the internal representation of a textarea field differs: when opened in edit-mode, there are more properties, but most importantly, the return+linefeeds are correctly set in both the value and the innerText property.
The button just contains a simple Change Mode action.
Has anyone heard of this anomaly? And does someone know what we did wrong?
PS I'll try to build a simple XPage that shows this behaviour more clearly tomorrow.
For IE switching from read to edit mode, you need a full page refresh
I'm using html frameset in one of my page. where i've divided that frameset to 3 frames. Like..
TitleFrame
LeftColFrame
RightColFrame
In my 'LeftColFrame' frame i've couple of links which has target attribute value as 'RightColFrame '. Every things are going fine except when i click any links from 'LeftColFrame ' it's opening the content in a new browser tab rather than opening in 'RightColFrame'.
Don't know what's going wrong. After googling , i got to know Chrome has some issue with Frameset. But, didn't got real solution to avoid this thing.
So, if any body have any idea about this plz share with me.
Regards
Holly Shit!!!
Guys, after 4hr of extensive debugging now i got the cause for which all these crap was happening. The thing is... in one of my javascript file i've used a variable by name as 'name'. Like this..
var name = false;
And, this 'name' was creating problem in webkit page rendering engine which used by both Google Chrome & Safari. After, googling a bit i got to know that 'name' is a reserve keyword in JavaScript. But,even if this.. IE & Mozilla have no issue with it. But, webkit has some issue.
I have problem with <input type="file" /> in Chrome - it does not show the textbox near the 'browse' button. What is a best way to show a standard file input (textbox+button) in Chrome?
This is the default behavior of Google chrome as well as Safari. Read this blog for a solution
The box is there, although it is not designed.
It might be on the "wrong" side of the window, but it's there.
Just for the matter - put a border around it - and you'll see it's there.
<input type="file" style="border: solid 1px red">
Also, after you select a file - you get the name of it.
<input type="file"/> has different visual appearance depending on the browser. On some browsers it is a text field with a button in others its just a button. Since the element isn't very styleable there isn't much you can do about it.
If you really want a file upload to look/behave different from the default implementation flash is the way to go.
For example many sites use sfwUpload. For full styleing freedom, you can make it invisible and place it on top of a html button via positioning.
Another way to work with the file upload inputs are to make them invisible via visibility: hidden, position them on top of other elements and thus forgo the use of flash, but the implementations are rarely very nice, so i wouldn't recommend it.
The file input element is styled differently depending on your browser (and probably OS - I've only ever used Windows). If you look at the same page with a file input element in FF, IE and Chrome, it will appear differently in each browser.
Why do you need to display the textbox anyway? In FF and IE you can't type directly into it anyway, so the only usage would be to display the filepath of the selected file; which Chrome already does for you, just not in a box.
I found a link from someone else who was having this problem, solution here.
It doesn't specifically mention chrome, but safari does the same thing apparently. (The link was an accepted answer posted in a chrome discussion)
edit: wow, second time this morning that I've been out googled by another member! at least questions are getting answered!
You could override the default behaviour and swap the control appearence alltogether. Found this today researching how to edit the css on fileupload.
Most of the times type file got display:none style. In that case use !important to display the input field.
<input id="cv_file" type="file" name="cv" style="display:block !important;"/>
Sometimes it is just caused by a javascript code similar to this one:
function someOnClickHandler(e)
{
e.preventDefault(); // it kills the file dialog
}
// somewhere:
$('.some-selector-which-contains-the-file-elem').on('click', someOnClickHandler);
This is something of a follow-up question to my question here. You can find the HTML source in a text file here.
When I load that page in IE8, I get the "Done, but with errors on page." message in my status bar. The detail view shows
Expected identifier
sms Line: 147
Code: 0 Char: 67
and I see absolutely no problems anywhere near there. In IE8, the page is still behaving erratically w/r/t the randomly losing focus as mentioned in my other question.
When I load the same exact page in Firefox (using Firebug) the console shows no errors and the page works perfectly. Any thoughts on what's going on here? This is driving me nuts and making me want to give up on even trying to write an IE friendly page.
Edit: Thanks for all the comments! This page is written as a JSP, so I edit in Eclipse. I found an Eclipse warning about the onblur event for the username field. I switched it from
onblur="alert(document.activeElement + ' class:' + document.activeElement.class)"
to
onblur="alert(document.activeElement)"
and that made the bizarre IE page error vanish. I had been trying to give more info (namely, its CSS class) about specifically which element is stealing focus - to my own detriment, apparently, since Javascript was interpreting the '.class' part in the Java(script) sense there is no class property (I should have been using className).
And, no, the page doesn't validate. But the errors were mostly/all ones that just didn't make sense to me, such as
Line 14, Column 41: Attribute "LANGUAGE" is not a valid attribute. Did you mean "language"?
But I'm still stuck trying to figure out why, as I enter text in the username & password fields, focus randomly switches to a div (working on figuring out which div currently).
Edit 2: It's the div between the two "global nav" comments, at the very top of the body. Still no idea why it's happening, though.
The problem appears to be the line
onBlur="alert(document.activeElement + ' class:' + document.activeElement.class)"
when you take off the ".class" it loads without issue. Are you sure ".class" is valid?
Does your HTML validate?
I agree, IE does a terrible job giving developers information about page errors. I only support IE on the principle that users shouldn't have to download twenty-odd browsers to go to their favorite websites. Web developers have a responsibility to make it "just work". Browser developers have a responsibility to communicate with each other and conform to standards.
Run your javascript through JSLint. You probably have a missing semicolon somewhere or a comma at the end of an object property that shouldn't be there. Firefox is more forgiving than IE when it comes to those types of syntax errors.
Edit: The inline js in your page seems to be OK. Check the contents of qm_scripts.js.
When I remove the .class from document.activeElement.class the error goes away.
The real issue is that you need to be able to debug your JS in IE 8, correct? There is a tool for that! :)