Like I said - I can implement that in my templates ? And are all browsers supporting CCS3 standard ? thanks
Nope, you can still use CSS3, but only use it to enchance your website, dont reply on it, the best two browsers for CSS3 support are Safari and FF, for example they both support attribute selectors.
Stick with CSS 2.1 for now. Most of the people who access the Internet will use a browser that is now starting to understand the most fundamental (and useful) parts of CSS 2.1 (I'm looking at you, Internet Explorer). The other browsers, unfortunately, have a COMBINED market share of about 20-25% overall (yes, the rest of that pie goes to IE). Of those browsers, Firefox, Opera and Safari have the best CSS 3 support, with (IIRC) Safari 3 (Beta) taking the lead, and Firefox/Opera fighting for second place (though I'll give the edge to Firefox due to its nightly builds, though I expect a FAR better implementation of CSS 3 in Opera 10 than Firefox 3 due to the rigorous development processes used by the team at Opera Software). If you want more information, check out www.css3.info
I wouldn't go that far - but then I recognize that entire sections of CSS2 aren't even fully implemented in Firefox (just like several entire sections of HTML4 STILL have yet to be implemented), so even THINKING of CSS3 at this point is jumping the gun... Seriously, hows that bug-free inline-block implementation coming along? Even the browsers that support it (Opera, IE7, Safari) don't fully support it properly since they all mess up when you nest them... How about that opacity command? You know, when it's in the specification, MAYBE your beta support should just USE the specification instead of that stupid -moz prefix? CSS3 is jumping the gun by about five to ten YEARS. Generally it seems to have taken almost a decade for CSS2 to even APPROACH being safe to deploy in the wild... CSS3? Forget it, what little is supported is a joke, inconsistant, it's like a trip in the wayback machine to 1998 with CSS2. There is a reason it is still only in 'working draft' - it's cute to play with, but I sure as shine wouldn't try to deploy ANY of it on a live website. Any specification that hasn't even been 'set in stone' yet is probably NOT worth even looking at for deployment on an actual website, and if browser support history is any indication, you are looking at YEARS before there's enough INSTALLED browser support (as in browsers users are actually using) for it to be safe for use in the wild.
Can you be specific? Again, specificity would be appreciated. That's a pretty much blanket indictment for not offerig any evidence. True enough in the general case, though progressive enhancements in UAs that support a given property are not out of line. This is a buggy property, probably due to some lack of specifics in the specs as to how it should be implemented. IE only "supports" inline-block on inline elements. Actually, it treats {display: inline;} elements as inline-block to a large extent. Firefox is in test mode, and quite properly using a proprietary value, -moz-inline-box, for the inline-block value. Nesting? Perhaps you should be able to, but just maybe inline-block is not the optimum value. Actually, opacity is not a part of css2. It is a css3 property, and strictly speaking, any UA implementing it should use the vendor identifier. eg. -moz, -o, -khtml, -msft, etc.. The opacity property recommendation has pretty much stabilized, and Firefox dropped the requirement for the -moz prefix a couple of years ago, sometime in 2005, as I recall, and as some of my documents from that period bear witness. There are certainly a lot of late adopters among authors. Actually, css2 was usable with IE5, and with the coming of IE6, NN6 and Opera5? (not sure of the version) and Phoenix0.5, css-p was very usable by 2002. Covered previously. CSS3 is definitely not ready for prime time. It represents a tremendous expansion of the power of the presentation language. It will also doubtless be affected by the work being done in the html5 wg. A lot of work is still to be done. That does not mean that certain parts should not be used as an add-on for those people who use a browser which will support them. cheers, gary
Sorry for the delay. width:100% when combined with border ends up inside, not outside, default line-height that is LARGER than the specification recommends (it is in excess of 1.2), :hover on non-anchor classes when stuck in quirks mode, inline-block, run-in, compact - the first being buggy as hell in a 'testing' -moz prefix, the other two outright MIA, how about content not overridding the content of tags it's assigned to? Well, the big one that comes to mind off the top of my head is Colgroups/Col - which are pretty much non-functional in Gecko... but from their website we come up with: HTML 4.0 - full support except for: elements: BDO, BASEFONT attributes: shape attribute on the A element, abbr, axis, headers, scope-row, scope-col, scope-rowgroup, scope-colgroup, charoff, datasrc, datafld, dataformat, datapagesize, summary, event, dir, align on table columns, label attribute of OPTION, alternate text of AREA elements, longdesc various metadata attributes: cite, datetime, lang, hreflang bidirectional text layout, which is only used in Hebrew and Arabic (IBM has begun work to add bidi support in a future release) and we wonder why the main branch still doesn't pass Acid2 - and I'll be SHOCKED if FF3 does (even though internal builds do... by cheating BTW) Once you get support for one of the properties in all four major engines in one way or the other, then yes, I can agree to that. Significantly less so in standards mode - where inline-block has worked 'as advertised' since IE 5.x <a href="#" style="height:50px; width:200px; border:1px solid #000;">Test</a> does NOT work in IE when in standards mode, only in quirks mode. IE 5.x and later you have to use inline-block... Which also works perfect in Opera and Safari... So I end up resorting to javascript or 2-3 extra k of code for something that's been in the specs for almost a decade - RIGHT. It is the optimum value, we just need gecko to stop acting like Netscape's sweetly retarded cousin. I disagree when you cannot deploy at least an equivalent to each browser, but that stems from dealing with clients who bitch if any part of the design or some feature is missing in "Fill in the blank" browser...
I haven't heard someone bash FF like that in a while. It's certainly not perfect, but I find it is consistently better than any other browser (excluding Lynx ) Forgive any misunderstandings in my reply, I've got a messed up eye today and your post is very "steam of thought." Putting a width of 100% and then adding borders will push the div outside of its parent elements. The width will be 100% of the parent element with the appropriate borders. How are you saying it should be? You're saying the value of "1" is the equivalent of 1.2+ in another browser? Which browser are you comparing it to? Judging by eye, the sizes are equal between Safari and FF. The only difference is that when not specified, safari defaults to 1.1ish and FF defaults to 1. Can you give code examples of these (or pseudo-code)? How about a code example? I pretty much never use those, but a quick test of <table border="1"> <colgroup span="3"> <col width="20"></col> <col width="50"></col> <col width="80"></col> </colgroup> <tr> <td>1</td> <td>2</td> <td>3</td> <td>4</td> </tr> </table> HTML: shows identical support in Safari and FF. <bdo dir="rtl">This is a test</bdo> HTML: Works fine. I didn't test basefont since that was DEPRECATED in HTML 4 and is not supported in XHTML 1 strict. You should make sure the page you are referencing isn't from 2000. OMG! It doesn't pass a test that is based on failing to follow the W3 standards! Examples that show how FF fails at specific standards are far more useful than the over-quoted Acid2 test. For sites I do for others, I make sure they are usable in at least IE6/7 FF, and Safari (sometimes Opera, if I'm inclined to spend the extra time). For my own sites, I just check in FF and Safari. I agree if "equivalent" refers to reasonable usability rather than appearance.
It should push outside it's parent container, yes. Firefox WILL screw this up from time to time and behave like you'd expect IE to screw it up from time to time - usually on float:right elements inside constraining margins. #content { margin:0 6px 4px 256px; } #content .wrap { float:right; width:100%; border:1px solid #00F; margin-bottom:4px; } Code (markup): By the spec the border should ride into the margin on #content - it does not and instead shrinks. This is actually because FF puts the right edge of a float as outside the border, the spec says inside. No, I'm saying the default line-height - as you'd use in %/em layouts is not the same, which is why you should usually declare your own default line-height. If you DECLARE 1.2/120%, you get 1.2... if you do not declare a line-height, you get anywhere from 1.1 to 1.3 between different browsers as the default. The firefox DEFAULT value is larger than the specification says. You can see that in action at: http://battletech.hopto.org/for_others/font_test.html You'll notice a odd man out on font sizes and the resulting box size. Add align to the equation. Colgroups is NOT fully supported. <table border="1"> <colgroup span="3"> <col width="20" align="left"></col> <col width="50" align="center"></col> <col width="80" align="right"></col> </colgroup> <tr> <td>1</td> <td>2</td> <td>3</td> <td>4</td> </tr> </table> Code (markup): Works in everything except firefox. Width works, background works - Nothing else does. Color? text-align? Forget it. Doesn't work... Which is annoying since text-align is the one I want to use the most. Works all the way back to IE 5.0, Opera 7 and near as I can tell safari can handle it... What does Mozilla tell us to use instead? table td { text-align:left; } table td+td { text-align:center; } table td+td+td { text-align:right; } Which of course is unsupported in IE, and a royal pain in the ass when dealing with trying to show a 20 column spreadsheet on the page. Hmm. That's got to be recent... that's one thing I will say is in FF's favor, it's a moving target so what was true yesterday might not be true today - though one should keep in mind that since you cannot rely on the user actually updating their software (hell, certain linux distro's like SUSE won't even do the main FF branch via the package manager, still using a fork of 1.0.3 unless you actually know how to build it yourself). The old rule, if support for it hasn't been around for more than five years, it's undeployable. Because of course, improper handling of errors is SO desirable. People want to discount acid2 because it doesn't pass the standards - it is AS IMPORTANT to test how errors are handled as it is how valid code is handled. Of course if I had my way browsers would just stop parsing a page and throw a huge error whenever one is encountered instead of trying to correct for it - things would be so much simpler if people were actually forced to write valid code instead of being mollycoddled and let slap any old buggy steaming pile of crap up and call it code. (though it would probably also make WYSIWYG's next to useless given the garbage they vomit up and try to pass off as html) I test all of them all the time these days. The more 'modern' browsers you can support WITHOUT hacks (IE 6 sometimes it's unavoidable - there's NO good reason to hack the others for 99.99% of site designs) the less likely a page is to break in the next 'flavor of the month'. Ah, meaning your layout has a really good chance of being broken to 80%+ of people on the web. Admittedly, I'm overly predjudiced against gecko based browsers because for me ALL of them prior to 2.0 locked up inside 15 minutes normal use regardless of OS or hardware (2.0 lasts about two hours before I have to kill it)... the dimwits at bugzilla were outright insulting and condescending over it, and then one of the developers tried to sell it leaking memory like a sieve as a 'feature' (begging the question why is this feature lacking in other browsers)... Follow that with an outright attack by one of the maintainers for my using the term 'crashed' instead of 'hung' - a distinction I've not heard in three decades of computing... Tack onto that my businessman's distaste for the dirty hippy commies in the FSF and other open source zealots, the endless praise by the press for a browser that has been NOTHING but a thorn in my side.... and, well. **** firefux and the open sores it rode in on. I end up wasting time coding around its LACK of certain bits of the specification (a WORKING inline-block for example) than I do coding around IE's shortcomings. hell, given the way I feel about 'hacks' I almost wanted to punch myself in the face for having to resort to html:not([lang*=""]) a couple weeks ago just to target gecko. Besides, it still resizes 'text' like Netscape 3's epileptic crack addict cousin. (IE7 came close, Opera got it RIGHT, give me a REAL ZOOM) Still that said, coding to all browsers isn't too hard once you learn the various quirks of each (and the rule IE is always wrong)... ALL of the browsers, even gecko based have major shortcomings, incompatabilites and improper behaviors compared to the specifications - relying on any one or even two of them is just asking to end up making more work for yourself in the long run and/or your clients going "I'm not using that guy again!" Or the next person to be hired to maintain a site (like me) going "What the hell? What did you do have a grade-schooler toss this together in Frontpage?"
Sorry for the only partial reply; in a bit of a hurry and I'm flying out of state Friday I think this demo is a little more interesting. All browsers have some differences in either default font sizes or spacing. Any good layout still looks fine when font size is increased or decreased by two notches, so the minor differences between browsers are just that, minor differences. Yup, the align is being ignored. Of course, FF isn't the only browser with incomplete col support. Opera has plenty of bugs too, unfortunately. Well, I'm not a fan of SUSE (or SLES) anyway Ubuntu stays up to date with FF, but I would assume most people running Linux know how to update if they care to. The problem is the majority audience, which varies from site to site, but is still generally IE6 Fortunately RTL text isn't a need I run into. As far as testing how good a browser is, sure, you can test how it handles crappy pages, but from a web designer's/developer's perspective, that shouldn't matter. A page should be made that adheres to the standards so the error handling does not matter. How well browsers handle tests like Acid2 will stay debatable because the expectations aren't always clear. That works for me! It's one of the reasons I like XML. I wouldn't put the figures that high. I do monitor analytics so I can see what people are using, but in my experience, a design that isn't excessively complex (read: poorly done) and that mostly uses common features will work the same in FF, Opera, Safari, etc. IE is the only one that consistently screws things up and IE represents a maximum of 53% on any of my personal sites (and, surprisingly, only 23% on the site I'm redesigning now). I haven't had those kinds of problems, but I can see where you are coming from if that's been your experience. I've had quite the opposite, taking advantage of extensions like Firebug and Web Developer that, together, virtually double my productivity. Personally, I prefer the way FF resizes text. I don't want a zoom. If I wanted everything on the page to change, I would be using em units to specify all sizes, including that of images. Agreed!