In Brilliant.org, when we look at the source of the pages, we see that they've rendered their mathematical formulas on the server. For example:
Page: https://brilliant.org/practice/distributive-property-misconceptions/
Source: view-source:https://brilliant.org/practice/distributive-property-misconceptions/
But as much as I know, when we use MathJax to render formulas, we should deliver them in original format, and it will render then client-side. And if we give MathJax the rendered formula, it throws many errors re-rendering them.
So, how brilliant.org has managed to render formulas on server-side?
Brilliant.org uses Katex library to render math formula. Katex offers server-side and client-side rendering. As I know, Brilliant renders on server side which is more efficient than rendering on the client-side.
There are several ready WYSWYG editors integrates Katex library. One of them is https://quilljs.com/. When you enter formula, it renders into the HTML editor.
https://katex.org/docs/cli.html
Related
Why do some webpages use a little HTML, but so much JavaScript? Someone even used JavaScript to append the HTML like: <div> <span> and so on; the HTML source code was hidden in JavaScript.
Like this:
The modern web is growing greatly in terms of complexity and user expectations.
Users want more complex, rich content, delivered faster. JavaScript provides the capability to enable meeting this demand.
HTML by definition, (HyperText Markup Language) provides zero functionality to a website. It simply displays stuff. And CSS (Cascading Style Sheets), in particular CSS3, provides a minimal level functionality (like import -ing a font for example, or making a div spin or fade in and out)
For anything and everything else, you gotta use JavaScript. From controlling HTML, CSS, retrieving data from APIs (Application Progamming Interface) and handling user input, JavaScript does it all.
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.
From the tutorial
But there's a problem! Our rendered comments look like this in the
browser: "<p>This is <em>another</em> comment</p>". We want those tags
to actually render as HTML.
That's React protecting you from an XSS attack. There's a way to get
around it but the framework warns you not to use it:
...
<span dangerouslySetInnerHTML={{__html: rawMarkup}} />
This is a special API that intentionally makes it difficult to insert raw HTML, but for Showdown we'll take advantage of this backdoor.
Remember: by using this feature you're relying on Showdown to be secure.
So there exists an API for inserting raw HTML, but the method name and the docs all warn against it. Is it safe to use this? For example, I have a chat app that takes Markdown comments and converts them to HTML strings. The HTML snippets are generated on the server by a Markdown converter. I trust the converter, but I'm not sure if there's any way for a user to carefully craft Markdown to exploit XSS. Is there anything else I should be doing to make sure this is safe?
Most Markdown processors (and I believe Showdown as well) allow the writer to use inline HTML. For example a user might enter:
This is _markdown_ with a <marquee>ghost from the past</marquee>. Or even **worse**:
<script>
alert("spam");
</script>
As such, you should have a whitelist of tags and strip all the other tags after converting from markdown to html. Only then use the aptly named dangerouslySetInnerHTML.
Note that this also what Stackoverflow does. The above Markdown renders as follows (without you getting an alert thrown in your face):
This is markdown with a ghost from the past. Or
even worse:
alert("spam");
There are three reasons it's best to avoid html:
security risks (xss, etc)
performance
event listeners
The security risks are largely mitigated by markdown, but you still have to decide what you consider valid, and ensure it's disallowed (maybe you don't allow images, for example).
The performance issue is only relevant when something will change in the markup. For example if you generated html with this: "Time: <b>" + new Date() + "</b>". React would normally decide to only update the textContent of the <b/> element, but instead replaces everything, and the browser must reparse the html. In larger chunks of html, this is more of a problem.
If you did want to know when someone clicks a link in the results, you've lost the ability to do so simply. You'd need to add an onClick listener to the closest react node, and figure out which element was clicked, delegating actions from there.
If you would like to use Markdown in React, I recommend a pure react renderer, e.g. vjeux/markdown-react.
I'm using React.js to build an app, which includes quite a few svg charts. I'm using d3 functions that help in chart creation, such as scales, but then using React to generate the svg elements. Here's a great writeup on the approach: http://10consulting.com/2014/02/19/d3-plus-reactjs-for-charting/
Part of why I'm going down this road was for performance - the first version of the app was too slow. It has a lot of elements and a lot of user-interactivity, all client-side. I'm trying to basically recreate the dc.js library in React.
It's a really fun approach and intuitive (more so than d3 alone IMO). Building axes is tedious though, and d3 does it so nicely. I would love d3 to just be able to output a string of svg elements that represent the axis (and maybe other elements) , and I feed it to React to include in the DOM.
I did see this SO question (How to make d3.js generate an svg without drawing it?) and the answer was to append it in the DOM and remove it, or create a DOM fragment. Those approaches go against the React approach and likely negate the performance benefits of React. I also saw jsdom and phantomjs solutions, which will not work in my case.
Can d3 generate svg without appending it to the DOM?
#Lars is correct if you are using traditional means. However, this is definitely possible with 'jsdom'. This library can simulate the DOM and also allows for string input. Which means you could inject the root element into the fake DOM and get a new window element to manipulate. You could then use D3 without changing it's source and using is like normal.
This would allow for the generation of an SVG.
No. D3 by design operates directly on the DOM through its selections. To have it generate string representations instead without modifying the DOM, you would need to modify its source code (and it would be quite a significant modification).
When designing and previewing a report in BIDS everything looks fine, but once rendered in a web browser the text boxes resize. I've tried a few things to stop this including using rectangles as place holders. Does anyone know of a workaround for this?
Here are some screenshots. First design view:
Render view:
In my experience, SSRS is not a very good tool for precise rendering. I've had the issue describe in various forms before, and can only offer a few options:
Don't care. Design your report in a way that it doesn't matter how it's exactly rendered.
Focus on one renderer. Don't optimize for both the BIDS Preview and the HTML rendering, but only on the final one (probably HTML). Note that with HTML you do have to deal with cross-browswer issues.
Use tables for layout. I know, this is frowned upon in CSS land, and I personally don't like it either. But a matrix may be your best bet at approaching pixel-perfectness, and from your screenshot it even looks like you have tabular data so it's even possible to rationalize the choice.
Choose another renderer. Deliver your report in Excel instead of HTML. With Excel it should be easier to get to a nicely layouted table.