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.
In an attempt to understand if W3C validation can assist better DOM rendering or if it is just a standard for HTML coding, I tried to validate major websites but all of them fail with some errors.
Here are typical examples:
google.com 36 Errors, 2 warning(s)
facebook.com 42 Errors
youtube.com 91 Errors, 3 warning(s)
yahoo.com 212 Errors, 8 warning(s)
amazon.com 510 Errors, 138 warning(s)
When major websites do not seem to spend enough time for W3C validation, is it needed to spend time to do so for small- and medium-sized websites?
Validation is a sore issue. In XHTML days (pre html5 doctype ubiquity) it was almost impossible to validate a complex layout against the strict DTD published by the W3C. I think you could probably point fingers at IE for being the prime culprit, as so many totally non-standard hacks were needed to make it behave in a reasonable cross-browser way, and IE was and is the most-used browser on the planet. It is to be lamented that MS, instead of following the lead given by webkit and gecko engines, have decided to add yet more browser extensions and hacks to muddy the waters, instead of going for plain adherence to the 'standards'.
We all know that if time were not an issue, we as developers could create pages that validate, but in practical terms, as the others have pointed out, validation ends up being a helpful tool not a defacto objective. If a client demands validation, then there is a cost involved, and that has to be explained - managing the expectations here is very important.
The html web advanced in very short time from being a very simplistic semantic text layout engine to fully dynamic applications running inside the browser, and the validation tools simply have not kept up with this. I'm not even sure they can, given that browser technology is advancing daily, across a thousand or more different platforms.
So - rounding up, it's a tool to be used by developers, but your own personal ability is what will determine if the project is fit to purpose or not. Having an icon or green 'ok' box in a validator is absolutely not going to define if a project fits this definition or not.
Validation is cheap quality assurance. It will help you spot errors (especially nesting errors and those those caused by mistyping something). It will save more time then it costs (especially if implemented at the outset).
I've not seen any performance metrics for error recovery routines in browsers. It would be hard to produce any which would give useful information as there are so many different errors.
In my opinion the best reason why you should validate your pages, is that then you have the highest probability that your page looks the same in every browser. And you minimize the probability that the layout (or even some Javascript logic) is broken.
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 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.
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 think most template engines are hard to use for designers and front end developers leaving you, the programmer with the burden of maintaining them.
And frequently updating the templates after the designer updates the html mockup is a nightmare because your templates are no longer compatible with the original htmls.
I had this problem for very long time, recently I had an idea, but I don't know if I'm not reinventing something or if something better exists.
So, I'm asking if you found better solutions for this problem and if so which one?
Since I've switched to full separation of content from presentation, I've never looked back, and here's why:
Your business logic becomes very clear. Without HTML tags and presentation logic mixed in, the code takes ½ the space and less than ½ the time to maintain. The burden of maintaining the link between code and presentation can be mitigated by specifying a formal interface between the two, even as a text file or a Wiki note, listing all the variables and values presented to/required by the presentation layer.
Frequently updating the templates from designer's changes means that your presentation layer should be sub-divided to various "blocks", such as menu block, page layout block, and content block. On most pages, only the content block is different. When properly divided and implemented using CSS and other modern web techniques, reasonable changes in design will have minimal impact on your presentation code.
CMSes automate this process even further, and are now at the point where even 5-10 page sites can benefit from using a CMS vs. hand-coded HTML from both consistency and ease of support perspectives.
Code security - Smarty is not PHP, so your designers can have a lower level of trust on the site (they can't mess with the underpinnings too much, although they can mangle the presentation to the same effect as a DoS would have, so don't mess with them anyway); if you don't care about security that much, PHPTal and others run almost at "native" speed.
As for my working solutions, I have two recommendations:
Develop a projectwide folder structure and naming convention, and stick to it. Given a name of your business logic file, I should be able to tell you what the presentation files are, and vice versa.
Have an explicit interface spec (again, a text file or a Wiki entry is all you really need) between business logic and presentation. Knowing which vars are available, and how they should be (programmer) / are (designer) formatted, makes both of them very happy when they have to maintain the page a year later.
Yes, but only if they are as close to Native HTML as possible.
Dreamweaver templates (ignoring the editor) basically accomplish this pretty well since they basically markup a plain old HTML (POH™) page with some HTML Comments.
I personally like how some CMS solutions enable me to break my templates into very small pieces. SiteCore does this well through placeholders and renderings which map to usercontrols.
I've also used UserControls heavily in the past to break out common functionality like login, menu, footer links, etc to make it easier to modify or replace functionality in the future. (ASP.NET)
What template-engines are you using? Something like Smarty for PHP?