It seems that most affiliate programs (e.g. Amazon, Linkshare, etc.) provide non W3C compliant XHTML code fragments. When I use the W3C validator I get hundreds of errors and warnings on any pages that use affiliate links.
Mostly the issues are non-encoded special characters, but there are other problems too.
I'm a bit worried about the impact on SEO, but it also just clutters the validator output and makes it extremely hard to use.
If you use affiliate links, how do you deal with this? Hand-correct the markup?
Does it matter?
Lengthy w3c error reports have no effect on SEO or SERPs if the errors are merely improperly escaped entities within affiliate URLs. I stopped using w3c to validate my pages because the error reports are just ridiculously long, perhaps they need to adjust the tool to ignore affiliate codes. Chrome and IE have debugging tools that are decent and free, just check under the options or tools menu.
Related
I recently installed a Firefox extension and noticed that it was doing something very odd in the background.
I'm a web developer and use Wordpress mainly. One day I was working on a page in WP admin and switched to the Text rather than Visual mode so I could edit some HTML. I noticed a load of junk html in there hidden using display:none
The class names rang a bell, it was the name of the extension I had installed several weeks previous
I immediately uninstalled the extension but of course it was too late. Since it was injecting code right into the text entry boxes in Wordpress, all that junk got saved with my pages. I had to weed through dozens and manually delete this junk, which in some cases had affected the layout.
I contacted the developers, and they gave me some rubbish about it being totally normal, everyone does this sort of thing, its within the Mozilla dev terms, and that it was a feature not a horrific Malware as I was putting forward.
In this case it was just html/css, but what if they were injecting JS/php etc, they could be causing all kinds of damage
I just wondered from a development perspective what peoples thoughts were. Is this legal?
Many thanks in advance
The best course of action is to spread awareness. I would not do here, but maybe write a detailed article explaining which extension it is, what it does, how, why it's bad, how to get rid of it, and alternatives.
Medium, your own blog, Hacker News and other social outlets will certainly be welcoming of such informations. The developers are very well aware of what they are doing so don't expect them to broadcast it and/or take action.
Be also sure to read their ToS again, see what you agreed to. If something seems suspicious you can talk to a lawyer or probably report them, altough this is beyond what I know.
I am a Mozilla Addon reviewer. Please report your findings as Abuse report and/or addon review (it will be read).
Is there anyway to detect old browsers in HTML like the code I use for IE e.g :
<!--[if lt IE 9]>
...
<![endif]-->
I want to show a warning message as some of my web features are not supported for them.Is it better to use a JavaScript to detect this instead ?
Thanks
I finally used the code found at
http://www.php.net/manual/en/function.get-browser.php#92310
by using PHP
Feature detection. Not browser detection.
If you want to warn them about missing web features, why not use feature detection for those specific features, rather than browser version detection?
This has two major advantages:
Firstly, for your code, it has the advantage of making it clear what you're actually doing, and why you're doing it. This will make your code easier to work with in the future.
Secondly, this will allow you to reliably pick up all browsers that don't have the feature(s) you need, which means that if someone visits your site using (for example) and old mobile phone browser that's never been updated, you'll still be able to pick it up and show the correct message, even though you never thought to test for that specific browser.
You didn't tell use which specific features your site needs, so I can't give you details of how to detect it, but you may find the Modernizr library useful; it does feature detection for a wide range of modern browser features.
You may also have the option to add a 'polyfill' to your site to add support for the missing feature to old browsers. Modernizr is good for helping with this, and they also have a big list of polyfills you might like to try.
Many big website (google.com, apple.com, microsoft.com) are never validated. When the big shots don't do it, is there a reason why others should?
w3.org provide a page dedicated to people asking just that question, it's here.
Of course places like Google and Microsoft are there to appeal and should all be consistent across browsers. The w3 does have some good points
Using standard, interoperable markup and stylesheets, on the other hand, offers a much greater chance of having one's page handled consistently across platforms and user-agents. Indeed, most developers creating rich Web applications know that reliable scripting needs the document to be parsed by User-Agents without any unexpected error, and will make sure that their markup and CSS is validated before creating a rich interactive layer.
When surveyed, a large majority of Web professionals will state that validation errors is the first thing they will check whenever they run into a Web styling or scripting bug.
Another very important point is maintenance. A strictly valid XHTML document as much easier to maintain than a bowl full of HTML tag soup. Trust me.
We must remember that the markup is there as a data format. The way a browser renders this markup is what's generally important to a user.
Do remember: household-name companies expect people to visit because of the name and in spite of dreadful websites. Can you afford that luxury?
They are probably validated, but need to support older browsers (like IE6), so comptability-code is added.
Just because someone else doesn't, doesn't mean it's not a good thing. When you validate, you not only find out if your pages are well-formed, but you also track down bugs in your code, make the web pages easier to maintain and your code is more likely to work cross browser as well with future browsers. In addition to this, it shows that you take your job serious and that you have a good habit of trying to generate quality code.
Staying strictly within a known range of syntax (or technologies, in general) is good for optimizing maintenance costs, because all technologies you depend on (browsers in this case) are very well tested for the standard-conforming cases (subset of HTML/CSS/JS) only and are only randomly tested beyond.
I have a small application that will be used by both spanish and english users. The application has about four webpages with various asp.net functions. The database backend is sound.
What is the best approach for the front end / UI? Two websites with the different languages ? A single website with all text in both EN, ES? Or a single website with text appearing in the language of their choosing?
EDIT: This is an ASP.NET application
Two websites with different languages is a lot of maintenance. Any modifications made will need to be done twice. For this reason, as a programmer, I dislike it. However, if the person maintaining the site prefers it this way, then by all means, go this route.
However, if you are looking to provide a proper bilingual solution, you would definitely be better off with a single website instance, with a multilingual data provider.
There is a pretty good one for Wordpress that I have been playing with lately, called LangSwitcher. I have no idea how you have your website setup, or what you are using to develop it. Just throwing out an idea for you.
I'm unsure how to do it specifically in .NET, but a solution is to store the text in a database, and select which language as the page is generated (ideally by either URL (like /en) or cookie setting). Any resources can be stored in "en" and "es" folders, which should use the same logic to select. Then, as long as you're consistent, your translators / graphics people can just look at the raw, un-translated files, translate, put in the proper folder / database location, and viola.
Any number of languages can be handled, easily extending in the future, and it can even handle most language-specific layouts if you do the same with your CSS files. You should be using CSS to do all layout / styling anyway, in part for reasons just like this.
No matter what, you need more than one of every kind of language-specific data, so you're best off using as much text as possible so your graphics people don't have to pull double-duty in addition to the translators. Using CSS to put the text over the image lets you use a single image for any number of languages, and you can do some pretty impressive stuff with just CSS styling of text. If you want to get tricky, and don't mind breaking the site for older browsers, consider rendering things with the <canvas>. Just pull in the language-specific text & definition with Javascript.
In the meantime, there are a bunch of website widgets to do automatic translation, though they obviously don't touch images (another reason to stick with text wherever possible: anyone using a translation tool will be able to read it). I'm personally a fan of Google's: http://translate.google.com/translate_tools
None are perfect, but it's better than nothing.
Jeff mentioned the concept of 'Progressive Enhancement' when talking about using JQuery to write stackoverflow.
After a quick Google, I found a couple of high-level discussions about it.
Can anyone recommend a good place to start as a programmer.
Specifically, I have been writing web apps in PHP and would like to use YUI to improve the pages I am writing, but a lot of them seem very JavaScript based, with most of the donkey work being done using JavaScript. To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
Anyone have some good places to start using this idea, I don't really care about the language.
Ideally, I would like to see how you start creating the static HTML first, and then adding the YUI (or whatever Ajax framework) to it so that you get the benefits of a richer client?
As you've said
To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
This isn't progressive enhancement. Progressive enhancement is when the site works perfectly without JavaScript or CSS, and then adding (layering) these extra technologies/code to increase the usability and functionality of the website.
The best example I can give is the tag input box on this website. With JavaScript turned off, it would still work allowing you to enter tags separated with a space. With JavaScript turned on, you get a drop down with suggestions of previous entries.
This is progressive enhancement.
See also Unobtrusive JavaScript which is the bedrock progressive enhancement is built.
Going at it from the other direction is sometimes referred to as graceful degradation. This is usually needed when the site is built first with the enhanced functionality afforded by the various technologies then modified to degrade gracefully for browsers with those technologies are not available.
It is also graceful degradation when designing to work with older browsers (ancient in the Internets terminology) such as IE 5.5, Netscape, etc...
In my opinion it is much more work to gracefully degrade the application. Progressively enhancing it tends to be much more efficient; however, sometimes the need to take an existing app and make it accessible in these lacking environments arise.
Basically, if your site still works with JavaScript turned off, then anything you add with JavaScript can be considered progressive enhancement.
Some people may think that this is unnecessary, but plenty of people browse with addons like NoScript (or, with JavaScript simply turned off in their browser settings). In addition, many Mobile web browsers may or may not support JavaScript. So, it's always a good idea to test your site completely with and without JavaScript.
Progressive Enhancement is a development technique that stresses the primacy of the semantic HTML, then testing for browser-capability and conditionally "layering" on JavaScript and/or CSS enhancements for the browsers that can utilize those enhancements.
One of the keys is understanding that we're testing for what the browser can do, as opposed to browser-sniffing. Modernizr is a very popular browser-capability test suite.
Progressive-Enhancement is inherently (section 508) accessible; it provides for meeting the letter of the law and the spirit of the rule.
The Filament Group wrote the excellent "Designing With Progressive Enhancement" book on the subject. (I am not affiliated with Filament Group, though they are so freaking smart I wish I were.)
This is such an important concept and it saddens me that so few web developers understand it.
Basically, start by building a site/framework in Plain Old HTML -- structural elements, links and forms. Then add on some style and then shiny stuff (Ajax or what have you).
It's not very difficult. Like palehorse says, graceful degradation is more work.
Websites should work in any user agent, not look the same (not even look but sound if your vision impaired), just work.
Progressive Enhancement:
The plain HTML/CSS site is awesome (fully working and user-friendly).
Adding JavaScript defines a new level of awesome.