Then there's Digg; Digg's pages are such a load on the visitor's CPU that I have to click "script not responding, continue?" three times on a page with 800 or so comments with Firefox and a dual-core 2 GHz CPU just to get the page to completely render.
Sounds like Digg is attaching events to every show/hide link instead of using event delegation and using only one event listener. Browsers can't really handle hundreds of attached event listeners, it is a known performance issue.
Now using event delegation instead of attaching hundreds of events should definitely be in a set of web development best practices.
The answer is by no means clear and besides, if the European Union does manage to seriously affect Microsoft's bottom line, they'll just try to make up the lost profits here in the States
That might be a good thing for US people to pay about the same price as people in the UK. Take for example Vista which costs UK purchasers twice as much as US purchasers( see here ). I guess most of the EU is subsidising low US prices, so it would be a good step to eliminate that subsidy, and stop gouging those profits off EU residents.
Nominet even make it a policy to dissuade domain spammers from registering expired domains:
This is a red herring. A spammer (or domain squatter) know that a domain name will expire in a certain period, so they just run a cron job to check the status of the domain every 15 minutes or so, and register it if they find its available. That's what they do with expiring.coms. Yes its a bit riskier with the.co.uk of another spammer sneaking in, but a spammer will be able to grab the domain name before a good faith buyer can, just as easily as in the.com arena.
Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)
on
CSS: The Definitive Guide
·
· Score: 2, Informative
There are elements of CSS that are quite functional and workable, but for the most part its just a cludge and a bad one at that. Lets take for example something that could make all of our lives easier, the basic ability to have include files. All you CSS lovers hate frames and you hate tables. Well with frames I can make ONE file contain the entire drop down menu section. I create it in one file and ONLY one file. I edit it in ONE file and ONE file only.
CSS isn't a content language, its a styling language. A styling language that relies on the underlying semantics of the markup language you are using.
Of course, using SSI means using a webserver and configuring it properly. Even decent shared hosting gets that right. Might not work on Geocities though, but HTML preprocessing will.
I am SO going to get a contract job writing acessible versions for p0rn sites!
Although your comment does sound tongue-in-cheek, you're already too late. The (Not safe for work) Sounds Dirty porn site is already accessible, and its already been tested by a well established disability organisation. Content accessible to screen readers and screen magnifiers. And there's definitely a market for it.
But there's an important issue of scale. Compared with how many users overall use a site like target.com I imagine the percentage who would require special consideration in the design is pretty tiny. So in reality the site operators would lose money - but not much - probably less than it would cost to do a redesign.
What you've left out are the number of people who benefit (as opposed to require) from the special consideration. What's typically happened on websites that have been made accessible (from small businesses right up to FTSE100 companies and public organisations) is that making websites accessible also provides a far easier website for all people (disabled or non-disabled). Its not uncommon to see convesion rates of shoppers to increase by 100% to 250% because of the launch on an accessible website. A FTSE 100 company, for instance, made back the investment into making their websites accessible within five months.
Because the situation today is the same as that of 100 years ago? The majority of people think racism is bad. They would not shop anywhere that practiced it.
So your solution to disabled people being discriminated by Target on its website is to... wait 100 years? At which stage the majority of people will think that disability discrimination is bad, and non-disabled people will decide not to buy from Target, thus putting them out of business?
Do you think we should do something in the meantime? We've got plenty of time till then.
If the disabled person can't access your website but still could come to your physical store then I see no harm done. They can still access your goods, so that is all that should matter.
Well actually they can't - particularly a blind person. Visiting a physical store presents a multitude of different barriers to overcome. Have you noticed that most of the items in a physical shop don't have their product names braille labelled (let alone the list of ingredients)? Getting to the store and moving around it is only a tiny part of the real problem.
I suggest the next time you do some food shopping by yourself, get to the store first (Just to make it much much easier for you), blindfold yourself and walk around getting all the items on your shopping list. That will give you a partial impression of what its like.
Now a website, properly done, can alleviate all those barriers - at a staggeringly smaller cost. In terms of return on investment, an accessible web site outdoes physical premises - for both the business and the customer. Accessible websites and home delivery are a boon to disabled people (as well as non-disabled people). With an accessible website, a blind person can do their regular shop without needing to inconvenience other people - its a means of self-sufficiency. What was once an arduous task is now something that can be completed successfully from their own homes - providing Target had done two really simple things.
If they will only gain $100 in profit, (not sales) from making their stuff accessible, and they would have to spend $1000 to make it accessible, then they should be free not to make their business accessible.
And yet, back in the real world - a large FTSE-100 listed financial services company made their website accessible. They made back the money spent within five months. What they saw was a minimum 100% increase in the number of sales, with different products conversion rates doubling or tripling. The number of people arriving to purchase went up over 30%. The return on investment for making websites accessible is there.
They have a large amount of fabric online you can buy. It's just pictures and sku numbers. There's not any text descriptions. Why? Well that takes time to write, time they don't have.
Sounds like a very search-unfriendly site. Adding descriptions - which would certainly help people relying on screen readers - has a knock on effect of those descriptions being indexed on search engines. This has the benefit of bringing in targeted traffic to the website - of people looking for a particular fabric. An immediate 30% boost in natural search engine traffic is not uncommon when making websites more accessible.
One of the most common arguments I've heard in favor of accepting CSS as the cure-all of website design is that it if you use tables instead, blind people will be inconvenienced by your site.
Its a nice sound bite - but, in practice, tables for layout aren't that much of an accessibility barrier. Screen readers today can ignore table markup - they've had to adapt to the bad markup practices and short comings of web designers and web developers. But there is a limit to what they can do, and its certainly not equitable for screen reader vendors to have to make up for web designer deficiencies and ignorance.
Part of the problem of tables for layout is when you also use tables for tabular data. Answering the question of is this table a data table or a layout table isn't straightforward with screen readers. Ignoring layout tables helps, but ignoring the structure of data tables can create an accessibility barrier, since there's typically a two-dimensional relationship (or more, if you have subheadings and complex tables) described by the table markup - that is necessary for screen reader users to access the information. The data without the semantic structure is difficult to digest.
The main benefit to accessibility of CSS is that it encourages a consistency of markup across a websites. This consistency offers benefits like:
since the navigation always starts at the same place in every page of a website, it can be skipped to (or over) easier than if a screen reader user needs to plough through the entire document every time. Consistency is a key requirement for highly accessible websites.
If the styles of the CSS are proving to be a barrier (colour contrast or text sizing), the CSS can either be removed, or overridden by a user stylesheet.
The helpful benefit to accessibility of CSS lie in the simple fact that the separation of structured content and presentation allows a visitor to remove the presentation if that creates an accessibility barrier that must be overcome before the information can be read. That simply cannot be easily done when there's font tags all over the document.
For CSS to be a benefit to accessibility, it needs a well structured and semantically descriptive document to work from. There's little accessibility benefit in marking up HTML with just div and span, and then styling that. The structure of an HTML document is important to accessibility, and thus, not damaging the real structure of an HTML document by using layout tables is certainly helpful in that regard.
That part is insane and I hope in the next couple of years we see a proliferation of fully CSS compliant browsers. I mean, that's the whole point of standard in the first place. Even Firefox doesn't fully implement CSS correctly, and I'm not sure why.
Full support of CSS isn't necessary for the production of CSS designed websites. It just needs to be good enough - which is where we already are. Its the same as not needing to know every word in the English language in order to have a conversation.
This seems like a problem that could very easily be solved by one perfect piece of screen reading software.
The biggest problem is the classical case of Garbage In - Garbage Out. The vast majority of pages out there on the web have no logical structure, no text equivalent content to non-text content - there's no way a piece of technology can do that without an advanced form of AI.
This isn't a problem browser and assistive technology vendors can solve on their own. This isn't a problem web developers can solve on their own. Each have to pull their weight to get the job done. Web developers need to be using structured markup, and providing alternate equivalent content when content is inside a non-text format. Assistive technology vendors can then improve their tools to render your content in a better way to the tool user.
I think users who are disabling JavaScript are already doing themselves more harm than good.
A website should work without JavaScript - that's the whole point of a webstandards based approach to website design. If a site requires JavaScript to provide access to data, it is fundamentally broken.
Its amusing that AJAX is promoted as a means for making websites more usable, but surely this should not be at the cost of its accessibility?
Nothing wrong with building AJAX based applications, just make sure you do it properly and offer the equivalent core functionality without requiring JavaScript. Its called progressive enhancement, or Hijax. (Note, drag and drop widgets are not core functionality, core functionality is about completing the task the website is intended for, e.g. purchasing a book.
Yet another one of Sys-Con's online publications people should avoid for various reasons.
Hmmm, thanks for the reminder. They are the ones that did the hatchet job on Pamela Jones of GrokLaw. I actually was scanning through the website above looking for a subscription to this "Ajax developer" this morning, couldn't find it (saw a reference to an AJAX article written by Maureen O'Gara - name was familiar, but I didn't remember why).
I was going to try again later. I guess not now. Thanks.
I'm on the continent of Africa (I was born here), thus I am an African, a South African, to be more specific.... We are not complete neanderthals.
Quite right. What impresses me most about the Computer Science graduates from South Africa is the number of them working in the US, Canada, UK and the rest of Europe, and they are quite successful - and they are consistently impressive compared against similar graduates from the US and UK. Not to mention that US and UK institutions turn to Africa to hire people that their own education system cannot provide.
Even Nigeria produces outstanding quality of developers - Dare Obasanjo, once the XML Product Manager for Microsoft, now works on MSN spaces and Hotmail (and also the developer behind the RSS Aggregator RSS Bandit) - technically excellent.
And of course, Mark Shuttleworth, the brains behind Thawte - the first recognised SSL certificate provider (sold to Versign for millions after running for years from Cape Town). Been to space and back, and now the main driver behind Ubuntu, which is now recognised as one of the better Linux installations out there.
Even IBM UK are realising the technical proficiency of their operations in South Africa - they are in the process of migrating their mainframe support operations to South Africa. I've had the pleasure of working with these South Africans - these guys are very impressive.
Microsoft Nigeria's comments are laughable, but understandable in its prolonged and largely unsuccessful fight against Open Source.
As I recall he was mostly convicted for telephone- and creditcard fraude. Which makes him a common thief, not (his words) the 'Osama bin Mitnick' of the hackercommunity.
Not without the RSS parser needing to guess whether the content is plain text or html. The existence of a less than sign or greater than sign is not a definitive sign that the content is HTML. The RSS2.0 specification makes no mention of how to handle content - it might be text, or it might be HTML (sorry, no XHTML).
When your parsing the feed and the content contains the following:
Todays topic is the <br> tag which forms the cornerstone of HTML.
Is the content to be treated as plain text, or as HTML? Its very difficult to know, and even today RSS2.0 gives no way of allowing the author to specify. The aggregator has to guess. With Reuters, aggregators guessed wrongly.
It's working it's way through the IETF, if I understand right.
The Atom Syndication Format - the feed format - got signed off as a Proposed Standard last week. That means the RFC number is on the way. Its here. The publishing protocol still has some way to go yet.
Atom is more complicated than RSS 1.0, which is more complicated than RSS 2.0.
I don't know how you've come to the conclusion that Atom is more complicated than RSS1.0, other than to say that you'd be the first person I've ever seen saying that.
RSS2.0 is simple up to a point - for instance if you are publishing plain text entries with no angle brackets then you should be okay (or if you don't mind silent data loss). If you want to mark up your content with XHTML, with RSS2.0 you are out of luck unless you define an extension, and then hope aggregator developers pick up on it and implement it.
Atom cleanly specifies how to have content as plain text, HTML, XHTML, XML, or even a different media format altogether. RSS2.0 leaves you with plain text, or HTML.
Yeah, you're right that it has nothing to do with sales, but you're wrong that's it just because "they can." They do it because "they make money."
As I understand it, spammers make their money by charging business a fee for sending out spam on their behalf. That way, the spammer gets a prenegotiated upfront fee, and not a fee based on sales resulting from the spam.
I guess the problem is that businesses are falling for the myth that because spam is prevalent there must be sales in it - so they co-opt a spammer's services. How many businesses are repeat buyers of spam services?
According to the article, a joint statement included a statement from Richter that he is not a spammer. So why settle for $7 million? Is that a desperate move on Richter's part, or a result of a calculation that court costs would far outweight the paltry $7 million?
Slashdot Mirror
Thursday. I was off sick yesterday.
Custom Events are your friend, and a sound basis for designing any complicated user-interface or series of interactions: http://developer.yahoo.com/yui/examples/event/custom-event.html So your problem above boils down to:
Another good writeup of custom events is: http://nefariousdesigns.co.uk/archive/2007/07/ajaxevent-using-yui-custom-events-with-ajax/
Sounds like Digg is attaching events to every show/hide link instead of using event delegation and using only one event listener. Browsers can't really handle hundreds of attached event listeners, it is a known performance issue.
Now using event delegation instead of attaching hundreds of events should definitely be in a set of web development best practices.
CSS isn't a content language, its a styling language. A styling language that relies on the underlying semantics of the markup language you are using.
Your problem has been solved over a decade ago:
Of course, using SSI means using a webserver and configuring it properly. Even decent shared hosting gets that right. Might not work on Geocities though, but HTML preprocessing will.
Although your comment does sound tongue-in-cheek, you're already too late. The (Not safe for work) Sounds Dirty porn site is already accessible, and its already been tested by a well established disability organisation. Content accessible to screen readers and screen magnifiers. And there's definitely a market for it.
What you've left out are the number of people who benefit (as opposed to require) from the special consideration. What's typically happened on websites that have been made accessible (from small businesses right up to FTSE100 companies and public organisations) is that making websites accessible also provides a far easier website for all people (disabled or non-disabled). Its not uncommon to see convesion rates of shoppers to increase by 100% to 250% because of the launch on an accessible website. A FTSE 100 company, for instance, made back the investment into making their websites accessible within five months.
So your solution to disabled people being discriminated by Target on its website is to ... wait 100 years? At which stage the majority of people will think that disability discrimination is bad, and non-disabled people will decide not to buy from Target, thus putting them out of business?
Do you think we should do something in the meantime? We've got plenty of time till then.
Well actually they can't - particularly a blind person. Visiting a physical store presents a multitude of different barriers to overcome. Have you noticed that most of the items in a physical shop don't have their product names braille labelled (let alone the list of ingredients)? Getting to the store and moving around it is only a tiny part of the real problem.
I suggest the next time you do some food shopping by yourself, get to the store first (Just to make it much much easier for you), blindfold yourself and walk around getting all the items on your shopping list. That will give you a partial impression of what its like.
Now a website, properly done, can alleviate all those barriers - at a staggeringly smaller cost. In terms of return on investment, an accessible web site outdoes physical premises - for both the business and the customer. Accessible websites and home delivery are a boon to disabled people (as well as non-disabled people). With an accessible website, a blind person can do their regular shop without needing to inconvenience other people - its a means of self-sufficiency. What was once an arduous task is now something that can be completed successfully from their own homes - providing Target had done two really simple things.
To protect the rights of real people from being trampled and disregarded by businesses and government organisations.
And yet, back in the real world - a large FTSE-100 listed financial services company made their website accessible. They made back the money spent within five months. What they saw was a minimum 100% increase in the number of sales, with different products conversion rates doubling or tripling. The number of people arriving to purchase went up over 30%. The return on investment for making websites accessible is there.
Sounds like a very search-unfriendly site. Adding descriptions - which would certainly help people relying on screen readers - has a knock on effect of those descriptions being indexed on search engines. This has the benefit of bringing in targeted traffic to the website - of people looking for a particular fabric. An immediate 30% boost in natural search engine traffic is not uncommon when making websites more accessible.
The Prototype JavaScript library.
Its a nice sound bite - but, in practice, tables for layout aren't that much of an accessibility barrier. Screen readers today can ignore table markup - they've had to adapt to the bad markup practices and short comings of web designers and web developers. But there is a limit to what they can do, and its certainly not equitable for screen reader vendors to have to make up for web designer deficiencies and ignorance.
Part of the problem of tables for layout is when you also use tables for tabular data. Answering the question of is this table a data table or a layout table isn't straightforward with screen readers. Ignoring layout tables helps, but ignoring the structure of data tables can create an accessibility barrier, since there's typically a two-dimensional relationship (or more, if you have subheadings and complex tables) described by the table markup - that is necessary for screen reader users to access the information. The data without the semantic structure is difficult to digest.
The main benefit to accessibility of CSS is that it encourages a consistency of markup across a websites. This consistency offers benefits like:
The helpful benefit to accessibility of CSS lie in the simple fact that the separation of structured content and presentation allows a visitor to remove the presentation if that creates an accessibility barrier that must be overcome before the information can be read. That simply cannot be easily done when there's font tags all over the document.
For CSS to be a benefit to accessibility, it needs a well structured and semantically descriptive document to work from. There's little accessibility benefit in marking up HTML with just div and span, and then styling that. The structure of an HTML document is important to accessibility, and thus, not damaging the real structure of an HTML document by using layout tables is certainly helpful in that regard.
The biggest problem is the classical case of Garbage In - Garbage Out. The vast majority of pages out there on the web have no logical structure, no text equivalent content to non-text content - there's no way a piece of technology can do that without an advanced form of AI.
This isn't a problem browser and assistive technology vendors can solve on their own. This isn't a problem web developers can solve on their own. Each have to pull their weight to get the job done. Web developers need to be using structured markup, and providing alternate equivalent content when content is inside a non-text format. Assistive technology vendors can then improve their tools to render your content in a better way to the tool user.
A website should work without JavaScript - that's the whole point of a webstandards based approach to website design. If a site requires JavaScript to provide access to data, it is fundamentally broken.
Its amusing that AJAX is promoted as a means for making websites more usable, but surely this should not be at the cost of its accessibility?
Nothing wrong with building AJAX based applications, just make sure you do it properly and offer the equivalent core functionality without requiring JavaScript. Its called progressive enhancement, or Hijax. (Note, drag and drop widgets are not core functionality, core functionality is about completing the task the website is intended for, e.g. purchasing a book.
Hmmm, thanks for the reminder. They are the ones that did the hatchet job on Pamela Jones of GrokLaw. I actually was scanning through the website above looking for a subscription to this "Ajax developer" this morning, couldn't find it (saw a reference to an AJAX article written by Maureen O'Gara - name was familiar, but I didn't remember why).
I was going to try again later. I guess not now. Thanks.
Quite right. What impresses me most about the Computer Science graduates from South Africa is the number of them working in the US, Canada, UK and the rest of Europe, and they are quite successful - and they are consistently impressive compared against similar graduates from the US and UK. Not to mention that US and UK institutions turn to Africa to hire people that their own education system cannot provide.
Even Nigeria produces outstanding quality of developers - Dare Obasanjo, once the XML Product Manager for Microsoft, now works on MSN spaces and Hotmail (and also the developer behind the RSS Aggregator RSS Bandit) - technically excellent.
And of course, Mark Shuttleworth, the brains behind Thawte - the first recognised SSL certificate provider (sold to Versign for millions after running for years from Cape Town). Been to space and back, and now the main driver behind Ubuntu, which is now recognised as one of the better Linux installations out there.
Even IBM UK are realising the technical proficiency of their operations in South Africa - they are in the process of migrating their mainframe support operations to South Africa. I've had the pleasure of working with these South Africans - these guys are very impressive.
Microsoft Nigeria's comments are laughable, but understandable in its prolonged and largely unsuccessful fight against Open Source.
Not without the RSS parser needing to guess whether the content is plain text or html. The existence of a less than sign or greater than sign is not a definitive sign that the content is HTML. The RSS2.0 specification makes no mention of how to handle content - it might be text, or it might be HTML (sorry, no XHTML).
When your parsing the feed and the content contains the following:
Is the content to be treated as plain text, or as HTML? Its very difficult to know, and even today RSS2.0 gives no way of allowing the author to specify. The aggregator has to guess. With Reuters, aggregators guessed wrongly.Can you show me your RDF parser? The extension handling mechanism is something I'm having a lot of problems getting my head around.
The Atom Syndication Format - the feed format - got signed off as a Proposed Standard last week. That means the RFC number is on the way. Its here. The publishing protocol still has some way to go yet.
The backbone on RSS1.0 extensibility is namespaces _and_ RDF, in that it can be merged with any other RDF vocabularies.
RSS2.0 is extensible via namespaces. For example, Microsoft's Simple List Extension to RSS 2.0.
I don't know how you've come to the conclusion that Atom is more complicated than RSS1.0, other than to say that you'd be the first person I've ever seen saying that.
RSS2.0 is simple up to a point - for instance if you are publishing plain text entries with no angle brackets then you should be okay (or if you don't mind silent data loss). If you want to mark up your content with XHTML, with RSS2.0 you are out of luck unless you define an extension, and then hope aggregator developers pick up on it and implement it.
Atom cleanly specifies how to have content as plain text, HTML, XHTML, XML, or even a different media format altogether. RSS2.0 leaves you with plain text, or HTML.
As I understand it, spammers make their money by charging business a fee for sending out spam on their behalf. That way, the spammer gets a prenegotiated upfront fee, and not a fee based on sales resulting from the spam.
I guess the problem is that businesses are falling for the myth that because spam is prevalent there must be sales in it - so they co-opt a spammer's services. How many businesses are repeat buyers of spam services?
According to the article, a joint statement included a statement from Richter that he is not a spammer. So why settle for $7 million? Is that a desperate move on Richter's part, or a result of a calculation that court costs would far outweight the paltry $7 million?