As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm making a text based game in JavaScript, and I'm looking for a command line widget, with the following features:
print - Be able to send a synchronous command to put some text (preferably support arbitrary HTML) into the command line.
commands - Be able to specify commands which a user can type in, which will then execute functions (should support parameters to such commands, and preferably also have an auto-complete).
prompt - Be able to request input (and send that input to a callback). This should queue prints, and disable commands.
The user shouldn't be able to edit output text (but should be able to copy and paste).
Preferably using semantic elements.
Browser Support: Latest Firefox & Chrome, preferably also IE9, latest Safari & Opera.
Does anyone know about any such preexisting widget, if not, can anyone give me tips for how to make one?
It's not as tricky as you'd think to make this. I made one recently for a project, using HTML elements and jQuery JS.
I used an input element for the input line - handling special keypresses like enter and tab. For previous commands and responses I used a scrollable area which I appended new elements to as new inputs or responses were available.
I displayed the commands and responses in DIVs, which allowed for copy and pasting (and HTML formatting). I even made the responses disclosable so I'd only show the command initially and you could click on the 'expand' button to show the rest of it.
It all worked really well in the end. Just a few simple HTML elements and some jQuery code which wasn't as complex as I thought it would be when starting it. By far the most complexity and most code was in tweaking the aesthetics!
Look here that is a »virtual box« coded in Javascript with Linux running in it, the terminal might be something you could have a look at it. As far I looked at it, there is done with tables.
Greeting...
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I believe I have found a bug in HTML / JavaScript, but I have no idea where to post this bug. Any information on where to post such bugs is appreciated.
The bug can be recreated as follows:
Go to W3Schools Tryit Editor
Make sure you have some other tab open in the same window
Click on the input field to focus it
Click on a different tab in your browser
Depending on your browser, different effects will occur (all unwanted)
This has been tested in Chrome (it will give an infinitely repeating alert), on Firefox (it will give the alert, but not switch tabs when clicking the alert away), and on Edge (it will show that the new tab is selected in the tabs bar, but the rest of the page doesn't switchenter link description here).
Since this bug occurs in multiple browsers, and also since the bug occurs with sample code from w3schools, I believe that this bug is related to HTML / JavaScript more than to a specific browser.
W3Schools isn't affiliated with W3C, the organisation who maintain the HTML specification. Nor are they affiliated with Ecma International, the organisation who maintain the JavaScript specification. Nor, for that matter, are they affiliated with any browser.
The code they've supplied here is their own code. It's not official by any stretch of the imagination: it's code that you or I could have written.
However that said, it looks like you have discovered a bug which affects multiple browsers. This is something you an report on the various browser channels if you so desire. Potorr has already linked you to a couple of these, which can be found by simply searching for something like "{browser name} bug tracker" with a search engine.
However you may consider instead posting directly on W3Schools' forum, as, after all, this is their code: http://w3schools.invisionzone.com/index.php?/forum/45-general.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am using fancyBox to display menus/dialogues to users of an app I am building. The content displayed in the box is HTML - I could generate it all in JS and put it into a hidden div to display when needed, or make an AJAX call to fetch the content when a fancyBox is opened.
Is there any downside to having a bunch of hidden divs in a page (performance issues on mobile browsers etc)? I'd prefer to do it this way as the user experience is obviously going to be snappier.
In general, you should load information as soon as you can as the time to complete requests is the main bottleneck in most web apps. The issue here is not so much the html but the assets that are requested in addition to the html (e.g. images, videos, etc). These take up memory and also, potentially slow down the initial page load time as you could be blocking visible image loads by loading images that are not (yet) visible. To work out if either of these issues is a problem you don't really have any alternative but to test on your target devices. However, in your case you don't actually save any memory by fetching the assets later as they are still ultimately being fetched at some point and so the browser is going to have to be able to cope with everything being loaded in the end - therefore you might as well have them in the beginning. If page load times are an issue you could still defer loading the assets but only until the dom has rendered rather than waiting until the hidden div is needed. That way you don't hold up the page load but still have the assets when you need them. For example in JQuery:
$(function() {
$('#hiddenDiv').html(hiddenContent);
});
The assets (images, etc) will not be requested until the html referencing them has been added to the dom.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Just found out about the CSS tilde selector and it seems like it could be an elegant way to handle toggling input visibility.
The use-case I have in mind is when you only want to display an input to the user when they have checked a checkbox. Currently I do this with javascript and attach listeners to each checkbox, which then search through the DOM to find the appropriate input and toggle a class.
So the question is, why is this bad? And if it isn't, why isn't this prevalent? Why do we do this with .js rather than CSS? It seems to me they are both manipulating the presentation layer in fairly similar ways...
Bonus points for resources.
HTML is the Model, it contains the Data
CSS is the View, it contains the Styles
JS is the Controller, it contains the Interactions
This MVC structure makes for a powerful delegation of responsibility. When you want to change the state of a widget on a page, you can use JavaScript to change the available styling hooks:
jQuery used for brevity
$('#button').on('click', function () {
$('#widget').toggleClass('hidden');
});
CSS:
.hidden {
display: none;
}
Using this structure will easily allow you to change how interactions are performed. If you decide later that the widget should be animated, it's a simple change.
Using JavaScript also has the advantage of being backwards compatible. The percentage of users who have JavaScript disabled is remarkably few. While I highly recommend supporting people with JS disabled, that can often be done simply by showing all the content by default, and hiding things only for users who have JS enabled.
The use-case I have in mind is when you only want to display an input
to the user when they have checked a checkbox.
If you're planning to use the :checked selector for that, your app won't run in old browsers (IE < 9). If you're OK with this restriction, that is, only modern browsers concerned, CSS will do fine as well.
Using JS ensures that your site will run on older browsers too, provided the users have JS enabled.
You can also use a mix of both and it will ensure that your page works in modern browsers even with JS disabled as well as JS-enabled old browsers.
It is often easier to detect whether the browser has JS disabled (e.g. using a stylesheet inside <noscript>) than determining whether a browser supports certain CSS selectors.
Therefore using a JS solution allows you to easily place a disclaimer asking the user to enable JS for the page to work properly.
Though, again, if your site is not aimed at general public that may be using IE8 and below, the CSS solution will do just fine.
I would say if you can get away with using the tilde selector, or css in general, then go for it. CSS imho is a cleaner, usually more concise and superior performance way to accomplish the same thing as toggling the item in js. Plus, the browswer support for the tilde is quite good - see http://www.quirksmode.org/css/contents.html
There are times when you must use javascript to accomplish this, for example the element to hide is not a sibling or a descendant of the element in question.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I get tired of the dotted box that appears when you click a tags...so that I started replacing them with p tags...and adding an event listener for click events.
I can't help but notice that other popular sites don't do this ( for example when you click Post Your Question on SO the annoying dotted box appears )
Is there any good reason not to replace a tags by p tags. I don't need any of the special a tag properties...in fact I have to use preventDefault() in my JavaScript to stop them from linking some times.
Is it O.K to pretty much eliminate the A tag?
This is a question regarding major modern browsers.
I'm about to rid myself of them...and am paranoid I'm missing something as I see them still in use pretty much everywhere.
No, this is not okay.
Anchor tags are needed for browsers that don't support your styling, and I'm just talking about old versions of IE. Remember that screen readers, text-only users, and browser plugins all expect to find your anchor tags.
As Dash has pointed out, bots such as search engine crawlers also need your anchor tags to be able to follow them and index your pages.
HTML is for document structure. CSS is for styling. It is important to keep this principal.
A note regarding that dotted box... that is there to show focus on an element. Not everyone uses a mouse you know. Some prefer to tab through the document with a keyboard, and that focus box helps with that. Even if you succeed in removing it with CSS... please don't.
Don't do this, because of html semantics. Screen readers and search engines may not be able to follow your link, for example.
If you don't want buttons and links to have a dotted box around them after they've been clicked, simply add a listener that blurs the element:
Look ma, no dots
There is also a CSS property you can set to not have dots too, but I can't remember it. Do a search or look at the Mozilla default stylesheet.
I disagree with the other two commenters a little. While it is true that it will break screen readers and not be backward compatible in general.....
IF you have a specific use case where you don't care about any of the above, well...it is your project. :)
And you COULD also mostly achieve this and keep the anchor tags by add the following to your CSS:
a
{
text-decoration: none;
}
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We are in need of a DOM parser, that will be able to run a bunch of patterns and would store the results. For this we are looking for libraries that are open and we can start on,
able to select elements by regexp (for example grab all elements that contain "price" either in class, id, other attributes like meta attributes),
should have a lot of helpers like: remove comments, iframes, etc
and be pretty fast.
can be run from browser extensions.
Ok, I'll say it :
You can use jQuery.
ups :
it is a very good dom parser
it is very good at manipulating the dom (removing/adding/editing elements)
it has a great and intuitive api
it has a big & great community => lots of answers to any jquery related question
it works in browser extensions (tested it myself in chrome and it apparently works in ff extensions too : How to use jQuery in Firefox Extension)
it is lightweight (About 31KB in size - minified and gzipped)
it is cross-browser
it is definitely open source
downs :
it doesn't rely on regex (although this is a very good thing - as dda already mentioned), but regex can be used to filter the elements
dont know if it can access/manipulate comments
Here's an example of some jquery action :
// select all the iframe elements with the class advertisement
// that have the word "porn" in their src attribute
$('iframe.advertisement[src*=porn]')
// filter the ones that contains the word "poney" in their title
// with the help of a regex
.filter(function(){
return /poney/gi.test((this.title || this.document.title).test()));
})
// and remove them
.remove()
// return to the whole match
.end()
// filter them again, this time
// affect only the big ones
.filter(function(){
return $(this).width() > 100 && $(this).height() > 100;
})
// replace them with some html markup
.replaceWith('<img src="harmless_bunnies_and_kitties.jpg" />');
node-htmlparser can parse HTML, provides a DOM with a number of utils (also supports filtering by functions) and can be run in any context (even in WebWorkers).
I forked it a while back, improved it for better speed and got some insane results (read: even faster than native libexpat bindings).
Nevertheless, I would advice you to use the original version, as it supports browsers out-of-the-box (my fork can be run in browsers using browserify, which adds some overhead).