I am using standard HTML . All I care about is new lines and plaintext. Textarea works great for me. Except, when pasting content that is embedded in . This makes the Textarea uneditable, unless I delete the last line of the blockquote.
Example: http://jsfiddle.net/enf84xmj/1/
<textarea
autoCapitalize='sentences'
cols='69'
maxLength='1000'
minLength='1'
rows='1000'>
“One of us can be dismissed. Two of us can be ignored. But together, we are a movement and we are unstoppable.”
- Cecile Richards, president of Planned Parenthood Federation of America & Planned Parenthood Action Fund
In a surreal time when our hard-fought reproductive rights are in real peril, it is imperative that all-of-us stand strong and stand together in their defense.
To help Planned Parenthood launch its new project, UNSTOPPABLE, our Bay Area filmmaker friend and fellow activist Tiffany Shlain made a powerful short film called “Unstoppable Manifesto.” Hear what Tiffany had to share about her own personal experience and motivation:
“I grew up hearing stories from my late father, who, as a young surgeon, would try to save women in the emergency room after they were unable to get a safe abortion and ended up trying to do it themselves. In my early twenties, long before I was ready to have children, or had started my career or even met Ken, I became pregnant. I was in no way ready to become a mother, and was so grateful to be able to get a safe abortion. But even though I had a place to go, I still, like so many women, had to make my way through a line of protestors shouting terrible things at me, making what was already so difficult, worse.
</textarea>
I am trying to avoid adding a WYSIWYG editor and doing it using just HTML. Is it not possible?
As #chaska pointed out, the maxlength attribute was responsible for it and had nothing to do with the type of content being pasted
Related
We are working on making our eCommerce site accessible for screen readers and have a conflict about pricing. Our categories and product pages list multiple dollar amounts when a product is discounted:
Original Price (in strikethrough)
Discounted Price (what customer will actually pay)
Savings (orig - discounted)
Is there any standard way to communicate all of this information for visually impaired users? We don't want to omit anything but also want to avoid making the product listing too long to traverse.
Currently, VoiceOver reads our pricing as "price, $9.99" [TAB] "sale, $7.99" [TAB] "savings, $2"
We are considering relabeling this all to a single statement so that the user doesn't have to tab through each price. "was $9.99, now on sale for $7.99, save $2"
Would the above work, or is there a more standardized way to communicate this?
As far as I know, there is no real standard telling precisely how you should present the pricing information.
It's up to you to find the best formulation for your particular case.
As long as everything is clearly stated in text, it should be fine.
The thing you must absolutely avoid is giving (implicitly) an information only by its visual formatting.
For example, making a price striketrough without explicitly saying somewhere that this is the original price and that there is currently a discount creates an accessibility problem for screen reader users and those who may not see well the striketrough.
So basicly you are on the right track by indicating everything textually.
Now, personnally by experience as a screen reader user myself, starting from your example, I would say:
Give first the discounted price before the original price, because what I'm going to pay is the information I'm looking for in priority.
Be smart and give the complete information in a single concise sentance. Example: "$7.99 instead of $9.99, saving $2".
Don't give the saving first, as it can be easily perceved as an excessive marketing manipulation. Example: "Save 20%! $10 instead of $12" vs. "$10 instead of $12, save 20%!"
#QuentinC has some good advice on the order of information (most important first - the price you're going to pay) but one thing that bothers me in the OP is why the user is going to tab through all the prices. Are the prices interactive elements?
Or perhaps this is just a terminology issue. I think by tab, you really mean swipe right to move the VoiceOver focus.
One thing to consider if you decide to make it one big sentence, it makes it a little harder to parse all that information. A VoiceOver user can change their rotor to "words" and then swipe up/down to navigate a word at a time in order to hear the info, but it might not be the best user experience to force them to do so. But the fact that you're providing all this information is really the important part, so kudos to you.
Also, VoiceOver stops at element boundaries when you're swiping right so if you have something like:
<div>
<span>hello</span>
<s>there</s>
<span>world</span>
</div>
You're going to hear "hello" swipe right "there" swipe right "world".
If you just want to hear "hello there world" with one swipe, then you'll need the undocumented (and thus not officially supported) "text" role.
<div role="text">
<span>hello</span>
<s>there</s>
<span>world</span>
</div>
As a side note, even though <s> and <del> are semantic elements, their meaning is not conveyed to screen readers. One way to handle that is documented in a "Short note on making your mark (more accessible)".
Would the above work, or is there a more standardized way to communicate this?
You should avoid to disturb the attention by introducing too many informations to the screenreader.
I am not saying this is a standard solution, but a solution you have to consider is just to ignore the old price using aria-hidden:
$7.99 <div aria-hidden="true">($9.99)</div>
This way a screenreader user will only ear the new price, and really gain in accessibility. As the text is strike-through, I won't think that WCAG would require a speech alternative here.
I hope I do not break any rules of this website but posting a link to the issue is a necessity. I have copied the html from the source and tested in a local html file and it does not break. I can not work this out for the life of me.
If you look at the demo web page you can see where the text breaks throughout the whole site (it is a wordpress site if that helps).
Online Demo
Here is the html:
<h2>Our Core Values:</h2>
<strong>Relationship with God: </strong> This is our primary relationship. We were created to serve and give praise to our Creator, through our thoughts, words, and actions. When we do this, we experience the presence of God as our Heavenly Father and live in a joyful, intimate relationship with Him.
<strong>Relationship with Self:</strong> People are uniquely created in the image of God and thus have inherent worth and dignity. While we must remember that we are not God, we have the high calling of reflecting God’s being, making us superior to the rest of creation.
<strong>Relationship with Others:</strong> God created us to live in loving relationship with one another, and to encourage one another to use the gifts God has given to each of us to fulfill our calling.
<strong>Relationship with the rest of Creation:</strong> The cultural mandate of Gen 1:28-30 teaches that God created us to be stewards, people who understand, subdue and manage the world that God created in order to produce bounty. While God made the World ‘perfect’ He left it incomplete. God called humans to interact with creation to make possibilities into realities and to be able to sustain ourselves via the fruit of our stewardship. The economically poor are singled out in the Scriptures as being in a particularly desperate category and as needing very specific attention (Acts :-1:6-7)
<ul>
<li>Faith – God is our provider and equips in all He calls us to do.</li>
<li>The Great Commissions - We are called to make disciples of all nations (Matthew 28:19-20)</li>
<li>Relationship - The body of Christ is held together in relationship with the Lord and each other and self.</li>
<li>Partnership – The Lord never calls one person to work alone. A biblical, effective model of missionary involvement. Ministry partnerships should promote interdependence, not dependence.</li>
<li>Leadership – The five-fold gifts are meant to operate in the establishment and leading of the church.</li>
<li>Faithful stewardship and accountability are essential for successful ministry.</li>
Like I said this works fine if you copy the source into a local html page and test using WAMP.
Please I hope someone can help me with this and again if posting a link is against the rules I am sorry but as the issue is localised to this one instance I have no other choice.
Add this CSS
li { word-wrap: break-word; }
Your page http://kenyaaustraliamission.com/statement-of-faith/
is breaking out of the container because the spaces in the text are replaced with non-breaking space entity references
check the actual text in your WordPress Dashboard
We believe the Bible to be the inspired, only, infallible and authoritative Word of God
Your html problem please remove in p tag in your html code
Example is below
Now check to this answer
Your page is http://kenyaaustraliamission.com/statement-of-faith/ is breaking because its taking whole line as a single word and going out of div. This is due to non breaking space in each space.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am very well aware of the principles behind deprecating layout HTML like FONT, CENTER, etc., in favor of the more-or-less equivalent CSS.
But, in reading the extensive amount of verbiage on this over the years, I've never read anything about what this does to the teaching of HTML, especially to those new to the entire concept of computer languages, markup, and metadata.
I'm thinking of 4th and 5th graders, but there are many older people who fit this profile, too.
Suppose one of these kids wants to build a website with things that kids like, such as colors, font families and sizes, formatting, and so on?
In putting together a course for schoolchildren, I find they want to know about controlling presentation at about lesson 5, just after I've introduced paragraphs. But, this is no time to introduce CSS, as I haven't even gotten to attributes yet. Equal signs, colons, quotes, and brackets are still sea of confusing characters at this point.
Trying to teach:
<p style='text-align: center;'>
instead of
<center>
just doesn't work. The students get discouraged and the course grinds to a halt.
Worse, the two aren't equivalent, since the inline styles only apply to one tag, whereas the deprecated tag applies until ended. Introducing DIV to get around this is no real help, as it still suffers from taking the student down a complex path much too early.
OK, so there must be a question in here at some point, right? ;-)
How about this for a some questions:
Has anyone actually taught HTML to 4th and 5th graders without using deprecated tags?
Is anyone aware of any part of the various HTML standards development that included educational issues? (I'm not talking about education for highly motivated, somewhat technically-inclined adults here. I'm talking about HTML for kids and casual computer users.)
Is anyone out there willing to agree with me that teaching deprecated HTML is a way to lower the slope of the learning curve?
Reviewing in my mind the various reasons for deprecation, I can't see why, for example, deprecating CENTER is justified. While it has been removed from certain strict HTML standards, there will never be a browser that doesn't handle it. (Other than research tools.) While more powerful constructs exist, none of them are even close to as convenient to code. Thoughts on this issue?
(Please, no responses along the lines of "let beginners use WYSIWYG editors". These kids want to learn HTML, not just post some pretty content. There's a big difference.)
I first have to commend you on a bold mission. My wife is a 5th grade teacher and I have seen worlds of difference in one student's inability to spell their own name vs. some that can do serious math. To teach them html when they haven't even mastered basic spelling is a challenge I would not dare take. But that is not the point...
I am a professional web developer. I have tried to teach people (grown up interns at our firm) basic code before, but limited time prevents me from getting too involved in more technical details. Even they had a hard time "getting it" so to say. So it could be similar to a kind of curriculum. I would say this - for students in 4th or 5th grade only - basic deprecated html 4 is perfectly acceptable to teach. I would boilerplate a basic template because I can't imagine them understanding headers or anything like that.
Why is it acceptable? Because the odds are less than 1% will actually go on to do anything with it. If they do, they are competent enough to understand the progression of code and have little problems adapting to the real world environment. Anyhow, they may end up taking a CS course and figuring out what's happening behind the code. The rest of them will probably dismiss it and never look back.
Good luck. I am curious to see the results of this plan. Make a site and report the progress.
I'd argue that while more complicated to start with, the separation of content from style is a key concept for writing real web pages and if learnt early on would give anyone a huge advantage later if they were to continue with their learning rather than use deprecated techniques.
Would doing something using classes to replicate the basic style properties provided by these tags be that hard to teach?
<html>
<head>
<style type="text/css">
.center {text-align: center;}
.bold {font-weight: bold;}
.italic {font-style: italic;}
.big {font-size: 18;}
</style>
</head>
<body>
<p class="big center bold">
Hello world!
</p>
</body>
</html>
I guess as it's at such a young age, maybe it would. Although as Kai suggested you will need a boilerplate template to provide them anyway, so setting up a bunch of classes and placing all the formatting for a paragraph in one place (in the class attribute) is in my opinion easier to read and understand than having a whole lot of tags you have to remember to close.
Many users and forum programs in attempt to make automatic e-mail address harversting harder conseal them via obfuscation - # is replaced with "at" and . is replaced with "dot", so
team#stackoverflow.com
now becomes
team at stackoverflow dot com
I'm not an expert in regular expressions and I'm really curious - does such obfuscation really make automatic harvesting harder? Is it really much harder to automatically identify such obfuscated addresses?
Definitely!
I read this article a while ago which shows how effective (as well as the relative degree) the various methods can be.
Reversing an already reversed string seems to be fairly decent protection at the moment.
The following code sample:
<style type="text/css">
span.codedirection { unicode-bidi:bidi-override; direction: rtl; }
</style>
<p><span class="codedirection">moc.etalllit#7raboofnavlis</span></p>
Will output the email so it's readable at least.
That said, it is almost an arms race. But as long at you're ahead of the curve, it'll be more effort to harvest your address rather than ordinary un-obfuscated ones.
Obfuscation techniques falls in the same category than captchas. They are not reliable and tend to hurt regular users more than bots.
Javascript obfuscation seems to be praised, but is no silver bullet : it is not that hard today to automate a browser for email sniffing. If it can be displayed in a browser, it can be harvested. You could even imagine a bot that's taking screenshots of a browser window and using OCR to extract addresses to beat your million-dollar-obfuscation-technique.
Depending on where and why you want to obfuscate emails, those techniques could be useful :
Restrict email visibility : you may hide emails on your website/forum to anonymous users, to new users (with little to no activity or posts to date) or even hide them completely and replace email contact between members with a built-in private messaging feature.
Use a dedicated spam-filtered email : you will get spammed, but it will be limited to this particular address. This is a good trade-off when you need to expose the email address to any user.
Use a contact form : while bots are pretty good at filling forms, it turns out that they are too good at filling forms. Hidden field techniques can filter most of the spam coming through your contact form.
When I see this type of obfuscation I also immediately think of regular expressions. It's a piece of cake to harvest emails "obfuscated" in this manner.
I once came with an idea to publish my email address in this way:
You can mail me here:
string myEmail = "";
myEmail = myEmail
.Append ("myname")
.Append ("#")
.Append ("domain")
.Append (".")
.Append ("com");
Whoever does not make it out, has failed my basic intelligence test.
It will be difficult for the spammers as well as your users to identify the email address.
A nice article from wikipedia on Email obfuscation or address munging
One common way of hiding email from
bots and spammers is to create an
image containing the email address.
Facebook does this, for instance. Now,
using images for email is inherently
bad for accessibility, because text
readers will not be able to read it.
But even otherwise, there are several
free character recognition programs
that do a pretty good of decoding such
email-images.
From here
I'm not sure if it really helps with spam - but I've learned to love the Escape Encode Obfuscation for mailto: tags/emails. An example tag:
team#stackoverflow.com
Mails team#stackoverflow.com
It's analagous to putting a "protected by ADT" sticker on your front door.
Will that prevent a talented burglar from entering your house? Of course not.
Will it make the house next door with an unlocked door and an iPod in the window a more compelling target? Pretty likely.
A simple unobfuscated email scraper is going to get TONS of emails as it is. Maybe a very simple regex to pick up very common obfuscation methods is worth the effort. Past that, you're spending a lot of time trying to decipher an increasingly small percentage of emails.
All that to say, having some clever obfuscation is probably worth it.
For the record, my email has been on my public resume in plain text for years now, because I use gmail, which has a spam filter that works.
I was wondering why nobody mentioned ALAs solution so far.
Roel Van Gils wrote an Article about Graceful Email Obfuscation in 2007
Graceful Email Obfuscation is simply a JavaScript Email Obfuscation technique with a contact form fallback.
Email addresses are obfuscated by converting them into a url poiting to a contact form and applying a ROT13 transform
mailto:mail#example.com → contact/mail+example+com → contact/znvy+rknzcyr+pbz
Via javascript contact/znvy+rknzcyr+pbz is converted back to mailto:mail#example.com
If no javascript is available, the browser will open contact/znvy+rknzcyr+pbz as a fallback. The contact form will know where to send the email because of the url.
http://www.alistapart.com/articles/gracefulemailobfuscation/
It does make it harder but there are so many really smart scrapers that it probably doesn't help a lot, since the big spammers are using the high quality spam tools.
How to fight spamers? Make email address less recognizable for something without brain (i.e. computer).
Non-English speakers are your friends: if your user base is non-English speaking community, switch to obfuscating using other languages: team_małpa_stackoverlow_kropka_com or team_Affenschwanz_stackoverflow_Punkt_com are perfectly recognizable email addresses for respectively Polish- and German-speaking communities. Some email harvesters know Polish or German, but chance is most of harvesters will understand only English.
If you cannot leave English, than switch to some descriptive phrases- like: “in order to send us message write team in your address field, than put symbol AT, than write the name of our site!”.
To provide a literal answer, yes, harvesting obfuscated addresses is harder than harvesting standardized addresses. The real question is whether the extra effort will be put in by harvesters and if the (major? minor?) barrier to the harvesters is worth the possible problems for your users.
If you are going to scramble addresses or otherwise transpose them away from the standard form, you should avoid being consistent in how you do so – at least on the same site.
For example, if every email address on a large community site is reversed in the markup and rendered properly with CSS, or token-replaced (# becomes 'at'), or any other predictable method, the harvesters will just write a thin adapter for your site.
Think of it this way: if it only takes you one line of code to "scramble" them sitewide, it will only take the harvester one line of code to "unscramble" them for your site. Roughly speaking.
In my opinion, spam has become such a problem and so many DBs have been turned over that we're beyond hiding our addresses. Instead, consider looking at Defensio and Akismet, etc, to help classify and block spam.
I have a solution, well, more of a theory.
Problem is, the bots parse the page. they can get the text. even if it's being put
into the page in some sophisticated way through Javascript.
So, just you CSS3 pseudo element! it won't be a link, but your email will be visible, and will never be an actual text. something like this:
.email::after{ content:'myemail#gmail.com'; }
Again, it's a theory, I've no idea how far these evil people can go to get it, but I think this be pretty safe. (unless they parse the CSS files, which I don't think they do)
It does make it harder to a degree, but the simple ones used by users even today (the [dot] and [at]) are obsolete and can be captured easily using a simple regex by spammers.
Using something as simple as an image would be helpful and readable for the intended human reader without effort to 'decrypt' the encoded email id.
Contact email:
If you are still paranoid about character recognition equipped spam bots, them something like this would be effective.
It uses optical illusion as an advantage to complete letters in the human mind that cannot be easily understood by computer vision. Applying CAPCHA-like overlay can also help, but I doubt you need to go that far.
Does anyone know of a library or bit of code that converts British English to American English and vice versa?
I don't imagine there's too many differences (some examples that come to mind are doughnut/donut, colour/color, grey/gray, localised/localized) but it would be nice to be able to provide localised site content.
I've been working on one to convert US English to UK English. As I've discovered it's actually a lot harder to write something to convert the other way but I hope to get around to providing a reverse conversion one day.
This isn't perfect, but it's not a bad effort (even if I do say so myself). It'll convert most US spellings to UK ones but there are some words where UK English retains the US spelling (e.g. "program" where this refers to computer software). It won't convert words like pants to trousers because my main goal was simply to make the spelling uniform across the whole document.
There are also words such as practice and license where UK English uses either those or practise & licence, depending on whether the word's being used as a verb or a noun. For those two examples the conversion tool will highlight them and an explanatory note pops up on the lower left hand of your screen when you hover your mouse over them. All word patterns which are converted are underlined in red, and the output is shown in a side by side comparison with your original input.
It'll do quite large blocks of text quite quickly, but I prefer to go use it just for a couple of paragraphs at a time - copying them in from a Word doc.
It's still a work in progress so if anyone has any comments or suggestions then I'd appreciate feedback I can use to improve it.
http://www.us2uk.eu/
The difference between UK and US English is far greater than just a difference in spelling. There is also the hood/bonnet, sidewalk/pavement, pants/trousers idea.
Guess it depends how far you need to take it.
I looked forever to find a solution to this, but couldn't find one, so, I wrote my own bit of code for it, using a master list of ~20,000 different spellings that were freely available from the varcon project and the language experts at wordsworldwide:
https://github.com/HoldOffHunger/convert-british-to-american-spellings
Since I had two source lists, I used them each to crosscheck each other, and I found numerous errors and typos (varcon lists "preexistent"'s british equivalent as "preaexistent"). It is possible that I may have accidentally made typos, too, but, since I didn't do any wordsmithing here, I don't believe that to be the case.
Example:
require('AmericanBritishSpellings.php');
$american_british_spellings = new AmericanBritishSpellings();
$text = "Axiomatically ax that door, would you, my neighbour?";
$text = $american_british_spellings->SwapBritishSpellingsForAmericanSpellings(['text'=>$text]);
print($text); // output: Axiomatically axe that door, would you, my neighbor?
I think if you're thinking of converting from American English to British English, I personally wouldn't bother. Britain is very Americanised anyway, we accept silly yank spellings on the net :)
I had a similar problem recently. I discovered the following tool, called VarCon. I haven't tested it out, but I needed a rough converter for some text data. Here's an example.
echo "I apologise for my colourful tongue ." | ./translate british american
# >> I apologize for my colorful tongue .
It looks like it works for various dialects. Be sure to read the README and proceed with caution.
*note: This will only correct spelling variations.