I have a site that's maintained by a 3rd party. They will allow us to load our custom js file in the header so that we can manipulate the DOM as each page loads. I know how to swap out classes, etc. but I was curious if I can sniff for a HEX value and swap it out for another instead of adding classes here and there to do the same thing.
I don't want to this to one element (e.g. getElementByID or tag) I want it to swap out ALL instances of this variable. So if the CSS is:
fred { color: #e3e3e3; } (and other classes are also using #e3e3e3)
I want to be able to search for all instances of #e3e3e3 and change them to #d9d9d9. or something like that.
Thanks
If you are explicitly trying to modify the CSS instead of just adding either inline styles to an element or by adding your own style tag to the document with more specific CSS, you could technically do what you are asking, as answered by this other SO question.
I would recommend instead of that you either inline your CSS if you are targeting only a few DOM elements, or create a more specific CSS rule targeting the classes you want to change.
Normally css files are put inside <head></head>, what if I put it inside <body></body>, what difference will it make?
Just to add on to what jdelStrother has mentioned about w3 specs and ARTstudio about browser rendering.
It is recommended because when you have the CSS declared before <body> starts, your styles has actually loaded already. So very quickly users see something appear on their screen (e.g. background colors). If not, users see blank screen for some time before the CSS reaches the user.
Also, if you leave the styles somewhere in the <body>, the browser has to re-render the page (new and old when loading) when the styles declared has been parsed.
The most recent versions of the HTML spec now permits the <style> tag within body elements. https://www.w3.org/TR/html5/dom.html#flow-content
Also the scoped attribute which used to be prerequisite to have a style tag in the body is now obsolete.
This means, that you can use the style tag everywhere you want, the only implications are decreased page performance due to possible reflows/repaints once the browser hits styles further down in the page tree.
Obsolete answer:
The <style> tag isn't allowed within <body> according to the w3 specs. (You can, of course, apply inline styles via <div style="color:red"> if necessary, but it's generally considered poor separation of style & content)
Putting CSS in body means it is loaded later. It is a technique some use to let the browser start drawing the interface faster (i.e., it removes a blocking step). This is important for user experience on SmartPhones.
I do my best to keep one small css on the <head> and I move the rest at the bottom. For example, if a page uses JQuery UI CSS, I always move it at the bottom of the <body>, just before the links to JQuery javascript. At least, all the non Jquery item can already be drawn.
Head is designed for (Quoting the W3C):
"information about the current
document, such as its title, keywords
that may be useful to search engines,
and other data that is not considered
document content"
See the Global structure of an HTML document. As CSS is not document content, it should be in the head.
Also every other Web developer will expect to see it there, so don't confuse things by putting it in the body, even if it works!
The only CSS you should put in the body is inline CSS, though I usually avoid inline styles.
The standards (HTML 4.01: the style element) clearly specifies that the style tag is only allowed inside the head tag. If you put style tags in the body tag the browsers will try to make the best of it anyway, if possible.
It's possible that a browser would ignore a style tag in the body if you specify a strict document type. I don't know if any current browser does this, but I wouldn't count on all future versions to be so relaxed about where you place the style element.
Although the style tag is not allowed in the body, the link tag is, so as long as you are referencing an external stylesheet, all browsers should render and use the CSS correctly when used in the body.
Source: https://html.spec.whatwg.org/multipage/semantics.html#the-link-element
In addition to earlier answers, though putting a style code block inside the element may work in modern browsers (though that still doesn't make it right), there's always a danger, particularly with older browsers that the browser will render the code as text unless the style section's included within a CDATA section.
Of course the other thing with putting it inside the element, other than inline styles, is that as it doesn't meet with the W3C HTML/XHTML specs is that any page with it within the body will fail on the W3C validator. It's always easier to bug-hunt unexpected display problems if all your code is valid, making it easier to spot mistakes. An invalid HTML element can adversely effect the rending of any and all element beyond where it occurs in the code, so you can get unexpected effects having elements in places where they shouldn't be, because when a browser finds an invalid element, it just makes it's best guess as to how it should display it, and different browsers may make different decisions in how they render it.
Whether you use a transitional or a strict doctype, it would still be invalid according to the (X)HTML specs.
Two conflicting answers:
From MDN page on link tag:
A <link> element can occur either in the <head> or <body>
element, depending on whether it has a link type that is body-ok. For
example, the stylesheet link type is body-ok, and therefore a
<link rel="stylesheet"> is permitted in the body. This isn't however
best practice; it makes more sense to separate your <link> elements
from your body content, putting them in your head.
From CSS The Definitive Guide (4th Edition/2017) page 10
To successfully load an external stylesheet, link must be placed inside the head element but may not be placed in any other element.
You would actually defeat the purpose of using CSS by putting the styles in the body. The point would be to separate content from presentation (and function). This way, any changes to style can be done in the stylesheet, not in the content. Once you use the inline style method, every page that has inline styling needs to changed one by one. Tedious, and risky since you could miss a page or three, or ten.
Using a stylesheet, you only need to change the stylesheet; the changes propagate automagically to every HTML page that links to the stylesheet.
neonble's point is also another great reason; if you mess up the HTML by adding CSS inline, rendering becomes a problem. HTML doesn't throw exceptions to your code. Instead it goes out and renders it the best way it can, and moves on.
Adhering to web standards by using a stylesheet makes for a better website. And when you need help because things on your page aren't exactly that way you want them, placing your CSS in the head as opposed to the body makes for much better troubleshooting by yourself and for anyone you ask for help from.
The difference is.
The loading of the page is asynchronous, so if you have external stylesheet it will load the css file immediately when it reach the link tag, that is why it is good to have at the top in head.
What difference will it make?
Pros: Sometimes easier to apply certain attributes in certain places, especially if code is being generated on the fly (such as building via php and each of a dynamically sized list needs its own class... such as for item timings for transforms).
Cons: Slightly slower, may not work someday in the distant future.
My General opinion on it:
Don't do it it you don't have to, but if you do have to, don't lose any sleep over it.
Putting the <style> in the body works well with all modern browsers.
I had been using this in eBay.
If it works, don't kick it.
Every Node instance has a baseURI property.
Node instances of ELEMENT_NODE type maintain namespaceURI property.
What are the significance of these two properties for a browser to manage the nodes in DOM?
The namespaceURI is the namespace of the element. So for non-foreign elements in the HTML serialisation, that's http://www.w3.org/1999/xhtml.
The Base URL of a node is, in principal, akin to the <base> element in HTML. That element only sets the base URL for the document. But in XML, a base can be set on any element such that it applies to the xlink:href attributes of its descendent elements, via the xml:base attribute. The XML Base spec describes this. Again, in principal, this should apply to XHTML documents (properly served as application/xhtml+xml of course), for example <a> elements in the svg namespace. However, a quick test shows that in fact, while Firefox supports this correctly, Chrome and IE do not.
I have a test page: http://benfrain.com/playground/svg-test/
On it I have inserted the same SVG a number of ways (img, object, inline, and background image)
I have also implemented the use method of re-using defs from within the SVG (only for the object insertion method and the 'inline' insertion method).
In the console you will see I am also attempting to access the SVG contents from each insertion method (I know img and background image should not be accessible via script - I'm just proving the point).
However, on any version of Internet Explorer (IE9+) the object insertion method fails to load the external CSS (as noted in the comments, IE requires the alternative linking mechanism) referenced from within (via xlink, you would see a 6px wide stroke if it was working) and it is not reachable via JavaScript (works in all the other evergreen browsers) (my mistake).
Can anyone clarify why? I've had a look through the spec: http://www.w3.org/TR/html5/embedded-content-0.html#the-object-element but I must confess some of the technicalities are beyond my comprehension.
Update:
Further to Robert's comments below I made some tweaks to the test page above.
Firstly, the object is accessible with script (rookie mistake). However, oddities still abound:
If the SVG has a link in this format: <?xml-stylesheet href="styles.css" type="text/css"?> then IE11 applies the styles within that stylesheet to the SVG whether it is inserted in the page via img, background-image, inline or object (Safari/Firefox/Chrome only apply the styles if the SVG is inserted inline or via object).
There is a w3c testsuite page for external <use>: http://www.w3.org/Graphics/SVG/Test/20110816/svg/struct-use-05-b.svg
The implementation matrix suggests that IE9 doesn't support external <use> I'm not sure why Firefox is listed as failing as I think even at that time it should have passed that particular test.
For the <object> issue, you need to run the script in the onload event of the <object> tag. I guess you just get lucky with the other UAs as you basically have a race condition.
Presumably IE doesn't support including stylesheets using html syntax. Try XML syntax instead: <?xml-stylesheet href="mystyle.css" type="text/css"?>
Allowing images to use external files is a privacy leak which is why Firefox, Chrome and Safari disallow it. If you converted the CSS to a data URL you could use a link element.
I'm trying to create Dynamic SVG graphics, it is my understanding that the only way to create dynamic SVG is to use a scripting language, so I have a few questions, basically I'd like to load or embed the SVG to a HTML web page and control the graphics using Inputs in the web page, rather than hardcoding the ECMAscript in the SVG file. I'm not entirely sure if I should use the embed tag or an iframe for displaying the SVG here are my doubts regarding SVG and scripting:
Whats the difference (in terms of scripting) in using an <iframe> or and <embed> tag for accessing the SVG elements?, maybe someone can include simple examples.
Can SVG evaluate math expressions in element attributes(just to be sure)?
Don't use either <iframe> or <embed>. Instead, embed your SVG directly in XHTML like so:
http://phrogz.net/svg/svg_in_xhtml5.xhtml
With that, you have full access to the SVG DOM as part of your document. As shown in that example, you simply need to be certain to create SVG elements (but not attributes) using the SVG namespace. You must also ensure that your web host is sending the content type for xhtml as application/xhtml+xml or text/xml, not text/html.
phrogz$ curl --silent -I http://phrogz.net/svg/svg_in_xhtml5.xhtml | grep "Type"
Content-Type: application/xhtml+xml
For more examples of JavaScript manipulating SVG mixed with HTML, see the various .xhtml files in that same directory. A particularly compelling example is this one, which dynamically creates hundreds of small SVG files as inline elements flowing like text.
And to your question:
Can SVG evaluate math expressions in element attributes(just to be sure)?
Not in general, no. However, the usage of SMIL Animation does allow you to specify various interpolation methods of properties over time.
Finally, note that you don't have to put SVG in HTML to make it dynamic. You can script SVG with JavaScript directly. For example, see this test file (press the green button to start simulation):
http://phrogz.net/svg/SpringzTest.svg
Whats the difference (in terms of scripting) in using an or and tag for accessing the SVG elements?, maybe someone can include simple examples.
<iframe>:
Scripts trying to access a frame's content are subject to the same-origin policy, and cannot access most of the properties in the other window object if it was loaded from a different domain. This also applies to a script inside a frame trying to access its parent window. Cross-domain communication can still be achieved with window.postMessage.
Source: https://developer.mozilla.org/en/HTML/Element/iframe#Scripting
We access iframe content by iframe_element.contentWindow method:
<html>
<body>
<iframe id="SVG_frame" src="image.svg"></iframe>
</body>
<script>
var SVG_frame = document.getElementById ( "SVG_frame" );
var SVG_content = null;
function getContent ()
{
SVG_content = SVG_frame.contentWindow;
SVG_content ? alert ( "YAY!" ) : alert ( "BOO!" );
}
SVG_frame.onload = getContent;
</script>
</html>
<embed>:
Example (view source): https://jwatt.org/svg/demos/scripting-across-embed.html
(both methods fail at least in Chromium)
<object>
Example (view source): https://jwatt.org/svg/demos/scripting-across-object.html
Can SVG evaluate math expressions in
element attributes(just to be sure)?
like <element attribute="48/2*(9+3)"/>?
I did't find a word about it in SVG spec.
EDIT
Personally, I recommend to use <object> + Data URI Scheme and/or object_element.contentDocument. I've tested both in Chromium and Firefox.
AHA! <object> has similar security behavior to <iframe>: domain, protocol must be same for site and SVG file.
EDIT2
If You are interested how to get markup vector graphics to work in Internet Explorer(s) without plug-in(s), then Vector Markup Language is the way.
Well, it depends on what you mean with dynamic. In most cases yes, you'll probably want scripts. There's no difference if you put your script in the HTML or the SVG file, both will be executed by the same engine.
You can create interactive/animated svg content with the declarative animation elements (aka SMIL). You can also do simple hover effects with CSS :hover rules, or transitions with CSS3 Transitions.
XSLT can also be used to make somewhat dynamic svg content, since it can transform your input to something else. It doesn't cover the interaction aspect though.
You can access the svg elements from the HTML file that includes it with either of:
theEmbeddingElement.contentDocument (preferred, but doesn't work on <embed>)
or alternatively theEmbeddingElement.getSVGDocument().