I am dynamically building style tags which have classes and css data inside of them. It seems after looking at it, that IE will not rerender items with those style classes. Inline still works, but going to a class, and changing values inside of those classes does not update all tags WITH that class
I was curious if there is a javascript command i can use in IE to refresh/rerender the page based on the current style tags on the page?
It works in chrome, but it seems that IE doesnt do this rerender.
This is a big issue since the users can define their own styles on a page i created, so there are 2 concepts at hand: On load: loading the last set of style tags (during js runtime) and the edit / save of the ones created in this session.
After looking into it with IE, it seems that adding style tags with Rules in it, does not mean that these rules are going to applied to the document.styleSheets run-time CSS.
On the contrary, it seems that the css is scraped first. so when it is loading controls, has something to look at for rendering.
To Get around this, I have not seen any "repaint" functions in JavaScript as of yet, but i did notice that you can actually change the rules of the CSS in the run-time, by looking at document.styleSheets object
You can add rules dynamically via JavaScript which will take effect immediately.
With that said, it might be smart to create a setter/getter for this so everything is smooth and simple to understand. The reason for setters and getters is that you can easily find the objects that you added (Just in case you needed to remove, modify, or append to them later.
The MS page i found is: http://msdn.microsoft.com/en-us/library/ms533039(v=vs.85).aspx
Although is it archived as of 2011, i felt it relevant.
If anyone has more up to date information, i would appreciate it, but that is what was found on my end.
Related
Also what is the best way to hide the elements from the DOM so that the attacker won't be able to change the css property or html attribute in order to access the element. I know we can use React or Angular to develop website and it is easier to hide or display elements. But I want to know in pure HTML & JS what is the best way?
Anyone can just use the browser console and find all elements with for example:
document.querySelectorAll('*');
It does not matter if elements are hidden with CSS.
Even if you encrypt your HTML you will have to decrypt it to show it to the browser. Then the above code still finds all the elements.
Any code you have can be deactivated by setting a breakpoint and rewriting it in-browser using the developer tools.
Even if you replace document.querySelectorAll and all like them with an empty function, developers can still just add jQuery or any DOM querying engine and find your elements that way.
Any code you can use to hide or show elements can just be executed using the browser console if someone spends the time understanding your code.
How else would you debug or test it?
Angular, Vue etc. does remove elements from the DOM but you should never expect this to be a security feature! A hacker can easily set a breakpoint anywhere in your code, inspect API results from the Network panel, go into the components' code to find out what HTML they would be rendering and much more I haven't started to mention.
To implement security you want to only have in the browser what the user needs to see.
There is no way around it.
DOM, stylings, scripts, assets, etc. can always be accessed using developer tools.
As for the question in your question title:
style attribute styles have a higher specificity than CSS from file (or style tags)
CSS from file (or style tags) with !important has higher specificity than styles from the style attribute
style attribute styles with !important have the highest specificty
So !important just overrides specificity if you want to look at it that way. Other than that you should read about CSS Specificity.
Both are same. If you store your value from html hidden or css hide. Anyone can find out them.
So if you are using html , js & css and want to pass value as hidden than disable developer tool and shortkey to open it by this way you can protect your data or else use any encryption method for that.
I am thinking about experimenting with a custom stylesheet. One big issue that I've seen for a long time is the simple fact that we only have h1 and p tags for typography.
It would make a lot more sense to (me to) have descriptive tags such as <hero>, <copy>, <micro>, <mini> etc that can be used instead of doing weird things like <h1 class='hero'>.
What actually happens with evergreen browsers & IE 10+ if you just define a new tag? It does work in general at least in chrome to just define a new tag and assign some CSS properties to it. However, will there be limitations on how we could use Javascript on a tag defined like this? Are there any big downsides?
I am not considering defining a webcomponent for <hero> since that would need to register a component whenever it gets attached which I'm sure would be heavy on performance for something as simple as a heading hero tag. Last time I remembered the html5shiv did something like this for IE8 or IE9. When it wouldn't know the tag it would just convert the tag to a block level element I think with standard properties. Is this what is happening in all evergreen browsers as of now, meaning as long as we don't need special events, methods and properties defined on a tag it would be ok to just write tags such as <hero>?
The the browser will stick the unrecognised element in the DOM with some default styling on the assumption that it is a new feature (and in the hope that there will be a CSS/JS shim to add backwards compatibility) rather than falling over because it's been given invalid HTML.
(Then, in the future, an element of that name does get added to the spec, and your page breaks).
Don't write invalid HTML.
I've had this happen to me three times now and I feel it's time I learned how to avoid this scenario.
Typically, I build the HTML. Once I'm content with the structure and visual design, I start using jQuery to wire up events and other things.
Thing is, sometimes the client wants a small change or even a medium change that requires me to change the HTML, and this causes my javascript code to break because it depends on HTML selectors that no longer exist.
How can I avoid digging myself into this hole every time I create a website? Any articles I should read?
Make your selectors less brittle.
Don't use a selector by index, next sibling, immediate child, or the like
Use classes so even if you have to change the tag name and the element's position in the HTML, the selector will still work
Don't use parent() or child() without specifying a selector. Make sure you look for a parent or child with a specific class
Sometimes, depending on the amount of rework, you'll have to update the script. Keep them as decoupled as possible, but there's always some coupling, it's the interface between script and HTML. It's like being able to change an implementation without having to change the interface. Sometimes you need new behavior that needs a new interface.
I think the best way to help you is for you to show a small sample of a change in the HTML that required a change to your jQuery code. We could then show you how to minimize changes to JS as you update the HTML
I'm dealing with a complex page with a lot of different scripts going on, some ASP.NET AJAX and some jQuery.
For some reason when the page loads one of the elements has its visibility set to hidden.
Is there anything out there that can tell me what it is that's causing this element to be invisible? Or even something that would stop everything that's happening in whatever script is doing this so I can see what it is?
Use a DOM inspector (like the one built in to Chrome) to first determine if it's set to hidden because of a CSS rule or because it was programmatically set to hidden with a direct inline style setting.
If it was programmatically set to hidden, then the only thing I know of is to search all the javascript code for anything that could be changing the visibility.
Then, when you find some candidate lines of code, use a javascript debugger (my favorite is the one built into Chrome) and set breakpoints on each of those lines. Then, reload the page after the breakpoints are set and when one of those breakpoints is hit, you can step through that part of the code and see who is doing it. At that point, you can even look at the call stack and see what code called this and so on. Or, you can step through and out of this code into the higher levels that called it and see why they are doing it.
If it is CSS rules that are making it hidden, then you need to look at what triggers those CSS rules (classes, IDs, etc...) and figure out how to change one or the other so that your desired object isn't hidden by that CSS rule. Remember that classes can be added/removed from objects in the DOM via javascript so that could also be part of the cause.
using Firebug you can set breakpoints throughout your scripts and watch variables as they change at different points. Set a watch on your variable and set breakpoints in your scripts to try and figure out when it is being set. Good luck I've had this problem before it can be a pain
you could try and debug.. or you could override it with something like this:
CSS
#element, .elements{
visibility: visible !important;
}
Modifying the script could break other things.
Sometimes in production environments you're not allowed to modify other pre-exisiting scripts.
Sometimes it's just not worth all the time trying to figure out what script it is. Especially if there are 10-20 scripts on the page that could be updated or changed whenever.
The only reasons I see on the internet to not to use inline-css is because of the separation of html and css & management, but if this is not a problem in my case I don't care I will use.
Another pro I can say is this: imagine you want to load a widget made by another user, you will only need to load 1 file, the javascript and not the css.
But it might have other problems?
thanks
If you read your question again, you have answered it yourself. There is a reason for the "separation" of html and CSS. Because at some point in time, you will eventually want to change the look of what you have coded up. These are the times when having a separate CSS file would be very helpful so you are only ever making changes in one place and not throughout your application.
EDIT
Another usefulness of having the CSS separate is the caching. Most of the modern browsers cache the CSS files. This means there are less round-trips to the server and quicker response times. I'm not sure if same is the case for JavaScript, because JavaScript files would be cached, but the client browser will have to execute the code every time it loads.
I think this is a good question that is worth exploring. I don't think there is a performance or standards-based argument for not using inline CSS - it works perfectly well - the only (though considerable) argument for separated CSS is for maintainability / readability. And so if you are generating CSS from JavaScript, generating it inline is just as sound as any other way.
In fact, DOM APIs in general expose much simpler methods for assigning styles directly to elements ( https://developer.mozilla.org/en/DOM/element.style ) than for creating new stylesheets. Therefore almost all JavaScript libraries, like jQuery, when they have to manipulate styles they do it by adding inline styles to an element.
Having said that, I have never before seen a situation where the mark-up and styling for a whole page was generated with JavaScript. I would expect this to be rather inefficient. I can see that if you have a web application where all content is pulled in through Ajax (a perfectly good solution) then you might write a fair bit of the mark-up with JavaScript, but still it would be better/more efficient to load most of the surrounding mark-up for your content in the initial page load, and then use JavaScript to swap out content within existing elements.
In any case, I would recommend that you keep most of your CSS in an external stylesheet with relevant classes already defined, so that all your JavaScript does is create elements with the correct class. This would have a performance advantage and would also mean that all your style information was located in one place, and is separate from your JavaScript, which would make your code easier to maintain.
It's OK to use inline css. (in this specifice case)