As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I heard Joel and Jeff talking about sIFR in one of the early podcasts. I've been using it on www.american-data.com and www.chartright.us with some fairly mixed results.
Yesterday I was informed that the first line of text on my website appeared upside down in Internet Explorer 6 without flash player. I'm pretty sure that assessment was wrong, owing to no flash player = no sIFR. But I'm getting some odd behavior on my pages, at least in IE 6, 7 and 8. I only really wanted to use sIFR because my fonts looked crummy on my computer in Firefox.
My question is: if you use sIFR, when do you use sIFR? In which cases do you disable sIFR? When is it better to just use the browser font?
You use sIFR moderately, say for headlines. Try not to use it for links, because links in Flash don't work as well as normal HTML links. It also makes little sense to use sIFR only for text that never changes, an image would work a lot better.
I haven't heard about the upside-down problem in a few years now, but in any case, that's an issue with IE 6 and (an old?) Flash player. In any case, it always makes sense to test thoroughly.
Also, did you look into sIFR 3 lately? It's much improved over v2.
I had plenty of headaches after implementing sIFR on my last website project. Most of the problems were to do with browser inconsistencies like you are describing. Text would appear in odd places, not wrap properly or just not display the way I wanted it to. I found that, as per usual, firefox was displaying nicely while I had to implement several different css hacks in order to get the same code to display properly in IE7 and IE6.
I say stick to standard browser fonts if you can, but if the project / client requires you to use it then make sure you test it thoroughly in all browsers and with various flash blockers etc.
Try to consider up front what kind of headache you're creating for yourself (if you are, which isn't always the case) by implementing sIFR. It's probably advisable to only use it when your site design is relatively straightforward. As soon as you start having to deal with specific browser rendering exceptions (CSS, for instance) due to a complex design, you're going to run into problems related to sIFR. And if you design sites for clients, it's tough to go back and tell them halfway through that sIFR is going to have to be removed. So try to identify issues up front.
One example we ran into was having sIFR titles, and then directly to the right of the title, say about padding-right: 20px (so, dependent on the width of the title text), some kind of icon. That led to a lot of hassle, making us wish we hadn't started using sIFR in the first place.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've started learning and researching HTML5, I only ever studied HTML classic some 6 years ago and I never got quite far with it.
I want to build a website and publish it to the WWW.
Should I stick with HTML4 for now? Or should I just jump straight into HTML5?
I've read & I understand that a lot of the new elements are not supported, but I feel a bit stupid to type outdated tags. Are HTML5 elements more supported in 2013?
Is it better to just start with 5 now, as the future is HTML5?
I've also started doing CSS3 and I think it would benefit me rather than CSS2.
Thank you everyone.
I suggest you give "The truth about html5" a read if you have the time.
Html5 so to speak offers a lot of new stuff. But the reality of the market is a bunch of stuff either just plain works with a handful of browsers, and other stuff has been around for years and simply got included under the so to say html5 branding.
Also keep in mind that ie8 still represents a huge piece of the pie of the ie landscape and will do so for years to come. In the end it all comes down to what your project target audience is and how many percent of users you are willing to sacrifice or allowed to sacrifice.
Caniuse.com should be of good use to you, and understanding when and how too use polyfills too.
Myself I manage a big site which uses a bunch of html5, css3, and responsive design that scales from mobile phones to tablets to desktops, and works just fine in ie7 too.
But it didn't suffice to say hey let's code it in html5, but instead took a lot of reflection and compromises to get there.
So actually my answer would be: use the parts of css3 that degrade gracefully as much as you like. The parts of html5 that you find indispensable ..at the condition you have a fallback polyfill in place. And the rest ..think 20 times before jumping on the buzzword bandwagon.
In the end you don't even have to choose between html4/5 or css2/3. You can mix and match both easily .. as the latter simply build on the previous. As long as you know what you are doing, and why.
But yes learn it !
You should code your website in a language that meets your website's requirements.
What I mean by this is if your proposed website will include features of html 5, then you should write it in html 5.
You could most probably achieve the same or a similar effect using html 4, but why go to the bother when html 5 has built in features to help you.
I personally would use html 5 anyway as you are essentially future proofing your project for some years to come.
Also use CSS3 but just check the availability of rules in browsers.
Hope this helped.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been reading a lot of stuff about HTML 5 recently. Something still looks very fuzzy to me and I hope somebody can help me understand it better.
Is HTML 5 for the "technology" to create the UI only? If I need to create an application to access bank accounts, how is it possible that HTML 5 will replace all other technologies? I mean there must be some kind of web service that the application has to use to access the data on the server and I can't see how that piece can be done with HTML 5.
As with any new technology there is always a lot of speculation from commentators who don't really understand it... It always made me chuckle when I heard people talking about sites being 'Web 2.0' or 'Ajaxy'
Put simply:
HTML5 is just the same old html which we've been using since the nineties but with some improvements from HTML4&XHTML1. There are a few new tags, some of which aren't even new they've just been standardised.
HTML5 provides native support for many features that used to be possible only with plugins or complex hacks (a native drawing API, native sockets, and so on). Plugins, of course, present problems:
Plugins cannot always be installed.
Plugins can be disabled or blocked (for example, the Apple iPad does not ship with a Flash plugin).
Plugins are a separate attack vector.
Plugins are difficult to integrate with the rest of an HTML document (because of plugin boundaries, clipping, and transparency issues).
Although some plugins have high install rates, they are often blocked in controlled corporate environments. In addition, some users choose to disable these plugins due to the unwelcome advertising displays that they empower. However, if users disable your plugin, they also disable the very program you’re relying on to display your content.
This is where HTML5 comes on the scene, smiles, and waves its magic wand of native functionality. You can style elements with CSS and script with JavaScript. In fact, this is where HTML5 flexes its biggest muscle, showing us a power that just didn’t exist in previous versions of HTML. It’s not just that the new elements provide new functionality. It’s also the added native interaction with scripting and styling that enables us to do much more than we could ever do before.
Take the new canvas element, for example. It enables us to do some pretty fundamental things that were not possible before (try drawing a diagonal line in a web page in HTML4). However, what’s most interesting is the power that we can unlock with the APIs and the styling we can apply with just a few lines of CSS code. Like well-behaved children, the HTML5 elements also play nicely together. For example, you can grab a frame from a video element and display it on a canvas, and the user can just click the canvas to play back the video from the frame you just grabbed. This is just one example of what a native code has to offer over a plugin. In fact, virtually everything becomes easier when you’re not working with a black box. What this all adds up to is a truly powerful new medium.
HTML 5 is indeed markup and JavaScript APIs for the browser. It isn't intended to access data on servers.
But it's rarely used on its own.
CSS adds style to content.
JavaScript makes client side code dynamic.
AJAX allows you to make asynchronous calls to services to get data, keeping your UI responsive.
Yes, you still need services.
HTML 5 replaces earlier versions of HTML, nothing more.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I found this W3C proposal for CSS variables and was wondering if any modern browsers (i.e. IE7+, Firefox 5+, Chrome) implement them yet?
As of this week, WebKit -- which is used by Safari and Chrome -- will be working to implement CSS variables.
http://trac.webkit.org/changeset/120154
https://developer.mozilla.org/en/CSS_Reference
This is a reference to MDN - they do a pretty good job of listing known browser compatibility. What is/isn't possible is going to be dependent upon each individual css rule. The world of web development would be a lot easier if everything followed the specs perfectly; but that is rarely the case. The #variables rule you referenced isn't listed there, so I'm guessing you're out of luck. Though there are a lot of mobile browsers coming out as people keep buying newer phones - so you might find somewhere that can use this out in the wild world of mobile browsers.
I don't know of any browser that uses CSS variables like that. The W3C document you linked was only a proposal, not a standard. Even stanards take a while to get full support in browsers, so I'd imagine widespread implementation is a ways off regardless.
If you want that sort of functionality though, you can look into something like LESS or Sass.
Variables are listed as "working draft" in CSS3, or "exploring phase" which means there is no agreement how best to implement it, or even if it should be.
Browser support will be constantly a moving target so the answer "No" is difficult to stake and still be accurate when you read this. Variables aren't even listed on most browser comparison charts (March 2012)
This is not standard in most browser rendering of CSS, it may be part of a working group for the css3 spec though I do not believe I have seen mention of it previously.
It is possible to achieve this kind of effect with the addition of other libraries, the one I am most familiar with is called less CSS which supports some cool stuff like variables and nesting rules but it works by translating that to long form CSS.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
It is said that the unreleased HTML 5 and CSS 3 can produce the effects and graphics which can be done in Microsoft Silverlight. It thats true then can I skip learning Silverlight and wait for HTML5 and CSS 3?
Silverlight is a tool for developing web applications (RIA - Rich Internet Applications).
Pure HTML+ CSS (even if it is HTML5 and CSS3) will only produce web sites unless you put some code/framework behind them.
Therefore while visually they might look similar they are two completely separate things behind the scenes.
It's like comparing apples and oranges, but one thing is makes HTML 5 + CSS better then Silverlight: It runs on every modern browser, mobile device, etc...
You don't need to wait for HTML5 and CSS 3, they are here today and can be used right now. Web standards aren't 'released' in the way software is, they are standardisations of existing browser implementations.
What front-end technology you choose very much depends on project requirements, some things that are easy in Flash/Silverlight are just not possible yet or really hard to achieve using web standards (think Canvas and WebGL).
There is no definitive answer for this, and there may never be.
HTML5 + CSS + JavaScript, you mean? The future of RIAs does look bright given the promise of these technologies; however, they do not likely represent a replacement for Silverlight right now. If you need to build a complex web app now, Silverlight can do it, and even though some browsers like Chrome, Safari and Firefox have already implemented parts of HTML5, the support is too jagged to allow you to build a stable cross-browser application.
Silverlight, however, should behave the same way in all browser on all OSes.
if you use silverlight (and/or flash) only for a nice layout and some stuff like animations, yuo don't need it - this can be done with html5/css3 only.
but note that silverlight (and/or flash) give your a lot of possibilities to write applications witch can do a lot more stuff.
The only reason I prefere to use Flash/Silverlight over HTML+JS+CSS is, they run pretty much similarly on all platforms and they are independent of browser's code, although html has some standard but coders dont have any standard, similar functionality needs different javascript in different browser, more over rendering html elements is also different on different browser so does printing.
No matter HTML5 or HTML 10 coming in future will attract developers, but not implementing correct standards by OS and browsers will always make them weak enough.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm talking about these.
Yeah, I know they are intended to show that the page conforms to the standards and should link to page revalidation service. Ok. But why should I as a regular user bother with this? As a visitor I'm indifferent to whether the page is strict XHTML or not, whether it contains dirty IE hacks or not. It is important that a page renders correctly, is convenient and works fast. That's all! And in reality, in many cases these requirements don't get along with W3C standards smoothly.
So what is the mania to add something targeted toward developers to a product face? Am I missing a point?
It's not a selling point like the "Be Safe With " type tags.
Including the w3c badges are a way to show that you know that there are standards that should be followed for web page construction. It's a way of showing that you want to be courteous to all users no matter the browser and to help promote the idea that browsers should implement, at least, the standards.
It's also a way to educate your readers. Not everyone knows that these standards exist or why they exist. Educating your readers will hopefully empower them to find a browser that fits their browsing expectations and to raise those expectations above "show me some images from 4chan."
Though, at the end of the day, it usually turns out to be another way to put things on a website because you lack the artistic savvy to make things look good without putting 'stickers' all over something.
It´s weird but virtual medals do work. It´s no coincidence that SO has rep and badges.
There are plenty of sites with important text that is missed by my browser because I don't use the browser that the author of the page used. If I see one of these badges then I can be confident that all of the page is rendered.
It is important that a page renders correctly, is convenient and works fast. Thats all! And in reality, in many cases these requirements don't get along with W3C standards smoothly.
You don't think these are conflicting ?
I would take the validated page over the "with hacks for every browser" page any day.
It matters to no one, including potential employers and other developers and especially not to users. I've seen pages that do NOT validate despite the badges, and valid markup only means the syntax is correct but does not mean it's well designed, laid out, formatted, well thought out, flexible, usable, or of any interest to anyone else. I'll look at the markup to see what the author has done and that is what counts.
It's just a way to show your technically competent users that you are technically competent. They have no other reason to be. I try to validate always, but never put them. If I had a blog, I might put them in the about section.
It's just bragging rights. Same as any badge/award implementation. Sure, it doesn't really matter to 99% of your visitors, but it might matter to you, the developer.
You do not need the badges. When they are present however, they indicate for you that all modern browsers will render the page [almost] identically.
An example: they give the user a confidence that when he goes back home (at office he is forced to use Mac OS X, but has Windows at home), the page will still display properly for him. Nothing critical, but sometimes really important to know.
As a visitor I'm indifferent to whether the page is strict XHTML or not, whether it contains dirty IE hacks or not.
Well, if you are using Safari and the site only works with IE because of "dirty IE hacks" then for you, the site is broken and useless. Likewise, if you are an IE user, and the site is full of "dirty Firefox hacks" then the site will be broken for you as well.