So I am Curious about how the browser window itself is generated and what it is.
I don't mean the website itself, I mean the Ctrl + f components , the tabs, the x mark to close the browser , the url input field, the history buttons etc.
How are they programmed , rendered and what is listening to the events?
Are these html elements as well?
The actual browser would be made in another language like c++ or rust, html is only used to create webpages.
Related
I understand that the background page of a Chrome extension is never displayed. It makes sense to me that a background page should contain only scripts. In what situations would HTML markup ever be needed?
At https://developer.chrome.com/extensions/background_pages there is an example with an HTML background page, but I haven't been able to get it to work (perhaps because I am not sure what it should be doing).
Are there any examples of simple Chrome extensions which demonstrate how HTML markup can be useful in a background page?
Historical reasons
The background page is, technically, a whole separate document - except it's not rendered in an actual tab.
For simplicity's sake, perhaps, extensions started with requiring a full HTML page for the background page through the background_page manifest property. That was the only form.
But, as evidenced by your question, most of the time it's not clear what the page can actually be used for except for holding scripts. That made the entire thing being just a piece of boilerplate.
That's why when Chrome introduced "manifest_version": 2 in 2012 as a big facelift to extensions, they added an alternative format, background.scripts array. This will offload the boilerplate to Chrome, which will then create a background page document for you, succinctly called _generated_background_page.html.
Today, this is a preferred method, though background.page is still available.
Practical reasons
With all the above said, you still sometimes want to have actual elements in your background page's document.
<script> for dynamically adding scripts to the background page (as long as they conform to extension CSP).
Among other things, since you can't include external scripts through background.scripts array, you need to create a <script> element for those you whitelist for the purpose.
<canvas> for preparing image data for use elsewhere, for example in Browser Action icons.
<audio> for producing sounds.
<textarea> for (old-school) working with clipboard (don't actually do this).
<iframe> for embedding an external page into the background page, which can sometimes help extracting dynamic data.
..possibly more.
It's debatable which boilerplate is "better": creating the elements in advance as a document, or using document.createElement and its friends as needed.
In any case, a background page is always a page, whether provided by you or autogenerated by Chrome. You can use all the DOM functions you want.
My two cents:
Take Google Mail Checker as an example, it declares a canvas in background.html
<canvas id="canvas" width="19" height="19">
Then it could manipulate the canvas in background.js and call chrome.browserAction.setIcon({imageData: canvasContext.getImageData(...)}) to change the browser action icon.
I know we could dynamically create canvas via background.js, however when doing something involving DOM element, using html directly seems easier.
I want to add on my site a text who is writing, as in http://www.whoismrrobot.com/
I use the code <Marquee>Text Here</Marquee> but this code only rolls the text.
The effect on your example site is not achieved with the marquee tag, and it can't be done this way. I guess the site is using some combination of JavaScript, CSS and maybe server side scripting.
Generally using the marquee tag is a bad idea, as it is some remnant of the "old times", when format and content both were provided by the html page itself. Even back then the marquee tag wasn't part of the html-specification and not supported by every browser.
For further details see this description of the tag.
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?
I have seen webpage with a PDF icon, where you could click on it to print the content of that webpage.
The page i am intending to add the print feature is designed in JSF, so is there anyway where i could add a print button, to get the webpage printed ?
No, you must do this yourself. Get some PDF library (for example iText), then get web page output (plain HTML). Then you will have to iterate thru HTML and create PDF version (for example build iText document). You will probably have to do this yourself, because some elements (javascript powered) will need to turn into static content. Nobody but you knows how the output should look like.
At what stage does my input in the textarea change from being this raw text, and become HTML?
For example, say I indent 4 spaces
like this
Then the WMD Showdown.js will render it properly below this textarea I type in. But the text area still literally contains
like this
So is PHP server side responsible for translating all the same things the showdown.js does to permanently be HTML in the SoF Database?
There are some other posts here about this, but basically it works like this. Or at least this is how I do it on my website using WMD; see my profile if you're interested in checking out my WMD implementation.
User enters the Markdown on the client, and showdown.js runs in real time in the browser (pure client-side JavaScript; no AJAX or anything like that) to give the user the preview.
Then when the user posts to the server, WMD sends the Markdown (you have to configure WMD to do this though; by default WMD sends HTML).
Run showdown.js server-side to convert the Markdown to HTML. In theory you could use some other method but it makes sense to try to get the same transformation on the server that the user sees on the client, other than any HTML tag filtering you want to do server-side.
As just noted, you'll need to do appropriate HTML tag filtering to avoid cross-site scripting (XSS) issues. This is both important and nontrivial, so be careful.
Save both the Markdown and the HTML in the database—the Markdown because if users want to edit their posts, you want to give them the Markdown, and the HTML so you don't have to transform Markdown to HTML every time you display answers.
Here are some related posts.
Convert HTML back to Markdown for editing in wmd: Tells how to configure WMD to send Markdown to the server instead of HTML.
What HTML tags are allowed on Stack Overflow?: Useful for thinking about HTML tag filtering.
Well first of all StackOverflow is built on ASP.NET, but yes essentially the characters in the rich text box gets translated back and forth.