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".
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 can't seem to wrap my head around why headings (h1-6) are a concept of their own in HTML/CSS separate from any regular style. It appears to me there is no good reason as it just confuses the user by adding to the available tag universe whereas all that it does can be accomplished by being just another regular style defined as, for example:
.headStyle1
{
font-size: 30px;
font-weight:bold;
}
and then, instead of using a separate tag <h1></h1>, you just do something like:
<span class="headStyle1">My Heading</span>
And you live happier because you have one tag less to have to be dealing with in your working memory, heading are just another style rather than its own category. To me, simplicity is a virtue.
Please explain if I am wrong and if there is a reasonable justification for this addition in complexity.
It's a semantic tag, designed to designate the importance of a particular heading with regard, and contrast to, the other headings on the page; for example an h1 is the most important heading, whereas h2 is slightly less-important.
It describes, and is not designed to describe, any presentational aspect of the content, merely the importance/significance relative to the other headings, which denotes similar importance the content that follows that heading (sort of).
References:
Heading elements, at the Mozilla Developer Netork.
Heading elements, from the W3C.
You need to think about the reason that html semantic markup was created in the first place. Take a look at the W3C spec...
A heading element briefly describes the topic of the section it
introduces. Heading information may be used by user agents, for
example, to construct a table of contents for a document
automatically.
There are six levels of headings in HTML with H1 as the most important
and H6 as the least. Visual browsers usually render more important
headings in larger fonts than less important ones.
http://www.w3.org/TR/html401/struct/global.html#edef-H6
HTML is not just a framework for stylesheets, it is a way to "mark up" information. The span tag has very little meaning to screen readers or to search engines, however, the h1 tag means quite a bit.
Why stop at heading tags? We could just put everything in a span tag, get rid of p, em, cite and nearly every other tag and use styles to indicate importance. Then everyone who looked at the site would know what was important and what was less important. The problem would start when someone using a screen reader was accessing the site, or a search engine. By using semantic markup, you make the internet 'better'. You allow search engines now and in the future understand what is on the website you are creating.
Best to use the markup that exists. It is a way to define the type of content that is on the page. It really is simple once you embrace the 'complexity'.
The heading tags provide semantic meaning to a document, providing structure to a document without styling.
For example, they help make website accessible to those using screen readers. A screen reader wouldn't understand the importance of headStyle1 compared with h1.
I suggest to use them, because they mean a lot for searching bots like Google, etc. Here's an example: You write an article and name it Current situation in our company. Now, if I were to find your article by any chance and forget to save an URL, I might not ever be able to Google it, because Google would rate it as some part of text on your website instead of important heading.
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 thinking of learning (X)HTML.
I have read on the web about w3schools and discussions on the subject and intend to stay away from it (or at most use it as a reference).
I think it is best when learning programming languages to go to the original source (php.net, python.org, mysql.com, ...).
I tried to read the (X)HTML 4/5 spec but gave up soon after starting. The next best thing as far as I can tell is the DTD.
What are your opinions in this kind if learning and can you recommend alternatives?
Also is there a DTD or something like a DTD for HTML 5 yet?
HTML is more than the DTD. Learning HTML from DTD is like learning C from include files — you just don't do it.
The DTD just specifies a few simple grammar rules. You can use it to roughly validate your code but it's limited. And it definitely knows nothing about semantics.
It's a guess-work. It's like, you have:
<html>
<body>
and now the DTD only says you can choose one of: <h1>, <h2>, …, <ul>, <ol>, …, <p>, …
Well, sometimes it gives a brief description of what particular elements or attributes mean (in comments). But that's all. It doesn't explain what is the purpose of given element, what are the alternatives and which one should fit the particular task better.
Also, remember that HTML is rarely used alone these days. You at least have to know CSS as well (unless you're going to write some ugly soup — then please don't even start), and CSS is not fit for DTD.
The specs are the most important documents for you but they are not fit for learning either. The spec is the thing you start to use after you catch all the basics already, and where you check your understanding of them. But the HTML and CSS specs alone are not enough either. There's WCAG at least. And a fair bit of common sense.
I think the one tutorial you could start with is the one from Mozilla. It's not perfect either and you will need to read much more before you start writing good HTML.
There's plenty of resources out there. Many great books and websites. Don't learn from the spec, it's very dry. You can't learn from the DTD - it's just a bunch of code outlining what elements can contain what, and so on. Here's a few things to check out:
http://jessey.net/simon/xhtml_tutorial/
http://diveintohtml5.info
http://www.kirupa.com/html5/introduction_html.htm
https://developer.mozilla.org/en-US/docs/HTML/Introduction
And yes, I do(!) think that you can learn from w3schools. It's another good resource.
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.
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..