Does anyone know if I could use custom HTML attributes in a Web Page, most of mobile devices could read it? or some devices will omit attributes as a default way? In other words: Most default web-browsers installed into mobile devices has the ability to process custom attributes?
I have some code like this:
<input type="text" id="txt1" value="0" percent="50" idColor="12">
the items you are talking about are attributes. If the webbrowser doesn't understand a particular attribute it should ignore them.
Modern browsers generally treat unknown attributes as properties assigned to elements, without any default impact, but recognized as attributes in CSS and JavaScript. In your case, for example, the CSS selector input[idColor] would match those input elements that have the attribute idColor, even though such an attribute is not defined in HTML specs.
In JavaScript, however, they are normally not available directly as properties, so e.g. document.getElementById('txt1').percent would yield undefined, though there are browser differences. But document.getElementById('txt1').getAttribute('percent') would yield 50.
I would expect this to apply to mobile browsers, too, though I only tested this on Android.
It is however unsafe to make up your own attribute names in HTML. What happens if some future HTML spec, or just some browser, assigns a meaning to an attribute called percent? The meaning could be quite surprising, for all that we can now.
Therefore the recommended way to use attributes that carry arbitrary data for use in client side scripting is to use names that start with data-. This gives you your own naming space to play with. No reasonable browser or search engine will ever treat such attributes as anything but page author’s private playground, not to be messed up with. So it would be better to use e.g. data-percent="50" data-color="12".
Related
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.
In manifest.json, we specify our background page and can put an html or a js file for it. Since it is only a script that executes what sense does it make to have an html file for it?
I mean where is UI going to get shown anyway?
Similarly the devtools_page property has to be an html file. What sense does that make?
It will not be shown anywhere (that's the essence of "background"), but some elements on it make sense.
You can have an <audio> tag, and if you play it, it will be heard.
You can have an <iframe> with some other page loaded invisibly.
..and so on
As for devtools_page, it would actually be visible in the interface (as an extra panel in the DevTools)
It is possible that devtools_page must be an HTML file just for legacy reasons: it was not updated when manifest version 2 rolled out with changes to how background pages are specified. Still, the same arguments as above apply.
background_page is a legacy feature from the initial support of extensions in Chrome. background.scripts was added in Chrome 18. I can't speak for Google's original intentions but I'd guess that in the original design using an page felt more natural and would be less likely to confuse developers. Once they realized how many background_pages were just being used to load JavaScript it made sense to explicitly support that.
In HTML5, elements can have arbitrary metadata stored in XML attributes whose names start with data- such as <p data-myid="123456">. Is this part of the SVG spec too?
In practice this technique works fine for SVG docs in many places. But I'd like to know if it's part of the official SVG spec or not, because the format is young enough that there's still a lot of incompatibility between browsers, especially in mobile. So before committing to code I'd like know if I can expect future browsers to converge on supporting this.
I found this message from the working group mailing list saying they "expect [they] will" support it. Did this become official?
While other answers are technically correct, they omit the fact that SVG provides an alternative mechanism for data-*. SVG allows any attribute and tag to be included, as long as it doesn't conflict with existing ones (in other words: you should use namespaces).
To use this (equivalent) mechanism:
use mydata:id instead of data-myid, like this: <p mydata:id="123456">
make sure you define the namespace in SVG opening tag, like this: <svg xmlns:mydata="http://www.myexample.com/whatever">
EDIT: SVG2, currently W3C Candidate Recommendation (04 October 2018), will support data- directly (without namespaces, the same as HTML). It will take some time before the support is widespread though. Thanks #cvrebert for pointing this out.
The data-* attribute is part of HTML5. It’s not a generic XML attribute.
The current SVG W3C Recommendation is SVG 1.1 (from 2011-08). It doesn’t allow this attribute, as you can check in the attributes list.
The same is the case for the SVG 2 Working Draft (from 2012-08). Update (2015): It seems that it’s intended to support data-* attributes in SVG 2 (currently still a Working Draft).
data-* attributes on SVG elements are officially supported in the current draft of SVG2. See:
w3c/svgwg commit 1cb4ee9: Added SVGElement.dataset and allowed data-* attributes on all SVG elements.
ACTION-3694: Add "data-*" attributes notes to spec. (Created on: January 15, 2015)
RESOLUTION: We will reserve "data-*" attributes to be used in SVG content. The API for handling them is on Element. (from SVG WG Telecon on 15-Jan-2015)
https://lists.w3.org/Archives/Public/www-svg/2014Dec/0022.html
there is a more general mechanism.
svg supports desc elements which may contain arbitrary xml from other namespaces. link instances of this elements or child nodes from you own namespace by dependent ids or refid attributes.
this is the relevant part of the spec (5.4).
I'd like do this programmatically:
Given a page URL, I need to get all links on the page. What's important is that at least 3 pieces of link info must be obtained: anchor text, href attribute value, absolute position of the link on the page.
Java CSSBox library is an option, but it's not fully implemented yet(the href attribute value cannot be obtained at the same time and some extra mapping must be done with additional library such as Jsoup). What's more, the CSSBox library renders a page really slow.
It seems that Javascript has all functions available but we have to inject the javascript code into the page and write a driver to take advantage of existing browsers. Scripting languages such as Python and Ruby have support for this as well. It is hard for me to find out the most handy tool.
Does PHP's DOM manipulation library help you? http://www.php.net/manual/en/book.dom.php
My objective is to generate a graphic layout (made of Richfaces components) based on some input configuration (like an XML file) and display it in my web app. The layout is composed of graphic symbols representing various entities in the system: each symbol should be mapped to an entity in the system, in order to display its state. The XML configuration file is used to define the symbol connections and positions within the layout, and their mapping rules to an entity. How can I achieve this?
I was thinking to create a symbol library in a technology such as SVG, where you can define both the aspect and the behaviour, and then simply "wrap" each SVG symbol in a dynamically created richfaces component, which would allow me to handle both the user interactions and the mapping rules defined in the symbol. Unfortunately JSF/Richfaces don't support SVG images, therefore I would have to use plain HTML without Richfaces features.
Another way to achieve that would be to simply define generic symbols in the XML file, each one of them with an attribute specifying the related image, the mapping rule, etc., and then generate the corresponding richfaces component from within the web-app. By doing so, would I be able to then display all the symbols in the right position and therefore generate the complete dynamic layout?
Could you suggest a better approach? Thank you very much.
I believe that HTML5 has direct support for SVG images, however it is still an embedded object in regular HTML after all. This too is something I have been waiting for however I don't believe any of the current JSF2 component libraries have an offerring for this yet.
Here is a good explanation of a possible workaround:
Getting started with SVG graphics objects in JSF 2.0 pages
Potentially you could build a custom facelet component utilizing this workaround?
My thought though is that when your only tool is a hammer, everything looks like a nail. I would try to utilize an RIA (Rich Internet Application) technology better suited for display and manipulation of vector graphics like HTML5, Flash+Flex, Silverlight, etc..