Related
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
I am trying to disable and hide a checkbox. So the total amount of HTML is small; I can't imagine performance could be an issue.
As far as writing server code goes, the coding work is about the same.
Given these two options, is one better practice than the other? Or does it not matter which I use at all?
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
No, these two options don’t have "exactly the same behavior".
If you hide an element with CSS (display:none), it will still be rendered for
user agents that don’t support CSS (e.g., text browsers), and
user agents that overwrite your CSS (e.g., user style sheets).
So if you don’t need it, don’t include it.
If, for whatever reason, you have to include the element, but it’s not relevant for your document/users (no matter in which presentation), then use the hidden attribute. By using this attribute, you give the information on the HTML level, hence CSS support is not needed/relevant.
You might want to use display:none in addition (this is what many CSS supporting user agents do anyway, but it’s useful for CSS-capable user agents that don’t support the hidden attribute).
You could also use the aria-hidden state in addition, which could be useful for user agents that support WAI-ARIA but not the hidden attribute.
I mean do you need that checkbox? If not then .hide() is just brushing things under the carpet. You are making your HTML cluttered as well as your CSS. However, if it needs to be there then sure, but if you can do without the checkbox then I would not have it in the HTML.
Keep it simple and readable.
The only positive thing I see in hiding it is in the case where you might want to add it back in later as a result of a button being clicked or something else activating it in the page. Otherwise it is just making your code needlessly longer.
For such a tiny scenario the result would be practically the same. But hiding the controls with CSS is IMO not something that you want to make a habit of.
It is always a good idea to make both the code and its output efficient to the point that is practical. So if it's easy for you to not include some controls in the output by adding a little condition everything can be managed tidily, try to do so. Of course this would not extend to the part of your code that receives input, because there you should always be ready to handle any arbitrary data (at least for a public app).
On the other hand, in some cases the code that produces the output is hard to modify; in particular, giving it the capability to determine what to do could involve doing damage in the form of following bad practices: perhaps add a global variable, or else modify/override several functions so that the condition can be transferred through. It's not unreasonable in that case to just add a little CSS in order to again, achieve the solution in a short and localized manner.
It's also interesting to note that in some cases the decision can turn out to be based on hard external factors. For example, a pretty basic mechanism of detecting spambots is to include a field that appears no different in HTML than the others but is made invisible with CSS. In this situation a spambot might fill in the invisible field and thus give itself away.
The confusion point here is this: Why would you ever use display: none instead of simply not render something?
To which the answer is: because you're doing it client side!
"display: none" is better practice when you're doing client side manipulations where the element might need to disappear or reappear without an additional trip to the server. In that case, it is still part of the logical structure of the page and easier to access and manipulate it than remove (and then store in memory in Javascript) and insert it.
However if you're using a server-side heavy framework and always have the liberty of not rendering it, yes, display:none is rather pointless.
Go with "display:none" if the client has to do the work, and manage its relation to the DOM
Go with not rendering it if every time the rendered/not rendered decision changes, the server is generating fresh (and fairly immutable) HTML each time.
I'm not a fan of adding markup to your HTML that cannot be seen and serves no purpose. You didn't provide a single benefit of doing that in your question and so the simple answer is: If you don't need a checkbox to be part of the page, then don't include it in your markup.
I suspect that a hidden checkbox will not add any noticeable time to the download or work by the server. So I agree it's not really a consideration. However, many pages do have extra content (comments, viewstate, etc.) and it can all add up. So anyone with the attitude that they will go ahead and add content that is not needed and never seen by the user, I would expect them to create pages that are noticeably slower overall.
Now, you haven't provided any information about why you might want to include markup that is not needed. Although you said nothing about client script, the one case where I might leave elements in a page that are hidden is when I'm writing client script to remove them. In this case, I may hide() it and leave in the markup. One reason for that is that I could easily show it again if needed.
That's my answer, but I think you'd get a much better answer if you described what considerations you had for including markup on the page that no one will see. Surely, it must offer some benefit that you haven't disclosed or you would have no reason to do it.
In order to track an almost entirely dynamic DOM layout I am considering using the HTML5 data attribute to track elements.
Would placing one on each DOM element begin to affect load performance, or negatively affect other searching mechanisms such as getElementById or $(#Selector)?
It will not affect any other searching mechanism. As far as load performance goes, if you were to measure it down to the microsecond, sure... The more markup gets rendered, the slower it will be. If you're talking about data- attributes, the difference is probably negligible.
So I've read this article and from what I understand, each native browser widget is actually a combination of basic elements, styling and scripts. This begs the question - if they are consisted of basic building blocks, does that mean that there is a way of customizing them through JavaScript? And I don't mean in the replacement sort of way, as some JavaScript libraries/plugins do - simply by accessing their "Shadow DOM" properties and adding some CSS styles to them, for example. Also, this page has some use cases, but nothing practical.
Anyone ever tried anything like this? Is it possible at all? Downsides?
Thanks.
My main concern would be that the implementations of the shadow DOM would be different between browsers and then you are basically back to needing some sort of library to deal with it. I'm not sure if that is the case, but its worth considering. Also, given that there are so many widget libraries available and that is the standard way of handling most of these issues, is it worth taking on a whole new set of unknown issues instead of just working with known elements?
Ok so in another question something was being discussed, and this link was mentioned:
https://developer.mozilla.org/en/Writing_Efficient_CSS
In that article, they say some things I didn't know, but before I ask about them, I should ask this... Does that apply to CSS interpreted by Firefox? Forgive my noobness, but I wasn't sure what they meant by Mozilla UI. (don't hurt me!)
If it does apply, when they say:
Avoid the descendant selector!
The descendant selector is the most
expensive selector in CSS. It is
dreadfully expensive, especially if a
rule using the selector is in the tag
or universal category. Frequently what
is really desired is the child
selector. The use of the descendant
selector is banned in UI CSS without
the explicit approval of your skin's
module owner.
* BAD - treehead treerow treecell { }
* BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { }
The descendant selector is just a space? And then what would the difference be between child and descendant? Child is an element inside another, but isn't that the same as descendant? As I'm writing I think I might have figured it out. A descendant could be a child/grandchild/great-grandchild/etc? And child is only one deep?
Sorry again for the stupid level of my question... just wondering, because I have been constantly using descendants in my CSS for my site. But yeah, if this isn't about Firefox then this whole question is pointless...
If its not about Firefox, does anyone have a link to an article explaining efficiency for Firefox or Browsers in general?
A descendant could be a child/grandchild/great-grandchild/etc? And child is only one deep?
Yes, exactly. Since a child can only be one deep, there's a much smaller space that the rendering engine has to recursively search to check if the rule matches or not.
And yes, that article is about both Firefox and browsers in general. Most (all?) of what is in it applies to any page rendering engine.
First of all - the suggestions in this article are not for html pages - they are specifically for the Mozilla UI - XUL, so it may be best practice for XUL, but not for html.
Applying the CSS on an average HTML page is one of the quickest things than happen while loading the page.
Also, the article may suggest the fastest way to apply css rules, but at what cost? For example, they suggest not having more than one class per rule:
BAD - .treecell.indented { }
GOOD - .treecell-indented { }
That is almost outrageous. It may lead to quicker CSS, but who cares? Assuming you already have .treecell and .indented, following these suggestions leads to complicated logic, harder maintenance, duplicated css rules, harder JavaScript (which costs a lot more that CSS), etc.
They suggest not using the full richness of CSS selectors and replacing these selectors with flat classes, which is a shame.
...as I'm writing I think I might have figured it out. A descendant could be a child/grandchild/great-grandchild/etc? And child is only one deep?
Indeed.
One thing I can add on the efficiency side of things is: Don't use * unless you really mean it. It's pretty intensive as rules go and most people could get away just specifying the elements they really want to target.
A "parent > child" is only one step down, whereas an "ancestor descendant" could be one or more steps down.
Even better is to use "#id" tags wherever possible such that there is less DOM searching.
The UI CSS is for styling the internals of the browser - the settings dialog, extensions interfaces etc.
Descendants and children are different, children are much more specific and result in much less having to be considered.
The problem with the child selector is that it's not as well supported. Of course, this might've been fixed on newer IE browsers.
In any case, when writing CSS for a webpage it isn't going to be that big of a deal. I doubt the fractions of seconds you'd save in page load would even be noticed. This article seems more directed towards people writing stuff for the actual browser, not websites.
O'Reillys "Even Faster Web Sites" has a whole chapter on this entitled "Simplifying CSS Selectors". It references your link on Mozilla.
I think two points are worth bearing in mind.
Yes, if you did this as far as possible, your HTML and CSS would be a mess of styles and possibly even more inefficient due to added file size. It is up to the developer to pick the best balance. Don't agonize over optimizing every line as you write it, get it working then see what can be beneficial.
As another commenter noted, it takes the browser milliseconds to figure it out how to apply your styles on page load. However, where this can have much bigger impact is with DHTML. Every time you change the DOM, the browser re-applies your whole style sheet to the page. In this scenario many inefficient selectors could make a visible impact to your page (perceived lagginess/ unresponsiveness).
The documentation for Google's Page Speed (a Firefox/Firebug add-on) includes a good page on efficient CSS.
Looking at the source code for Stack Overflow, I noticed they have used tables and inline CSS quite a bit, also something I found odd was use of inline table attribute formatting.
<table width="100%">
I'm just curious if there was any specific reason(s) to why they used tables to structure their template instead of the popular (or used to be popular) DIVs.
As well...the purpose of using CSS includes and using inline CSS on the same page (I know there is probably a great answer/solution(s) for this...I'm just curious to what they are)
I understand there is nothing wrong with using tables for tabular data...but in this case Stack Overflows tables are used for structure.
Tables vs. Divs is a pointless holy war.
There are specific issues with using tables in particular ways for layout that can cause problems. One of these is building an entire site layout in a single table in order to handle margins and placement -- because of the way tables are rendered this frequently means a website will not render progressively by the browser engine as the content downloads, and can only be rendered after the entire thing has been received. For a large page or slow modem user, they may be staring at a blank page for quite a while, which is a "Bad Thing". Never mind a lot of the inconsistencies in table rendering in the mozilla/ie5 generation of browsers that made consistent cross-browser table layouts somewhat painful, especially with images in the cells.
Supporters of the pure div path like to talk about content vs. presentation, because in theory HTML 4.01 is pure content, all of it meaningful. The divs provide meaningful organizational structure in an abstract sense, which is then given presentation exclusively by CSS. In these arguments, tables are valid only if being used to contain actual tabular data. Of course, this ignores the fact that for any sufficiently complex layout, there are almost always quite a few empty divs floating around simply to support the necessary hooks for presentation CSS, breaking the first level of this abstraction. Once this abstraction is broken, there's no law stating that, when your layout simply requires a presentation hook in the HTML that has no meaningful content, a div is somehow more appropriate than a table. If you are stuck with the choice of a meaningless div or a meaningless table in order to make your layout work, choose whichever is easier.
In the end, it's about being aware of the limitations in all methods and using the one that is most appropriate. There are many cases where using a table is simply easier than setting up a pointless (i.e. not-content-meaningful) array of divs, and the table rendering limitations don't apply. If the table is small and represents a minor chunk of the interior content, the rendering delay is not relevant.
Having not been involved in SO development, I only speak generally:
I've found that tables are often easier and more consistent across browsers than CSS-based layouts.
Also, emitting random CSS here and there often happens when trying to get things done. It can be refactored later, I suppose.
With respect to why they chose to set a table's width in HTML instead of CSS, I couldn't say.
I know that SO used a real, honest to goodness designer when they started. I don't know, though, if that designer gave them an image of what the site should look like or actual markup.
Please don't flame me for saying so. We're not all CSS ninjas.
SO was probably written by programmers, not web developers.
Tables are not evil, but certain uses of them (which used to be everywhere) are evil. Namely, using spacers, nested cells, etc, to control margin and padding.
Even though everyone now a days talk about layout with css and divs, the truth of the matter is css is awful when it comes to layout. You can only do so much. Look at some suggested solutions to get 2 or 3 column layouts using css, they all suck. Throwing a <table><tr><td id="left-column"><td id="right-column"></tr></table> is a lot easier.
css is just not suitable for non-trivial layout (and by that, I mean pure div/css)
The table solution I just threw above needs to use css to control width and padding and borders and background images, etc.
Give up and use tables
Because Internet Explorer does not support the display:table CSS property, which is what provides the grid-like layout model (equivalent to how html tables are rendered). The grid-model is the simplest and most flexible way to model many layouts.
So you have three choices, none of them attractive:
sacrifice support for Internet Explorer (all other modern browsers supports display:table property, which have been part of the CSS2 standard for more than a decade)
use cumbersome CSS workarounds which are costly and hard to maintain.
sacrifice semantic purity and use TABLE-elements.
SO chose the last option, probably because they think support for Internet Explorer users is more important than support for disabled users, and because they wanted something that was quick to develop and simple to maintain.
Jeff and his team were getting it done quick and dirty. This was a very quick development cycle, without the time to refactor out much of the clutter.
And face it - unless you are an expert, CSS is time consuming for table structures.
Inline styles and included css are just a sign they were trying to get it done, not worrying (at least for the first iteration) about the "right" way of doing it. The right way was whatever worked and got it done fast.
IE8 will be the last major browser to finally add support for the CSS display: table-* values, so the distinction will go away. Hopefully this will end the whining about how hard CSS is, and people can stop polluting markup with presentation.
I'm a reasonably smart person, not too far below average at least, but I find css layout totally unintuitive. Tables are extremely intuitive. I think one measure of a good technology is how often you have to refer to the manual while reading it. Tables blow CSS out of the water in this way compared to css. Again and again, when using css, I have to dig to figure out how to do something like this
Tables and layout
SO's layout is not based on tables.
At a quick glance, I'd say SO layout is 80% div-based and 20% table-based. Tables are used in the header and on the "badges" box. Table use is appropriate for badges IMHO (it's a list of items, after all), not so good for the header.
Anywhere else, divs are used.
Inline CSS
Again, many inline definitions are used (probably to quickly mockup site's structure), but SO correctly uses also css (to style the divs and to provide print formatting).
"css is too hard" and "tables are quicker and easier" excuses, coupled with some down right misgivings about what's wrong with the use of tables for structural markup.
The question is asking why SO chose to use tables, inline css, etc., to which I think the answer is probably nothing more than that either they aren't familiar with graceful degradation and semantics, or they didn't consider it important enough to devote the time and resources.
There's nothing wrong with not knowing css, but to dismiss semantic markup and the proper use of css just because you don't know it is just WRONG.
To champion that your site looks the same in every browser using tables, while not giving a seconds thought to those that don't use a visual browser smacks of selfishness - that's a strong word, and I apologize for the tone, as I don't intend to insult.
BTW - I take umbrage at the idea that the use of tables for structural markup is a 'holy war'. While some might think that Semantic markup is overly championed, it is not based upon blind faith.
CSS is great and can really simplify your markup, however, sometimes aligning content with tables is just easier and more reliable. Also for code generated dynamically some of the pain points for non-CSS based styling are less bad. Specifically, since you are dynamically, creating the markup you can re-factor the styling elements in the functional code.
As for the in-line styles, I often use these when I'm building a page and then try to re-factor them into an external sheet later. This makes it a little easier for my testing (no need to do a hard refresh) and changes are in one file instead of two.
My thougths would be they went with table because (apart from the argument table vs css)
They needed to get the functionality get out rolled quickly to have an opinion
After all this is just the public beta.
They were experimenting with ASP.NET MVC more and layout issues less
SO is all about programming questions and answers and at the end that what matters.
SO is all about recognizing the contributors by rewarding points and badges which it does quite decently (this may also be a controversial topic).
and so on....
I have no idea, but the only explanation I can come up with is that Jeff isn't as supportive of web standards as he'd like us to think and none of the team are that hot on CSS. Programmers often use cross-browser-ness, ease-of-use and numerous other supposed time benefits to excuse their lack of CSS skills. And I don't mean that as a criticism, they're probably really good at programming C#/Java/Ruby/SQL/whatever, they just can't seem to admit that they don't really know something as well us a bunch of polo-neck wearing, Mac Book wielding designers...