I have a question regarding grouping html tags under one class name if possible.
For example I wanted to define <h1> <h2> <h3> <h4> but not for the whole site.
I tried like this below but it this does not work.
.stylename h1, h2, h3, h4 {color:#FFF;}
<div class="stylename">
<h1>I want to be #FFF color</h1>
<h2>Me too</h2>
</div>
What am I doing wrong?
thanks in advance.
You could just use:
.stylename {
color:#FFF;
}
<h1 class="stylename">I want to be #FFF color</h1>
If you would like to have that class applied to all headings:
h1.stylename,
h2.stylename,
h3.stylename{
color:#FFF;
}
But I wonder why not apply color: #FFF to all <h> elements in the first place
h1, h2, h3, h4, h4, h6 {
color:#FFF;
}
, and if there should be a heading different apply a class on that one.
Thanks for reply, I was trying to avoid exactly that, to attach style name to each tag individually.
I Already have page-wide CSS for those elements, thing is that right side of my website where navigation goes etc. is reverse color background. its dark. so All the input would have to have opposite color coordination.
thanks again, i guess ill have to apply style individually.
Why not apply/add a color style using the parent?
#rightbar h1,
#rightbar h2,{
color: #FFF;
}
Your problem is simple:
Improper targets:
.stylename h1, h2, h3, h4 {color:#FFF;}
The moment you add the comma you are starting an ENTIRE new target – so you have to restate .stylename again for each one, it does NOT inherit to the ones after the comma so in your original code the h2, h3 and h4 would be being applied globally.
PROPER targets:
.stylename h1,
.stylename h2,
.stylename h3,
.stylename h4 {
color:#FFF;
}
NOT that you should be needing it on the h1, since you should only ever have one h1 per page.
If he’s got an ID on that right side that is how I would be doing it too. That would override any site-wide styles that may be associated with the headings via classes.
That’s not necessarily true. It depends on the semantics of the document. It’s especially not accurate if considered in terms of the current HTML 5 specification, where it’s made clear that H1 should often be used instead of H2-H6, in conjunction with SECTION.
/facepalm
please link me
Sorry, what are you looking for? A link to the HTML 5 spec?
Ah, so another reason to HATE HTML5, it’s breaking how heading tags are supposed to work and their semantic meaning – JOYOUS.
ASSUMING that’s in the specification, but then I don’t understand the POINT of ‘section’ since that’s redundant to DIV, just as I don’t get the point of NAV or most of the other new tags and attributes.
NOT that ANY of us have ANY business deploying websites in HTML 5 yet… and I’m hoping it stays that way for a long long time given what total pointless overcomplicated garbage it is.
There’s a reason I have no plans to migrate past XHTML 1.0 for the foreseeable future – thanks for ANOTHER reason to not embrace the total idiocy that is 5.
@deathshadow60, I don’t have a lot of time to write a reply, but I’ll throw a few things at you.
it’s breaking how heading tags are supposed to work and their semantic meaning
The H1-H6 scheme was pretty ill-conceived to begin with. Their semantic meaning is that they’re headings with different ranks. It’s a pretty clunky way to specify the rank for a variety of reasons though. HTML 5 doesn’t fundmentally change the semantics, it just provides an improved way of specifying the rank. Granted, legacy user agents won’t fully understand it, but that’s the price of progress. Doesn’t bother me because for years I’ve been using H1 predominantly and just pretending DIV had the semantics of SECTION in those cases.
but then I don’t understand the POINT of ‘section’ since that’s redundant to DIV
DIV is purely structural. SECTION associates a heading with content and is used for an outlining algorithm and determining the rank of the heading.
just as I don’t get the point of NAV or most of the other new tags and attributes
I haven’t looked into that too much myself, but taking NAV for example, accessibility is at least part of the point of it, e.g. obviating the need for “skip nav” links, I’d imagine.
and I’m hoping it stays that way for a long long time
I think you’re going to end up being disappointed on that count, but we’ll see.
here’s a reason I have no plans to migrate past XHTML 1.0 for the foreseeable future
What’s the reason – that it’s “pointless overcomplicated garbage” and “total idiocy”? What about, say, the client-side form validation additions. You don’t think that’s worthwhile? Would you rather have to rely on scripting for that?
I’m not totally sold on everything about HTML 5 either, but that definitely seems to be the way the wind is blowing and there’s already a lot of buzz around it. Unfortunately it’s not practical for a lot of developers, including myself for the most part, but for what it’s worth if you have some free time you can participate in the WHATWG mailing lists and give your two cents on what gets spec’ed.
It’s only ill concieved to those who fail to grasp how SIMPLE they are… and I’m CONSTANTLY amazed at the people who cannot grasp what the specification is actually saying, and the sheer common sense of it. It’s so moronically simple!
H1 is the heading under which all content and headings on the page are subsections of; H2’s are the start of sections that are subsections of the h1. H3’s are the start of subsections of the h2’s. It fans out like a tree – just like the auto-section navigation in Blazer gives you on pages that bother to use it properly; Just like the summary you can pull up with a user style in Lynx – Just like the document outline in the FF web developer toolbar can create (If you are still using a version of Firefox prior to 3.6, since it’s not been updated to work properly)
That’s their meaning – BECAUSE they use words like “importance” (which they mean in the structural sense) or rankings people have repeatedly taken the meanings incorrectly or out of context – which I believe is why people CONSTANTLY screw up something so easy!
As opposed to just using a heading tag to say “This is the start of a section”… yeah, that’s so much simpler; NOT.
Which of course precludes the use of accesskeys menus for most mobile browsers OTHER than webkit… IMHO the NAV element is simply being added to justify that extra pointless div people slap around their menu UL’s for no good reason; They are just using accessibility as an excuse since I doubt we’ll see many user agents be able to use it the way their explanation claims it will work.
Pretty much – I wrote about many of my reasons on the blog I really need to post in more than once every six months…
People can barely manage to use any of the tags we already have correctly if they even know most of them, adding MORE tags to the specification isn’t going to help matters; and is in fact undoing ALL of the progress STRICT offered us. You want evidence of idiocy, look no further than AUDIO, VIDEO, and making EMBED official… Since STRICT was supposed to be paving the way to replace APPLET, EMBED, IMG and BGSOUND with OBJECT. One tag… does the job, one tag is simpler than ten tags – which we let this HTML5 train wreck through is basically what we are looking at!
CISC vs. RISC?
They are the only thing in it that is remotely close to attractive, but since you would need to re-verify all the inputs server side ANYWAYS, what good is it? MAYBE if people stopped using 200k of markup and 900k of javascript to deliver a 4k form, they wouldn’t need any of that client side validation nonsense! On my own forms and testing I actually ended up saving bandwidth by doing AWAY with client side validation… since my average form page is 8-12k.
Keyword being buzz. Meaningless background noise spouted more as marketspeak than actual meaningful thought. ONE STEP removed from Web 2.0
Which I tried and got pissed with being constantly shot down over pointing out all the redundancies, undoing of the progress of the past ten years by making what is effectively “Transitional on Steroids”, etc, etc… They don’t want progress or cleaner code, they just want to keep bolting on new redundancies and pointless “gee ain’t it neat” nonsense that does the end user no good and just wastes more bandwidth… It’s one step removed from the dumbasses who slap jquery on a page just so they can change the color of an anchor.
Which makes it REALLY pathetic when they try to sell it as saving bandwidth or making things simpler. I suspect my definition of simpler differs from theirs.
But as my favorite apprentice said shortly before his unfortunate passing just over a year ago “The same people who made endless bloated nested tables today just make endless bloated nested div’s.” – to which HTML 5 must be a dream come true with all the silly extra tags to justify those pointless wrapping elements by trying to sell us on them as semantic – when they generally are so vague as to be meaningless. Hardly surprising since it seems most of the people working on the specification never actually embraced the concept of STRICT.
When HTML5 reaches the point of being what’s “expected” on new sites that’s about when I’m probably walking away from web development entirely. NOT that I haven’t been considering hanging up my shingle for good due to the constant frustration of dealing with people who vomit up HTML 3.2, slap a HTML 4 tranny or HTML 5 doctype on it, and then wonder why their pages load slow, are a pain in the ass to maintain and rarely work cross browser. Even sadder is that with all this gee ain’t it neat javascript and flash nonsense pages are LESS useful and chew more bandwidth than they were when HTML 3.2 was king a decade ago!
As it is I’ve stopped taking on new clients altogether and have been weening off my existing ones to the point they are self sustaining. My increasing disgust with the sleazeball crap out pages any old way industry has me ready to go on a shooting spree; As such I’ve taken a renewed interest carving, bicycle building, and busking on the EWI.
It just gets sleazier, sloppier and stupider every month…
The only thing I can see where the idea of multiple h1’s make sense (sorry to keep this off-topic) is those bloggitty pages, where the main page is like
THIS IS JOE’S WEB SITE
I write about stuff
which might not be an appropriate h1 if then the main section is followed by articles with titles:
RON PAUL IS MY HERO
written 1 aug by Joe
this article is the section belonging to the header above…
If, like a newspaper, you can’t convince yourself that RON PAUL IS MY HERO is really a subheader of THIS IS JOE’S WEB SITE then individual articles have their own h1.
Once you actually click to read the whole article, it’s easy: RON PAUL IS MY HERO is clearly the h1 since the rest of the page is just that article. But what is it on the main page?
I notice a lot of HTML5 tags seem to assume websites are newspaper-like blogs though.
On http://www.sitepoint.com/ they do what I’ve done in the past: each article header is an h2, because none of them are the main header of the whole page. Problem is, “SITEPOINT.COM” isn’t really a header of that content either, is it? They didn’t think so either: there’s NO h1 on that page at all! Arg.