If yes then presentational elements would be helpful in this condition so should we use those?
<b>…</b> , <i>…</i>, <big>…</big>, <small>…</small>, <tt>…</tt>, <hr />
These are valid tags
The page should be marked up semantically, not for its presentation. If you put proper semantic markup on elements, the browser will usually apply a basic style to them by itself. You should not be concerned with how the document looks unstyled. If it's unstyled, it has no style. CSS is responsible for the style. If a user chooses to view the document without style, let it be so.
Generally a ("normal") user cannot disable CSS as easy as JavaScript.
So I would answer NO.
CSS is a part of the presentation and when the CSS is not available we should think that the presentation is not available. Thus the client side is broken.
You should not be concerned about that as you don't want to debug a client abusing the presentation.
BUT, if you need to support non-standard devices (old mobiles maybe) this is a valid concern. Still instead of changing the page to "fit all sizes", you should have a separate page for such devices.
Not sure about tt (I guess you can use).
But b, i should be replaced by strong and em respectively.
big and small should not be used IMO and be replaced by alternative tags depending on the semantics.
Technically, you could pretty much create an entire page using <div> and <span> tags. That would just be messy though, and not very intuitive. Personally, I find that the tags you list make it easier for a human to parse what the page is attempting to communicate, while also offering the benefit of making a page readable when the CSS doesn't load.
It sounds like you're asking if you should use tags like <small> so that, in the absence of CSS, what you want to be small will be small.
No.
The reason to consider how the page will look without CSS is to know if you are using good semantic layout. If it's usable, your HTML, which is only designed with semantic organization in mind, is okay. That's it. If your users, for whatever reason, don't want to support presentational things like CSS, don't use presentational tags.
And, really. If your users don't have CSS for whatever reason, they don't deserve to see something as bold. It's more work for you, it's not semantic, and no one will ever care.
Related
I'm fairly new to HTML. With the rise of HTML5's popularity as a standard (at least, from what I've learned and experience the past couple of semesters), I am wondering if it is still considered good practice to use [DIV] instead of new container elements, such as [main], [nav], etc.
I feel far more comfortable using div's as opposed to the new container tags because of their default values and how much like putty they are when it comes to box modeling a page the way I want it.
My main question is this: If a potential employer or well-seasoned programmer were to look at my HTML5 code and saw div's instead of new container tags, would it be considered bad practice/sloppy coding? Or is using div's still entirely acceptable? Apologies if this is a silly question, but I ask because after this semester is over I'm going to start applying for jobs and want to make sure that my practices/standards are conducive to those that will offer me the highest chance of landing a good employment opportunity!
DIV tags do not convey meaning like you get with the html5 specific section tags. The functionality is the same as far as the block element. Using the new HTML5 tags help self document your code and not need comments to explain what each DIV does.
I would recommend to get into using the new tags in HTML5 instead of just divs. You should always want to write as semantically as possible. This helps you grow as a coder and move the web forward.
Default behavior is a poor reason to not use semantic markup. For one thing, almost every site should use a CSS reset mechanism. Bootstrap, et al, do this for you, and they generally apply border-box sizing for convenience.
Aside from polyfills for older browsers, fallback markup is an option. Wrap a classed div with an HTML5 element and apply CSS to both.
Semantic markup allows other types of content consumption beyond the standard web page, such as syndication feeds and print document generation. HTML5 elements provide much contextual information in those cases, as well as for visually-impaired users who employ screen readers and other assistive technology.
All that said, I doubt many employers will deduct for element choice. Overall page structure, markup cleanliness, appropriate internal documentation, etc. are probably more important.
DIV's are always acceptable, but for a better codding semantic and for the searching engines it's a better practice to use the HTML5 tags. Sooner or later you'll use them so better start practicing.
HTML5 tags are a better way to organize code and help searching engines for best results. It's also help for the CSS because surely you'll save classes and will target the tags.
HTML5 is the way...
I'm building my first website for an internship. My instructors always told me to never embed any styles on my html page.Now that I'm actually creating a site I find it annoying that, if I want to change the color of my font for a span tag - I have to I.D. it and reference it in a css file. Is there some other reason then organizational purposes for using CSS? Would embedding a single style be such a convention breaker? Thanks for reading this and I'd appreciate any feedback.
There are a couple of reasons.
Times when you want to change the style of a single element on a single page should be exceedingly rare, so it shouldn't be such a hardship. Any other time, it is going to be more efficient (from an HTTP caching perspective) and easier to maintain (from a separation of style and structure perspective) to externalize the style information.
Since there is a good chance that you'll want to style it differently for different media (e.g. screen and print), you'll need a proper stylesheet for that too.
If you embedd a style to several HTML pages, and want to change it later, you have to go file by file changing it. That is one good enough reason for me.
The key word here is maintainability. Organized code is maintainable code! It is far better to add an id to a tag and reference it in the global css file than to do it inline, because if you want to change that style later, you know where to find it, and you only have to change it in one place.
The reason you want to offload the CSS into a different file is so the browser can cache it. Otherwise, the browser has to load all the CSS as well as all the markup on every page. If you keep it in a separate file, the browser only has to load the CSS once.
The basic argument for this is that HTML's purpose is to provide structure while CSS's job is to provide styling, by embedding CSS in HTML you're breaking this basic rule. Plus, you'll have a tough time in maintaining pages.
Ideally, a design should be consistent enough that you can use generic rules for such situations. If you want to emphasize something, then <em> or <strong> is likely the way to go. After styling your <em> or <strong>, you can easily add the same emphasis to other areas of the site.
It's not simply about performance or style, it's also about consistency and ease of maintenance.
Find the similar elements in your design and mark them up similarly. It's as easy as that.
Even if it's "just 1" you should still do it because it helps you get in the habit of it.
embedded css has the following problems:-
1. It has browser compatibility problem. Example Ie has problem understanding inbuilt styling.
2. If you want to use the same css style again , it is better to have a class for it.
What is the actual meaning of separation of content and presentation?
Is it just mean to avoid inline css?
Does it mean that the design should be able to manipulated without changing the HTML?
Can we really make any change in design from CSS only?
If we want to change the size of
images then we will have to go to in
HTML code
If we wan to add one more line break in paragraph then again we will
have to go to in HTML code
If we want to add one more separator
at some place then again we will have
to go to in HTML code
Which X/HTML tag we should avoid to use to keep separation of content and presentation?
Is separation of content and presentation also helpful for accessibility/screen reader users? ... and for programmer/developer/designer?
When defining what is content and presentation, see your HTML document as a data container. Then ask yourself the following on each element and attribute:
Does the attribute/element represent a meaningful entity in my data?
For example, are the words between <b> tag are in bold simply for display purposes or did I want to add emphasis on that data?
Am I using the proper attribute/element to property represent the type of data I want to represent?
Since I want to add emphasis on that particular section, I should use <em> (it doesn't mean italic, it means emphasis and can be made bold) or <strong> depending of the level of emphasis wanted.
Am I using the attribute/element only for display purposes? If yes, can the element be removed and the parent element styled using CSS?
Sometimes an presentational tag can simply be replaced by CSS rules on the parent element. In which case, the presentational tag needs to be removed.
After asking yourself these three simple questions, you are usually able to make a pretty informed decision. An example:
Original Code:
<label for="name"><b>Name:</b></label>
Checking the <b> tag...
Does the attribute/element represent a meaningful entity in my data?
No, the tag doesn't represent a data node. It is there purely for presentation.
Am I using the proper attribute/element to property represent the type of data I want to represent?
<b> is used for presentation of bold elements.
Am I using the attribute/element only for display purposes? If yes, can the element be removed and the parent element styled using CSS?
Since <b> is presentational and I am using it for presentation, yes. And since the <b> element affects the whole of <label>, it can be removed and style be applied to the <label>.
Semantic HTML's goal is not to simplify design and redesign or to avoid inline styling, but to help a parser understand what that particular tag represent in your document. That way, applications can be created (ie.: search engine) to intelligently decide what your content signify and to classify it accordingly.
Therefore, it makes sense to use the CSS property content: to add quotes around text located in a <q> tag (it has no value to the data contained in your document other that presentation), but no sense to the use the same CSS property to add a © symbol in your footer as it does have a value in your data.
Same applies to attributes. Using the width and height attribute on an <img> tag representing an icon at size 16x16 makes semantic sense as it is important to understand the meaning of the <img> tag (an icon can have different representations depending on the size it is displayed at). Using the same attributes on an <img> tag representing a thumbnail of an larger image does not.
Sometimes you will need to add non-semantic elements to be able to achieve your wanted presentation, but usually those are avoidable.
There are no wrong elements. There are wrong uses of particular elements. <b> should not be used when adding emphasis. <small> should be used for legal sub-text, not to make text smaller (see HTML5 - Section 4.6.4 for why), etc... All elements have a particular usage scenario and they all represent data (minus presentational elements, but they do have a use in some cases). No elements should be set aside.
Attributes are a different thing. Most the attributes are presentational in nature. Attributes such as <img border> and <body fgcolor> rarely have signification in the data you are representing therefore you should not use them (except in those rare cases).
Search Engines are a good examples as to why semantic documents are so important. Microformats are a predefined set of elements and classes which you can use to represent data which search engines will understand in a certain way. The product price information in Google Searches is an example of semantics at work.
By using the predefined rules in set standards to store information in your document allows third-party programs to understand what seems to be a wall of text without using heuristics algorithms which may be prone to failures. It also helps screen readers and other accessibility applications to more easily understand the context in which the information is presented. It also greatly helps the maintainability of your markup as everything is tied to a set definition.
The best example is probably the CSS Zen Garden.
The goal of this site is to showcase what is possible with CSS-based design only, with a strict separation of content from the design. Style sheets contributed by various graphic designers are used to change the visual presentation of a single HTML file, producing hundreds of different designs. The HTML markup itself never changes between the different designs.
On each design page, you'd have a link to view the CSS file of that design.
What is the actual meaning of separation of content and presentation?
It is rather a design philosophy than somewhat concrete. In general, it means that you should preserve the semantics of the content, think of your content as of a piece of structured information. And that also means that you should keep all aesthetic details away from this structured information.
is it just mean to avoid inline css?
As noticed above, inline styles have nothing to do with semantics of your content and should be avoided at all costs. But it isn't just that.
is it just mean if after writing html according to design then if then if we want to do any change in design then it should be only with css, no need to html
Unfortunately, it is not always possible to achieve some concrete aesthetic goals without modifying the underlying markup; CSS3 tries it's best to address these issues.
Which X/HTML tag we should avoid to use to keep separation of content and presentation?
Look for deprecated tags in W3C HTML 4.01 / XHTML 1.0 Reference
Is separation of content and presentation also helpful for accessibility/screen reader users?
Surely. Better structured information generally remains readable even if certain browsers render styles incorrectly (or do not render them at all). Such content may also look more adequate on printed media (though print styles may be applied to achieve even better aestherics -- they, again, have nothing to do with content semantics).
Is separation of content and presentation also helpful for programmer/developer/designer ?
Of course. The separation of content and presentation takes its roots from more general philosophy, the separation of concerns. Everybody benefit from the separation: the content supplier does not have to be a good designer and vice versa.
Putting in line breaks at certain points is inevitable, there will usually be some overlap of presentation and content. You should always aim for perfect separation though.
Take the other extreme: A page containing loads and loads of tables that are used for layout purposes only. This is the definite anti-pattern that should be avoided at all cost. The content plays a second fiddle after the layout here; it's often not in the right order and thereby hardly machine readable. Not machine readable content is bad for accessibility and bad for the page's search engine ranking.
By marking up content without concern for presentation, you are first and foremost making it machine readable. You are then also in a position to serve the same content to different clients in different formats, say in a mobile-optimized version. You can also change the presentation easily without having to mess with the HTML files, say for a big redesign.
Another benefit that comes naturally by separating content and presentation (HTML - CSS files) is that you have less to type and less to maintain, plus your pages can have a consistent styling applied very easily. Contrast thousands of inline styles vs. one style definition in one CSS file, which is "naturally" applied to all elements with the same "meaning" (markup).
Ideally your (X)HTML consists only of meaningful, semantic markup and your CSS of styles using this markup for its selectors. In the real world you'll often mix classes and IDs into your markup that add no extra meaning, because you need these extra "hooks" to style everything the way you want to. But even here there's a difference between class="blue right-aligned" and class="contact-info secondary". Always try to add meaning to the content, not style. Balancing this is quite an art in itself. :)
Is it possible to convert HTML + CSS into HTML for a system that doesn't handle CSS, not even inline CSS?
What options do I have?
No. Much of what CSS does is not possible with HTML alone. Your best option is to design your site in such a way that when it loses CSS, it still renders in a nice and orderly fashion. Pay very close attention to things like Heading Tags, paragraph tags, lists, etc. Be sure to build semantically-correct sites, and they (in most cases) will degrade quite nicely.
The only thing you can do is add styles that were possible with old html3+ attributes and font tags. Quite a bit of stuff is possible, but none of it is going to be automatic. You can go through pretty much everything in css and try to find it's html3+ attribute equivalent.
Things like background font b i center width height are examples of old attributes (or tags in the case of font) that define style (and should generally be ignored these days). I don't envy the work ahead of you, but just make a happy medium between reasonable things and unreasonable styles. Tables also might come in handy for floats as well.
Sounds like an old mobile device?
If you can't use any CSS, I would imagine you would have to resort to possibly deprecated HTML tags/attributes, like font tags and attributes like bgcolor.
This would probably be rather difficult, because to my knowledge you can't achieve everything you can do with CSS, like positioning for example. You would have to switch your layout to use tables and set align, valign, etc.
use this first
http://www.mailchimp.com/labs/inlinecss.php
then replace css with deprecated html
http://www.highdots.com/css-editor/articles/css_equiv.html
Two words: Image Maps :) (I've actually seen sites that, in order to "render correctly on every browser" literally just make a big fancy image the background, and add links accordingly via an image map)
I have an app that reprocesses HTML in order to do nice typography. Now, I want to put it up on the web to let users type in their text. So here's the question: I'm pretty sure that I want to remove the SCRIPT tag, plus closing tags like </form>. But what else should I remove to make it totally safe?
Oh good lord you're screwed.
Take a look at this
Basically, there are so many things you want to strip out. Plus, there's stuff that's valid, but could be used in malicious ways. What if the user wants to set their font size smaller on a footnote? Do you care if that get applied to your entire page? How about setting colors? Now all the words on your page are white on a white background.
I would look into the requirements phase again.
Is a markdown-like alternative possible?
Can you restrict access to the final content, reducing risk of exposure? (meaning, can you set it up so the user only screws themselves, and can't harm other people?)
You should take the white-list rather than the black-list approach: Decide which features are desired, rather than try to block any unwanted feature.
Make a list of desired typographic features that match your application. Note that there is probably no one-size-fits-all list: It depends both on the nature of the site (programming questions? teenagers' blog?) and the nature of the text box (are you leaving a comment or writing an article?). You can take a look at some good and useful text boxes in open source CMSs.
Now you have to chose between your own markup language and HTML. I would chose a markup language. The pros are better security, the cons are incapability to add unexpected internet contents, like youtube videos. A good idea to prevent users' rage is adding an "HTML to my-site" feature that translates the corresponding HTML tags to your markup language, and delete all other tags.
The pros for HTML are consistency with standards, extendability to new contents types and simplicity. The big con is code injection security issues. Should you pick HTML tags, try to adopt some working system for filtering HTML (I think Drupal is doing quite a good job in this case).
Instead of blacklisting some tags, it's always safer to whitelist. See what stackoverflow does: What HTML tags are allowed on Stack Overflow?
There are just too many ways to embed scripts in the markup. javascript: URLs (encoded of course)? CSS behaviors? I don't think you want to go there.
There are plenty of ways that code could be sneaked in - especially watch for situations like <img src="http://nasty/exploit/here.php"> that can feed a <script> tag to your clients, I've seen <script> blocked on sites before, but the tag got right through, which resulted in 30-40 passwords stolen.
<iframe>
<style>
<form>
<object>
<embed>
<bgsound>
Is what I can think of. But to be sure, use a whitelist instead - things like <a>, <img>† that are (mostly) harmless.
† Just make sure that any javascript:... / on*=... are filtered out too... as you can see, it can get quite complicated.
I disagree with person-b. You're forgetting about javascript attributes, like this:
<img src="xyz.jpg" onload="javascript:alert('evil');"/>
Attackers will always be more creative than you when it comes to this. Definitely go with the whitelist approach.
MediaWiki is more permissive than this site; yes, it accepts setting colors (even white on white), margins, indents and absolute positioning (including those that would put the text completely out of screen), null, clippings and "display;none", font sizes (even if they are ridiculously small or excessively large) and font-names (even if this is a legacy non-Unicode Symbol font name that will not render text successfully), as opposed to this site which strips out almost everything.
But MediaWiki successifully strips out the dangerous active scripts from CSS (i.e. the behaviors, the onEvent handlers, the active filters or javascript link targets) without filtering completely the style attribute, and bans a few other active elements like object, embed, bgsound.
Both sits are banning marquees as well (not standard HTML, and needlessly distracting).
But MediaWiki sites are patrolled by lots of users and there are policy rules to ban those users that are abusing repeatedly.
It offers support for animated iamges, and provides support for active extensions, such as to render TeX maths expressions, or other active extensions that have been approved (like timeline), or to create or customize a few forms.