Best practices?
How does this differ from HTML4 or XHTML1?
There's a lot of discussion going on over here: http://html5doctor.com/html-5-reset-stylesheet/
I'm wondering what other resources/discussion exists.
The comments on that post are crazy. You're certainly not going to find a more thorough discussion.
I think you should delete unnecessary rules and deprecated tags from whatever reset you've been using and keep truckin. Paul Irish (jQuery core contributor, co-creator of Modernizr and now Googler) has a comment in the article you link to that has all the HTML5 specific CSS leveling you're likely to need:
article, aside, dialog, figure, footer, header, hgroup, nav, section { display:block; zoom:1; }
Google's using a simpler version in their base.css on HTML5Rocks.com:
section, article, header, footer { display: block; }
You'll still need to use Remy Sharp's simple, bare-bones HTML5 Shiv or Modernizr to run a JavaScript loop to enable styling of new HTML5 elements in IE. HTML5 Shiv just creates the elements to allow styling, Modernizr is a much more full-featured HTML5 and CSS3 detection/styling solution. There's another great post on HTML5 Doctor worth a look, How to use HTML5 in your client work right now from March 2010, co-written by Remy and Richard 8 months after the reset article. They mention using Modernizr "to detect Web Forms 2.0 and other HTML5-type support."
Also, Dion (from Ajaxian and now Palm) tweeted about css3pie that will render visual elements like border-radius, box-shadow, and gradients in IE. Can't vouch for it myself.
(I had more links in here but had to remove all but one b/c my rep. is < 10, if there's something you can't find. reply and I'll post it.)
HTML5 is still not widely supported. As such, I don't think you will find an HTML5 specific reset stylesheet yet. My recommendation would be to take Eric Meyer's and add the tags for HTML5. (e.g. nav, header, footer, etc)
I just use my variation of Eric Meyer's reset, with my own preferences. For HTML5 compatibility, I add the new elements in as needed.
One thing in particular is that new elements are unstyled by default, so you need to provide your own defaults. This is especially important for block elements like section, aside, and article. You need to ensure you specify display:block for those elements.
I modified Eric Meyers reset late last year for HTML5. Use it for every project, and it works great: CSS Reset Refreshed
It sets the new HTML5 block elements to display accordingly. This is not done in any mainstream browser today, and you will run into problems if you do not set this.
It also "resets" HTML5 element styles. Technically, the resetting is not yet needed as browsers do not natively style HTML5 elements, but your site will be future proofed for when they do.
There's a lot to it. You can't take one persons css rest as gospel. I recently made a custom reset sheet by revising parts of boilerplate, YUI, my preference and some other ppls methods.
It's more down to preference & practicality. In terms of differentiating html5 css standards from xhtml & html4, don't bother compare you should aim to use html5 doc-types for all your new work unless your project specifically requires xhtml by request.
Related
I have an application developed in VS2005 and html4. First of all my question is, is there any tool that will do migration from html4 to html5.
My plan is first select HTML5 from dropdown available in VS2012 then just change the doctype definition from master page to <!DOCTYPE html> and fix all the warning like replace cell padding with padding and etc.
Does these steps are sufficient in order to convert an application in to HTTML5?
Are these steps are sufficient in order to convert an application in to HTML5?
In short, yes, that's pretty much it.
HTML5 is explicitly designed to be backward compatible with HTML4; there is very little that you should need to change apart from the doctype.
There are a few things to be aware of, which might need changing:
A few older HTML tags have been deprecated in HTML5. You can't use things like <blink>, <marquee> or other awful things like that. Hopefully you weren't using them anyway though?
Also some attributes have been deprecated, mostly in favour of using CSS instead. So if you're using width or height or color attributes in your HTML tags, you should replace them with CSS. The same also applies to the <font> tag; use CSS to define your fonts and font sizes instead.
There are various new tags in HTML5 which you may want to use. These are tags like <section> and <footer>, which are designed to make your site's code more readable for search engines. But you don't have to use them; they are entirely optional. Note that IE8 and earlier don't support them unless you use a JavaScript hack, so if you need to support IE8, it may be best not to use these tags. You can still use the HTML5 doctype in IE8 though.
You might find it useful to read the official documentation from the W3C that details the differences between HTML4 and HTML5. Read it here: http://www.w3.org/TR/html5-diff/
I'm working on a browser extension that adds it's UI to the pages DOM. On some pages I have the problem certain styles affect my UI. To counter this I keep my UI underneath a common root which resets most of the styles to the default value.
Sometimes I missed things which causes visual glitches in my UI. (i.e. the pages CSS file sets form { width: 80%; } so I need to add form { width: auto; } to my reset styles.
Is there a collection of styles that reset every CSS attribute to the value that is declared as default by the standard for every element?
I have come across the same problem. The usual CSS normalizers listed by the other answers does not answer the question because it is made to cancel the differences across the browser's default styles.
In the context of an extension, I needed to cancel every specific style that may exist on a random website.
I have come across this solution (I am not sure if it was possible at the time of the question, 7 years ago).
.your-container-class,
.your-container-class *,
.your-container-class *::before,
.your-container-class *::after {
all: initial;
}
So far it seems to achieve the goal by removing the differences across websites. The downside is that it resets even some default styles (ol, ul, li not behaving like lists for example).
Eric Meyer’s “Reset CSS” 2.0
(the original one)
HTML5 Doctor CSS Reset
(extends the Eric Meyer's one to improve HTML5 tags reset)
Yahoo! (YUI 3) Reset CSS
(based on Normalize.css)
Universal Selector ‘*’ Reset
Normalize.css 1.0 2.1.3
("…as used by Twitter Bootstrap, HTML5 Boilerplate, YUI 3, Pure, TweetDeck, Soundcloud, Medium, NASA, GOV.UK, Guardian, Rdio, Favstar, iA, and many others.")
There are others, but this were (and still are) the 2012’s most popular CSS Reset scripts.
I recommend using a quick Google search to find something like so: http://meyerweb.com/eric/tools/css/reset/
You can implement the reset in as-is and then if any problems arise down the road, simply add to it as needed.
Be aware that some pre-made CSS resets require a shout-out to using them.
Yes, absolutely.
There are two schools of thought to this. One is the zeroing style reset sheets, which basically remove all margin, padding and other such settings from the css. A good example of this is Eric Meyer's Reset CSS
The other approach is to set everything to roughly what you'd sensibly expect it to be, setting a reasonably looking margin to paragraphs and headings, indenting lists etc. A good example of this is Normalize.css
Some browsers also support the initial value, which sets the value of a property back to what it intially was. It's not widely supported enough to use in production, IMO.
Html5 boilerplate has an normalize.css which sets al lot of css styles to a default.
http://html5boilerplate.com/
As you are applying your styles to different pages with different unique styles, its hard to say if you will get success on removing all styles from all pages with some CSS reset.
But maybe these can help:
Normalize.css (used by many CSS frameworks)
CSS Reset by Meyer
There's a working example here
I've got Modernizr running; I've got
article, aside, details, figcaption, figure, footer, header, hgroup, menu, nav, section {
display: block;
}
...in the css, but in IE8 and below the styles don't carry, even though the elements wrap the child elements correctly?
Can anyone tell me what I'm doing wrong?
Thanks
James
You're not including modernizr anywhere in the source as far as I could see.
I did notice that you have a minified require.min.js script at the bottom of the page. If that script is dynamically loading modernizr, it'll break the HTML5 shiv, as document.createElement needs to be called in older versions of IE before any of the elements are used in the DOM.
From the Modernizr Documentation:
Drop the script tags in the of your HTML. For best performance, you should have them follow after your stylesheet references. The reason we recommend placing Modernizr in the head is two-fold: the HTML5 Shiv (that enables HTML5 elements in IE) must execute before the , and if you’re using any of the CSS classes that Modernizr adds, you’ll want to prevent a FOUC.
In IE8 and below, the elements appear as </element/>, correct?
You will need to use something that translates the elements for you. For instance, you can use HTML5 Shiv to allow the browsers to properly understand the elements.
I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.
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)