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.
Applying styles to <form> tag is:
a) a good practice, it decreases the count of elements on a page and makes code clear
b) a bad practice because of semantics, use other elements instead, div is for style, form is for forms
c) don't ask silly questions and focus on real job!
d) none of the above
Style the form if that makes life easier for you. It is not against semantics if you do it.
a - Decreasing the amount of elements is not necessarily a good practice. If creating more elements will make your layout more readable/understandable then go ahead.
b - Divs are not for styling, they are there to divide sections in the document
c - You should worry about semantics. This is not a silly question.
a) Yes.
b) No. Div is a generic element. It is not for "style" it is for "when nothing else describes the semantics".
A and C. Simple way checking for good answer is: Write a code and validate it with validator.
Since semantics are seperate from style, applying style to a form has no semantic consequences. Go right ahead and style a form if you like, it makes no difference to the semantic meaning of the page.
In my personal experience, (a) is especially true because:
You will be reducing the overall filesize of your page, with no real disadvantage (especially if you have multiple forms and run into this a lot).
You will be reducing the amount of confusion when you have to go back to edit this style in the future (where someone may have the same question as you).
You will be reducing the ambiguity as to where certain styles come from (e.g. this form has too large of a top margin. Is that coming from the margin on the <div> or the margin on the <form>?)
You will be reducing the possibility of introducing bugs or cross-browser quirks, stemming from browsers not implementing the same default styles on all elements (in this case, the <form> element).
While I suppose one could argue that (b) is a "problem" in theory (and should therefore be avoided), it will never be a "problem" in practice. But as you can see above, wrapping it in a <div> can certainly be a problem in practice.
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 10 years ago.
For quite some time, I have been using "deprecated" HTML tags such as b, i, u in my HTML for projects where optimization is important. I would often find code like:
<div class="WrapperName">
<div class="ItemElementName">
</div>
</div>
A while back (some odd years) I noticed that Google used tags like the ones I mentioned in the search listings, obviously to optimize the output. So my example above could look like this:
<b>
<u>
</u>
</b>
I liked this and have been using it regularly ever since. I mainly use the tags in parts of the code that don't define the lay-out, but things like parts of a repeated container, because that's where the biggest win is to be made. Using CSS I unset the default properties of the elements to make them "clean" elements.
Even though in modern browsers you can use any tag name you like and it will work, I chose these ones because they work in older (IE) browsers so that I don't need to register them with the browser.
Is there any real objection against this way of working? The tags as they were are already deprecated (so don't add any specific value - like what I want) and they are short and work in all browsers..
Elements such as <b>, <i> an <u> are not deprecated, their meanings have just changed, so carry on using them.
(I have linked each one above to it's entry in the W3C HTML5 specification)
It is irrelevant to the basic question whether some element is deprecated or not. You are effectively asking about the use of HTML tags as independent of their defined meaning, and even against their defined meaning, simply because the tags are short and you expect to override their default styling and impose your own. There are several arguments against such usage. They are not decisive against all kinds of use, but they make the use highly questionable on web pages:
Some elements have defined or actual functionality that you might be unable to override. For example, an <input> element takes user input and participates in tabbing order. This might not apply to the single-letter tags you have in your mind, but it’s worth noting as a general point about “free” use of tags.
Elements may have default rendering that you cannot (completely) override in (all) browsers. Especially older browsers may use rendering routines (e.g. for form fields) that are immune to CSS. This, too, might not apply to single-lette tags.
CSS is ultimately just presentational suggestions that may be ignored or overridden by a multitude of reasons and in a multitude of ways; see CSS Caveats.
Search engines will handle tags their ways. For example, they may take b element contents as carrying more relative weight than other texts on the same page.
Maintenance of a page using tags that way gets complicated, especially if people not familiar with the idea will need to take it over.
It might be better to use undefined tags like <c>, <d>, <e> etc., even though you would have to “register” them with IE (it’s just one document.createElement() per tag name). But many of the counterarguments would still apply (and some browser might some day define <c> with some surprising meaning).
b, i, and u are deprecated, and you should not make up your own tag names either since the specification does not allow that. Use the strong tag for things you want to emphasize and use span for the rest. span has the specific purpose of allowing you use it for applying whatever CSS you like to some text.
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'm on mobile now, and I cannot find the post I recently read which advises not to use a div for the functionality of a button. Perhaps the philosophy is well enough agreed upon that it doesn't matter.
It seems divs are a bit easier to style than <button> type (which was recommended in the answer i unfortunately cannot refer to). Even if that's not true, what is the disadvantage to using a div as a button?
Thanks!
<div> has little or no semantic meaning. It's just a generic container.
<a>, <button>, or <input type=button> all make it much more clear what the thing actually is, what it's supposed to do, etc.
This has several advantages:
Accessibility: Chances of a screen reader or whatever knowing what to do with an <a> is much greater than it managing to figure out that your <div> is actually a way to communicate back to the web server or whatever.
User interface advantages: If a user is used to tabbing through clickable elements or whatever, their browser is far more likely to do the right thing if you use an element that clearly indicates that it's there for the user to click/press/whatever. If you use <div>, then the browser might not highlight it or do whatever it normally does to tell the person that they can click it.
You get the clickability for free, rather than having to attach an onclick or whatever. With a <div>, there's probably no way to make it work without JavaScript. With the other elements, there's at least a hope (especially with <a>).
I'm probably leaving out a ton of other things that I just never thought about and maybe the above aren't the best examples, but I suspect you get the idea.
<div> does not support the tabindex attribute. So keyboard users are at a disadvantage.
Additionally, webpage optimizers (eg. Google on mobile) would be less likely to strip out an <input>.
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 10 years ago.
I have a beginner's question for web development. I am going to create a table in which I am having input fields which I will submit to the server.
What is the common practice for doing this? Should I use html-tables or should I build the tables using stylesheets for positioning and sizing cells, columns, etc.? If both are common practice, what are the pros and cons of using eithor of those?
If the content is tabular in nature, logically structured in rows and columns, then the appropriate tags - the tags that describe the structure of the content - are table tags.
You will have folks on both side and some will be nicer than others. Essentially, you use tables for tabular data and not to make a layout for your buttons, logos, etc..
On the other hand, I have some old asp Classic code where we used tables everywhere and it still works great.
If I did it today, I'd use "semantically correct" design where I could which means tables for table data (things displayed in row and column) and the css stuff for layouts.
I usually use divs for this purpose. The strict definition would be to use tables only to display semantic content.
You need to plan carefully first what you need in terms of layout, whether sections are going to be similar, whether there is a lot of sharing or not. And the amount of formatted container your foresee.
It naturally occurs to you that if you can centralise the design on some CSS commands, you will benefit from being able to change looks at once as they are all linked to a common source.
If you are going to have several pages, you will be thinking of having the CSS even on a different page and link to it from others.
Also, you need to know that divs and spans work in a different way than other HTML elements. You will not be able to obtain effects that you would have obtained with a table.
In other words, what you need to do is go to the w3 website and read everything about CSS. Expecting to get an answer in 3 lines about such a huge subject will not help you much.
Alvaro
My motto for html/css is:
"Use the right tag for the job". If its a table let it be a table :)