Is there any practical benefit of using <header> over <div id="header">?
and writing css for header {} over #header {}
I know one downside is , I will have to punish IE users with a Javascript if use <header> otherwise it will not take style.
I know it's HTML5 but is there any advantage of using it until non HTML5 supported browsers are still in use.
IE6, IE7, IE8 and some old mobile browsers do not understand these new tags.
Edit:
It's OK to use a JS Canvas library to do something awesome in all browsers but to use a Javascript just to use some tags in IE wil decrease performance without a big reason.
Besides the fact that it gives more meaning to the markup , when working with css you can more easily select the required items without resorting to id's or class.That reduces the amount of markup you are required to write , it makes mantaining the site alot easier and help other developers understand your code better if needed.
I don't know for a fact, but I think it almost certain that using semantically better markup (e.g. <header>) will help search engine crawlers construct a better image of your website.
There is probably no other practical benefit of going HTML5, and even the above is not exactly tangible. So in practice I don't really believe you can argue that going HTML 5 (and doing the extra work needed to make your page compatible with earlier IE versions) is going to be a good investment.
On the other hand, if you don't care about obsolete browsers then there's really no drawback.
Well, from my point of view, it gives further meaning to the markup. At least in a more structured way. Say, for instance that you have to parse automatically your page (if it wasn't yours), you would know that the header will always be a and it doesn't depend on the CSS class used.
Gives better structure to your page as Carles points out - this is especially helpful when it comes to search engines - they'll be able to crawl all your website a lot more effectively. You can use javascript to get IE to recognise HTML5 elements (simply put it inside an if statement).
Related
Questions
On average, has the usage of HTML5
semantic tags increased compared to
the usage of CSS layers (div)?
Also, is there a good difference between them and does it optimize the code for better speed and maintainability?
Differences in character length is not much
and <div id="footer"> is
compatible in older browser without
using Modernizr or other
Javascript solutions to emulate
support of HTML5 in non supported
browsers.
Therefore, if I only use semantic
tags of HTML5, and not using any
advance functionality of HTML5 like
audio, video, etc. am I missing
something?
Examples
HTML
<footer> and <div id="footer">
CSS
#footer {} and Footer {}
From what I've seen and experienced, HTML5 tags like and are mainly provided for SEO so that search engines can (one day?) possibly use those sections and other tags properly.
Like you said, most of the tags are semantic and provide no real functional benefit- in fact, most break rendering in older browsers. I ran into an issue with these new tags when I tried dynamically loading HTML5 content with jQuery and the HTML5Shiv.js/Modernizr.js. I was unable to properly render the elements that were dynamically loaded in older browsers such as IE8 and IE7.
At this point, I'd recommend sticking with divs, as they're more widely used and provide better cross-browser functionality.
My two cents.
On average, has the usage of HTML5 semantic tags increased compared to the usage of CSS layers (div)?
You are conflating two different ideas here. CSS can be applied to new elements just as easily as it can to old ones. The use of CSS is independent of use of semantics.
Also, is there a good difference between them and does it optimize the code for better speed and maintainability?
Speed? Certainly not.
Maintainability? Well, they reduce div soup, so in theory, yes.
The advantage comes from having more semantics in the document, so tools can extract relevant parts of documents, skip over sections, etc.
Differences in character length is not much and is compatible in older browser without using Modernizr or other Javascript solutions to emulate support of HTML5 in non supported browsers. Therefore, if I only use semantic tags of HTML5, and not using any advance functionality of HTML5 like audio, video, etc. am I missing something?
Err… you're missing audio and video. (Whether that matters for your site is another story)
I know this could boil down to a philosophical issue, so I don't mean to start a discussion on the topic. But I'm looking for the (or a couple of them) best way to resolve most issues of CSS styling in Internet Explorer 6.
I'm aware of this article on forabeautifulweb.com, and it's recommendation to just feed IE6 users a universal plain IE6 stylesheet with just some basic styling better than the browser defaults. For my application this is not the best.
I'm also aware of the concept of "fixing" IE6's CSS support via Javascript, and I'm sort of a fan of this idea. But I don't know what (if any) the best one is - I know there's several floating around in the wild. This article by Eric Meyer mentions one, but this was written almost 2 years ago, so is there a more standard script to use for this purpose now?
Can anybody point me to one or two such scripts that have been proven to be effective for updating some of IE6's handling of CSS to behave more like a modern browser?
UPDATE: to all the people answering who are trying to convince me not to use JS to fix the problem - I am plugging my ears and humming. :)
Seriously, I'm not asking whether or not to use JS for this. We've already decided we don't need to support IE6 and it is not worth the time for us to try to "debug" our stylesheets just for IE6. This decision is based on our audience and on our site stats for IE6 usage.
As far as all the comments about "what if the user doesn't have JS enabled?" Well in that case a lot of stuff on our site is not going to look right anyway, so that is somewhat of a mute point.
I've already implemented the IE7.js that Gordon suggested, and that is quite sufficient for us to get by in IE6, with very little drawback.
Thank you all just the same for your input.
You can use this library if you want to do it with JavaScript:
IE7.js is a JavaScript library to make Microsoft Internet Explorer behave like a standards-compliant browser. It fixes many HTML and CSS issues and makes transparent PNG work correctly under IE5 and IE6.
There is also CSS3Pie, which adds CSS3 support to browsers:
PIE makes Internet Explorer 6-8 capable of rendering several of the most useful CSS3 decoration features.
Also have a look at Progressive Enhancement and Graceful Degradation for a design philosophy.
Please don't use JavaScript to fix the problem, just add some rules to a stylesheet to fix them...
<link rel="stylesheet" type="text/css" href="normal.css" />
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="ie6.css" />
<![endif]-->
In the ie6.css, you just have rules that fudge the styles to work in IE6, you still use your normal stylesheet alongside it, so your site looks the same in IE6 and normal world.
From personal experiance, ie6 can be fixed within a few lines of CSS and a fair bit of inspecting with firebug/developers toolbar.. without the need for conditional comments.
majority of the problems I come accross are padding / margin based and it is down to me not using the best method first time round.
I also find that overflow:hidden fixes its fair share of ie6 bugs too.
i suggest, get ie6 open with the developers toolbar and try and find where the problem lies, and think of a better way to code that section.
Thats just me personally, I use conditional comments as a LAST resort.
Dean Edwards’ ie7.js script (linked by Gordon) is still the state of the art in this area.
As to what’s the best approach, it depends. Dean Edwards’ script fixes a lot of IE CSS bugs, and allows you to use selectors like the multiple class selector and the child selector that aren’t supported at all in IE 6.
If you’re happy that the IE 6 users in your target audience tend to have JavaScript turned on, a library like Dean’s can save you a bunch of time, and allow you to trim down your code by using the selectors that IE 6 doesn’t support.
However, you’ll likely still need an IE 6 stylesheet to deal with issues that Dean’s library doesn’t fix.
The best solution may be to wait for Microsoft to stop supporting IE 6 (like they did with Mac IE 5), because if Microsoft don’t support it, it’s hardly fair for people to expect you to. We‘re currently hoping for 2014 on that score.
Generally, you don't need javascript. You can use plain old CSS. It helps to have a good knowledge of hasLayout though.
More often than not, you can fix IE6 and 7's issues by giving the problem element layout. To do that, give it a fixed height or width, or use the proprietary zoom.
My favoured method of targeting specific versions of IE browser is to use conditional comments to add a <div> as a direct child of <body> which lets me know which version of IE I'm in (like so). That way, I can target IE6 directly:
.IE6 div.fubar {
zoom: 1;
}
The other thing to remember is that it's almost impossible to achieve pixel parity across IE6/7/8/Firefox/Safari/Chrome/Opera, so if some things don't look quite right in a browser that's nearly ten years old, you don't always need to worry about it.
Position is everything has some useful tips on IE bugs, too.
Don't use javascript if you can avoid it - you are not guaranteed that your users have JS activated (as already mentioned) and you actually don't need it.
To get rid of many problems of different interpretations from browsers (not just IE) user a css-reset stylesheet. There are many floating around.
Even better yet, use a CSS framework which will remove many many problems between different browsers and will come with many helpful classes to solve standard issues.
I for one love YAML (http://www.yaml.de/en/home.html), then there's Blueprint (http://www.blueprintcss.org/) and probably a few others. Believe me - once you used a CSS Framework you will never want to go back.
jQuery and its plugins work best for IE6 issues. Give it a try!
What should be written first while making CSS layouts XHTML code or CSS code?
Write Whole HTML first then write
CSS according to HTML
Write HTML for an design element and
CSS simultaneously
Write whole CSS first then write
HTML according to HTML
I read on this article's point # 7 "Create Your HTML First" is this advice best to follow?
Edit:
and in this tutorial author also write HTML First then write css using Edit CSS option of web developer toolbar i think this is best way.
In practice, you generally wind up needing to intermingle the two. Start out with HTML to rough out the basic areas of your design, then work in CSS around that rough idea. Typically you'll find yourself needing to add some more markup to allow for additional flexibility (perhaps you need a couple of nested containers to properly align something, et cetera).
I used to ponder about this long ago, when designing websites.
My conclusion was, and I believe it still stands today, that even though XHTML and CSS are meant to be isolated from each other as content and presentation respectively, the reality of the matter still makes the look of the website pretty much depend on the document structure - i.e. markup, XHTML - and thus CSS alone will not give you the magic wand to make your website change its look completely based on a stylesheet. I wish it were so however - certainly, that is the main purpose of CSS. And certainly, that would be the beauty of it - since each is completely isolated from the other, website developers can in peace of mind program the structure of the website documents, almost while the CSS authors can work in parallel and write the stylesheets. Then both are combined, and with the knowledge that the markup does not need to be changed ever again. That is the theory anyway.
In practice this often fails to work - because a document has a top-to-bottom left-to-right (usually) bound semantics, it becomes difficult to for instance, make an element appearing at the bottom of the document structure, appear at the top of the browser page to the user. The limitations work against the theory.
Because of the above implications, and some other real-world limitations of the CSS and markup technologies, I have decided to simply consider markup as something in between the content and the style. I.e. some of the markup will unfortunately dictate style, no matter stylesheet - the sequence of elements being one (see above), pagination limitations, etc - and so, while most of the structure may be isolated from its appearance, some of this appearance will be dictated by it. For this reason, if we don't regard client side scripting (which may aid styling by re-arranging elements of a document) - one way to do it is use XML as content, XHTML as content-style hybrid layer, and CSS to finally dictate the appearance.
Where does XML come into this? Well, you transform (either in browser or server-side) it with XSLT into a XHTML document, which you consider as relevant in the styling process. I.e. if you have an artist list of 1000 entries, and you want to customize how the page looks like, you use the following content XML:
<artists>
<artist name="Moby" />
<artist name="Cocorosie" />
<!-- and so on -->
</artists>
This is considered as an unchanging content, no matter the final style - part of the point of separating content from presentation, something you could not have done fully with XHTML because CSS cannot do certain things. With XSLT however, you can further transform the above into a desired markup ( you can then apply CSS to):
<xsl:transform>
<!-- XSLT is beyond the scope of this... -->
</xsl:transform>
will transform the XML into something like:
<h1>Artists</h1>
<h2>Page 1 of 10</h1>
<ul>
<li><a>Moby</a></li>
<!-- Only 100 artists per page -->
</ul>
And then you style it.
Bottomline is, you get to control each point of the transformation of your raw database content into final end-user application.
Much of what XSLT does with XML, can be instead done with JavaScript on XHTML, but I consider client-side scripting an addition, not replacement to things like XSLT. Then again, Firefox and most other modern browsers can do XSLT client-side, which blurs the distinction between scripting and document serving.
I think it's a mistake to do one before the other. Programming is an iterative process. Write them both until you have something small that works, then do it again. Build on it. Iterate.
If you write just HTML without writing any CSS, you'll find out later that you'll have a bunch of technical debt that needs to be paid off.
It really depends how big is your site... If it's a small website the order doesn't matter. If it's a big website i generally design basic structure in HTML then basic CSS and then move to details in HTML and then CSS.
Few advices.
re-use already made CSS and HTML.
ie. if you already have template
with basic HTML wrappers save it
for the next project or page or
if you set all images to
border:none in your CSS you can
easily save some CSS file with
basic settings
see an object in your head before
designing it
check in 5 major browsers (ie6 ie7
ie8 chrome and firefox)
I usually go with the second option:
Write HTML for an design element and
CSS simultaneously
This really helps, for example, when I am writing html, i write the CSS along the way too which helps me quickly spot any possible layout or cross-browser compatibility issues. If i wrote whole html first and then css, then things become little complicated and you have hard time correcting/styling the entire html which you already created.
As for the link you provided, i would simply say author has his own view and personal way of working. In other words, this also depends which way you are most comfortable with or rather fast.
You can't write CSS before writing the HTML (except for the body tag!), or you'll be working like a blind.
For me, I make a mock-up of the website layout, write down the whole HTML and then write CSS that just makes the layout.
I use Expression design to slice images and add/modify HTML/CSS until I get the final template.
I don't like the idea of going back and forth with code. If I'm at #header in html, it seems pretty logical to me to stylize the header right now. Is good for my mental sanity :D
So I go with the second option: I wrote code simultaneously.
You have to write HTML before CSS.
Your question is like, Is it better to design a car Interior, before having a car ?
Is it possible ? or Is it a intelligent work ?
Given that most designs are not simple, and following basic semantical rules, you will always need to adjust the html code when trying to get the layout looking as you have in mind. So doing both simultaneously is probably the most pratical way, although the other two options work as well; You just need to made adjustments then later.
Sorry , I am not choosing anyone of these..
In first you can't able to write the whole css for your page. although it's better you should write the common css classes and page layouts in the first.ie, after creating the page layout , you just design the page using table or div tags. after , while adding controls to the pages , you just identify the common styles u are using. These styles you can use like css classes. or seperate id. I am following this method for my designing.
i think its better.
By creating the HTML first, you can guarantee what the page will look like on the most basic browsers - it'll be legible on an old phone, everything's in logical order, and you aren't forcing screen readers to recite your site navigation first thing on every single page. That's design #1.
Design #2 is the CSS part, where you actually make things look visibly decent without limiting your user base.
Not that they can't be done simultaneously, mind. Just that's most likely what the author of that article was trying to get at.
See also: Progressive Enhancement.
I personally write much of the CSS first, then HTML, then tweak the two together - one page at a time (apart from common elements). At first it sounds counter-intuitive, but when you think of the CSS as not only styles but as elements that either have a style or have a style of nothing, it's actually very fast and produces lean code.
Once I've got some core styles in place, the HTML is just a question of...
<wrapper>
<div header>
<div this>
<div that>
<form>
<div footer>
... and it all slots roughly into the styles and layout that I've already defined. For elements that needed no styling, I just mentally skipped over when writing the CSS.
My 3 cents:
What's the goal of the webpage? Most of the time that goal is strongly related to it's content.
Thus, the first thing is content. HTML gives content gets it's semantics. CSS gives the semantics a context.
So the order:
content
html
css
But of course, it's an iterative process.
I write them at the same time, iteratively, in modules.
I will build out the general template (or base template) in html/css, do a full cross-browser test, then move on to the additional templates.
This fits in well with .net where I'm using master pages and nested master pages.
I may change this behaviour once IE6 is off the books, as you often have to completely restructure your markup to accommodate it.
I'd go with the second option. HTML in todays web dev is seen as a template to hold content. CSS should be used to format the layout and content within the web page.
Because of this, HTML and CSS should be used parallel in creating web-pages and individual elements.
I have designed many web-templates. But (except my first one) I've never used browser detection scripts to load corresponding CSS.
I am not sure whether it is a good technique, or just an alternative way (to struggle with a single CSS to satisfy all the browsers)?
It depends on how complex your layout is.
On the whole, there are a set of "problem features" with some browsers, such as the browser not following the border-box model and assigning margin, border and padding values incorrectly.
Many designs aren't affected by the problems and look very similar in all browsers, but if you have a part of your design that has a touch point on one of the issues, it is probably better to extract the "fixes" into a separate stylesheet, rather than pollute your standard CSS with hacks.
You should find that you have
1 Stylesheet for "standards compliant browsers"
and
1 Stylesheet to cater for any issues with the others
If you have more than this, you're creating trouble for yourself and are juat adding to the number of http requests for the page.
Most commonly people use conditional comments in Internet Explorer to load a separate stylesheet for just IE, and a default one for all the others.
More info on MSDN
The best option is to use a css which is compatible for each (major) browser.
So the question is; do you really need browser-specific-css?
If you really need it; you can use:
<!--[if IE 7]> <link rel="stylesheet" ....> <![endif]-->
From my experience I would always try to avoid to really fall into the specific-browser-CSS-trap. Try using CSS-reset-methods and from a fresh start build for a defined set of current browsers. I would rather try to make little changes to the designed layout to get it working as so much time can be saved by that (if it's possible in the project or the designer is cooperative).
Another aspect where it would make sense is an approach like the one Andy Clarke talks about in his nice book (Website http://www.transcendingcss.com/). Use latest tags and all options that make your code and CSS simpler, shorter, more semantic - even if it results in explicitely different look and feels for, e.g. Firefox and IE.
I'm using CSS Filters to modify images on the fly within the browser. These work perfectly in Internet Explorer, but aren't supported in Firefox.
Does anyone know what the CSS Filter equivalent for these is for Firefox? An answer that would work cross browser (Safari, WebKit, Firefox, etc.) would be preferred.
<style type="text/css">
.CSSClassName {filter:Invert;}
.CSSClassName {filter:Xray;}
.CSSClassName {filter:Gray;}
.CSSClassName {filter:FlipV;}
</style>
Update: I know Filter is an IE specific feature. Is there any kind of equivalent for any of these that is supported by Firefox?
Please check the Nihilogic Javascript Image Effect Library:
supports IE and Fx pretty well
has a lot of effects
You can find many other effects in the CVI Projects:
they are also JS based
there's a Lab to experiment
Good Luck
Could you give us a concrete example of what exactly you're trying to do? You'd probably get fewer "Your brower sux" responses and more "How about trying this different approach?" ones.
Normally CSS is used to control the look and feel of HTML content, not add effects or edit images in clever ways. What you're trying to do might be possible using javascript, but a behavior-oriented script still probably isn't very well suited for the kind of tweaking you want to do (although something like this is a fun and very inefficient adventure in CSS / JS tomfoolery).
I can't imagine a scenario when you would need the client to perform image tweaking in real-time. You could modify images server-side and simply reference these modified versions with your CSS or possibly Javascript, depending on what you're doing exactly. ImageMagick is a great little command-line tool for all the image effects you would ever need, and is pretty simple to use by itself or within the server-side language of your choice. Or if you're using PHP, I believe PHP's GD library is pretty popular.
There are no equivalents in other browsers. The closest you could get is using a graphics library like Canvas and manipulating the images in it, but you'd have to write the manipulations yourself and they'd require JavaScript.
filter is an IE-only feature -- it is not available in any other browser.
SVG filters applied to HTML content.
Only works in Firefox 3.1 and above, though I think Safari is heading in the same direction.
None that I know of. Filter was an IE only thing and I don't think any other browser has followed with similar functionality.
What is there a specific use case you need?
I'm afraid that you are pretty much out of luck with most of the cross-browser filter-type functionality. CSS alone will not allow you to do most of these things. For example, there is no way to invert an image cross-browser just using CSS. You will have to have two different copies of the image (one inverted) or you could try using Javascript or maybe go about it a completely different way, but there is no simple solution solely in CSS.
There are filters, such as Gaussian Blur et al in SVG, which is supported natively by most browsers except IE.
Pure thought experiment here, you could wrap your images in an SVG object on the fly with javascript and attempt to apply filters to them.
I doubt this would work for background images, though perhaps with alot of clever positioning it could work.
It's unlikely to be a realistic solution. If you don't want to permanently modify your source images, Rudi has the best answer, using server side tools to apply transformations on the fly (or cached for performance) will be the best cross browser solution.
This is a very very old question but css has updated to now support filters. Read more about it at
https://developer.mozilla.org/en-US/docs/Web/CSS/filter
Syntax
With a function, use the following:
filter: <filter-function> [<filter-function>]* | none
For a reference to an SVG element, use the following:
filter: url(svg-url#element-id)
Not really, and hopefully there never will be. It's not a web standard CSS feature for the reason that you're using CSS to format the webpage, not the browser itself. The day that other web designers and developers think they should style my browser how they wish and are then do so is the day I stop visiting their pages (and I say this as a front end web guy).