Basically, given that all possible contents of an element are known in advance, you can use a bunch of :after content styles instead of altering the innerHTML of the element. Just change the class to get new content.
My profiling in Chrome indicates that this does improve performance a bit, but I'm not entirely sure, as the cost might then be hidden somewhere else? And I'm not sure if it's a bad idea for other browsers besides Chrome. Any thoughts on this?
Please note that the context here is for 60 frames per second simulations/visualisations, so in this context 2 vs 4 milliseconds is a big and significant difference, which it might not be in the context of a page load.
Example styles for numbering can be seen here: https://github.com/magwo/elevatorsaga/blob/2fa5dc0c0397d0565ce5dcc45c68b19d924a4955/style.css#L290
pseudo-elements are design elements they are not content, they don't appear in the source code, they don't exist in the DOM, they wont be crawled by search engines, you cannot select or copy them, and of course, they don't exist without CSS, which is a style-sheet.
It may be faster, but that is probably because it is not content. And maybe it is easier for the browser to change a class than change the content of an element.
The question is, do you want to change the content, or the visual representation of it?
As for the implementation, I believe that having every possible content loaded in to a CSS is not an optimization, the same thing applies if you are planning to request a new CSS file for every new content change.
Finally, at least for now, you can't style individual parts of the content of a pseudo-element, you can't add paragraphs,spans and other markup.
Related
I have a web app that displays and passes around user-editable semantic markup. For a variety of reasons, including security, the markup consists entirely of custom elements (plus the i, b, and u tags). For regular rendering, I simply have styles for all the tags and stick them straight in the DOM. This looks and works great.
Now I'm doing screen-reader testing, and things aren't great. I have a bunch of graphical symbols I want to add labels for. I've got divs that I want to make into landmarks. I've got custom input fields and buttons.
It would be easy enough to just add role= to all the different tag instances. But part of the reason for the custom markup is to eliminate all the redundant information from the strings that get passed around (note: they're also compressed). My <ns-math> tag should always have role="math", and adding 11 bytes to what might be tags around a single character is an actual problem when multiplied out over a whole article. I know this because the app started with a bunch of <span class="... type elements instead of custom.
For the fields and buttons, I've used a shadow DOM approach. This was necessary anyway to get focus/keyboard semantics correct without polluting the semantic markup with a bunch of redundant attributes, so it's easy to also slap the ARIA stuff on the shadow elements. Especially since the inputs are all leaf nodes. But most of my custom tags amount to fancy spans, and are mostly not leaf nodes, so I don't really want to shadow them all when they're working so well in the light DOM.
After a bunch of searching, it seems like the internals.role property from "4.13.7.4 Accessibility semantics" of the HTML standard is maybe what I want. I may well be using it incorrectly (I'm a novice at front-end), but I can't seem to get this to work in recent versions of Firefox or Chrome. I don't get an error, but it seems to have no effect on the accessibility tree. My elements are not form-associated, but my reading is that the ARIAMixin should be functional anyway. This is maybe a working draft? If this is supposed to work in current browsers, does anybody have a code snippet or example?
Is there some other straight-forward way to achieve my goal of accessibility-annotating my custom elements without adding a bunch of explicit attributes to the element instances?
So you want the benefit of adding a role or an aria-attribute without actually adding those attributes? The concept of an "accessibility object model" (AOM) has been bantering around a bit that would let you access and modify the accessibility tree directly but it's still in the works. Here's an article from a couple years ago that talks about it. Nothing official. Just one person's thoughts.
Further research shows that, as of this time, the abstracted accessibility options I'm asking for are not yet implemented.
For the time being: eliminating a number of page-owned enclosing divs from the accessibility hierarchy via role="presentation" significantly improved my overall tree. With those out of the way, the majority of my custom tags seem to be simply semantically ignored. This is mostly fine as the majority of my content is plain text.
Since I already mark up the vast majority of even single-character symbols, I've simply added all my symbols to the markup generator. Since everything is already in custom tags, I then use a shadow DOM span with role="img" and a character-specific aria-label to present the symbolic character.
My solution is still incomplete. I wish that I could convey the full richness of the semantic content I have available.
I have noticed that in javascript frameworks elements such as dialogs, tooltips and alerts mostly appear at end of body.
I'm making my own implementation of these elements and trying to make it failproof. I'm repeating some techniques like using transparent iframe to overlay embeded objects in old browsers, and so on.
What restrictions could I face if I place my dialog/tooltip somewhere deep inside of the DOM tree with {position: fixed}? I'm afraid if there are some dangers to this approach, because big frameworks never use it.
I want to support IE8+.
Aside from z-ordering that is a very valid point made by Teemu, another major consideration in JS frameworks is speed of execution / speed of lookup.
The DOM in JS terms is one large object. The deeper into an object javascript needs to go to get what it's being asked for, the less performant the script gets, take a look at this answer.
Therefore it makes sense to keep everything that is probably going to be cloned or deep copied at a sensible nesting level and in the correct z-order. That happens to be toward the end of the body and usually wrapped by at most one containing element.
There may be other reasons but the depth / nesting sprung to mind as a consideration I'd take into account.
Short answer - very few techniques like this are "always necessary". JavaScript can easily remove items from their natural position in the DOM and relocate them at will.
Long answer - I don't think approaching this from a JavaScript first angle is correct. Look at it in terms of where the content belongs naturally within the hierarchy of the rest of the DOM.
For example, if you are talking about a modal dialog, then the chrome (the container elements) usually do not belong within the rest of the DOM - they exist only to contain and provide modal overlay functionality for the content within. This chrome does not participate in the outline of the DOM and the rest of the content. In that case, unless you are able to load them separately via ajax or embed the chrome HTML within the JavaScript, then the closest you will come to removing them from the main DOM is to append them to the bottom of the main DOM content. Note that this disregards the upcoming TEMPLATE element (http://www.html5rocks.com/en/tutorials/webcomponents/template/) which is designed for just this purpose.
However, the content of your dialog might very well belong within the main content of the DOM - either as an element, or as an attribute (i.e. title or data-) to an associated element. This would especially be true for tooltip text.
Preamble: Possible duplicate to my question can be found found here, although for me, this question was not sufficiently answered. A work-around is given, but a definitive answer to the question of whether or not it is possible, is not provided.
The question:
On my website, when a user clicks a button (or area of screen), I want that area to "flash" a couple of times before returning to its original state. (I think this gives the user a reassuring feel of something having been activated, as in some circumstances, they may have short delay before the feedback is given.)
Anyway, I've managed to get this working using a bit of JavaScript and jQuery, and you can see the results here >>.
As you may notice, the problem is that after the flashing is done, the element doesn't return to its original state. Rather, it keeps its last "flash" state, and overrides the underlying CSS styling which originally styles the object when the page loads.
I style the element with the following jQuery:
$jq_obj.css('background-color',flash_fg_color_).css('color',flash_bg_color_);
And I 'attempt' to un-style it with:
$jq_obj.removeAttr('background-color').removeAttr('color');
I've also tried:;
$jq_obj.css('background-color','').css('color','');
Despite the documentation saying that this should remove styling, it doesn't.
Is there a solution, or do I have to revert to the work-around solution referred to in my preamble? The nice thing about the JavaScript option is that it becomes a lot more versatile when you want to play around with the animations a bit.
Thanks,
===EDIT 2014-06-28===
As a demonstration of why the class solution is untidy, please see this fiddle: http://jsfiddle.net/Y9L4x/ (inspired by #BiffMaGriff 's proposed solutin here: http://jsfiddle.net/rte3G/)
The problem is that the elements being flashed could already be CSS-ed up to the hilt with multiple classes.
I recognise that I can remove styling classes first, before applying the "flash" classes, complicate the JavaScript and/or the CSS rules, etc. etc.
But the whole point of looking for a non-class-solution is that this option becomes extremely verbose in a real world situation, and you tend to have to program each flashing object individually, rather than the tidy one-JavaScript-function-fits-all that I'm searching for.
You are going to want to do your styles as classes.
.activated{
background-color: red; //or whatever else
}
and then with your jquery you can just toggle them a few times with the delays I assume you already have in your javascript.
$jq_obj.toggleClass('activated');
Try this:
$jq_obj.attr('style','');
The direct answer to the question appears to be a simple "No".
You cannot tell JavaScript to style an object, and then at a later stage, ask JavaScript to give styling responsibility back to CSS.
However, another messy work-around is to re-draw the HTML inside the element which contains your flashing-object.
$jq_flashing_obj.parent().html(original_html_);
This has the slight overhead of having to wrap your flashing object inside a div or span element, to ensure that the parent element contains nothing but your flashing element.
<div class="multiple-children">
link 1
<span class="wrapper">Click me to watch me flash</span>
link 3
</div>
You then, of course, have to capture the outerHTML of your flashing-object before the flashing starts.
original_html_ = $jq_obj[0].outerHTML;
The resulting JavaScript is a little bit verbose, as you see here: http://jsfiddle.net/CgsLs/ . However, it does have the following benefits:
Reusable on all clickable elements regardles of CSS :hover and other messy styling
Can optionally define the flash-color of the element inside the JS
Independent of CSS, meaning that the code is in one file, and therefore more maintainable
There are down-sides too
Requires the use of JQuery on() function (as opposed to simple click event handler)
Anyhoo... it may not be a solution for everyone. In some cases (maybe even most cases) the class option might be simpler.
But this is one other possible method of tackling this inherent shortcoming in JavaScript/Browser technology.
I have created a Javascript based element that can be embedded into websites. The Javascript itself adds the HTML code into a pre-defined HTML container and dynamically loads the necessary CSS file that contain the element's visual definitions.
The problem starts when the site itself has its own definitions for general items. For example: The site's CSS defines a certain list style which is applied on the element's list because the element's CSS doesn't define an explicit list style or if the site's CSS overrides the element's CSS definition.
For the time being, I was able to solve this specific issue by explicitly defining the list's style and adding the !important definition. However, I would definitely want to go for a more robust solution that will assure that:
1. CSS definitions from the site's CSS that are not explicitly defined in the element's CSS will not be applied on the element
2. I will not need to explicitly add the !important definition to every one of my CSS definitions
Is there a general way in which I can specify that a site's CSS will not be applied on a certain element or that only a certain CSS will be applied to a specific element?
Any help will be greatly appreciated.
You need to use a localised reset.
Grab an existing CSS reset, such as Eric Meyer's Reset Reloaded and namespace all the selectors with your parent element, e.g. #something a { ... }.
I was going to put up the same answer as Alex, but he beat me - but I was also going to add:
If you're not going to use #alex's suggestion then ultimately you have to explicitly style all of your elements the way that you want them to appear; using selectors that keep your styles local too (and don't interfere with the parent site) - in the same way that the localised reset is suggested.
Update
Or you could do what Google Translate and many other widget-type things do, usually a no-no but in dynamic scenarios I think perfectly acceptable; since the visual style of your elements is not just important to you but to the container site: use inline styles.
Final update
So I thought I'd just double check what Google Translate does. And of course it's an iFrame inject in addition to using inline styles. They no doubt use inline styles to maximise compatibility and so that the browser doesn't have to make another request to get the stylesheet; and they would be using an iFrame so they can ensure a consistent look and feel.
Consider both of those points in tandem - and weigh that up against the amount of work that might be required in resettting all the styles for a minority portion of the page; or defining rules for every CSS property you need to control - which, let's face it, is basically all visual CSS properties.
The iFrame solution actually seems to offer the best solution - if you can use it; hence I've +1'd the first comment by #roberkules on your question.
Recently we redesigned one of our pages and suddenly page has been increased from 1MB to 1.98MB.
I compared the no of DOM elements and its increased from 1600 to 2300. I found the no of elements from the below command
document.getElementsByTagName('*').length
We did a load test and found the load time also increased from 1.1 to 2 seconds. Is this the reason for all problems.
I think the above line won't consider any inline css and js right , as they are not DOM elements.
Can you please suggest
Without knowing exactly what you redesigned, it's impossible to know what change caused the increase. But even a 1MB page is pretty large. JavaScript (and particularly jQuery) can change the number of DOM objects... consider this:
$('p').append('<span>Blah</span> <span>blah</span> <span>blah</span>');
That will add 3 DOM objects for each p tag on the page (which could be a lot!) and yet it adds only 71 bytes to your page. jQuery can similarly remove DOM objects. So I don't think the number of DOM objects is really much of a consideration.
The javascript that runs can manipulate the dom and create new nodes which would affect your count. However it shouldn't make the page load any slower as it's rendered on the client side.
I think you need to include more information if you expect to get a better answer.
Also you should look into browser plugins (for firefox) like Yslow, or firebug (net tab) that show you all the files being loaded and how long they load.
Anytime that you have more information crossing the wire, it will take longer. Therefore, with more DOM elements in the page, the loading time will be slower. I hope this answers your question because I'm not really sure of what you are actually asking.