As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I apologise in advance if this question is asked too often, but I've been doing light web development lately and noticed this across many different (and somewhat prominent) webpages.
I see comments (of varying quality) being used in "more traditional" programming languages, but it's very, very uncommon for me to see them utilised in HTML or CSS. (I've seen it more in JavaScript, though.) I can usually figure out what's going on since HTML isn't very complicated, but why is this so?
Thanks!
Perhaps the commented version is kept locally, and minified/gzipped versions are the ones shown to the public. This makes loading times faster than those with the additional commentary.
I think because HTML (and CSS for the most part) is simple markup and rarely contains any complex logic in it (JavaScript maybe). So the markup itself is self-explanatory and requires no additional comments to explain/clarify what it is or what it does.
The pages you look at the internet are just the end products. Bandwidth costs money and noone wants to pay for sending noticies of the inner workings of their site to visitors most ofwhom never takes a look at the page source.
The backend which generates these pages (as most of the web pages are generated) can have comments of course. There are security concerns too, you don't want to give out unnecessary information about the inner workings of your site.
There are sepcialized tools too just to remove unnecessary content from pages (and css) to create smaller files.
I would speculate because HTML is a markup language, and all the content is quite transparent - so not necessary to comment compared with a procedural language where the logic can be complex, and a hint helps you to understand it.
I would also speculate it is because a large portion of the HTML is repetitive between pages and sites, so needs no explanation as it has been seen many times before.
You would not want to end up with this would you :)
<h1>My great site</h1>
<!-- heading level one - 'My great site' -->
Comments are best used to explain tricky bits of a file, and there's not a lot that's tricky about HTML or CSS.
WIth that said, if i'm doing something that works in some specific browser, i'll add a comment about why it's done the way it is. I'll often also use a comment to add notes about bug fixes (especially if there's a ticket for the bug and double-especially if there's a hundred other people working on the CSS as well). But often for HTML, it's almost no effort to turn the HTML comment into a comment in the server-side language, hiding it from the browser completely. So the code could be commented, without you ever knowing it.
I personally don't use them because during web development, comments tend to be personalized, especially ones you would put into HTML. Instead, I put them in PHP in HTML to make them invisible to the source reader.
As for CSS comments, the only time I have those is when I have over 5000 lines of CSS code and need to separate it into sections. Even then, I prefer to make several smaller files which are self-explanatory through file location and file name, rather than use extensive commenting.
I believe HTML and CSS to be simple and descriptive enough for anyone to derive their meaning very fast without help from comments.
CSS, especially, is incredibly self-describing. E.g.
margin: 0;
There’s not a lot to add to that. In CSS, I always try to add comments when the purpose of some code isn’t immediately obvious, e.g.
overflow: hidden; /* Contains descendant floats */
And in HTML, I try to make class names and id values self-describing, like good class, method and variable names in programming languages.
The most important reason for that is as you stated, there is no such a huge need for comments in HTML and CSS.
Secondly, commenting in HTML is very difficult compared to programming languages, putting a <!-- --> mark needs time, whereas // comes from inside.
Quite simply, HTML and CSS don't need as many comments. For the most part, the CSS and HTML you write does exactly what it says. While it is certainly possible to obfuscate HTML and CSS (especially CSS), it does not happen nearly as often as it does with programming languages. In programming, you need comments because the code is not always self-explanatory and you often do strange things for non-obvious reasons.
Commenting in HTML is only needed when you are doing strange things you neeed to explain. Otherwise, it is just as ridiculous as making comments for code that has an obvious behavior, like this:
var i = 3; //Declares a variable called i and assigns its value to 3.
Example of why you might need a comment in HTML:
<td> </td> <!--IE does not display borders on cells without content-->
I would assume that it is
because HTML is not a programming language and you usually do not have to explain why/how something works..
and also because people try to minimize the size of their pages..
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I understand the whole presentation vs relation argument that underlies the removal of as a tag from the HTML spec, however:
Some browsers still require/recognize this tag.
There are various issues with the (various) alternatives.
There are some arguable relational uses of the word 'center', as in that this element is to be considered central with respect to its neighbors, with no actual presentational meaning included (although a default CSS styling could be applied).
Would this line of reasoning be enough to bring back into the HTML standard as both a functional and practical way of doing things?
Apologies in advance if this question is provactive, one of my first SO questions.
To answer the core question here:
What would it take to get '' re-admitted to the HTML standard?
I think it would take a lot.
The thing is this: as it stands, <center> is very much a layout tag. Anything that changes the tag sufficiently to bring it back into contention would simultaneously alter its usage so much that it would be better for backward compatibility to have an entirely new tag instead.
Centering of elements and/or text can be done in CSS with well-established techniques, and with no compatibility issues, even in older browsers, so there's no need for a <center> tag either, any more than there is for <b> or <i> tags.
But I think the main point is that regardless of any merit or lack of merit in the <center> tag, the team responsible for developing the HTML spec have made the decision to deprecate it, and I can't imagine any line of thinking that would change their mind.
Your may be asking 'why not?', but I think their response would be 'why?'. And I don't think there's an answer you could give to that which would be sufficient to sway them.
"There are some arguable relational uses of the word 'center', as in that this element is to be considered central with respect to its neighbors"
This is very abstract semantics which doesn't really have any role in a document. I can't see it being useful. It's not even clear that 'center' is a good term for it - <focus> sounds more the point you are trying to make.
On the larger point. It would need a clear semantic meaning that is relevant to the actual structure of most content on the web. Hence the push for tags like <video>, <navigation> and <email>.
The key question you need to answer is "What is the problem that needs to be solved?" That is the starting point for all new or resurrected elements. If the problem is presentational, then its fix would be in CSS, not HTML. It is expected that you would provide data gathered from real world web pages to demonstrate the reality of the problem.
Once the problem has been identified, and it has been deemed that an appropriate solution is required and should be in HTML, and that there is no existing solution in HTML, you can contribute to the process to decide what the best solution to the problem is.
If you could gain agreement that adding the <center> element was the best solution to the problem, then it would likely be added to HTML.
Browsers handle many deprecated tags as a courtesy, not because the devs necessarily believe they should be in the spec
Such as?
This would fundamentally change the use of the tag, from formatting to presentation structure, no?
I think the center-tag is an element meant for styling and thus should be handled with CSS. It doesn't add semantics to the page.
See this SO-question
On a webpage, what exactly would a "" be?
Considering that the tags should describe what the content is. This tag only tells you where it is located on the page rather than anything about itself.
To bring back this tag, there would have to be a very compelling reason why to describe a pages content as center.
The reason that this tag is not valid in HTML5 is that they want to remove most of the styling tags and attributes so that styling will be only by CSS, also removed <font>, the align attribute, bgcolor attribute and some more design related things.
you can center elements in css with "margin: 0px auto".
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm updating a lot of code for a web app and tables are used everywhere to control layout.
I'm relatively new to HTML programming and am not sure what to make of the use of tables where CSS could seemingly be used. Is this just from a time now gone?
Bottomline, is the latest iteration of CSS and browser support acceptable enough to consider styling using tables antiquated?
In my opinion, the CSS is much easier to use.
It's a bit subjective, I know, but I think a consensus can be reached.
Use tables for tables. CSS for everything else.
The guy who first thought of using tables for layout wrote an article in 1997 stating, "The Web is Ruined and I Ruined It". There are countless similar articles, such as "Tables for Layout is Stupid" and the like. CSS has been around for that long and no developer worth his salt would not use it to layout his web pages. We're on the 3rd iteration of it and CSS itself is used to style tables by default in the browsers themselves.
At best, tables are a predefined, immovable grid of boxes you must fit your design into. Compare that to CSS which has limitless flexibility and reasoning for tables for layout flies out the window.
Do not use tables for layout. Use CSS. Nothing else to discuss.
This seems like a pretty subjective question, but basically the answer is that if the data lends itself to a table, put it in a table element. You can still style the tables with CSS, the HTML should describe the data whereas the CSS styles it.
If you have a table of data, don't make a "fake" table using divs/spans and make it look like a table. Put it in a table and style as appropriate.
If tables are being used for tricks like a 2-column layout, where there is no tabular data...yes that way of styling is obsolete and depreciated.
Keep in my though, I don't believe its a horrible "sin" to use tables for styling if it saves time, makes cross-browser compatibility easier, and looks fine. Remember, the only one (usually) reading your markup is the browser. If its going to take hours to rip out all the tables for the exact same end result, you might want to question if its worth the time/effort. On the other hand, when starting from scratch, you may as well learn the modern methods and create some maintainable markup.
Tables aren't going anywhere, it's in the HTML5 spec for a reason. You shouldn't use a table to style your website, but if you have some tabular data, then put it in a <table>. Just as you would put a paragraph into a <p>, a list of items into a <ul>, or a header into a <h1>.
People are so rash in their judgement of tables because they were used for evil for so long. I can use a bunch of <div> containers and a crap load of CSS to mimic an unordered-list, or just use semantic markup.
So, the lesson to be taken from this is, use tables for tabular data, and NEVER for styling. You should also never use things like valign="center" and cellpadding="0" on your table elements, this should be passed onto the responsibility of CSS to style.
P.S. look at Google's code, they're still using tables, and they're one of the main companies who are pushing HTML5.
It's easier (arguably), and has use for email clients. Legacy support is also better for IE 6 and below as well as other older browsers. Other than that, I have yet to see something tables can do that cannot be done with modern CSS. So the short answer is not any more.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Is it just because some people think they are harder to read? I find it much easier to explain a layout to somebody by drawing a grid than by using floating divs. And if they are learning to code floating divs then they have to deal with the setting widths and using CSS clear.
(by the way, I don't use tables myself)
They violate semantics of what a table is. Tables should be used for tabular data. They also are quite heavy on markup. In addition, they lock your site into one structure to a specific grid.
Tables are for storing tabular data. Content is not tabular data.
It's mostly a matter of separation of concerns - your HTML should be marking up your content, not decide on what the UI will look like and be layed-out, which is the concern of CSS.
Tables should be reserved for tabular data.
Its mainly a hype. Tables are an acceptable way and often more logically way of separating a view into multiple sections. However CSS is more dynamic, if you go with tables you're often stuck with them especially since tables are often placed in between 'the data' while css is defined externally. Also changing a 'table-like' layout made in css is easier than changing a table made layout.
On the internet there are a couple of good resources about this question:
http://www.decloak.com/dev/csstables/css_tables_01.aspx
http://iamelgringo.blogspot.com/2009/02/tables-vs-css-css-trolls-begone.html
As you can see it's also often a semantics thing. Semantically a table is not ment for layouts, (however it sure is handy and these kind of distinctions are more for purists).
This is taken from another site, but still just as relevant:
Tables are usually more bytes of markup. (Longer to download, and more
bytes of traffic for the host.)
Tables usually prevent incremental rendering. (Takes longer
for the user to see anything on the
page.)
Tables may require you to chop single, logical images into multiple
ones. (This makes redesigns total
hell, and also increases page load
time [more http requests and more
total bytes].)
Tables break text copying on some browsers. (That's annoying to the
user.)
Tables prevent certain layouts from working within them (like
height:100% for child elements of
). (They limit what you can
actually do in terms of layout.)
Once you know CSS, table-based layouts usually take more time to
implement. (A little effort up-front
learning CSS pays off heavily in the
end.)
Tables are semantically incorrect markup for layout. (They
describe the presentation, not the
content.)
Tables make life hell for those using screen readers. (Not only do you
get the other benefits of CSS, you're
also helping out the
blind/partially-sighted. This is a
Good Thing.)
Tables lock you into the current design and make redesigns MUCH harder
than semantic HTML+CSS. (Have you seen
CSS Zen Garden?)
SAUCE: http://phrogz.net/css/WhyTablesAreBadForLayout.html
Not every browser displays them the same way... should only be for tabular data, not content
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am implementing a comment control that allows a person to select comments and have them sent to specified departments. The email needs to be formatted in a specific way, and I was wondering what the best way to do this would be.
Should I just hard code all of the style information into one massive method, or should I try and create a separate file and read it in, and then replace certain tags with the relevant information?
Find and use some kind of template library, if possible. This will make each email a template which will then be much easier to maintain than the hardcoded form.
Campaign monitor has some great, well-tested free templates:
http://www.campaignmonitor.com/templates/
Make sure whatever you use will display well in all clients.
A great guide:
http://www.campaignmonitor.com/blog/archives/2008/05/2008_email_design_guidelines.html
In addition to using some sort of template, as tedious as it is, inline styles are the most cross-client compatible way of styling HTML emails. Not every email client will fetch an external stylesheet and many don't do so well with an embedded style section.
That being the case, I would choose a fairly simple set of style rules for the email in order to ensure that it looks the same in different email clients and try not to rely too heavily on images as many client will require that extra click to show content.
I would use a template approach. It wouldn't he hard to create a simple regex template system, replacing something like #somevar# with the value for 'somevar'. You could also use a premade template system, like Smarty for PHP. I think that would be the cleanest approach.
Alex
I've used XLST templates in the past to format emails. Generally emails are best constructed using tables and inline CSS. Note that outlook 2007 does not support background images :(
Definitely use templates. I have done it with text templates using custom tags like so:
<p>Dear |FIRST_NAME|,
But I really cannot recommend this; it is a world of pain. The second time I did it (an html email appender for log4net) I used an xslt to transform the object (in this case a log4net message) into an html email. Much neater.
Note that certain clients (e.g. Lotus Notes) do not support XHTML, so use plain old HTML 1.0, with no css, and you should be ok.
This question already has answers here:
Basic Coding Standard for HTML and CSS [closed]
(3 answers)
Closed 3 years ago.
The HTML standard defines a clear separation of concerns between CSS (presentation) and HTML (semantics or structure).
Does anyone use a coding standards document for CSS and XHTML that has clauses which help to maintain this separation? What would be good clauses to include in such a coding standards document?
We don't have a physical document we all adhere to where I work. There are a number of guidelines we try and keep in mind but there isn't really enough information to require a physcial document. This article sums them up these guidelines pretty well. You may also consider formatting your CSS to make it easier to read. Smashing Magazine has a great article on this subject.
The article referred to by #Lee Theobald is a good start.
Some basic ideas I try to keep in mind when marking up:
Regarding html:
Try to write for the next person - that is, think about how easy or difficult it might be for someone else to come and pick up your work and carry on.
To support this principle, you should try and make sure your markup is as legible as possible - class and id tags in particular should relate as much as possible to their intended content. In other words, try to use your tags to describe the kind of content they will have.
For example, "Sub-navigation", "content" etc.
The aim is to provide markup that someone can pickup having not looked at before and get a sense of the logical structure of the document.
Also, try to avoid the addition of markup that is purely to achieve a visual effect. But bear in mind that any website that requires even slightly sophisticated styling is unlikely to be able avoid non-semantic markup, due to weaknesses in current implementations of CSS and browser-compatibility issues.
Regarding CSS files:
Many people divide their css up into sections using comments, separating them into functional or structural areas. So you might have a section for your header, your footer, or typography and so on. Others take this further and split css across files, having one for typography, one for layout etc. However, this can according to Yslow! can have a negative impact on page loading, due to increased http requests.
I could write more, but as you can see I struggle to be concise. I hope this is of some use to you.